Re: [Mesa-dev] [PATCH] i965: consider a 'base level' when calculating width0, height0, depth0

[andrey simiklit]

Hello,

The test for this issue is pushed to the piglit.
It would be great to push the mesa fix too if it is still an acceptable for
all :)

Thanks,
Andrii.
On Sat, Oct 20, 2018 at 12:29 PM andrey simiklit 
wrote:

> Hello,
>
> On Fri, Oct 19, 2018 at 15:14 Kenneth Graunke 
> wrote:
>
>> On Thursday, October 11, 2018 12:12:38 PM PDT Kenneth Graunke wrote:
>> > On Thursday, October 11, 2018 11:58:40 AM PDT Kenneth Graunke wrote:
>> > > On Tuesday, October 2, 2018 9:16:01 AM PDT asimiklit.w...@gmail.com
>> wrote:
>> > > > From: Andrii Simiklit 
>> > > >
>> > > > I guess that when we calculating the width0, height0, depth0
>> > > > to use for function 'intel_miptree_create' we need to consider
>> > > > the 'base level' like it is done in the
>> 'intel_miptree_create_for_teximage'
>> > > > function.
>> > > >
>> > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107987
>> > > > Signed-off-by: Andrii Simiklit 
>> > > > ---
>> > > >  .../drivers/dri/i965/intel_tex_validate.c | 26
>> ++-
>> > > >  1 file changed, 25 insertions(+), 1 deletion(-)
>> > >
>> > > I believe this patch is correct - we're assembling things into a new
>> > > miptree, which we start at level 0 - so we need the sizes for level 0.
>> > >
>> > > Alternatively, we might be able to pass validate_first_level instead
>> > > of 0 when calling intel_miptree_create, to make one that's only good
>> > > up until the new base...and have to re-assemble it the next time they
>> > > change the base.  It would save memory potentially.  But more copies.
>> > > I don't have a strong preference which is better.
>> > >
>> > > Please do make a Piglit or dEQP test for this.
>> > >
>> > > Reviewed-by: Kenneth Graunke 
>> >
>> > Sorry, withdrawing my review. :(  Chris Forbes pointed out on IRC that
>> > your reproducer case is backwards:
>> >
>> > miplevel 0 - 1x1
>> > miplevel 1 - 2x2
>> > miplevel 2 - 4x4
>> >
>> > That's upside down.  A proper miptree would have the base be largest:
>> >
>> > miplevel 0 - 4x4
>> > miplevel 1 - 2x2
>> > miplevel 2 - 1x1
>> >
>> > So, yes, I could see this tripping an assert...but such a crazy texture
>> > will never be mipmap complete.  If they're expecting mipmapping, then
>> > it seems like they should get a fallback black texture (which normally
>> > happens for incomplete textures).  If not, maybe they should get a
>> > single miplevel?  Either way, seems like we should detect insanity and
>> > bail, rather than change size calculations for the normal sane case.
>> >
>>
>> So...looked at this again.  I'm not sure why upside-down matters.
>>
>> At DrawArrays time, we have a single miplevel (base = 2), and are trying
>> to put that single miplevel's image into a miptree.  We do properly
>> ignore levels 0..1 as they're beyond the base.
>>
>> We appear to use level 0 as the actual base, and want to store our
>> single level at level 2.  Other places (TexImage) seem to work that way
>> too.
>>
>> But, we're creating the miplevel with level 0 as the base, but where
>> level 0 has the dimensions of level 2.  This doesn't work.  And your
>> patch fixes that.
>>
>> I tried making the actual base of the unified tree be level 2, rather
>> than level 0...so that the BaseLevel is the actual base...but tons of
>> things broke.
>>
>> So, back to Reviewed-by.  I think once we get a Piglit test, I'm happy
>> to land this patch.
>
>
> Thanks for reviewing :-) I will start to work on it as soon as come back
> from vacation (on Monday)
>
>
>>
>> --Ken
>
>
> Thanks,
> Andrii.
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] i965: consider a 'base level' when calculating width0, height0, depth0

[andrey simiklit]

Hello,

Could somebody help me with a push of the following patch?
https://patchwork.freedesktop.org/patch/254397

This fix is needed to fix these fails:
https://mesa-ci.01.org/global_logic/builds/56/group/ac3c5a0dc1f15492570367c6c8ec835c

When this fix is pushed we will be able to remove the following test:
tex-upside-down-miptree
from Intel CI "[expected-crashes]" sections.

Thanks,
Andrii.

On Mon, Jan 14, 2019 at 3:05 PM andrey simiklit 
wrote:

> Hello,
>
> The test for this issue is pushed to the piglit.
> It would be great to push the mesa fix too if it is still an acceptable
> for all :)
>
> Thanks,
> Andrii.
> On Sat, Oct 20, 2018 at 12:29 PM andrey simiklit 
> wrote:
>
>> Hello,
>>
>> On Fri, Oct 19, 2018 at 15:14 Kenneth Graunke 
>> wrote:
>>
>>> On Thursday, October 11, 2018 12:12:38 PM PDT Kenneth Graunke wrote:
>>> > On Thursday, October 11, 2018 11:58:40 AM PDT Kenneth Graunke wrote:
>>> > > On Tuesday, October 2, 2018 9:16:01 AM PDT asimiklit.w...@gmail.com
>>> wrote:
>>> > > > From: Andrii Simiklit 
>>> > > >
>>> > > > I guess that when we calculating the width0, height0, depth0
>>> > > > to use for function 'intel_miptree_create' we need to consider
>>> > > > the 'base level' like it is done in the
>>> 'intel_miptree_create_for_teximage'
>>> > > > function.
>>> > > >
>>> > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107987
>>> > > > Signed-off-by: Andrii Simiklit 
>>> > > > ---
>>> > > >  .../drivers/dri/i965/intel_tex_validate.c | 26
>>> ++-
>>> > > >  1 file changed, 25 insertions(+), 1 deletion(-)
>>> > >
>>> > > I believe this patch is correct - we're assembling things into a new
>>> > > miptree, which we start at level 0 - so we need the sizes for level
>>> 0.
>>> > >
>>> > > Alternatively, we might be able to pass validate_first_level instead
>>> > > of 0 when calling intel_miptree_create, to make one that's only good
>>> > > up until the new base...and have to re-assemble it the next time they
>>> > > change the base.  It would save memory potentially.  But more copies.
>>> > > I don't have a strong preference which is better.
>>> > >
>>> > > Please do make a Piglit or dEQP test for this.
>>> > >
>>> > > Reviewed-by: Kenneth Graunke 
>>> >
>>> > Sorry, withdrawing my review. :(  Chris Forbes pointed out on IRC that
>>> > your reproducer case is backwards:
>>> >
>>> > miplevel 0 - 1x1
>>> > miplevel 1 - 2x2
>>> > miplevel 2 - 4x4
>>> >
>>> > That's upside down.  A proper miptree would have the base be largest:
>>> >
>>> > miplevel 0 - 4x4
>>> > miplevel 1 - 2x2
>>> > miplevel 2 - 1x1
>>> >
>>> > So, yes, I could see this tripping an assert...but such a crazy texture
>>> > will never be mipmap complete.  If they're expecting mipmapping, then
>>> > it seems like they should get a fallback black texture (which normally
>>> > happens for incomplete textures).  If not, maybe they should get a
>>> > single miplevel?  Either way, seems like we should detect insanity and
>>> > bail, rather than change size calculations for the normal sane case.
>>> >
>>>
>>> So...looked at this again.  I'm not sure why upside-down matters.
>>>
>>> At DrawArrays time, we have a single miplevel (base = 2), and are trying
>>> to put that single miplevel's image into a miptree.  We do properly
>>> ignore levels 0..1 as they're beyond the base.
>>>
>>> We appear to use level 0 as the actual base, and want to store our
>>> single level at level 2.  Other places (TexImage) seem to work that way
>>> too.
>>>
>>> But, we're creating the miplevel with level 0 as the base, but where
>>> level 0 has the dimensions of level 2.  This doesn't work.  And your
>>> patch fixes that.
>>>
>>> I tried making the actual base of the unified tree be level 2, rather
>>> than level 0...so that the BaseLevel is the actual base...but tons of
>>> things broke.
>>>
>>> So, back to Reviewed-by.  I think once we get a Piglit test, I'm happy
>>> to land this patch.
>>
>>
>> Thanks for reviewing :-) I will start to work on it as soon as come back
>> from vacation (on Monday)
>>
>>
>>>
>>> --Ken
>>
>>
>> Thanks,
>> Andrii.
>>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] i965: consider a 'base level' when calculating width0, height0, depth0

[andrey simiklit]

ping. the piglit test was pushed)

Thanks,
Andrii.

On Tue, Jan 22, 2019 at 1:31 PM andrey simiklit 
wrote:

> Hello,
>
> Could somebody help me with a push of the following patch?
> https://patchwork.freedesktop.org/patch/254397
>
> This fix is needed to fix these fails:
>
> https://mesa-ci.01.org/global_logic/builds/56/group/ac3c5a0dc1f15492570367c6c8ec835c
>
> When this fix is pushed we will be able to remove the following test:
> tex-upside-down-miptree
> from Intel CI "[expected-crashes]" sections.
>
> Thanks,
> Andrii.
>
> On Mon, Jan 14, 2019 at 3:05 PM andrey simiklit 
> wrote:
>
>> Hello,
>>
>> The test for this issue is pushed to the piglit.
>> It would be great to push the mesa fix too if it is still an acceptable
>> for all :)
>>
>> Thanks,
>> Andrii.
>> On Sat, Oct 20, 2018 at 12:29 PM andrey simiklit <
>> asimiklit.w...@gmail.com> wrote:
>>
>>> Hello,
>>>
>>> On Fri, Oct 19, 2018 at 15:14 Kenneth Graunke 
>>> wrote:
>>>
>>>> On Thursday, October 11, 2018 12:12:38 PM PDT Kenneth Graunke wrote:
>>>> > On Thursday, October 11, 2018 11:58:40 AM PDT Kenneth Graunke wrote:
>>>> > > On Tuesday, October 2, 2018 9:16:01 AM PDT asimiklit.w...@gmail.com
>>>> wrote:
>>>> > > > From: Andrii Simiklit 
>>>> > > >
>>>> > > > I guess that when we calculating the width0, height0, depth0
>>>> > > > to use for function 'intel_miptree_create' we need to consider
>>>> > > > the 'base level' like it is done in the
>>>> 'intel_miptree_create_for_teximage'
>>>> > > > function.
>>>> > > >
>>>> > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107987
>>>> > > > Signed-off-by: Andrii Simiklit 
>>>> > > > ---
>>>> > > >  .../drivers/dri/i965/intel_tex_validate.c | 26
>>>> ++-
>>>> > > >  1 file changed, 25 insertions(+), 1 deletion(-)
>>>> > >
>>>> > > I believe this patch is correct - we're assembling things into a new
>>>> > > miptree, which we start at level 0 - so we need the sizes for level
>>>> 0.
>>>> > >
>>>> > > Alternatively, we might be able to pass validate_first_level instead
>>>> > > of 0 when calling intel_miptree_create, to make one that's only good
>>>> > > up until the new base...and have to re-assemble it the next time
>>>> they
>>>> > > change the base.  It would save memory potentially.  But more
>>>> copies.
>>>> > > I don't have a strong preference which is better.
>>>> > >
>>>> > > Please do make a Piglit or dEQP test for this.
>>>> > >
>>>> > > Reviewed-by: Kenneth Graunke 
>>>> >
>>>> > Sorry, withdrawing my review. :(  Chris Forbes pointed out on IRC that
>>>> > your reproducer case is backwards:
>>>> >
>>>> > miplevel 0 - 1x1
>>>> > miplevel 1 - 2x2
>>>> > miplevel 2 - 4x4
>>>> >
>>>> > That's upside down.  A proper miptree would have the base be largest:
>>>> >
>>>> > miplevel 0 - 4x4
>>>> > miplevel 1 - 2x2
>>>> > miplevel 2 - 1x1
>>>> >
>>>> > So, yes, I could see this tripping an assert...but such a crazy
>>>> texture
>>>> > will never be mipmap complete.  If they're expecting mipmapping, then
>>>> > it seems like they should get a fallback black texture (which normally
>>>> > happens for incomplete textures).  If not, maybe they should get a
>>>> > single miplevel?  Either way, seems like we should detect insanity and
>>>> > bail, rather than change size calculations for the normal sane case.
>>>> >
>>>>
>>>> So...looked at this again.  I'm not sure why upside-down matters.
>>>>
>>>> At DrawArrays time, we have a single miplevel (base = 2), and are trying
>>>> to put that single miplevel's image into a miptree.  We do properly
>>>> ignore levels 0..1 as they're beyond the base.
>>>>
>>>> We appear to use level 0 as the actual base, and want to store our
>>>> single level at level 2.  Other places (TexImage) seem to work that way
>>>> too.
>>>>
>>>> But, we're creating the miplevel with level 0 as the base, but where
>>>> level 0 has the dimensions of level 2.  This doesn't work.  And your
>>>> patch fixes that.
>>>>
>>>> I tried making the actual base of the unified tree be level 2, rather
>>>> than level 0...so that the BaseLevel is the actual base...but tons of
>>>> things broke.
>>>>
>>>> So, back to Reviewed-by.  I think once we get a Piglit test, I'm happy
>>>> to land this patch.
>>>
>>>
>>> Thanks for reviewing :-) I will start to work on it as soon as come back
>>> from vacation (on Monday)
>>>
>>>
>>>>
>>>> --Ken
>>>
>>>
>>> Thanks,
>>> Andrii.
>>>
>>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] i965: consider a 'base level' when calculating width0, height0, depth0

[andrey simiklit]

Thanks a lot)
Andrii.

On Fri, Feb 8, 2019 at 9:39 AM Kenneth Graunke 
wrote:

> On Thursday, February 7, 2019 3:35:01 AM PST andrey simiklit wrote:
> > ping. the piglit test was pushed)
> >
> > Thanks,
> > Andrii.
>
> I landed this today.  Thanks!
>
> --Ken
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 4/5] main: avoid 'may be used uninitialized' warnings

[andrey simiklit]

Hello,

Could somebody take a look at this old patch?

Thanks,
Andrii.

On Tue, Nov 13, 2018 at 6:41 PM Eric Engestrom 
wrote:

> On Tuesday, 2018-11-13 14:19:31 +0200, asimiklit.w...@gmail.com wrote:
> > From: Andrii Simiklit 
> >
> > 1. main/texcompress_etc.c:1314:12:
> > warning: ‘*((void *)&dst+2)’ may be used uninitialized in this
> function
> > 2. main/texcompress_etc.c:1354:12:
> > warning: ‘*((void *)&dst+2)’ may be used uninitialized in this
> function
> > 3. main/texcompress_etc.c:1293:12:
> > warning: ‘dst’ may be used uninitialized in this function
> > 4. main/texcompress_etc.c:1335:12:
> > warning: ‘dst’ may be used uninitialized in this function
> > 5. main/texcompress_etc.c:1460:12:
> > warning: ‘*((void *)&dst+1)’ may be used uninitialized in this
> function
> >
> > v2: Fixed by adding the unreachable case to the etc2_rgb8_fetch_texel
> >( Eric Engestrom  )
> > Changes for warning 'pixerrorcolorbest' were removed.
> >
> > Signed-off-by: Andrii Simiklit 
>
> This is the right way of fixing this code-wise, but I'm not 100% sure we
> can actually guarantee this logic-wise, so I'll let someone else review
> (and push) this patch.
>
> Acked-by: Eric Engestrom 
>
> > ---
> >  src/mesa/main/texcompress_etc.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/src/mesa/main/texcompress_etc.c
> b/src/mesa/main/texcompress_etc.c
> > index b39ab33d36..f1da4d0f11 100644
> > --- a/src/mesa/main/texcompress_etc.c
> > +++ b/src/mesa/main/texcompress_etc.c
> > @@ -548,6 +548,7 @@ etc2_rgb8_fetch_texel(const struct etc2_block *block,
> >if (punchthrough_alpha)
> >   dst[3] = 255;
> > }
> > +   else unreachable("unhandled block mode");
> >  }
> >
> >  static void
> > --
> > 2.17.1
> >
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] Fix 105399 bug GPU hang on SNB using geometry shader. The end of thread (EOT) message with flags Complete=1 and Used=0 will leads to GPU hang on SNB and ILK when GS does not all

[andrey simiklit]

Hello,

Thanks for a fast feedback.
I have created new patch:
"i965/gen6/gs: Handle case where a GS doesn't allocate VUE"
which contains all fixes.

Regards,
Andrii.

On Tue, Jun 19, 2018 at 3:16 PM, Iago Toral  wrote:

> Hi Andrii,
>
> thanks for the fix!
>
> Kenneth, this patch makes it so that we end the GS program with and
> ENDIF. I remember that back in the day when I wrote this code you had
> concerns about that (that's why I added that comment), but that was a
> long time ago so maybe things have changed, do you know if this is
> still something that we should avoid?
>
> Andrii: limit the subject line (the one that shows up in the subject of
> the e-mail starting after "[PATCH]" small enough to fit in 80
> characters. I do a quick review of the patch inline below and will do a
> more thorough review tomorrow.
>
> On Tue, 2018-06-19 at 11:31 +0300, Andrii Simiklit wrote:
> > We can not use the VUE Dereference flags combination for EOT
> > message under ILK and SNB because the threads are not initialized
> > there with initial VUE handle unlike Pre-IL.
> > So to avoid GPU hangs on SNB and ILK we need
> > to avoid usage of the VUE Dereference flags combination.
> > (Was tested only on SNB but according to specification
> > https://01.org/sites/default/files/documentation/snb_ihd_os_vol2_part
> > 1_0.pdf
> > sections: 1.6.5.3, 1.6.5.6
> > the ILK must behave itself in the similar way)
> >
> > Signed-off-by: Andrii Simiklit 
>
> Add:
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105399
>
> > ---
> >  src/intel/compiler/gen6_gs_visitor.cpp | 53
> > ++
> >  1 file changed, 47 insertions(+), 6 deletions(-)
> >
> > diff --git a/src/intel/compiler/gen6_gs_visitor.cpp
> > b/src/intel/compiler/gen6_gs_visitor.cpp
> > index 66c69fb..2143fd2 100644
> > --- a/src/intel/compiler/gen6_gs_visitor.cpp
> > +++ b/src/intel/compiler/gen6_gs_visitor.cpp
> > @@ -300,10 +300,11 @@ gen6_gs_visitor::emit_urb_write_opcode(bool
> > complete, int base_mrf,
> >/* Otherwise we always request to allocate a new VUE handle.
> > If this is
> > * the last write before the EOT message and the new handle
> > never gets
> > * used it will be dereferenced when we send the EOT message.
> > This is
> > -   * necessary to avoid different setups for the EOT message
> > (one for the
> > +   * necessary to avoid different setups (under Pre-IL only) for
> > the EOT message (one for the
> > * case when there is no output and another for the case when
> > there is)
> > * which would require to end the program with an
> > IF/ELSE/ENDIF block,
> > -   * something we do not want.
> > +   * something we do not want.
> > +   * But for ILK and SNB we can not avoid the end the program
> > with an IF/ELSE/ENDIF block.
> > */
>
> Limit lines to 80 characters long.
>
> >inst = emit(GS_OPCODE_URB_WRITE_ALLOCATE);
> >inst->urb_write_flags = BRW_URB_WRITE_COMPLETE;
> > @@ -449,8 +450,12 @@ gen6_gs_visitor::emit_thread_end()
> >if (prog->info.has_transform_feedback_varyings)
> >   xfb_write();
> > }
> > -   emit(BRW_OPCODE_ENDIF);
> > -
> > +   enum { GEN5_ILK = 5 };
> > +   const bool common_eot_approach_can_be_used = (devinfo->gen <
> > GEN5_ILK);
>
> devinfo->gen < 5 is fine, we do that everywhere in the driver.
>
> > +   if(common_eot_approach_can_be_used)
> > +   {
> > +  emit(BRW_OPCODE_ENDIF);
> > +   }
> > /* Finally, emit EOT message.
> >  *
> >  * In gen6 we need to end the thread differently depending on
> > whether we have
> > @@ -463,8 +468,30 @@ gen6_gs_visitor::emit_thread_end()
> >  * VUE handle every time we do a URB WRITE, even for the last
> > vertex we emit.
> >  * With this we make sure that whether we have emitted at least
> > one vertex
> >  * or none at all, we have to finish the thread without writing
> > to the URB,
> > -* which works for both cases by setting the COMPLETE and UNUSED
> > flags in
> > +* which works for both cases (but only under Pre-IL) by setting
> > the COMPLETE and UNUSED flags in
> >  * the EOT message.
> > +*
> > +* But under ILK or SNB we must not use combination COMPLETE and
> > UNUSED
> > +* because this combination could be used only for already
> > allocated VUE.
> > +* But unlike Pre-IL in the ILK and SNB the initial VUE is not
> > passed to threads.
> > +* This behaver mentioned in specification:
> > +* SNB (gen6) Spec:
> > https://01.org/sites/default/files/documentation/snb_ihd_os_vol2_part
> > 1_0.pdf
>
> I think you can drop the URL, mentioning the specific section of the
> PRM with the relevant text is sufficient.
>
> > +*1.6.5.3 VUE Allocation (GS, CLIP) [DevIL]
> > +*1.6.5.4 VUE Allocation (GS) [DevSNB+]
>
> We usually write PRM citations with quotes.
>
> > +*   The threads are not passed an initial handle.
> > +*   Instead, they request a first handle (if any)

Re: [Mesa-dev] [PATCH 2/2] i965/gen6/gs: Handle case where a GS doesn't allocate VUE

[andrey simiklit]

HI all,

Sorry, just ignore this patch with incorrect subject.
I will send correct one shortly.

Regards,
Andrii.

On Thu, Jun 21, 2018 at 4:12 PM, Andrii Simiklit 
wrote:

> We can not use the VUE Dereference flags combination for EOT
> message under ILK and SNB because the threads are not initialized
> there with initial VUE handle unlike Pre-IL.
> So to avoid GPU hangs on SNB and ILK we need
> to avoid usage of the VUE Dereference flags combination.
> (Was tested only on SNB but according to the specification
> SNB Volume 2 Part 1: 1.6.5.3, 1.6.5.6
> the ILK must behave itself in the similar way)
>
> v2: Approach to fix this issue was changed.
> Instead of different EOT flags in the program end
> we will create VUE every time even if GS produces no output.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105399
>
> Signed-off-by: Andrii Simiklit 
> ---
>  src/intel/compiler/gen6_gs_visitor.cpp | 88
> +-
>  1 file changed, 23 insertions(+), 65 deletions(-)
>
> diff --git a/src/intel/compiler/gen6_gs_visitor.cpp
> b/src/intel/compiler/gen6_gs_visitor.cpp
> index ac3ba55..b831d33 100644
> --- a/src/intel/compiler/gen6_gs_visitor.cpp
> +++ b/src/intel/compiler/gen6_gs_visitor.cpp
> @@ -300,11 +300,10 @@ gen6_gs_visitor::emit_urb_write_opcode(bool
> complete, int base_mrf,
>/* Otherwise we always request to allocate a new VUE handle. If
> this is
> * the last write before the EOT message and the new handle never
> gets
> * used it will be dereferenced when we send the EOT message. This
> is
> -   * necessary to avoid different setups (under Pre-IL only) for the
> EOT message (one for the
> +   * necessary to avoid different setups for the EOT message (one for
> the
> * case when there is no output and another for the case when there
> is)
> * which would require to end the program with an IF/ELSE/ENDIF
> block,
> -   * something we do not want.
> -   * But for ILK and SNB we can not avoid the end the program with an
> IF/ELSE/ENDIF block.
> +   * something we do not want.
> */
>inst = emit(GS_OPCODE_URB_WRITE_ALLOCATE);
>inst->urb_write_flags = BRW_URB_WRITE_COMPLETE;
> @@ -351,27 +350,27 @@ gen6_gs_visitor::emit_thread_end()
> int max_usable_mrf = FIRST_SPILL_MRF(devinfo->gen);
>
> /* Issue the FF_SYNC message and obtain the initial VUE handle. */
> -   emit(CMP(dst_null_ud(), this->vertex_count, brw_imm_ud(0u),
> BRW_CONDITIONAL_G));
> -   emit(IF(BRW_PREDICATE_NORMAL));
> -   {
> -  this->current_annotation = "gen6 thread end: ff_sync";
> +   this->current_annotation = "gen6 thread end: ff_sync";
>
> -  vec4_instruction *inst;
> -  if (prog->info.has_transform_feedback_varyings) {
> +   vec4_instruction *inst = NULL;
> +   if (prog->info.has_transform_feedback_varyings) {
>   src_reg sol_temp(this, glsl_type::uvec4_type);
>   emit(GS_OPCODE_FF_SYNC_SET_PRIMITIVES,
> -  dst_reg(this->svbi),
> -  this->vertex_count,
> -  this->prim_count,
> -  sol_temp);
> +   dst_reg(this->svbi),
> +   this->vertex_count,
> +   this->prim_count,
> +   sol_temp);
>   inst = emit(GS_OPCODE_FF_SYNC,
>   dst_reg(this->temp), this->prim_count, this->svbi);
> -  } else {
> +   } else {
>   inst = emit(GS_OPCODE_FF_SYNC,
>   dst_reg(this->temp), this->prim_count,
> brw_imm_ud(0u));
> -  }
> -  inst->base_mrf = base_mrf;
> +   }
> +   inst->base_mrf = base_mrf;
>
> +   emit(CMP(dst_null_ud(), this->vertex_count, brw_imm_ud(0u),
> BRW_CONDITIONAL_G));
> +   emit(IF(BRW_PREDICATE_NORMAL));
> +   {
>/* Loop over all buffered vertices and emit URB write messages */
>this->current_annotation = "gen6 thread end: urb writes init";
>src_reg vertex(this, glsl_type::uint_type);
> @@ -415,7 +414,7 @@ gen6_gs_visitor::emit_thread_end()
> dst_reg reg = dst_reg(MRF, mrf);
> reg.type = output_reg[varying][0].type;
> data.type = reg.type;
> -   vec4_instruction *inst = emit(MOV(reg, data));
> +   inst = emit(MOV(reg, data));
> inst->force_writemask_all = true;
>
> mrf++;
> @@ -450,11 +449,8 @@ gen6_gs_visitor::emit_thread_end()
>if (prog->info.has_transform_feedback_varyings)
>   xfb_write();
> }
> -   const bool common_eot_approach_can_be_used = (devinfo->gen < 5);
> -   if(common_eot_approach_can_be_used)
> -   {
> -  emit(BRW_OPCODE_ENDIF);
> -   }
> +   emit(BRW_OPCODE_ENDIF);
> +
> /* Finally, emit EOT message.
>  *
>  * In gen6 we need to end the thread differently depending on whether
> we have
> @@ -464,35 +460,11 @@ gen6_gs_visitor::emit_thread_end()
>  *
>  * However, this would lead us to end the program with an ENDIF opcode,
>  * which we wan

Re: [Mesa-dev] [PATCH] i965/batch: don't ignore the 'brw_new_batch' call for a 'new batch'

[andrey simiklit]

Hi all,

The bug for this issue was created:
https://bugs.freedesktop.org/show_bug.cgi?id=107626

Regards,
Andrii.


On Mon, Aug 20, 2018 at 5:43 PM,  wrote:

> From: Andrii Simiklit 
>
> If we restore the 'new batch' using 'intel_batchbuffer_reset_to_saved'
> function we must restore the default state of the batch using
> 'brw_new_batch' function because the 'intel_batchbuffer_flush'
> function will not do it for the 'new batch' again.
> At least the following fields of the batch
> 'state_base_address_emitted','aperture_space', 'state_used'
> should be restored to default values to avoid:
> 1. the aperture_space overflow
> 2. the missed STATE_BASE_ADDRESS commad in the batch
> 3. the memory overconsumption of the 'statebuffer'
>due to uncleared 'state_used' field.
> etc.
>
> Signed-off-by: Andrii Simiklit 
> ---
>  src/mesa/drivers/dri/i965/intel_batchbuffer.c | 104
> +++---
>  1 file changed, 59 insertions(+), 45 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> index 65d2c64..b8c5fb4 100644
> --- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> +++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> @@ -219,7 +219,7 @@ add_exec_bo(struct intel_batchbuffer *batch, struct
> brw_bo *bo)
> bo->index = batch->exec_count;
> batch->exec_bos[batch->exec_count] = bo;
> batch->aperture_space += bo->size;
> -
> +   assert((batch->aperture_space >= 0) && "error 'batch->aperture_space'
> field is overflown!");
> return batch->exec_count++;
>  }
>
> @@ -290,6 +290,51 @@ intel_batchbuffer_reset_and_clear_render_cache(struct
> brw_context *brw)
> brw_cache_sets_clear(brw);
>  }
>
> +/**
> + * Called when starting a new batch buffer.
> + */
> +static void
> +brw_new_batch(struct brw_context *brw)
> +{
> +   /* Unreference any BOs held by the previous batch, and reset counts. */
> +   for (int i = 0; i < brw->batch.exec_count; i++) {
> +  brw_bo_unreference(brw->batch.exec_bos[i]);
> +  brw->batch.exec_bos[i] = NULL;
> +   }
> +   brw->batch.batch_relocs.reloc_count = 0;
> +   brw->batch.state_relocs.reloc_count = 0;
> +   brw->batch.exec_count = 0;
> +   brw->batch.aperture_space = 0;
> +
> +   brw_bo_unreference(brw->batch.state.bo);
> +
> +   /* Create a new batchbuffer and reset the associated state: */
> +   intel_batchbuffer_reset_and_clear_render_cache(brw);
> +
> +   /* If the kernel supports hardware contexts, then most hardware state
> is
> +* preserved between batches; we only need to re-emit state that is
> required
> +* to be in every batch.  Otherwise we need to re-emit all the state
> that
> +* would otherwise be stored in the context (which for all intents and
> +* purposes means everything).
> +*/
> +   if (brw->hw_ctx == 0) {
> +  brw->ctx.NewDriverState |= BRW_NEW_CONTEXT;
> +  brw_upload_invariant_state(brw);
> +   }
> +
> +   brw->ctx.NewDriverState |= BRW_NEW_BATCH;
> +
> +   brw->ib.index_size = -1;
> +
> +   /* We need to periodically reap the shader time results, because
> rollover
> +* happens every few seconds.  We also want to see results every once
> in a
> +* while, because many programs won't cleanly destroy our context, so
> the
> +* end-of-run printout may not happen.
> +*/
> +   if (INTEL_DEBUG & DEBUG_SHADER_TIME)
> +  brw_collect_and_report_shader_time(brw);
> +}
> +
>  void
>  intel_batchbuffer_save_state(struct brw_context *brw)
>  {
> @@ -311,6 +356,19 @@ intel_batchbuffer_reset_to_saved(struct brw_context
> *brw)
> brw->batch.exec_count = brw->batch.saved.exec_count;
>
> brw->batch.map_next = brw->batch.saved.map_next;
> +   if (USED_BATCH(brw->batch) == 0)
> +   {
> +  /**
> +   * The 'intel_batchbuffer_flush' function will not call
> +   * the 'brw_new_batch' function when the USED_BATCH returns 0.
> +   * It may leads to the few following issue:
> +   * The 'aperture_space' field can be overflown
> +   * The 'statebuffer' buffer contains the big unused space
> +   * The STATE_BASE_ADDRESS message is missed
> +   * etc
> +   **/
> +  brw_new_batch(brw);
> +   }
>  }
>
>  void
> @@ -529,50 +587,6 @@ intel_batchbuffer_require_space(struct brw_context
> *brw, GLuint sz)
> }
>  }
>
> -/**
> - * Called when starting a new batch buffer.
> - */
> -static void
> -brw_new_batch(struct brw_context *brw)
> -{
> -   /* Unreference any BOs held by the previous batch, and reset counts. */
> -   for (int i = 0; i < brw->batch.exec_count; i++) {
> -  brw_bo_unreference(brw->batch.exec_bos[i]);
> -  brw->batch.exec_bos[i] = NULL;
> -   }
> -   brw->batch.batch_relocs.reloc_count = 0;
> -   brw->batch.state_relocs.reloc_count = 0;
> -   brw->batch.exec_count = 0;
> -   brw->batch.aperture_space = 0;
> -
> -   brw_bo_unreference(brw->batch.state.bo);
> -
> -   /* Create a new batchbuffer and reset the associated state: */
> -   intel_batchbuffer_reset_and_clear_rend

Re: [Mesa-dev] [PATCH] i965/batch: don't ignore the 'brw_new_batch' call for a 'new batch'

[andrey simiklit]

Hi all,

It would be great if somebody look at this.
I guess that this issue can affect every place where we use
'intel_batchbuffer_save_state/intel_batchbuffer_reset_to_saved' but only
when the 'brw_batch_has_aperture_space' function returns false several
times in a row.
Pay attention that the last batch
<https://bugs.freedesktop.org/attachment.cgi?id=141200> of log has an
aperture with negative value "(-1023.8Mb aperture)".
Please correct me if I am incorrect.

Regards,
Andrii.
On Tue, Aug 21, 2018 at 3:00 PM andrey simiklit 
wrote:

> Hi all,
>
> The bug for this issue was created:
> https://bugs.freedesktop.org/show_bug.cgi?id=107626
>
> Regards,
> Andrii.
>
>
> On Mon, Aug 20, 2018 at 5:43 PM,  wrote:
>
>> From: Andrii Simiklit 
>>
>> If we restore the 'new batch' using 'intel_batchbuffer_reset_to_saved'
>> function we must restore the default state of the batch using
>> 'brw_new_batch' function because the 'intel_batchbuffer_flush'
>> function will not do it for the 'new batch' again.
>> At least the following fields of the batch
>> 'state_base_address_emitted','aperture_space', 'state_used'
>> should be restored to default values to avoid:
>> 1. the aperture_space overflow
>> 2. the missed STATE_BASE_ADDRESS commad in the batch
>> 3. the memory overconsumption of the 'statebuffer'
>>due to uncleared 'state_used' field.
>> etc.
>>
>> Signed-off-by: Andrii Simiklit 
>> ---
>>  src/mesa/drivers/dri/i965/intel_batchbuffer.c | 104
>> +++---
>>  1 file changed, 59 insertions(+), 45 deletions(-)
>>
>> diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
>> b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
>> index 65d2c64..b8c5fb4 100644
>> --- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
>> +++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
>> @@ -219,7 +219,7 @@ add_exec_bo(struct intel_batchbuffer *batch, struct
>> brw_bo *bo)
>> bo->index = batch->exec_count;
>> batch->exec_bos[batch->exec_count] = bo;
>> batch->aperture_space += bo->size;
>> -
>> +   assert((batch->aperture_space >= 0) && "error 'batch->aperture_space'
>> field is overflown!");
>> return batch->exec_count++;
>>  }
>>
>> @@ -290,6 +290,51 @@
>> intel_batchbuffer_reset_and_clear_render_cache(struct brw_context *brw)
>> brw_cache_sets_clear(brw);
>>  }
>>
>> +/**
>> + * Called when starting a new batch buffer.
>> + */
>> +static void
>> +brw_new_batch(struct brw_context *brw)
>> +{
>> +   /* Unreference any BOs held by the previous batch, and reset counts.
>> */
>> +   for (int i = 0; i < brw->batch.exec_count; i++) {
>> +  brw_bo_unreference(brw->batch.exec_bos[i]);
>> +  brw->batch.exec_bos[i] = NULL;
>> +   }
>> +   brw->batch.batch_relocs.reloc_count = 0;
>> +   brw->batch.state_relocs.reloc_count = 0;
>> +   brw->batch.exec_count = 0;
>> +   brw->batch.aperture_space = 0;
>> +
>> +   brw_bo_unreference(brw->batch.state.bo);
>> +
>> +   /* Create a new batchbuffer and reset the associated state: */
>> +   intel_batchbuffer_reset_and_clear_render_cache(brw);
>> +
>> +   /* If the kernel supports hardware contexts, then most hardware state
>> is
>> +* preserved between batches; we only need to re-emit state that is
>> required
>> +* to be in every batch.  Otherwise we need to re-emit all the state
>> that
>> +* would otherwise be stored in the context (which for all intents and
>> +* purposes means everything).
>> +*/
>> +   if (brw->hw_ctx == 0) {
>> +  brw->ctx.NewDriverState |= BRW_NEW_CONTEXT;
>> +  brw_upload_invariant_state(brw);
>> +   }
>> +
>> +   brw->ctx.NewDriverState |= BRW_NEW_BATCH;
>> +
>> +   brw->ib.index_size = -1;
>> +
>> +   /* We need to periodically reap the shader time results, because
>> rollover
>> +* happens every few seconds.  We also want to see results every once
>> in a
>> +* while, because many programs won't cleanly destroy our context, so
>> the
>> +* end-of-run printout may not happen.
>> +*/
>> +   if (INTEL_DEBUG & DEBUG_SHADER_TIME)
>> +  brw_collect_and_report_shader_time(brw);
>> +}
>> +
>>  void
>>  intel_batchbuffer_save_state(s

Re: [Mesa-dev] [PATCH] i965/gen6/xfb: handle case where transform feedback is not active

[andrey simiklit]

Hi all,

Could somebody push it if it seems good for all?

Regards,
Andrii.

On Thu, Aug 23, 2018 at 4:53 PM Samuel Iglesias Gonsálvez <
sigles...@igalia.com> wrote:

> The patch seems fine to me. I also tested it on Intel CI and there were no
> regressions.
>
> Reviewed-by: Samuel Iglesias Gonsálvez 
> 
> Thanks,
>
> Sam
>
> On 15/08/18 17:20, asimiklit.w...@gmail.com wrote:
>
> From: Andrii Simiklit  
>
> When the SVBI Payload Enable is false I guess the register R1.4
> which contains the Maximum Streamed Vertex Buffer Index is filled by zero
> and GS stops to write transform feedback when the transform feedback
> is not active.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107579
> Signed-off-by: Andrii Simiklit  
> 
> ---
>  src/mesa/drivers/dri/i965/genX_state_upload.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/mesa/drivers/dri/i965/genX_state_upload.c 
> b/src/mesa/drivers/dri/i965/genX_state_upload.c
> index ea5ad55..0f82500 100644
> --- a/src/mesa/drivers/dri/i965/genX_state_upload.c
> +++ b/src/mesa/drivers/dri/i965/genX_state_upload.c
> @@ -2806,7 +2806,7 @@ genX(upload_gs_state)(struct brw_context *brw)
>  #if GEN_GEN < 7
>   gs.SOStatisticsEnable = true;
>   if (gs_prog->info.has_transform_feedback_varyings)
> -gs.SVBIPayloadEnable = true;
> +gs.SVBIPayloadEnable = _mesa_is_xfb_active_and_unpaused(ctx);
>
>   /* GEN6_GS_SPF_MODE and GEN6_GS_VECTOR_MASK_ENABLE are enabled as it
>* was previously done for gen6.
>
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] i965/gen6/xfb: handle case where transform feedback is not active

[andrey simiklit]

Hello,

Thanks a lot)

Regards,
Andrii.

On Tue, Aug 28, 2018 at 4:35 PM Samuel Iglesias Gonsálvez <
sigles...@igalia.com> wrote:

> On Tuesday, August 28, 2018 2:02:07 PM CEST Samuel Iglesias Gonsálvez
> wrote:
> > I'll do it later today.
>
> Done!
>
> Sam
>
> >
> > Thanks for contributing!
> >
> > Sam
> >
> > On 28/08/18 13:59, andrey simiklit wrote:
> > > Hi all,
> > >
> > > Could somebody push it if it seems good for all?
> > >
> > > Regards,
> > > Andrii.
> > >
> > > On Thu, Aug 23, 2018 at 4:53 PM Samuel Iglesias Gonsálvez
> > >
> > > mailto:sigles...@igalia.com>> wrote:
> > > The patch seems fine to me. I also tested it on Intel CI and there
> > > were no regressions.
> > >
> > > Reviewed-by: Samuel Iglesias Gonsálvez 
> > > <mailto:sigles...@igalia.com>
> > >
> > > Thanks,
> > >
> > > Sam
> > >
> > > On 15/08/18 17:20, asimiklit.w...@gmail.com
> > >
> > > <mailto:asimiklit.w...@gmail.com> wrote:
> > >> From: Andrii Simiklit 
> > >> <mailto:asimiklit.w...@gmail.com>
> > >>
> > >> When the SVBI Payload Enable is false I guess the register R1.4
> > >> which contains the Maximum Streamed Vertex Buffer Index is filled
> by
> > >> zero
> > >> and GS stops to write transform feedback when the transform
> feedback
> > >> is not active.
> > >>
> > >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107579
> > >> Signed-off-by: Andrii Simiklit 
> > >> <mailto:andrii.simik...@globallogic.com>
> > >> ---
> > >>
> > >>  src/mesa/drivers/dri/i965/genX_state_upload.c | 2 +-
> > >>  1 file changed, 1 insertion(+), 1 deletion(-)
> > >>
> > >> diff --git a/src/mesa/drivers/dri/i965/genX_state_upload.c
> > >> b/src/mesa/drivers/dri/i965/genX_state_upload.c index
> > >> ea5ad55..0f82500 100644
> > >> --- a/src/mesa/drivers/dri/i965/genX_state_upload.c
> > >> +++ b/src/mesa/drivers/dri/i965/genX_state_upload.c
> > >> @@ -2806,7 +2806,7 @@ genX(upload_gs_state)(struct brw_context
> *brw)
> > >>
> > >>  #if GEN_GEN < 7
> > >>
> > >>   gs.SOStatisticsEnable = true;
> > >>   if (gs_prog->info.has_transform_feedback_varyings)
> > >>
> > >> -gs.SVBIPayloadEnable = true;
> > >> +gs.SVBIPayloadEnable =
> > >> _mesa_is_xfb_active_and_unpaused(ctx);
> > >>
> > >>   /* GEN6_GS_SPF_MODE and GEN6_GS_VECTOR_MASK_ENABLE are
> > >>   enabled as it
> > >>
> > >>* was previously done for gen6.
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v3] intel/decoder: fix the possible out of bounds group_iter

[andrey simiklit]

Hi all,

Could somebody push this small patch to mesa?

Regards,
Andrii.
On Mon, Aug 20, 2018 at 9:13 PM Lionel Landwerlin <
lionel.g.landwer...@intel.com> wrote:

> On 20/08/2018 17:20, asimiklit.w...@gmail.com wrote:
> > From: Andrii Simiklit 
> >
> > The "gen_group_get_length" function can return a negative value
> > and it can lead to the out of bounds group_iter.
> >
> > v2: printing of "unknown command type" was added
> > v3: just the asserts are added
> >
> > Signed-off-by: Andrii Simiklit 
>
> Reviewed-by: Lionel Landwerlin 
>
> Somebody should take a look at the other patches I sent out ;)
> Thanks!
>
> -
> Lionel
> > ---
> >   src/intel/common/gen_decoder.c | 5 -
> >   1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/intel/common/gen_decoder.c
> b/src/intel/common/gen_decoder.c
> > index ec0a486..2d9609a 100644
> > --- a/src/intel/common/gen_decoder.c
> > +++ b/src/intel/common/gen_decoder.c
> > @@ -803,8 +803,10 @@ static bool
> >   iter_more_groups(const struct gen_field_iterator *iter)
> >   {
> >  if (iter->group->variable) {
> > +  int length = gen_group_get_length(iter->group, iter->p);
> > +  assert(length >= 0 && "error the length is unknown!");
> > return iter_group_offset_bits(iter, iter->group_iter + 1) <
> > -  (gen_group_get_length(iter->group, iter->p) * 32);
> > +  (length * 32);
> >  } else {
> > return (iter->group_iter + 1) < iter->group->group_count ||
> >iter->group->next != NULL;
> > @@ -991,6 +993,7 @@ gen_field_iterator_init(struct gen_field_iterator
> *iter,
> >  iter->p_bit = p_bit;
> >
> >  int length = gen_group_get_length(iter->group, iter->p);
> > +   assert(length >= 0 && "error the length is unknown!");
> >  iter->p_end = length > 0 ? &p[length] : NULL;
> >  iter->print_colors = print_colors;
> >   }
>
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] mesa: ignore VAO IDs equal to 0 in glDeleteVertexArrays

[andrey simiklit]

Hello,

I believe that this check already added inside _mesa_lookup_vao:

>_mesa_lookup_vao(struct gl_context *ctx, GLuint id)
>{
>   if (id == 0) {
>  return NULL;
>   } else {
>  ...
>}

I guess that the '_mesa_lookup_vao' function returns NULL for zero indexes.
So we will never pass into the 'if(obj)' for 0 index case.
So I think that this additional check which was added by this patch is
unnecessary here
because this functionality works fine for zero indexes as is.
Please correct me if am wrong.

Regards,
Andrii.

On Fri, Aug 31, 2018 at 10:24 AM Ian Romanick  wrote:

> On 08/30/2018 07:42 PM, Marek Olšák wrote:
> > Sadly, there are no tests for this.
>
> Ok... I just sent one to the piglit list.  It should be easy enough to
> create a few more for other glDeleteFoo functions.  I'll save that for
> during boring meetings. ;)
>
> > Marek
> >
> > On Thu, Aug 30, 2018 at 6:24 PM, Ian Romanick 
> wrote:
> >> This patch is
> >>
> >> Reviewed-by: Ian Romanick 
> >>
> >> Is there a piglit test?  I wonder how many other glDeleteFoo functions
> >> mishandle the id=0 case. :(
> >>
> >> On 08/30/2018 12:16 PM, Marek Olšák wrote:
> >>> From: Marek Olšák 
> >>>
> >>> This fixes a firefox crash.
> >>>
> >>> Fixes: 781a78914c798dc64005b37c6ca1224ce06803fc
> >>> ---
> >>>  src/mesa/main/arrayobj.c | 4 
> >>>  1 file changed, 4 insertions(+)
> >>>
> >>> diff --git a/src/mesa/main/arrayobj.c b/src/mesa/main/arrayobj.c
> >>> index a23031fe182..6e0665c0e5d 100644
> >>> --- a/src/mesa/main/arrayobj.c
> >>> +++ b/src/mesa/main/arrayobj.c
> >>> @@ -1007,20 +1007,24 @@ _mesa_BindVertexArray(GLuint id)
> >>>   *
> >>>   * \param n  Number of array objects to delete.
> >>>   * \param idsArray of \c n array object IDs.
> >>>   */
> >>>  static void
> >>>  delete_vertex_arrays(struct gl_context *ctx, GLsizei n, const GLuint
> *ids)
> >>>  {
> >>> GLsizei i;
> >>>
> >>> for (i = 0; i < n; i++) {
> >>> +  /* IDs equal to 0 should be silently ignored. */
> >>> +  if (!ids[i])
> >>> + continue;
> >>> +
> >>>struct gl_vertex_array_object *obj = _mesa_lookup_vao(ctx,
> ids[i]);
> >>>
> >>>if (obj) {
> >>>   assert(obj->Name == ids[i]);
> >>>
> >>>   /* If the array object is currently bound, the spec says
> "the binding
> >>>* for that object reverts to zero and the default vertex
> array
> >>>* becomes current."
> >>>*/
> >>>   if (obj == ctx->Array.VAO)
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 7/7] virgl: use hw-atomics instead of in-ssbo ones

[andrey simiklit]

Hi,

One more small think here:
> +int virgl_encode_set_hw_atomic_buffers(struct virgl_context *ctx,
> +   unsigned start_slot, unsigned
count,
> +   const struct pipe_shader_buffer
*buffers)
> +{
> +   int i;
I believe that it will be better to use 'unsigned' type for 'i' here
because the 'count' variable has 'unsigned' type.

Please lat me know if I am incorrect.

Regars,
Andrii.

On Fri, Aug 31, 2018 at 8:35 PM Gurchetan Singh 
wrote:

> On Thu, Aug 30, 2018 at 6:41 AM Erik Faye-Lund
>  wrote:
> >
> > From: Tomeu Vizoso 
> >
> > Emulating atomics on top of ssbos can lead to too small max SSBO count,
> > so let's use the hw-atomics mechanism to expose atomic buffers instead.
> >
> > Signed-off-by: Erik Faye-Lund 
> > ---
> >  src/gallium/drivers/virgl/virgl_context.c  | 37 ++
> >  src/gallium/drivers/virgl/virgl_context.h  |  2 ++
> >  src/gallium/drivers/virgl/virgl_encode.c   | 23 ++
> >  src/gallium/drivers/virgl/virgl_encode.h   |  3 ++
> >  src/gallium/drivers/virgl/virgl_hw.h   |  5 +++
> >  src/gallium/drivers/virgl/virgl_protocol.h |  9 ++
> >  src/gallium/drivers/virgl/virgl_screen.c   | 14 +---
> >  7 files changed, 88 insertions(+), 5 deletions(-)
> >
> > diff --git a/src/gallium/drivers/virgl/virgl_context.c
> b/src/gallium/drivers/virgl/virgl_context.c
> > index edc03f5dcf..30cd0e4331 100644
> > --- a/src/gallium/drivers/virgl/virgl_context.c
> > +++ b/src/gallium/drivers/virgl/virgl_context.c
> > @@ -196,6 +196,19 @@ static void virgl_attach_res_shader_images(struct
> virgl_context *vctx,
> > }
> >  }
> >
> > +static void virgl_attach_res_atomic_buffers(struct virgl_context *vctx)
> > +{
> > +   struct virgl_winsys *vws = virgl_screen(vctx->base.screen)->vws;
> > +   struct virgl_resource *res;
> > +   unsigned i;
> > +   for (i = 0; i < PIPE_MAX_SHADER_BUFFERS; i++) {
>
> Why not PIPE_MAX_HW_ATOMIC_BUFFERS?
>
> > +  res = virgl_resource(vctx->atomic_buffers[i]);
> > +  if (res) {
> > + vws->emit_res(vws, vctx->cbuf, res->hw_res, FALSE);
> > +  }
> > +   }
> > +}
> > +
> >  /*
> >   * after flushing, the hw context still has a bunch of
> >   * resources bound, so we need to rebind those here.
> > @@ -214,6 +227,7 @@ static void virgl_reemit_res(struct virgl_context
> *vctx)
> >virgl_attach_res_shader_buffers(vctx, shader_type);
> >virgl_attach_res_shader_images(vctx, shader_type);
> > }
> > +   virgl_attach_res_atomic_buffers(vctx);
> > virgl_attach_res_vertex_buffers(vctx);
> > virgl_attach_res_so_targets(vctx);
> >  }
> > @@ -952,6 +966,28 @@ static void virgl_blit(struct pipe_context *ctx,
> >  blit);
> >  }
> >
> > +static void virgl_set_hw_atomic_buffers(struct pipe_context *ctx,
> > +   unsigned start_slot,
> > +   unsigned count,
> > +   const struct
> pipe_shader_buffer *buffers)
>
> nit: mixing tabs and spaces
>
> > +{
> > +   struct virgl_context *vctx = virgl_context(ctx);
> > +
> > +   for (unsigned i = 0; i < count; i++) {
> > +  unsigned idx = start_slot + i;
> > +
> > +  if (buffers) {
> > + if (buffers[i].buffer) {
> > +pipe_resource_reference(&vctx->atomic_buffers[idx],
> > +buffers[i].buffer);
> > +continue;
> > + }
> > +  }
> > +  pipe_resource_reference(&vctx->atomic_buffers[idx], NULL);
> > +   }
> > +   virgl_encode_set_hw_atomic_buffers(vctx, start_slot, count, buffers);
> > +}
> > +
> >  static void virgl_set_shader_buffers(sunsignedtruct pipe_context *ctx,
> >   enum pipe_shader_type shader,
> >   unsigned start_slot, unsigned
> count,
> > @@ -1209,6 +1245,7 @@ struct pipe_context *virgl_context_create(struct
> pipe_screen *pscreen,
> > vctx->base.blit =  virgl_blit;
> >
> > vctx->base.set_shader_buffers = virgl_set_shader_buffers;
> > +   vctx->base.set_hw_atomic_buffers = virgl_set_hw_atomic_buffers;
> > vctx->base.set_shader_images = virgl_set_shader_images;
> > vctx->base.memory_barrier = virgl_memory_barrier;
> >
> > diff --git a/src/gallium/drivers/virgl/virgl_context.h
> b/src/gallium/drivers/virgl/virgl_context.h
> > index 38d1f450e1..20988baa3c 100644
> > --- a/src/gallium/drivers/virgl/virgl_context.h
> > +++ b/src/gallium/drivers/virgl/virgl_context.h
> > @@ -75,6 +75,8 @@ struct virgl_context {
> > int num_draws;
> > struct list_head to_flush_bufs;
> >
> > +   struct pipe_resource *atomic_buffers[PIPE_MAX_HW_ATOMIC_BUFFERS];
> > +
> > struct primconvert_context *primconvert;
> > uint32_t hw_sub_ctx_id;
> >  };
> > diff --git a/src/gallium/drivers/virgl/virgl_encode.c
> b/src/gallium/drivers/virgl/virgl_encode.c
> > index bcb14d8939..c9cc099061 100644
> > --- a

Re: [Mesa-dev] [PATCH 8/9 v2] nir: Add partial redundancy elimination for compares

[andrey simiklit]

Hi,

I guess it is just a small mistake in description that:
'z' was before:
   z = y - x;
and became after:
   z = x - y;

I think you inadvertently misspelled in the description and you mean:

>
> This pass attempts to dectect code sequences like
>
> if (x < y) {
> z = y - x;
> ...
> }
>
> and replace them with sequences like
>
> t = *y - x*;
> if (t < 0) {
> z = t;
> ...
> }
>

Because the subtraction is not commutative operation)
Please correct me if I am incorrect.

Regards,
Andrii.

On Thu, Aug 30, 2018 at 8:36 AM Ian Romanick  wrote:

> From: Ian Romanick 
>
> This pass attempts to dectect code sequences like
>
> if (x < y) {
> z = y - x;
> ...
> }
>
> and replace them with sequences like
>
> t = x - y;
> if (t < 0) {
> z = t;
> ...
> }
>
> On architectures where the subtract can generate the flags used by the
> if-statement, this saves an instruction.  It's also possible that moving
> an instruction out of the if-statement will allow
> nir_opt_peephole_select to convert the whole thing to a bcsel.
>
> Currently only floating point compares and adds are supported.  Adding
> support for integer will be a challenge due to integer overflow.  There
> are a couple possible solutions, but they may not apply to all
> architectures.
>
> v2: Fix a typo in the commit message and a couple typos in comments.
> Fix possible NULL pointer deref from result of push_block().  Add
> missing (-A + B) case.  Suggested by Caio.
>
> Signed-off-by: Ian Romanick 
> ---
>  src/compiler/Makefile.sources |   1 +
>  src/compiler/nir/meson.build  |   1 +
>  src/compiler/nir/nir.h|   2 +
>  src/compiler/nir/nir_opt_comparison_pre.c | 360
> ++
>  src/compiler/nir/nir_search_helpers.h |  29 +++
>  5 files changed, 393 insertions(+)
>  create mode 100644 src/compiler/nir/nir_opt_comparison_pre.c
>
> diff --git a/src/compiler/Makefile.sources b/src/compiler/Makefile.sources
> index d3b06564832..9fe8d5b8904 100644
> --- a/src/compiler/Makefile.sources
> +++ b/src/compiler/Makefile.sources
> @@ -267,6 +267,7 @@ NIR_FILES = \
> nir/nir_move_load_const.c \
> nir/nir_move_vec_src_uses_to_dest.c \
> nir/nir_normalize_cubemap_coords.c \
> +   nir/nir_opt_comparison_pre.c \
> nir/nir_opt_conditional_discard.c \
> nir/nir_opt_constant_folding.c \
> nir/nir_opt_copy_prop_vars.c \
> diff --git a/src/compiler/nir/meson.build b/src/compiler/nir/meson.build
> index 5438c17a8f8..2bcc854829e 100644
> --- a/src/compiler/nir/meson.build
> +++ b/src/compiler/nir/meson.build
> @@ -151,6 +151,7 @@ files_libnir = files(
>'nir_move_load_const.c',
>'nir_move_vec_src_uses_to_dest.c',
>'nir_normalize_cubemap_coords.c',
> +  'nir_opt_comparison_pre.c',
>'nir_opt_conditional_discard.c',
>'nir_opt_constant_folding.c',
>'nir_opt_copy_prop_vars.c',
> diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
> index ddbcb3c647e..c78387d0acf 100644
> --- a/src/compiler/nir/nir.h
> +++ b/src/compiler/nir/nir.h
> @@ -3000,6 +3000,8 @@ bool nir_convert_from_ssa(nir_shader *shader, bool
> phi_webs_only);
>  bool nir_lower_phis_to_regs_block(nir_block *block);
>  bool nir_lower_ssa_defs_to_regs_block(nir_block *block);
>
> +bool nir_opt_comparison_pre(nir_shader *shader);
> +
>  bool nir_opt_algebraic(nir_shader *shader);
>  bool nir_opt_algebraic_before_ffma(nir_shader *shader);
>  bool nir_opt_algebraic_late(nir_shader *shader);
> diff --git a/src/compiler/nir/nir_opt_comparison_pre.c
> b/src/compiler/nir/nir_opt_comparison_pre.c
> new file mode 100644
> index 000..b2827c21816
> --- /dev/null
> +++ b/src/compiler/nir/nir_opt_comparison_pre.c
> @@ -0,0 +1,360 @@
> +/*
> + * Copyright © 2018 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the
> "Software"),
> + * to deal in the Software without restriction, including without
> limitation
> + * the rights to use, copy, modify, merge, publish, distribute,
> sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the
> next
> + * paragraph) shall be included in all copies or substantial portions of
> the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT
> SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
> OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH 

Re: [Mesa-dev] [PATCH v3] intel/decoder: fix the possible out of bounds group_iter

[andrey simiklit]

Hi,

Thanks a lot.

Regards,
Andrii.

On Mon, Sep 3, 2018 at 1:16 PM Lionel Landwerlin <
lionel.g.landwer...@intel.com> wrote:

> Done.
>
> -
> Lionel
>
> On 03/09/2018 08:55, andrey simiklit wrote:
>
> Hi all,
>
> Could somebody push this small patch to mesa?
>
> Regards,
> Andrii.
> On Mon, Aug 20, 2018 at 9:13 PM Lionel Landwerlin <
> lionel.g.landwer...@intel.com> wrote:
>
>> On 20/08/2018 17:20, asimiklit.w...@gmail.com wrote:
>> > From: Andrii Simiklit 
>> >
>> > The "gen_group_get_length" function can return a negative value
>> > and it can lead to the out of bounds group_iter.
>> >
>> > v2: printing of "unknown command type" was added
>> > v3: just the asserts are added
>> >
>> > Signed-off-by: Andrii Simiklit 
>>
>> Reviewed-by: Lionel Landwerlin 
>>
>> Somebody should take a look at the other patches I sent out ;)
>> Thanks!
>>
>> -
>> Lionel
>> > ---
>> >   src/intel/common/gen_decoder.c | 5 -
>> >   1 file changed, 4 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/src/intel/common/gen_decoder.c
>> b/src/intel/common/gen_decoder.c
>> > index ec0a486..2d9609a 100644
>> > --- a/src/intel/common/gen_decoder.c
>> > +++ b/src/intel/common/gen_decoder.c
>> > @@ -803,8 +803,10 @@ static bool
>> >   iter_more_groups(const struct gen_field_iterator *iter)
>> >   {
>> >  if (iter->group->variable) {
>> > +  int length = gen_group_get_length(iter->group, iter->p);
>> > +  assert(length >= 0 && "error the length is unknown!");
>> > return iter_group_offset_bits(iter, iter->group_iter + 1) <
>> > -  (gen_group_get_length(iter->group, iter->p) * 32);
>> > +  (length * 32);
>> >  } else {
>> > return (iter->group_iter + 1) < iter->group->group_count ||
>> >iter->group->next != NULL;
>> > @@ -991,6 +993,7 @@ gen_field_iterator_init(struct gen_field_iterator
>> *iter,
>> >  iter->p_bit = p_bit;
>> >
>> >  int length = gen_group_get_length(iter->group, iter->p);
>> > +   assert(length >= 0 && "error the length is unknown!");
>> >  iter->p_end = length > 0 ? &p[length] : NULL;
>> >  iter->print_colors = print_colors;
>> >   }
>>
>>
>>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] mesa/util: add missing va_end() after va_copy()

[andrey simiklit]

Hi,

Thanks for your reply.

These WIN32 compat functions seem iffy.
> Namely - often we'll issue a va_copy only to use the original va.
>

As far as I found there is the following reason to use va_copy:

https://linux.die.net/man/3/vsnprintf
"These functions do not call the va_end macro. Because they
  invoke the va_arg  macro, the value of ap is *undefined after the call*"

http://www.cplusplus.com/reference/cstdio/vsnprintf/
"nternally, the function retrieves arguments from the list identified by
arg as
 if va_arg was used on it, and thus the state of *arg is likely to be
altered by the call.*"

but unfortunately nothing about it on MSDN
so I presume the worst case - it works in the same way.

So the main reason to use va_copy it is when we need pass
our 'va_list' instance to more then one functions because the 'va_list'
instance
can be changed by the called function.

I think that the 'util_vasprintf' on line 116 also should be fixed
because it creates the the copy of 'va_list' but passes
the original 'va_list' instance into both function.

Looking through the rest of the code base:
> There are plenty of va_start + util_vsnprintf + va_free cases that
> could be replaced with util_snprintf.
>

I think that I misunderstand you here.
I don't know way to do it. For example:
>
> static inline void
> trace_dump_writef(const char *format, ...)
> {
>static char buf[1024];
>unsigned len;
>va_list ap;
>va_start(ap, format);
>len = util_vsnprintf(buf, sizeof(buf), format, ap);
>va_end(ap);
>trace_dump_write(buf, len);
> }
>
if I try to replace 3 lines above by util_snprintf what should I pass to
parameter '...' ?
Could you please give me an example how to do it?

There are also some util_vsnprintf users which use va_copy and some
> who do not :-\
>

How I explained above it is needed because
we can not pass the same instance of 'va_list' to multiple functions
because 'va_list' instance can be changed by the called function.

I will send new patch as soon as we came agreement about it.

Please correct me if I am incorrect.

Regards,
Andrii.

On Mon, Sep 3, 2018 at 6:27 PM Emil Velikov 
wrote:

> On 3 September 2018 at 15:49,   wrote:
> > From: Andrii Simiklit 
> >
> > MSDN:
> > "va_end must be called on each argument list that's initialized
> >  with va_start or va_copy before the function returns."
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107810
> > Signed-off-by: Andrii Simiklit 
> >
> > ---
> >  src/util/u_string.h | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/src/util/u_string.h b/src/util/u_string.h
> > index ce45430..883fa64 100644
> > --- a/src/util/u_string.h
> > +++ b/src/util/u_string.h
> > @@ -81,6 +81,7 @@ util_vsnprintf(char *str, size_t size, const char
> *format, va_list ap)
> > if (ret < 0) {
> >ret = _vscprintf(format, ap_copy);
> > }
> > +   va_end(ap_copy);
> > return ret;
>
> These WIN32 compat functions seem iffy.
> Namely - often we'll issue a va_copy only to use the original va.
>
> Looking through the rest of the code base:
> There are plenty of va_start + util_vsnprintf + va_free cases that
> could be replaced with util_snprintf.
>
> There are also some util_vsnprintf users which use va_copy and some
> who do not :-\
>
> I think those should be looked first, otherwise adding this va_end
> could easily break things.
>
> HTH
> Emil
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] mesa: ignore VAO IDs equal to 0 in glDeleteVertexArrays

[andrey simiklit]

Hello,

Thanks for your reply.
Yes you are right.
The new code was added 7 days ago)

Regards,
Andrii.
On Tue, Sep 4, 2018 at 8:53 PM Marek Olšák  wrote:

> On Mon, Sep 3, 2018 at 5:05 AM, andrey simiklit
>  wrote:
> > Hello,
> >
> > I believe that this check already added inside _mesa_lookup_vao:
> >
> >>_mesa_lookup_vao(struct gl_context *ctx, GLuint id)
> >>{
> >>   if (id == 0) {
> >>  return NULL;
> >>   } else {
> >>  ...
> >>}
>
> Your Mesa code is outdated.
>
> Marek
>
> >
> > I guess that the '_mesa_lookup_vao' function returns NULL for zero
> indexes.
> > So we will never pass into the 'if(obj)' for 0 index case.
> > So I think that this additional check which was added by this patch is
> > unnecessary here
> > because this functionality works fine for zero indexes as is.
> > Please correct me if am wrong.
> >
> > Regards,
> > Andrii.
> >
> > On Fri, Aug 31, 2018 at 10:24 AM Ian Romanick 
> wrote:
> >>
> >> On 08/30/2018 07:42 PM, Marek Olšák wrote:
> >> > Sadly, there are no tests for this.
> >>
> >> Ok... I just sent one to the piglit list.  It should be easy enough to
> >> create a few more for other glDeleteFoo functions.  I'll save that for
> >> during boring meetings. ;)
> >>
> >> > Marek
> >> >
> >> > On Thu, Aug 30, 2018 at 6:24 PM, Ian Romanick 
> >> > wrote:
> >> >> This patch is
> >> >>
> >> >> Reviewed-by: Ian Romanick 
> >> >>
> >> >> Is there a piglit test?  I wonder how many other glDeleteFoo
> functions
> >> >> mishandle the id=0 case. :(
> >> >>
> >> >> On 08/30/2018 12:16 PM, Marek Olšák wrote:
> >> >>> From: Marek Olšák 
> >> >>>
> >> >>> This fixes a firefox crash.
> >> >>>
> >> >>> Fixes: 781a78914c798dc64005b37c6ca1224ce06803fc
> >> >>> ---
> >> >>>  src/mesa/main/arrayobj.c | 4 
> >> >>>  1 file changed, 4 insertions(+)
> >> >>>
> >> >>> diff --git a/src/mesa/main/arrayobj.c b/src/mesa/main/arrayobj.c
> >> >>> index a23031fe182..6e0665c0e5d 100644
> >> >>> --- a/src/mesa/main/arrayobj.c
> >> >>> +++ b/src/mesa/main/arrayobj.c
> >> >>> @@ -1007,20 +1007,24 @@ _mesa_BindVertexArray(GLuint id)
> >> >>>   *
> >> >>>   * \param n  Number of array objects to delete.
> >> >>>   * \param idsArray of \c n array object IDs.
> >> >>>   */
> >> >>>  static void
> >> >>>  delete_vertex_arrays(struct gl_context *ctx, GLsizei n, const
> GLuint
> >> >>> *ids)
> >> >>>  {
> >> >>> GLsizei i;
> >> >>>
> >> >>> for (i = 0; i < n; i++) {
> >> >>> +  /* IDs equal to 0 should be silently ignored. */
> >> >>> +  if (!ids[i])
> >> >>> + continue;
> >> >>> +
> >> >>>struct gl_vertex_array_object *obj = _mesa_lookup_vao(ctx,
> >> >>> ids[i]);
> >> >>>
> >> >>>if (obj) {
> >> >>>   assert(obj->Name == ids[i]);
> >> >>>
> >> >>>   /* If the array object is currently bound, the spec says
> >> >>> "the binding
> >> >>>* for that object reverts to zero and the default vertex
> >> >>> array
> >> >>>* becomes current."
> >> >>>*/
> >> >>>   if (obj == ctx->Array.VAO)
> >> ___
> >> mesa-dev mailing list
> >> mesa-dev@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] mesa/util: add missing va_end() after va_copy()

[andrey simiklit]

On Thu, Sep 6, 2018 at 3:20 PM Emil Velikov 
wrote:

> Hi Andrii,
>
> I think you might be overthinking my comments.
> There's nothing special, nor am I trying to force my opinion.
>
> If you think my suggestions make sense, great. Otherwise don't bother too
> much.
>
Thanks a lot for your advices and reviewing)

>
> HTH
> Emil
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v4 0/8] mesa: fix usage of [v][s][n]printf functions

[andrey simiklit]

On Thu, Sep 6, 2018 at 7:58 PM Eric Engestrom 
wrote:

> On Thursday, 2018-09-06 17:43:50 +0300, asimiklit.w...@gmail.com wrote:
> > From: Andrii Simiklit 
> >
> > This patch improve usage of [v][s][n]printf functions.
> > Fixes cross platform implementation of vsnprintf
> >
> > v2: Linux man about vXXXprintf functions:
> > "These functions do not call the va_end macro. Because they
> >  invoke the va_arg  macro, the value of ap is undefined after the
> call"
> >  So we should have instance copy of va_list for each 'vXXXprintf'
> call.
> >
> > v3: Fixed case when malloc returns 0 in util_vasprintf
> >
> > v4: The single patch was separated to the patch series
> >
> > Andrii Simiklit (8):
> >   apple/glx/log: added missing va_end() after va_copy()
> >   mesa/util: don't use the same 'va_list' instance twice
> >   mesa/util: don't ignore NULL returned from 'malloc'
> >   mesa/util: add missing va_end() after va_copy()
>
> First 4 are
> Reviewed-by: Eric Engestrom 
> and pushed :)
>
> Thanks for taking the time to find the right Fixes: btw, that really
> helps when backporting to stable branches :)
>
> >   mesa/main: don't use win _vsnprintf. there is 'util_vsnprintf'
> > function
> >   mesa/util: use cross platform implementation 'util_vsnprintf'
>
> These will require more time than I can give right now; maybe later if
> nobody beats me to it :)
>
> >   radv: use cross platform implementation 'util_vsnprintf'
> >   egl/main: use cross platform implementation 'util_vsnprintf'
>
> These two are:
> Acked-by: Eric Engestrom 
>
> And I'll do all the double-checking later if I can and turn them into
> r-bs :P
>

Thanks a lot for your reviewing)


> >
> >  src/amd/vulkan/radv_util.c|  5 +++--
> >  src/egl/main/egllog.c |  3 ++-
> >  src/glx/apple/apple_glx_log.c |  1 +
> >  src/mesa/main/imports.c   | 11 +--
> >  src/util/ralloc.c | 25 ++---
> >  src/util/u_string.h   | 10 --
> >  6 files changed, 25 insertions(+), 30 deletions(-)
> >
> > --
> > 2.7.4
> >
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v4 7/7] egl/main: use cross platform implementation 'util_vsnprintf'

[andrey simiklit]

On Fri, Sep 7, 2018 at 5:40 AM Ian Romanick  wrote:

> On 09/06/2018 07:43 AM, asimiklit.w...@gmail.com wrote:
> > From: Andrii Simiklit 
> >
> > I guess it makes this implementation more portable.
> >
> > Signed-off-by: Andrii Simiklit 
> > ---
> >  src/amd/vulkan/radv_util.c | 5 +++--
> >  src/egl/main/egllog.c  | 3 ++-
> >  2 files changed, 5 insertions(+), 3 deletions(-)
> >
> > diff --git a/src/amd/vulkan/radv_util.c b/src/amd/vulkan/radv_util.c
> > index 72bedc6..90d3824 100644
> > --- a/src/amd/vulkan/radv_util.c
> > +++ b/src/amd/vulkan/radv_util.c
>
> I guess these changes were supposed to be in the next patch?
>

Oh it is my fail I forgot to remove this from patches folder.
It is just duplicate for:
[PATCH v4 8/8] egl/main: use cross platform implementation 'util_vsnprintf'
[PATCH v4 7/8] radv: use cross platform implementation 'util_vsnprintf'

Thanks for pointing out my mistake.
Just ignore this patch.


> > @@ -33,6 +33,7 @@
> >  #include "vk_enum_to_str.h"
> >
> >  #include "util/u_math.h"
> > +#include "util/u_string.h"
> >
> >  /** Log an error message.  */
> >  void radv_printflike(1, 2)
> > @@ -81,7 +82,7 @@ void radv_printflike(3, 4)
> >   char buffer[256];
> >
> >   va_start(ap, format);
> > - vsnprintf(buffer, sizeof(buffer), format, ap);
> > + util_vsnprintf(buffer, sizeof(buffer), format, ap);
> >   va_end(ap);
> >
> >   fprintf(stderr, "%s:%d: FINISHME: %s\n", file, line, buffer);
> > @@ -103,7 +104,7 @@ __vk_errorf(struct radv_instance *instance, VkResult
> error, const char *file,
> >
> >   if (format) {
> >   va_start(ap, format);
> > - vsnprintf(buffer, sizeof(buffer), format, ap);
> > + util_vsnprintf(buffer, sizeof(buffer), format, ap);
> >   va_end(ap);
> >
> >   fprintf(stderr, "%s:%d: %s (%s)\n", file, line, buffer,
> error_str);
> > diff --git a/src/egl/main/egllog.c b/src/egl/main/egllog.c
> > index c223f49..d21b070 100644
> > --- a/src/egl/main/egllog.c
> > +++ b/src/egl/main/egllog.c
> > @@ -42,6 +42,7 @@
> >  #include 
> >  #include "c11/threads.h"
> >  #include "util/macros.h"
> > +#include "util/u_string.h"
> >
> >  #include "egllog.h"
> >
> > @@ -154,7 +155,7 @@ _eglLog(EGLint level, const char *fmtStr, ...)
> > mtx_lock(&logging.mutex);
> >
> > va_start(args, fmtStr);
> > -   ret = vsnprintf(msg, MAXSTRING, fmtStr, args);
> > +   ret = util_vsnprintf(msg, MAXSTRING, fmtStr, args);
> > if (ret < 0 || ret >= MAXSTRING)
> >strcpy(msg, "");
> > va_end(args);
> >
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v4 5/8] mesa/main: don't use win _vsnprintf. there is 'util_vsnprintf' function

[andrey simiklit]

On Fri, Sep 7, 2018 at 5:38 AM Ian Romanick  wrote:

> It seems like it might better to just replace all the calllers of
> _mesa_*printf with util_*printf.
>

Thanks. Yes you're right. I am going to rework it today.


> On 09/06/2018 07:43 AM, asimiklit.w...@gmail.com wrote:
> > From: Andrii Simiklit 
> >
> > The win '_vsnprintf' function incompatibility with C99 vsnprintf.
> > At least for case when the input buffer size less than the required size:
> > '_vsnprintf' returns -1 for this case.
> > 'vsnprintf' returns the required size.
> >
> > So use cross platform implementation 'util_vsnprintf'.
> >
> > Fixes: 2353e96c320d "Coerce vsnprintf to _vsnprintf for windows"
> > Signed-off-by: Andrii Simiklit 
> > ---
> >  src/mesa/main/imports.c | 11 +--
> >  1 file changed, 5 insertions(+), 6 deletions(-)
> >
> > diff --git a/src/mesa/main/imports.c b/src/mesa/main/imports.c
> > index b4685b6..d42825e 100644
> > --- a/src/mesa/main/imports.c
> > +++ b/src/mesa/main/imports.c
> > @@ -46,6 +46,7 @@
> >  #include 
> >  #include "c99_math.h"
> >  #include "util/rounding.h" /* for _mesa_roundeven */
> > +#include "util/u_string.h"
> >  #include "imports.h"
> >  #include "context.h"
> >  #include "version.h"
> > @@ -58,9 +59,7 @@
> >  #endif
> >
> >
> > -#ifdef _WIN32
> > -#define vsnprintf _vsnprintf
> > -#elif defined(__IBMC__) || defined(__IBMCPP__)
> > +#if defined(__IBMC__) || defined(__IBMCPP__)
> >  extern int vsnprintf(char *str, size_t count, const char *fmt, va_list
> arg);
> >  #endif
> >
> > @@ -255,7 +254,7 @@ _mesa_bitcount_64(uint64_t n)
> >  int
> >  _mesa_vsnprintf(char *str, size_t size, const char *fmt, va_list args)
> >  {
> > -   return vsnprintf( str, size, fmt, args);
> > +   return util_vsnprintf( str, size, fmt, args);
> >  }
> >
> >  /** Wrapper around vsnprintf() */
> > @@ -264,8 +263,8 @@ _mesa_snprintf( char *str, size_t size, const char
> *fmt, ... )
> >  {
> > int r;
> > va_list args;
> > -   va_start( args, fmt );
> > -   r = vsnprintf( str, size, fmt, args );
> > +   va_start( args, fmt );
> > +   r = util_vsnprintf( str, size, fmt, args );
> > va_end( args );
> > return r;
> >  }
> >
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v4 0/8] mesa: fix usage of [v][s][n]printf functions

[andrey simiklit]

On Fri, Sep 7, 2018 at 12:09 PM Emil Velikov 
wrote:

> On 6 September 2018 at 17:58, Eric Engestrom 
> wrote:
> > On Thursday, 2018-09-06 17:43:50 +0300, asimiklit.w...@gmail.com wrote:
> >> From: Andrii Simiklit 
> >>
> >> This patch improve usage of [v][s][n]printf functions.
> >> Fixes cross platform implementation of vsnprintf
> >>
> >> v2: Linux man about vXXXprintf functions:
> >> "These functions do not call the va_end macro. Because they
> >>  invoke the va_arg  macro, the value of ap is undefined after the
> call"
> >>  So we should have instance copy of va_list for each 'vXXXprintf'
> call.
> >>
> >> v3: Fixed case when malloc returns 0 in util_vasprintf
> >>
> >> v4: The single patch was separated to the patch series
> >>
> >> Andrii Simiklit (8):
> >>   apple/glx/log: added missing va_end() after va_copy()
> >>   mesa/util: don't use the same 'va_list' instance twice
> >>   mesa/util: don't ignore NULL returned from 'malloc'
> >>   mesa/util: add missing va_end() after va_copy()
> >
> > First 4 are
> > Reviewed-by: Eric Engestrom 
> > and pushed :)
> >
> > Thanks for taking the time to find the right Fixes: btw, that really
> > helps when backporting to stable branches :)
> >
> Small nitpick: "mesa/util" should be just "util".
> Regardless, patches are spot on. Kudos for all the Fixes tags.
>
> >>   mesa/main: don't use win _vsnprintf. there is 'util_vsnprintf'
> >> function
> As-is, or reworked to drop the _mesa_ function (as Ian suggested) patch is
> Reviewed-by: Emil Velikov 
>

Changes are in progress. Thanks for reviewing.


> >>   mesa/util: use cross platform implementation 'util_vsnprintf'
> >
> "mesa/util" -> "util", with that
> Reviewed-by: Emil Velikov 
>

I will change it.


>
>
> >>   radv: use cross platform implementation 'util_vsnprintf'
> >>   egl/main: use cross platform implementation 'util_vsnprintf'
> >
> > These two are:
> > Acked-by: Eric Engestrom 
> >
> Reviewed-by: Emil Velikov 
>
> Admittedly, I doubt we'll get radv on Windows soon. At least not
> before we bump the requirement to MSVC2015 which has C99 compliant
> function.
>

Agree)
It would be great if it was similar to other places of the mesa code.
Thanks for reviewing.


> HTH
> Emil
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] i965/glsl: don't add unused aoa elements to the program resource list

[andrey simiklit]

Hi all,

Could somebody run it on CI to confirm that this patch fixes one test and
not add regressions or maybe even take a look at this patch)

Regards,
Andrii.

On Fri, Aug 31, 2018 at 5:13 PM  wrote:

> From: Andrii Simiklit 
>
> It fixes a bit incorrectly implemented ARB_program_interface_query.
> If input aoa element is unused in shader program
> the 'glGetProgramResourceIndex' function shouldn't
> return a valid resource index for it according to:
> ARB_program_interface_query spec:
> " For an active variable declared as an array of an aggregate data type
> (structures or arrays), a separate entry will be generated for each
> active array element"
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92822
> Signed-off-by: Andrii Simiklit 
> ---
>  src/compiler/Makefile.sources  |   4 +-
>  .../glsl/ir_collect_active_aoa_elements.cpp| 148
> +
>  src/compiler/glsl/ir_collect_active_aoa_elements.h |  49 +++
>  src/compiler/glsl/linker.cpp   |  75 +--
>  src/compiler/glsl/meson.build  |   2 +
>  5 files changed, 265 insertions(+), 13 deletions(-)
>  create mode 100644 src/compiler/glsl/ir_collect_active_aoa_elements.cpp
>  create mode 100644 src/compiler/glsl/ir_collect_active_aoa_elements.h
>
> diff --git a/src/compiler/Makefile.sources b/src/compiler/Makefile.sources
> index d3b0656..a2ba3e3 100644
> --- a/src/compiler/Makefile.sources
> +++ b/src/compiler/Makefile.sources
> @@ -154,7 +154,9 @@ LIBGLSL_FILES = \
> glsl/serialize.cpp \
> glsl/serialize.h \
> glsl/string_to_uint_map.cpp \
> -   glsl/string_to_uint_map.h
> +   glsl/string_to_uint_map.h \
> +   glsl/ir_collect_active_aoa_elements.cpp \
> +   glsl/ir_collect_active_aoa_elements.h
>
>  LIBGLSL_SHADER_CACHE_FILES = \
> glsl/shader_cache.cpp \
> diff --git a/src/compiler/glsl/ir_collect_active_aoa_elements.cpp
> b/src/compiler/glsl/ir_collect_active_aoa_elements.cpp
> new file mode 100644
> index 000..50042c7
> --- /dev/null
> +++ b/src/compiler/glsl/ir_collect_active_aoa_elements.cpp
> @@ -0,0 +1,148 @@
> +/*
> + * Copyright © 2018 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the
> "Software"),
> + * to deal in the Software without restriction, including without
> limitation
> + * the rights to use, copy, modify, merge, publish, distribute,
> sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the
> next
> + * paragraph) shall be included in all copies or substantial portions of
> the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT
> SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
> OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> + * DEALINGS IN THE SOFTWARE.
> + */
> +
> +#include "ir_collect_active_aoa_elements.h"
> +#include "program.h"
> +#include "linker_util.h"
> +#include "util/set.h"
> +#include "util/u_dynarray.h"
> +
> +namespace
> +{
> +/***
> + * Helps to collect the names of used aoa elements
> + * to the accessed_elements set
> + ***/
> +struct elem_inserter
> +{
> +elem_inserter(struct set *accessed_elements_)
> +: accessed_elements(accessed_elements_)
> +{}
> +void operator ()(const char *name)
> +{
> +if (NULL == _mesa_set_search(accessed_elements, name)) {
> +_mesa_set_add(accessed_elements, name);
> +}
> +}
> +struct set *accessed_elements;
> +};
> +
> +bool
> +ir_is_array_deref(ir_rvalue *const ir)
> +{
> +return (ir_type_dereference_array == ir->ir_type);
> +}
> +
> +ir_variable *
> +base_ir_dereference_var(ir_dereference_array *const ir)
> +{
> +ir_dereference_array const *base_ir = ir;
> +while (ir_type_dereference_array == base_ir->array->ir_type) {
> +base_ir = base_ir->array->as_dereference_array();
> +assert(NULL != base_ir);
> +}
> +
> +ir_dereference_variable *const d =
> +base_ir->array->as_dereference_variable();
> +return (NULL == d) ? NULL : d->var;
> +}
> +}
> +/**
> + * Helps to produce all combinations of used aoa elements
> + * for cases with constant and variable index.
> + **/
> +template 
> +inline void enumiramte_active_elements(void *memct

Re: [Mesa-dev] [PATCH] i965/batch: don't ignore the 'brw_new_batch' call for a 'new batch'

[andrey simiklit]

Hi all,

Could somebody check it on CI to confirm that this patch do not add
regressions or maybe even take a look at this patch.

Regards,
Andrii.

On Mon, Aug 27, 2018 at 12:39 PM andrey simiklit 
wrote:

> Hi all,
>
> It would be great if somebody look at this.
> I guess that this issue can affect every place where we use
> 'intel_batchbuffer_save_state/intel_batchbuffer_reset_to_saved' but only
> when the 'brw_batch_has_aperture_space' function returns false several
> times in a row.
> Pay attention that the last batch
> <https://bugs.freedesktop.org/attachment.cgi?id=141200> of log has an
> aperture with negative value "(-1023.8Mb aperture)".
> Please correct me if I am incorrect.
>
> Regards,
> Andrii.
> On Tue, Aug 21, 2018 at 3:00 PM andrey simiklit 
> wrote:
>
>> Hi all,
>>
>> The bug for this issue was created:
>> https://bugs.freedesktop.org/show_bug.cgi?id=107626
>>
>> Regards,
>> Andrii.
>>
>>
>> On Mon, Aug 20, 2018 at 5:43 PM,  wrote:
>>
>>> From: Andrii Simiklit 
>>>
>>> If we restore the 'new batch' using 'intel_batchbuffer_reset_to_saved'
>>> function we must restore the default state of the batch using
>>> 'brw_new_batch' function because the 'intel_batchbuffer_flush'
>>> function will not do it for the 'new batch' again.
>>> At least the following fields of the batch
>>> 'state_base_address_emitted','aperture_space', 'state_used'
>>> should be restored to default values to avoid:
>>> 1. the aperture_space overflow
>>> 2. the missed STATE_BASE_ADDRESS commad in the batch
>>> 3. the memory overconsumption of the 'statebuffer'
>>>due to uncleared 'state_used' field.
>>> etc.
>>>
>>> Signed-off-by: Andrii Simiklit 
>>> ---
>>>  src/mesa/drivers/dri/i965/intel_batchbuffer.c | 104
>>> +++---
>>>  1 file changed, 59 insertions(+), 45 deletions(-)
>>>
>>> diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
>>> b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
>>> index 65d2c64..b8c5fb4 100644
>>> --- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
>>> +++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
>>> @@ -219,7 +219,7 @@ add_exec_bo(struct intel_batchbuffer *batch, struct
>>> brw_bo *bo)
>>> bo->index = batch->exec_count;
>>> batch->exec_bos[batch->exec_count] = bo;
>>> batch->aperture_space += bo->size;
>>> -
>>> +   assert((batch->aperture_space >= 0) && "error
>>> 'batch->aperture_space' field is overflown!");
>>> return batch->exec_count++;
>>>  }
>>>
>>> @@ -290,6 +290,51 @@
>>> intel_batchbuffer_reset_and_clear_render_cache(struct brw_context *brw)
>>> brw_cache_sets_clear(brw);
>>>  }
>>>
>>> +/**
>>> + * Called when starting a new batch buffer.
>>> + */
>>> +static void
>>> +brw_new_batch(struct brw_context *brw)
>>> +{
>>> +   /* Unreference any BOs held by the previous batch, and reset counts.
>>> */
>>> +   for (int i = 0; i < brw->batch.exec_count; i++) {
>>> +  brw_bo_unreference(brw->batch.exec_bos[i]);
>>> +  brw->batch.exec_bos[i] = NULL;
>>> +   }
>>> +   brw->batch.batch_relocs.reloc_count = 0;
>>> +   brw->batch.state_relocs.reloc_count = 0;
>>> +   brw->batch.exec_count = 0;
>>> +   brw->batch.aperture_space = 0;
>>> +
>>> +   brw_bo_unreference(brw->batch.state.bo);
>>> +
>>> +   /* Create a new batchbuffer and reset the associated state: */
>>> +   intel_batchbuffer_reset_and_clear_render_cache(brw);
>>> +
>>> +   /* If the kernel supports hardware contexts, then most hardware
>>> state is
>>> +* preserved between batches; we only need to re-emit state that is
>>> required
>>> +* to be in every batch.  Otherwise we need to re-emit all the state
>>> that
>>> +* would otherwise be stored in the context (which for all intents
>>> and
>>> +* purposes means everything).
>>> +*/
>>> +   if (brw->hw_ctx == 0) {
>>> +  brw->ctx.NewDriverState |= BRW_NEW_CONTEXT;
>>> +  brw_upload_invariant_state(brw);
>>> +   }
>>> +
>>> +   brw->ctx.New

Re: [Mesa-dev] [PATCH] i965: Bump aperture tracking to u64

[andrey simiklit]

On Fri, Sep 7, 2018 at 4:35 PM Chris Wilson 
wrote:

> As a prelude to handling large address spaces, first allow ourselves the
> luxury of handling the full 4G.
>
> Reported-by: Andrey Simiklit 
> Cc: Kenneth Graunke 
> ---
>  src/mesa/drivers/dri/i965/brw_context.h   | 2 +-
>  src/mesa/drivers/dri/i965/intel_batchbuffer.c | 9 +
>  src/mesa/drivers/dri/i965/intel_batchbuffer.h | 8 ++--
>  3 files changed, 8 insertions(+), 11 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_context.h
> b/src/mesa/drivers/dri/i965/brw_context.h
> index d3b96953467..ca1fe8ef0ea 100644
> --- a/src/mesa/drivers/dri/i965/brw_context.h
> +++ b/src/mesa/drivers/dri/i965/brw_context.h
> @@ -509,7 +509,7 @@ struct intel_batchbuffer {
> int exec_array_size;
>
> /** The amount of aperture space (in bytes) used by all exec_bos */
> -   int aperture_space;
> +   uint64_t aperture_space;
>

There are several fields which are not cleaned when
Mesa managed to save the 'empty batch' and uses
'intel_batchbuffer_reset_to_saved' to restore back to it)
The negative aperture just helped me to find
the root cause of the issue)
But actually you are right I also do not know why
we use the signed 32bit integer there)


>
> struct {
>uint32_t *map_next;
> diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> index 65d2c64e319..4363b146150 100644
> --- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> +++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> @@ -870,7 +870,7 @@ _intel_batchbuffer_flush_fence(struct brw_context *brw,
>bytes_for_commands, 100.0f * bytes_for_commands / BATCH_SZ,
>bytes_for_state, 100.0f * bytes_for_state / STATE_SZ,
>brw->batch.exec_count,
> -  (float) brw->batch.aperture_space / (1024 * 1024),
> +  (float) (brw->batch.aperture_space / (1024 * 1024)),
>brw->batch.batch_relocs.reloc_count,
>brw->batch.state_relocs.reloc_count);
>
> @@ -890,13 +890,6 @@ _intel_batchbuffer_flush_fence(struct brw_context
> *brw,
> return ret;
>  }
>
> -bool
> -brw_batch_has_aperture_space(struct brw_context *brw, unsigned
> extra_space)
> -{
> -   return brw->batch.aperture_space + extra_space <=
> -  brw->screen->aperture_threshold;
> -}
> -
>  bool
>  brw_batch_references(struct intel_batchbuffer *batch, struct brw_bo *bo)
>  {
> diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.h
> b/src/mesa/drivers/dri/i965/intel_batchbuffer.h
> index d10948f1916..0632142cd31 100644
> --- a/src/mesa/drivers/dri/i965/intel_batchbuffer.h
> +++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.h
> @@ -44,8 +44,12 @@ int _intel_batchbuffer_flush_fence(struct brw_context
> *brw,
>  void intel_batchbuffer_data(struct brw_context *brw,
>  const void *data, GLuint bytes);
>
> -bool brw_batch_has_aperture_space(struct brw_context *brw,
> -  unsigned extra_space_in_bytes);
> +static inline bool
> +brw_batch_has_aperture_space(struct brw_context *brw, uint64_t
> extra_space)
> +{
> +   return brw->batch.aperture_space + extra_space <=
> +  brw->screen->aperture_threshold;
> +}
>

>  bool brw_batch_references(struct intel_batchbuffer *batch, struct brw_bo
> *bo);
>
> --
> 2.19.0.rc2
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] i965/batch: don't ignore the 'brw_new_batch' call for a 'new batch'

[andrey simiklit]

Hello,

Thanks for your reply.
Please find my comments below:

On Mon, Sep 10, 2018 at 2:45 PM Chris Wilson 
wrote:

> Quoting andrey simiklit (2018-08-21 13:00:57)
> > Hi all,
> >
> > The bug for this issue was created:
> > https://bugs.freedesktop.org/show_bug.cgi?id=107626
>
> What about something like
>

Yes I think it is good idea.
One more point, there are multiple places where 'saving/restoring' api is
used and
I guess that each should be fixed.
That is why I added my solution into location where it could fix each of
them.
But your solution will be better for performance I think.
Is it acceptable for you to merge our solutions to:

---
 src/mesa/drivers/dri/i965/brw_compute.c   |  3 ++-
 src/mesa/drivers/dri/i965/brw_draw.c  |  3 ++-
 src/mesa/drivers/dri/i965/genX_blorp_exec.c   |  3 ++-
 src/mesa/drivers/dri/i965/intel_batchbuffer.c | 12 
 src/mesa/drivers/dri/i965/intel_batchbuffer.h |  1 +
 5 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_compute.c
b/src/mesa/drivers/dri/i965/brw_compute.c
index de08fc3..5c8e3a5 100644
--- a/src/mesa/drivers/dri/i965/brw_compute.c
+++ b/src/mesa/drivers/dri/i965/brw_compute.c
@@ -167,7 +167,7 @@ static void
 brw_dispatch_compute_common(struct gl_context *ctx)
 {
struct brw_context *brw = brw_context(ctx);
-   bool fail_next = false;
+   bool fail_next;

if (!_mesa_check_conditional_render(ctx))
   return;
@@ -185,6 +185,7 @@ brw_dispatch_compute_common(struct gl_context *ctx)
intel_batchbuffer_require_space(brw, 600);
brw_require_statebuffer_space(brw, 2500);
intel_batchbuffer_save_state(brw);
+   fail_next = intel_batchbuffer_saved_state_is_empty(brw);

  retry:
brw->batch.no_wrap = true;
diff --git a/src/mesa/drivers/dri/i965/brw_draw.c
b/src/mesa/drivers/dri/i965/brw_draw.c
index 8536c04..19ee396 100644
--- a/src/mesa/drivers/dri/i965/brw_draw.c
+++ b/src/mesa/drivers/dri/i965/brw_draw.c
@@ -885,7 +885,7 @@ brw_draw_single_prim(struct gl_context *ctx,
 {
struct brw_context *brw = brw_context(ctx);
const struct gen_device_info *devinfo = &brw->screen->devinfo;
-   bool fail_next = false;
+   bool fail_next;

/* Flag BRW_NEW_DRAW_CALL on every draw.  This allows us to have
 * atoms that happen on every draw call.
@@ -898,6 +898,7 @@ brw_draw_single_prim(struct gl_context *ctx,
intel_batchbuffer_require_space(brw, 1500);
brw_require_statebuffer_space(brw, 2400);
intel_batchbuffer_save_state(brw);
+   fail_next = intel_batchbuffer_saved_state_is_empty(brw);

if (brw->num_instances != prim->num_instances ||
brw->basevertex != prim->basevertex ||
diff --git a/src/mesa/drivers/dri/i965/genX_blorp_exec.c
b/src/mesa/drivers/dri/i965/genX_blorp_exec.c
index 34bfcad..fd9ce93 100644
--- a/src/mesa/drivers/dri/i965/genX_blorp_exec.c
+++ b/src/mesa/drivers/dri/i965/genX_blorp_exec.c
@@ -268,7 +268,7 @@ genX(blorp_exec)(struct blorp_batch *batch,
assert(batch->blorp->driver_ctx == batch->driver_batch);
struct brw_context *brw = batch->driver_batch;
struct gl_context *ctx = &brw->ctx;
-   bool check_aperture_failed_once = false;
+   bool check_aperture_failed_once;

 #if GEN_GEN >= 11
/* The PIPE_CONTROL command description says:
@@ -309,6 +309,7 @@ retry:
intel_batchbuffer_require_space(brw, 1400);
brw_require_statebuffer_space(brw, 600);
intel_batchbuffer_save_state(brw);
+   check_aperture_failed_once =
intel_batchbuffer_saved_state_is_empty(brw);
brw->batch.no_wrap = true;

 #if GEN_GEN == 6
diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
index 4363b14..e0b7c94 100644
--- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
+++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
@@ -57,6 +57,9 @@ static void
 intel_batchbuffer_reset(struct brw_context *brw);

 static void
+brw_new_batch(struct brw_context *brw);
+
+static void
 dump_validation_list(struct intel_batchbuffer *batch)
 {
fprintf(stderr, "Validation list (length %d):\n", batch->exec_count);
@@ -299,6 +302,13 @@ intel_batchbuffer_save_state(struct brw_context *brw)
brw->batch.saved.exec_count = brw->batch.exec_count;
 }

+bool
+intel_batchbuffer_saved_state_is_empty(struct brw_context *brw)
+{
+   struct intel_batchbuffer *batch = &brw->batch;
+   return (batch->saved.map_next == batch->batch.map);
+}
+
 void
 intel_batchbuffer_reset_to_saved(struct brw_context *brw)
 {
@@ -311,6 +321,8 @@ intel_batchbuffer_reset_to_saved(struct brw_context
*brw)
brw->batch.exec_count = brw->batch.saved.exec_count;

brw->batch.map_next = brw->batch.saved.map_next;
+   if (USED_BATCH(brw->batch) == 0)
+brw_new_batch(brw);
 }

 void
diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.h
b/src/mesa/drivers/dri/i965/intel_batchbuffer.h
index

Re: [Mesa-dev] [PATCH v4 0/8] mesa: fix usage of [v][s][n]printf functions

[andrey simiklit]

Hi all,

Could somebody helps me push the remaining patches which were already
reviewed:

1. [PATCH v5 5/8] mesa/main: don't use win _vsnprintf. there is
'util_vsnprintf' function
https://patchwork.freedesktop.org/patch/247749/
2. [PATCH v5 6/8] util: use cross platform implementation 'util_vsnprintf'
https://patchwork.freedesktop.org/patch/247748/
3. [PATCH v4 7/8] radv: use cross platform implementation 'util_vsnprintf'
https://patchwork.freedesktop.org/patch/247611/
4. [PATCH v4 8/8] egl/main: use cross platform implementation
'util_vsnprintf'
https://patchwork.freedesktop.org/patch/247612/

Regards,
Andrii.
On Fri, Sep 7, 2018 at 12:42 PM andrey simiklit 
wrote:

> On Fri, Sep 7, 2018 at 12:09 PM Emil Velikov 
> wrote:
>
>> On 6 September 2018 at 17:58, Eric Engestrom 
>> wrote:
>> > On Thursday, 2018-09-06 17:43:50 +0300, asimiklit.w...@gmail.com wrote:
>> >> From: Andrii Simiklit 
>> >>
>> >> This patch improve usage of [v][s][n]printf functions.
>> >> Fixes cross platform implementation of vsnprintf
>> >>
>> >> v2: Linux man about vXXXprintf functions:
>> >> "These functions do not call the va_end macro. Because they
>> >>  invoke the va_arg  macro, the value of ap is undefined after the
>> call"
>> >>  So we should have instance copy of va_list for each 'vXXXprintf'
>> call.
>> >>
>> >> v3: Fixed case when malloc returns 0 in util_vasprintf
>> >>
>> >> v4: The single patch was separated to the patch series
>> >>
>> >> Andrii Simiklit (8):
>> >>   apple/glx/log: added missing va_end() after va_copy()
>> >>   mesa/util: don't use the same 'va_list' instance twice
>> >>   mesa/util: don't ignore NULL returned from 'malloc'
>> >>   mesa/util: add missing va_end() after va_copy()
>> >
>> > First 4 are
>> > Reviewed-by: Eric Engestrom 
>> > and pushed :)
>> >
>> > Thanks for taking the time to find the right Fixes: btw, that really
>> > helps when backporting to stable branches :)
>> >
>> Small nitpick: "mesa/util" should be just "util".
>> Regardless, patches are spot on. Kudos for all the Fixes tags.
>>
>> >>   mesa/main: don't use win _vsnprintf. there is 'util_vsnprintf'
>> >> function
>> As-is, or reworked to drop the _mesa_ function (as Ian suggested) patch is
>> Reviewed-by: Emil Velikov 
>>
>
> Changes are in progress. Thanks for reviewing.
>
>
>> >>   mesa/util: use cross platform implementation 'util_vsnprintf'
>> >
>> "mesa/util" -> "util", with that
>> Reviewed-by: Emil Velikov 
>>
>
> I will change it.
>
>
>>
>>
>> >>   radv: use cross platform implementation 'util_vsnprintf'
>> >>   egl/main: use cross platform implementation 'util_vsnprintf'
>> >
>> > These two are:
>> > Acked-by: Eric Engestrom 
>> >
>> Reviewed-by: Emil Velikov 
>>
>> Admittedly, I doubt we'll get radv on Windows soon. At least not
>> before we bump the requirement to MSVC2015 which has C99 compliant
>> function.
>>
>
> Agree)
> It would be great if it was similar to other places of the mesa code.
> Thanks for reviewing.
>
>
>> HTH
>> Emil
>>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] i965/glsl: don't add unused aoa elements to the program resource list

[andrey simiklit]

Hello,

Thanks a lot for reviewing and testing on CI.
I will send new patch as soon as fix all these issues.

Regards,
Andrii.

On Thu, Sep 13, 2018 at 2:32 PM Tapani Pälli  wrote:

>
>
> On 09/07/2018 03:25 PM, andrey simiklit wrote:
> > Hi all,
> >
> > Could somebody run it on CI to confirm that this patch fixes one test
> > and not add regressions or maybe even take a look at this patch)
>
> CI reports failures in following conformance test:
>
> KHR-GL46.enhanced_layouts.varying_structure_locations
>
> As example:
>
> --- 8< ---
> Test case (float) failed.
> FAILURE. Test case: mat2. Inspection of separable draw program interface
> failed:
> Failed to query program for varying: single. Reason:
> GetProgramResourceiv: glGetError() returned GL_INVALID_VALUE at
> gl4cEnhancedLayoutsTests.cpp:3073
> Failed to query program for varying: array. Reason:
> GetProgramResourceiv: glGetError() returned GL_INVALID_VALUE at
> gl4cEnhancedLayoutsTests.cpp:3073
> --- 8< ---
>
> There are similar/same failures for each glsl type.
>
> Please find couple of small review notes below.
>
> > Regards,
> > Andrii.
> >
> > On Fri, Aug 31, 2018 at 5:13 PM  > <mailto:asimiklit.w...@gmail.com>> wrote:
> >
> > From: Andrii Simiklit  > <mailto:andrii.simik...@globallogic.com>>
> >
> > It fixes a bit incorrectly implemented ARB_program_interface_query.
> > If input aoa element is unused in shader program
> > the 'glGetProgramResourceIndex' function shouldn't
> > return a valid resource index for it according to:
> > ARB_program_interface_query spec:
> >  " For an active variable declared as an array of an aggregate
> > data type
> >  (structures or arrays), a separate entry will be generated
> > for each
> >  active array element"
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92822
> > Signed-off-by: Andrii Simiklit  > <mailto:andrii.simik...@globallogic.com>>
> > ---
> >   src/compiler/Makefile.sources  |   4 +-
> >   .../glsl/ir_collect_active_aoa_elements.cpp| 148
> > +
> >   src/compiler/glsl/ir_collect_active_aoa_elements.h |  49 +++
> >   src/compiler/glsl/linker.cpp   |  75
> +--
> >   src/compiler/glsl/meson.build  |   2 +
> >   5 files changed, 265 insertions(+), 13 deletions(-)
> >   create mode 100644
> > src/compiler/glsl/ir_collect_active_aoa_elements.cpp
> >   create mode 100644
> src/compiler/glsl/ir_collect_active_aoa_elements.h
> >
> > diff --git a/src/compiler/Makefile.sources
> > b/src/compiler/Makefile.sources
> > index d3b0656..a2ba3e3 100644
> > --- a/src/compiler/Makefile.sources
> > +++ b/src/compiler/Makefile.sources
> > @@ -154,7 +154,9 @@ LIBGLSL_FILES = \
> >  glsl/serialize.cpp \
> >  glsl/serialize.h \
> >  glsl/string_to_uint_map.cpp \
> > -   glsl/string_to_uint_map.h
> > +   glsl/string_to_uint_map.h \
> > +   glsl/ir_collect_active_aoa_elements.cpp \
> > +   glsl/ir_collect_active_aoa_elements.h
> >
> >   LIBGLSL_SHADER_CACHE_FILES = \
> >  glsl/shader_cache.cpp \
> > diff --git a/src/compiler/glsl/ir_collect_active_aoa_elements.cpp
> > b/src/compiler/glsl/ir_collect_active_aoa_elements.cpp
> > new file mode 100644
> > index 000..50042c7
> > --- /dev/null
> > +++ b/src/compiler/glsl/ir_collect_active_aoa_elements.cpp
> > @@ -0,0 +1,148 @@
> > +/*
> > + * Copyright © 2018 Intel Corporation
> > + *
> > + * Permission is hereby granted, free of charge, to any person
> > obtaining a
> > + * copy of this software and associated documentation files (the
> > "Software"),
> > + * to deal in the Software without restriction, including without
> > limitation
> > + * the rights to use, copy, modify, merge, publish, distribute,
> > sublicense,
> > + * and/or sell copies of the Software, and to permit persons to
> > whom the
> > + * Software is furnished to do so, subject to the following
> conditions:
> > + *
> > + * The above copyright notice and this permission notice (including
> > the next
> > + * paragraph) shall be included in all cop

Re: [Mesa-dev] [PATCH 2/2 (resend)] virgl: Pass resource size and transfer offsets

[andrey simiklit]

Hello,

Please find my comment below:

Regards,
Andrii.
On Fri, Sep 14, 2018 at 12:23 PM Gert Wollny 
wrote:

> From: Tomeu Vizoso 
>
> Pass the size of a resource when creating it so a backing can be kept in
> the other side.
>
> Also pass the required offset to transfer commands.
>
> This moves vtest closer to how virtio-gpu works, making it more useful
> for testing.
>
> v2: - Use new messages for creation and transfers, as changing the
>   behavior of the existing messages would be messy given that we don't
>   want to break compatibility with older servers.
>
> v3: - Gert: Use correct strides: The resource corresponding to the output
>   display might have a differnt line stride then the IOVs, so when
>   reading back to this resource take the resource stride and the the
>   IOV stride into account.
>
> Signed-off-by: Tomeu Vizoso  (v2)
> Signed-off-by: Gert Wollny 
> ---
>  .../winsys/virgl/vtest/virgl_vtest_socket.c| 143
> +++--
>  .../winsys/virgl/vtest/virgl_vtest_winsys.c|  38 --
>  .../winsys/virgl/vtest/virgl_vtest_winsys.h|  19 ++-
>  src/gallium/winsys/virgl/vtest/vtest_protocol.h|  29 +
>  4 files changed, 201 insertions(+), 28 deletions(-)
>
> diff --git a/src/gallium/winsys/virgl/vtest/virgl_vtest_socket.c
> b/src/gallium/winsys/virgl/vtest/virgl_vtest_socket.c
> index 4d20a63ad6..3aa01aabdf 100644
> --- a/src/gallium/winsys/virgl/vtest/virgl_vtest_socket.c
> +++ b/src/gallium/winsys/virgl/vtest/virgl_vtest_socket.c
> @@ -221,6 +221,42 @@ int virgl_vtest_send_get_caps(struct
> virgl_vtest_winsys *vws,
> return 0;
>  }
>
> +static int virgl_vtest_send_resource_create2(struct virgl_vtest_winsys
> *vws,
> + uint32_t handle,
> + enum pipe_texture_target
> target,
> + uint32_t format,
> + uint32_t bind,
> + uint32_t width,
> + uint32_t height,
> + uint32_t depth,
> + uint32_t array_size,
> + uint32_t last_level,
> + uint32_t nr_samples,
> + uint32_t size)
> +{
> +   uint32_t res_create_buf[VCMD_RES_CREATE2_SIZE],
> vtest_hdr[VTEST_HDR_SIZE];
> +
> +   vtest_hdr[VTEST_CMD_LEN] = VCMD_RES_CREATE2_SIZE;
> +   vtest_hdr[VTEST_CMD_ID] = VCMD_RESOURCE_CREATE2;
> +
> +   res_create_buf[VCMD_RES_CREATE2_RES_HANDLE] = handle;
> +   res_create_buf[VCMD_RES_CREATE2_TARGET] = target;
> +   res_create_buf[VCMD_RES_CREATE2_FORMAT] = format;
> +   res_create_buf[VCMD_RES_CREATE2_BIND] = bind;
> +   res_create_buf[VCMD_RES_CREATE2_WIDTH] = width;
> +   res_create_buf[VCMD_RES_CREATE2_HEIGHT] = height;
> +   res_create_buf[VCMD_RES_CREATE2_DEPTH] = depth;
> +   res_create_buf[VCMD_RES_CREATE2_ARRAY_SIZE] = array_size;
> +   res_create_buf[VCMD_RES_CREATE2_LAST_LEVEL] = last_level;
> +   res_create_buf[VCMD_RES_CREATE2_NR_SAMPLES] = nr_samples;
> +   res_create_buf[VCMD_RES_CREATE2_DATA_SIZE] = size;
> +
> +   virgl_block_write(vws->sock_fd, &vtest_hdr, sizeof(vtest_hdr));
> +   virgl_block_write(vws->sock_fd, &res_create_buf,
> sizeof(res_create_buf));
> +
> +   return 0;
> +}
> +
>  int virgl_vtest_send_resource_create(struct virgl_vtest_winsys *vws,
>   uint32_t handle,
>   enum pipe_texture_target target,
> @@ -231,10 +267,17 @@ int virgl_vtest_send_resource_create(struct
> virgl_vtest_winsys *vws,
>   uint32_t depth,
>   uint32_t array_size,
>   uint32_t last_level,
> - uint32_t nr_samples)
> + uint32_t nr_samples,
> + uint32_t size)
>  {
> uint32_t res_create_buf[VCMD_RES_CREATE_SIZE],
> vtest_hdr[VTEST_HDR_SIZE];
>
> +   if (vws->protocol_version >= 1)
> +  return virgl_vtest_send_resource_create2(vws, handle, target,
> format,
> +   bind, width, height, depth,
> +   array_size, last_level,
> +   nr_samples, size);
> +
> vtest_hdr[VTEST_CMD_LEN] = VCMD_RES_CREATE_SIZE;
> vtest_hdr[VTEST_CMD_ID] = VCMD_RESOURCE_CREATE;
>
> @@ -282,7 +325,7 @@ int virgl_vtest_send_resource_unref(struct
> virgl_vtest_winsys *vws,
> return 0;
>  }
>
> -int virgl_vtest_send_transfer_cmd(struct virgl_vtest_winsys *vws,
> +static int virgl_vtest_send_transfer_cmd(struct virgl_vtest_winsys *vws,
>uint32_t vcmd,
> 

Re: [Mesa-dev] [PATCH] Revert "radeonsi: avoid syncing the driver thread in si_fence_finish"

[andrey simiklit]

Hi,

Please find my comments below:

Regards,
Andrii.

On Tue, Sep 18, 2018 at 4:49 AM Marek Olšák  wrote:

> Reviewed-by: Marek Olšák 
>
> Marek
>
> On Wed, Sep 12, 2018 at 6:50 AM, Timothy Arceri 
> wrote:
> > This reverts commit bc65dcab3bc48673ff6180afb036561a4b8b1119.
> >
> > This was manually reverted. Reverting stops the menu hanging in
> > some id tech games such as RAGE and Wolfenstein The New Order.
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107891
> > ---
> >  .../auxiliary/util/u_threaded_context.h   |  8 --
> >  src/gallium/drivers/radeonsi/si_fence.c   | 82 +--
> >  src/gallium/drivers/radeonsi/si_gfx_cs.c  |  2 -
> >  3 files changed, 40 insertions(+), 52 deletions(-)
> >
> > diff --git a/src/gallium/auxiliary/util/u_threaded_context.h
> b/src/gallium/auxiliary/util/u_threaded_context.h
> > index be6933d05a4..a32f893592a 100644
> > --- a/src/gallium/auxiliary/util/u_threaded_context.h
> > +++ b/src/gallium/auxiliary/util/u_threaded_context.h
> > @@ -408,14 +408,6 @@ threaded_transfer(struct pipe_transfer *transfer)
> > return (struct threaded_transfer*)transfer;
> >  }
> >
> > -static inline struct pipe_context *
> > -threaded_context_unwrap_unsync(struct pipe_context *pipe)
> > -{
> > -   if (!pipe || !pipe->priv)
> > -  return pipe;
> > -   return (struct pipe_context*)pipe->priv;
> > -}
> > -
> >  static inline void
> >  tc_unflushed_batch_token_reference(struct tc_unflushed_batch_token
> **dst,
> > struct tc_unflushed_batch_token *src)
> > diff --git a/src/gallium/drivers/radeonsi/si_fence.c
> b/src/gallium/drivers/radeonsi/si_fence.c
> > index 186a785437d..abb7057f299 100644
> > --- a/src/gallium/drivers/radeonsi/si_fence.c
> > +++ b/src/gallium/drivers/radeonsi/si_fence.c
> > @@ -291,8 +291,12 @@ static boolean si_fence_finish(struct pipe_screen
> *screen,
> >  {
> > struct radeon_winsys *rws = ((struct si_screen*)screen)->ws;
> > struct si_multi_fence *rfence = (struct si_multi_fence *)fence;
> > +   struct si_context *sctx;
> > int64_t abs_timeout = os_time_get_absolute_timeout(timeout);
> >
> > +   ctx = threaded_context_unwrap_sync(ctx);
> > +   sctx = (struct si_context*)(ctx ? ctx : NULL);
>

Looks like it should be like:
sctx = (struct si_context*)ctx;
or maybe you meant:
sctx = (struct si_context*)(ctx ? ctx->** : NULL);

> +
> > if (!util_queue_fence_is_signalled(&rfence->ready)) {
> > if (rfence->tc_token) {
> > /* Ensure that si_flush_from_st will be called
> for
> > @@ -345,49 +349,43 @@ static boolean si_fence_finish(struct pipe_screen
> *screen,
> > }
> >
> > /* Flush the gfx IB if it hasn't been flushed yet. */
> > -   if (ctx && rfence->gfx_unflushed.ctx) {
> > -   struct si_context *sctx;
> > -
> > -   sctx = (struct si_context
> *)threaded_context_unwrap_unsync(ctx);
> > -   if (rfence->gfx_unflushed.ctx == sctx &&
> > -   rfence->gfx_unflushed.ib_index ==
> sctx->num_gfx_cs_flushes) {
> > -   /* Section 4.1.2 (Signaling) of the OpenGL 4.6
> (Core profile)
> > -* spec says:
> > -*
> > -*"If the sync object being blocked upon
> will not be
> > -* signaled in finite time (for example, by
> an associated
> > -* fence command issued previously, but not
> yet flushed to
> > -* the graphics pipeline), then
> ClientWaitSync may hang
> > -* forever. To help prevent this behavior, if
> > -* ClientWaitSync is called and all of the
> following are
> > -* true:
> > -*
> > -* * the SYNC_FLUSH_COMMANDS_BIT bit is set
> in flags,
> > -* * sync is unsignaled when ClientWaitSync
> is called,
> > -* * and the calls to ClientWaitSync and
> FenceSync were
> > -*   issued from the same context,
> > -*
> > -* then the GL will behave as if the
> equivalent of Flush
> > -* were inserted immediately after the
> creation of sync."
> > -*
> > -* This means we need to flush for such fences
> even when we're
> > -* not going to wait.
> > -*/
> > -   threaded_context_unwrap_sync(ctx);
> > -   si_flush_gfx_cs(sctx,
> > -   (timeout ? 0 : PIPE_FLUSH_ASYNC)
> |
> > -
> RADEON_FLUSH_START_NEXT_GFX_IB_NOW,
> > -   NULL);
> > -   rfence->gfx_unflushed.ctx = NULL

Re: [Mesa-dev] [PATCH mesa 3/6] vulkan/wsi/display: pass the plane's modifiers to the image

[andrey simiklit]

Hi,

Please find my comment below:

Regards,
Andrii.

On Wed, Sep 26, 2018 at 6:39 PM Eric Engestrom 
wrote:

> Signed-off-by: Eric Engestrom 
> ---
>  src/vulkan/wsi/wsi_common_display.c | 95 -
>  1 file changed, 94 insertions(+), 1 deletion(-)
>
> diff --git a/src/vulkan/wsi/wsi_common_display.c
> b/src/vulkan/wsi/wsi_common_display.c
> index 6c9160a445c8f25a8ad5..2a30b1139f06cbb56769 100644
> --- a/src/vulkan/wsi/wsi_common_display.c
> +++ b/src/vulkan/wsi/wsi_common_display.c
> @@ -958,6 +958,87 @@ wsi_display_destroy_buffer(struct wsi_display *wsi,
> &((struct drm_mode_destroy_dumb) { .handle = buffer
> }));
>  }
>
> +static uint64_t*
> +wsi_get_modifiers_for_format(const struct wsi_display * const wsi,
> + const uint32_t plane_id,
> + const uint32_t drm_format,
> + uint32_t * const modifiers_count)
> +{
> +   /* Get the properties of the plane */
> +   drmModeObjectProperties *props =
> +  drmModeObjectGetProperties(wsi->fd, plane_id,
> + DRM_MODE_OBJECT_PLANE);
> +   if (!props)
> +  return NULL;
> +
> +   /* Find the blob the contains the formats and their modifiers */
> +   uint32_t blob_id = 0;
> +   for (size_t i = 0; i< props->count_props; i++) {
> +  const drmModePropertyPtr prop =
> + drmModeGetProperty(wsi->fd, props->props[i]);
> +
> +  if (!strcmp(prop->name, "IN_FORMATS")) {
> + blob_id = props->prop_values[i];
> + drmModeFreeProperty(prop);
> + break;
> +  }
> +
> +  drmModeFreeProperty(prop);
> +   }
> +
> +   /* Property not found, which means old kernel, so definitely no
> +* modifiers support */
> +   if (blob_id == 0)
> +  return NULL;
> +
> +   /* Grab the IN_FORMATS blob */
> +   drmModePropertyBlobRes *blob = drmModeGetPropertyBlob(wsi->fd,
> blob_id);
> +   if (!blob)
> +  return NULL;
> +
> +   /* Get the formats and modifiers out of the blob */
> +   struct drm_format_modifier_blob *fmt_mod_blob = blob->data;
> +   uint32_t *blob_formats = (uint32_t*)((char*)fmt_mod_blob +
> +fmt_mod_blob->formats_offset);
> +   struct drm_format_modifier *blob_modifiers =
> +  (struct drm_format_modifier *)((char*)fmt_mod_blob +
> + fmt_mod_blob->modifiers_offset);
> +
> +   /* Find the format we care about in the list */
> +   size_t format_index = 0;
> +   for (size_t i = 0; i < fmt_mod_blob->count_formats; i++) {
> +  if (blob_formats[i] == drm_format) {
> + format_index = i;
> + break;
> +  }
> +   }
> +
> +   /* Get the list of modifiers supported by that format */
> +   uint32_t count_modifiers = 0;
> +   uint64_t *modifiers = NULL;
> +   for (size_t i = 0; i < fmt_mod_blob->count_modifiers; i++) {
> +  struct drm_format_modifier *mod = &blob_modifiers[i];
> +
> +  if ((format_index < mod->offset) || (format_index > mod->offset +
> 63))
> + continue;
> +  if (!(mod->formats & (1 << (format_index - mod->offset
>

Would it be better to use '1ull << ... ' here?
The 'formats' filed is defined as '__u64 formats'.

+ continue;
> +
> +  modifiers = realloc(modifiers,
> +  (count_modifiers + 1) *
> +  sizeof(modifiers[0]));
> +  assert(modifiers);
> +  modifiers[count_modifiers++] = mod->modifier;
> +   }
> +
> +   drmModeFreePropertyBlob(blob);
> +
> +   drmModeFreeObjectProperties(props);
> +
> +   *modifiers_count = count_modifiers;
> +   return modifiers;
> +}
> +
>  static VkResult
>  wsi_display_image_init(VkDevice device_h,
> struct wsi_swapchain *drv_chain,
> @@ -969,6 +1050,10 @@ wsi_display_image_init(VkDevice device_h,
>(struct wsi_display_swapchain *) drv_chain;
> struct wsi_display *wsi = chain->wsi;
> uint32_t drm_format = 0;
> +   VkIcdSurfaceDisplay *surface = chain->surface;
> +   wsi_display_mode *display_mode =
> +  wsi_display_mode_from_handle(surface->displayMode);
> +   wsi_display_connector *connector = display_mode->connector;
>
> for (unsigned i = 0; i < ARRAY_SIZE(available_surface_formats); i++) {
>if (create_info->imageFormat ==
> available_surface_formats[i].format) {
> @@ -981,9 +1066,17 @@ wsi_display_image_init(VkDevice device_h,
> if (drm_format == 0)
>return VK_ERROR_DEVICE_LOST;
>
> +   uint32_t modifiers_count = 0;
> +   uint64_t *modifiers = wsi_get_modifiers_for_format(wsi,
> connector->plane_id, drm_format,
> +  &modifiers_count);
> +   assume(!modifiers || modifiers_count > 0);
> +
> VkResult result = wsi_create_native_image(&chain->base, create_info,
> - 0, NULL, NULL,
> + !!modifiers_count,
> +

Re: [Mesa-dev] [PATCH 2/4] i965: be more specific about FBO completeness errors

[andrey simiklit]

Hello,

I tried to compile latest mesa master this morning but faced with a
compilation error:
   intel_fbo.c: In function ‘intel_validate_framebuffer’:
   intel_fbo.c:696:25: error: ‘GL_FRAMEBUFFER_INCOMPLETE_DIMENSIONS’
undeclared (first use in this function); did you mean
‘GL_FRAMEBUFFER_INCOMPLETE_DIMENSIONS_EXT’?
 fbo_incomplete(fb, GL_FRAMEBUFFER_INCOMPLETE_DIMENSIONS,
^
   intel_fbo.c:642:21: note: in definition of macro ‘fbo_incomplete’
  fb->_Status =
error_id; \
^~~~
   intel_fbo.c:696:25: note: each undeclared identifier is reported only
once for each function it appears in
 fbo_incomplete(fb, GL_FRAMEBUFFER_INCOMPLETE_DIMENSIONS,
^
   intel_fbo.c:642:21: note: in definition of macro ‘fbo_incomplete’
  fb->_Status =
error_id; \

This small change helped me but I can't say for sure that it is right:
diff --git a/src/mesa/drivers/dri/i965/intel_fbo.c
b/src/mesa/drivers/dri/i965/intel_fbo.c
index febd1aca98..5d870c65f8 100644
--- a/src/mesa/drivers/dri/i965/intel_fbo.c
+++ b/src/mesa/drivers/dri/i965/intel_fbo.c
@@ -693,7 +693,7 @@ intel_validate_framebuffer(struct gl_context *ctx,
struct gl_framebuffer *fb)
  d_depth != s_depth ||
  depthRb->mt_level != stencilRb->mt_level ||
 depthRb->mt_layer != stencilRb->mt_layer) {
-   fbo_incomplete(fb, GL_FRAMEBUFFER_INCOMPLETE_DIMENSIONS,
+   fbo_incomplete(fb, GL_FRAMEBUFFER_INCOMPLETE_DIMENSIONS_EXT,
"FBO incomplete: depth and stencil must match
in"
"width, height, depth, LOD and layer\n");
 }

Thanks,
Andrii.

On Thu, Nov 15, 2018 at 8:01 PM Gert Wollny 
wrote:

> The driver was returning GL_FRAMEBUFFER_UNSUPPORTED for all cases of an
> incomplete fbo, be a bit more specific about this following the description
> of glCheckFramebufferStatus.
>
> This helps to keeps dEQP happy when adding EXT_texture_sRGB_R8 support.
>
> Signed-off-by: Gert Wollny 
> ---
>  src/mesa/drivers/dri/i965/intel_fbo.c | 42 +++
>  1 file changed, 23 insertions(+), 19 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/intel_fbo.c
> b/src/mesa/drivers/dri/i965/intel_fbo.c
> index 2bbbc34114..d657fdf8e4 100644
> --- a/src/mesa/drivers/dri/i965/intel_fbo.c
> +++ b/src/mesa/drivers/dri/i965/intel_fbo.c
> @@ -629,7 +629,7 @@ intel_render_texture(struct gl_context * ctx,
>  }
>
>
> -#define fbo_incomplete(fb, ...) do {
> \
> +#define fbo_incomplete(fb, error_id, ...) do {
>   \
>static GLuint msg_id = 0;
>  \
>if (unlikely(ctx->Const.ContextFlags & GL_CONTEXT_FLAG_DEBUG_BIT))
> {\
>   _mesa_gl_debug(ctx, &msg_id,
>  \
> @@ -639,7 +639,7 @@ intel_render_texture(struct gl_context * ctx,
>  __VA_ARGS__);
>  \
>}
>  \
>DBG(__VA_ARGS__);
>  \
> -  fb->_Status = GL_FRAMEBUFFER_UNSUPPORTED;
>  \
> +  fb->_Status = error_id;
>  \
> } while (0)
>
>  /**
> @@ -693,7 +693,7 @@ intel_validate_framebuffer(struct gl_context *ctx,
> struct gl_framebuffer *fb)
>   d_depth != s_depth ||
>   depthRb->mt_level != stencilRb->mt_level ||
>  depthRb->mt_layer != stencilRb->mt_layer) {
> -   fbo_incomplete(fb,
> +   fbo_incomplete(fb, GL_FRAMEBUFFER_INCOMPLETE_DIMENSIONS,
> "FBO incomplete: depth and stencil must match
> in"
> "width, height, depth, LOD and layer\n");
>  }
> @@ -705,7 +705,7 @@ intel_validate_framebuffer(struct gl_context *ctx,
> struct gl_framebuffer *fb)
>   */
>  if (depthRb->mt_level != stencilRb->mt_level ||
>  depthRb->mt_layer != stencilRb->mt_layer) {
> -   fbo_incomplete(fb,
> +   fbo_incomplete(fb, GL_FRAMEBUFFER_UNSUPPORTED,
> "FBO incomplete: depth image level/layer %d/%d
> != "
> "stencil image %d/%d\n",
> depthRb->mt_level,
> @@ -715,13 +715,14 @@ intel_validate_framebuffer(struct gl_context *ctx,
> struct gl_framebuffer *fb)
>  }
>} else {
>  if (!brw->has_separate_stencil) {
> -   fbo_incomplete(fb, "FBO incomplete: separate stencil "
> -   "unsupported\n");
> +   fbo_incomplete(fb, GL_FRAMEBUFFER_UNSUPPORTED,
> +  "FBO incomplete: separate stencil unsupported\n");
>  }
>  if (stencil_mt->format != MESA_FORMAT_S_UINT8) {
> -   fbo_incomplete(fb, "FBO incomplete: separate stencil is %s "
> -   "instead of S8\n",
> -   _mesa_get_format_name(stencil_mt->format));
> +   fbo_incomplete(fb, GL_FRAMEBUFFER_INCO

Re: [Mesa-dev] [PATCH v4 5/5] intel/tools: make sure the binary file is properly read

[andrey simiklit]

Hello,

Could you please take a look on this v4 if it is possible?

Thanks,
Andrii.

On Wed, Nov 14, 2018 at 6:30 PM  wrote:

> From: Andrii Simiklit 
>
> 1. tools/i965_disasm.c:58:4: warning:
>  ignoring return value of ‘fread’,
>  declared with attribute warn_unused_result
>  fread(assembly, *end, 1, fp);
>
> v2: Fixed incorrect return value check.
>( Eric Engestrom  )
>
> v3: Zero size file check placed before fread with exit()
>( Eric Engestrom  )
>
> v4: - Title is changed.
> - The 'size' variable was moved to top of a function scope.
> - The assertion was replaced by the proper error handling.
> - The error message on a caller side was fixed.
>( Eric Engestrom  )
>
> Signed-off-by: Andrii Simiklit 
> ---
>  src/intel/tools/i965_disasm.c | 16 +---
>  1 file changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/src/intel/tools/i965_disasm.c b/src/intel/tools/i965_disasm.c
> index 73a6760fc1..0efbdab706 100644
> --- a/src/intel/tools/i965_disasm.c
> +++ b/src/intel/tools/i965_disasm.c
> @@ -47,17 +47,23 @@ i965_disasm_get_file_size(FILE *fp)
>  static void *
>  i965_disasm_read_binary(FILE *fp, size_t *end)
>  {
> +   size_t size;
> void *assembly;
>
> *end = i965_disasm_get_file_size(fp);
> +   if (!*end)
> +  return NULL;
>
> assembly = malloc(*end + 1);
> if (assembly == NULL)
>return NULL;
>
> -   fread(assembly, *end, 1, fp);
> +   size = fread(assembly, *end, 1, fp);
> fclose(fp);
> -
> +   if (!size) {
> +  free(assembly);
> +  return NULL;
> +   }
> return assembly;
>  }
>
> @@ -167,7 +173,11 @@ int main(int argc, char *argv[])
>
> assembly = i965_disasm_read_binary(fp, &end);
> if (!assembly) {
> -  fprintf(stderr, "Unable to allocate buffer to read binary file\n");
> +  if(end)
> +fprintf(stderr, "Unable to allocate buffer to read binary
> file\n");
> +  else
> +fprintf(stderr, "Input file is empty\n");
> +

   exit(EXIT_FAILURE);
> }
>
> --
> 2.17.1
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] miptree: test ability to use upside down miptree

[andrey simiklit]

Hello,

Could somebody take a look at this patch?

Thanks a lot,
Andrii.

On Tue, Nov 6, 2018 at 12:33 PM andrey simiklit 
wrote:

> Hi all,
>
> Have somebody some suggestions for this test?
> This patch is needed to test an issue (assertion in mesa) which will be
> fixed by this mesa patch:
> https://patchwork.freedesktop.org/patch/254397/
>
> Regards,
> Andrii.
>
> On Tue, Oct 23, 2018 at 4:44 PM  wrote:
>
>> From: Andrii Simiklit 
>>
>> Test that usage of upside down miptree doesn't cause assertion
>>
>> The miptree:
>>
>> level 0 = 1x1
>> level 1 = 2x2
>> level 2 = 4x4
>> ...
>> level n = NxN
>>
>> should be acceptable for case when we don't use a min filter.
>>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107987
>> Signed-off-by: Andrii Simiklit 
>> ---
>>  tests/opengl.py   |   1 +
>>  tests/texturing/CMakeLists.gl.txt |   1 +
>>  tests/texturing/tex-upside-down-miptree.c | 171 ++
>>  3 files changed, 173 insertions(+)
>>  create mode 100644 tests/texturing/tex-upside-down-miptree.c
>>
>> diff --git a/tests/opengl.py b/tests/opengl.py
>> index f7e408cd5..f6a38e40e 100644
>> --- a/tests/opengl.py
>> +++ b/tests/opengl.py
>> @@ -704,6 +704,7 @@ with profile.test_list.group_manager(
>>  g(['getteximage-targets', '1D'])
>>  g(['getteximage-targets', '2D'])
>>  g(['teximage-scale-bias'])
>> +g(['tex-upside-down-miptree'])
>>  add_msaa_visual_plain_tests(g, ['draw-pixels'])
>>  add_msaa_visual_plain_tests(g, ['read-front'], run_concurrent=False)
>>  add_msaa_visual_plain_tests(g, ['read-front', 'clear-front-first'],
>> diff --git a/tests/texturing/CMakeLists.gl.txt
>> b/tests/texturing/CMakeLists.gl.txt
>> index e5d41e432..02b572c79 100644
>> --- a/tests/texturing/CMakeLists.gl.txt
>> +++ b/tests/texturing/CMakeLists.gl.txt
>> @@ -98,5 +98,6 @@ piglit_add_executable (texture-al texture-al.c)
>>  piglit_add_executable (texture-rg texture-rg.c)
>>  piglit_add_executable (teximage-colors teximage-colors.c)
>>  piglit_add_executable (zero-tex-coord zero-tex-coord.c)
>> +piglit_add_executable (tex-upside-down-miptree tex-upside-down-miptree.c)
>>
>>  # vim: ft=cmake:
>> diff --git a/tests/texturing/tex-upside-down-miptree.c
>> b/tests/texturing/tex-upside-down-miptree.c
>> new file mode 100644
>> index 0..2d10fb49a
>> --- /dev/null
>> +++ b/tests/texturing/tex-upside-down-miptree.c
>> @@ -0,0 +1,171 @@
>> +/*
>> + * Copyright (c) 2018 Andrii Simiklit
>> + *
>> + * Permission is hereby granted, free of charge, to any person obtaining
>> a
>> + * copy of this software and associated documentation files (the
>> "Software"),
>> + * to deal in the Software without restriction, including without
>> limitation
>> + * the rights to use, copy, modify, merge, publish, distribute,
>> sublicense,
>> + * and/or sell copies of the Software, and to permit persons to whom the
>> + * Software is furnished to do so, subject to the following conditions:
>> + *
>> + * The above copyright notice and this permission notice (including the
>> next
>> + * paragraph) shall be included in all copies or substantial portions of
>> the
>> + * Software.
>> + *
>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>> EXPRESS OR
>> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
>> MERCHANTABILITY,
>> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT
>> SHALL
>> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
>> OTHER
>> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
>> ARISING
>> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
>> DEALINGS
>> + * IN THE SOFTWARE.
>> + *
>> + * Authors:
>> + *Andrii Simiklit 
>> + *
>> + */
>> +
>> +/**
>> + * Test what there no an assertion when we use upside down miptree and
>> + * GL_TEXTURE_MIN_FILTER is GL_LINEAR, base level is not 0
>> + * Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107987
>> + */
>> +
>> +#include "piglit-util-gl.h"
>> +#define TW 64
>> +#define TH 64
>> +
>> +PIGLIT_GL_TEST_CONFIG_BEGIN
>> +
>> +   config.supports_gl_compat_version = 10;

Re: [Mesa-dev] [PATCH v4 5/5] intel/tools: make sure the binary file is properly read

[andrey simiklit]

On Fri, Nov 30, 2018 at 5:49 PM Eric Engestrom 
wrote:

> On Friday, 2018-11-30 15:47:11 +, Lionel Landwerlin wrote:
> > On 14/11/2018 16:30, asimiklit.w...@gmail.com wrote:
> > > From: Andrii Simiklit 
> > >
> > > 1. tools/i965_disasm.c:58:4: warning:
> > >   ignoring return value of ‘fread’,
> > >   declared with attribute warn_unused_result
> > >   fread(assembly, *end, 1, fp);
> > >
> > > v2: Fixed incorrect return value check.
> > > ( Eric Engestrom  )
> > >
> > > v3: Zero size file check placed before fread with exit()
> > > ( Eric Engestrom  )
> > >
> > > v4: - Title is changed.
> > >  - The 'size' variable was moved to top of a function scope.
> > >  - The assertion was replaced by the proper error handling.
> > >  - The error message on a caller side was fixed.
> > > ( Eric Engestrom  )
> > >
> > > Signed-off-by: Andrii Simiklit 
> >
> >
> > With the nit below :
> >
> >
> > Reviewed-by: Lionel Landwerlin 
>
> I'll change that as I push it in a minute :)
> Reviewed-by: Eric Engestrom 
>

Thanks a lot for reviews :)


>
> >
> >
> > > ---
> > >   src/intel/tools/i965_disasm.c | 16 +---
> > >   1 file changed, 13 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/src/intel/tools/i965_disasm.c
> b/src/intel/tools/i965_disasm.c
> > > index 73a6760fc1..0efbdab706 100644
> > > --- a/src/intel/tools/i965_disasm.c
> > > +++ b/src/intel/tools/i965_disasm.c
> > > @@ -47,17 +47,23 @@ i965_disasm_get_file_size(FILE *fp)
> > >   static void *
> > >   i965_disasm_read_binary(FILE *fp, size_t *end)
> > >   {
> > > +   size_t size;
> > >  void *assembly;
> > >  *end = i965_disasm_get_file_size(fp);
> > > +   if (!*end)
> > > +  return NULL;
> > >  assembly = malloc(*end + 1);
> > >  if (assembly == NULL)
> > > return NULL;
> > > -   fread(assembly, *end, 1, fp);
> > > +   size = fread(assembly, *end, 1, fp);
> > >  fclose(fp);
> > > -
> > > +   if (!size) {
> > > +  free(assembly);
> > > +  return NULL;
> > > +   }
> > >  return assembly;
> > >   }
> > > @@ -167,7 +173,11 @@ int main(int argc, char *argv[])
> > >  assembly = i965_disasm_read_binary(fp, &end);
> > >  if (!assembly) {
> > > -  fprintf(stderr, "Unable to allocate buffer to read binary
> file\n");
> > > +  if(end)
> > if (end)
> > > +fprintf(stderr, "Unable to allocate buffer to read binary
> file\n");
> > > +  else
> > > +fprintf(stderr, "Input file is empty\n");
> > > +
> > > exit(EXIT_FAILURE);
> > >  }
> >
> >
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v4 5/5] intel/tools: make sure the binary file is properly read

[andrey simiklit]

Hello,

I'm sorry for disturbing, could I ask you to push this patch if it
possible? )))

Regards,
Andrii.

On Fri, Nov 30, 2018 at 6:19 PM andrey simiklit 
wrote:

> On Fri, Nov 30, 2018 at 5:49 PM Eric Engestrom 
> wrote:
>
>> On Friday, 2018-11-30 15:47:11 +, Lionel Landwerlin wrote:
>> > On 14/11/2018 16:30, asimiklit.w...@gmail.com wrote:
>> > > From: Andrii Simiklit 
>> > >
>> > > 1. tools/i965_disasm.c:58:4: warning:
>> > >   ignoring return value of ‘fread’,
>> > >   declared with attribute warn_unused_result
>> > >   fread(assembly, *end, 1, fp);
>> > >
>> > > v2: Fixed incorrect return value check.
>> > > ( Eric Engestrom  )
>> > >
>> > > v3: Zero size file check placed before fread with exit()
>> > > ( Eric Engestrom  )
>> > >
>> > > v4: - Title is changed.
>> > >  - The 'size' variable was moved to top of a function scope.
>> > >  - The assertion was replaced by the proper error handling.
>> > >  - The error message on a caller side was fixed.
>> > > ( Eric Engestrom  )
>> > >
>> > > Signed-off-by: Andrii Simiklit 
>> >
>> >
>> > With the nit below :
>> >
>> >
>> > Reviewed-by: Lionel Landwerlin 
>>
>> I'll change that as I push it in a minute :)
>> Reviewed-by: Eric Engestrom 
>>
>
> Thanks a lot for reviews :)
>
>
>>
>> >
>> >
>> > > ---
>> > >   src/intel/tools/i965_disasm.c | 16 +---
>> > >   1 file changed, 13 insertions(+), 3 deletions(-)
>> > >
>> > > diff --git a/src/intel/tools/i965_disasm.c
>> b/src/intel/tools/i965_disasm.c
>> > > index 73a6760fc1..0efbdab706 100644
>> > > --- a/src/intel/tools/i965_disasm.c
>> > > +++ b/src/intel/tools/i965_disasm.c
>> > > @@ -47,17 +47,23 @@ i965_disasm_get_file_size(FILE *fp)
>> > >   static void *
>> > >   i965_disasm_read_binary(FILE *fp, size_t *end)
>> > >   {
>> > > +   size_t size;
>> > >  void *assembly;
>> > >  *end = i965_disasm_get_file_size(fp);
>> > > +   if (!*end)
>> > > +  return NULL;
>> > >  assembly = malloc(*end + 1);
>> > >  if (assembly == NULL)
>> > > return NULL;
>> > > -   fread(assembly, *end, 1, fp);
>> > > +   size = fread(assembly, *end, 1, fp);
>> > >  fclose(fp);
>> > > -
>> > > +   if (!size) {
>> > > +  free(assembly);
>> > > +  return NULL;
>> > > +   }
>> > >  return assembly;
>> > >   }
>> > > @@ -167,7 +173,11 @@ int main(int argc, char *argv[])
>> > >  assembly = i965_disasm_read_binary(fp, &end);
>> > >  if (!assembly) {
>> > > -  fprintf(stderr, "Unable to allocate buffer to read binary
>> file\n");
>> > > +  if(end)
>> > if (end)
>> > > +fprintf(stderr, "Unable to allocate buffer to read binary
>> file\n");
>> > > +  else
>> > > +fprintf(stderr, "Input file is empty\n");
>> > > +
>> > > exit(EXIT_FAILURE);
>> > >  }
>> >
>> >
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] i965: add missing rollback of a xfb zero_offsets flag

[andrey simiklit]

Hi all,

Could somebody take a look at this patch?

Regards,
Andrii.

On Mon, Nov 19, 2018 at 11:19 PM  wrote:

> From: Andrii Simiklit 
>
> This patch is needed to avoid incorrect value of StreamOffset flag
> in 3DSTATE_SO_BUFFER command after rollback operation.
>
> To be able to test easily this issue
> the following workaround is necessary:
> -if (!brw_batch_has_aperture_space(brw, 0)) {
> by:
> +if (true) {
> in brw_draw_single_prim function.
>
> This workaround forces a rollback for each batch.
> The "gl-3.2-adj-prims pv-first -fbo" piglit test with this workaround
> failed
> (when URB requirements was fixed this test started to fail instead of a
> hang).
> Investigation of this failure helped to find that some batches have a
> different
> Stream Offset in the 3D STATE_SO_BUFFER command in compare to batches
> which were
> generated without this workaround.
>
> Reported-by: Kenneth Graunke 
> Signed-off-by: Andrii Simiklit 
> ---
>  src/mesa/drivers/dri/i965/brw_context.h   |  3 +++
>  src/mesa/drivers/dri/i965/intel_batchbuffer.c | 10 ++
>  2 files changed, 13 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_context.h
> b/src/mesa/drivers/dri/i965/brw_context.h
> index 4e1682ba5c..86c9bf0a5c 100644
> --- a/src/mesa/drivers/dri/i965/brw_context.h
> +++ b/src/mesa/drivers/dri/i965/brw_context.h
> @@ -521,6 +521,9 @@ struct intel_batchbuffer {
>int batch_reloc_count;
>int state_reloc_count;
>int exec_count;
> +  struct {
> + bool zero_offsets;
> +  } xfb;
>struct {
>   GLuint vsize;
>   GLuint gsize;
> diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> index bae9f2ffed..85e5f64123 100644
> --- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> +++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> @@ -295,10 +295,15 @@
> intel_batchbuffer_reset_and_clear_render_cache(struct brw_context *brw)
>  void
>  intel_batchbuffer_save_state(struct brw_context *brw)
>  {
> +   struct brw_transform_feedback_object *brw_xfb_obj =
> +   (struct brw_transform_feedback_object *)
> +brw->ctx.TransformFeedback.CurrentObject;
> +
> brw->batch.saved.map_next = brw->batch.map_next;
> brw->batch.saved.batch_reloc_count =
> brw->batch.batch_relocs.reloc_count;
> brw->batch.saved.state_reloc_count =
> brw->batch.state_relocs.reloc_count;
> brw->batch.saved.exec_count = brw->batch.exec_count;
> +   brw->batch.saved.xfb.zero_offsets = brw_xfb_obj->zero_offsets;
> brw->batch.saved.urb.vsize = brw->urb.vsize;
> brw->batch.saved.urb.gs_present = brw->urb.gs_present;
> brw->batch.saved.urb.gsize = brw->urb.gsize;
> @@ -310,6 +315,10 @@ intel_batchbuffer_save_state(struct brw_context *brw)
>  void
>  intel_batchbuffer_reset_to_saved(struct brw_context *brw)
>  {
> +   struct brw_transform_feedback_object *brw_xfb_obj =
> +   (struct brw_transform_feedback_object *)
> +brw->ctx.TransformFeedback.CurrentObject;
> +
> for (int i = brw->batch.saved.exec_count;
>  i < brw->batch.exec_count; i++) {
>brw_bo_unreference(brw->batch.exec_bos[i]);
> @@ -319,6 +328,7 @@ intel_batchbuffer_reset_to_saved(struct brw_context
> *brw)
> brw->batch.exec_count = brw->batch.saved.exec_count;
>
> brw->batch.map_next = brw->batch.saved.map_next;
> +   brw_xfb_obj->zero_offsets = brw->batch.saved.xfb.zero_offsets;
> brw->urb.vsize = brw->batch.saved.urb.vsize;
> brw->urb.gs_present = brw->batch.saved.urb.gs_present;
> brw->urb.gsize = brw->batch.saved.urb.gsize;
> --
> 2.17.1
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] i965: add missing rollback of URB requirements

[andrey simiklit]

Hi all,

Could somebody take a look at this patch?

Regards,
Andrii.

On Mon, Nov 19, 2018 at 11:19 PM  wrote:

> From: Andrii Simiklit 
>
> This patch is needed to avoid missing 3DSTATE_URB_* commands in a batch
> after
> rollback operation.
>
> To be able to test easily this issue
> the following workaround is necessary:
> -if (!brw_batch_has_aperture_space(brw, 0)) {
> by:
> +if (true) {
> in brw_draw_single_prim function.
>
> This workaround forces a rollback for each batch.
> The "gl-3.2-adj-prims pv-first -auto -fbo" piglit test with this workaround
> led to a hung. The hung investigation helped to find that some batches
> didn't have the 3DSTATE_URB_* commands in compare to batches which were
> generated without this workaround.
>
> Reported-by: Kenneth Graunke 
> Signed-off-by: Andrii Simiklit 
> ---
>  src/mesa/drivers/dri/i965/brw_context.h   |  8 
>  src/mesa/drivers/dri/i965/intel_batchbuffer.c | 12 
>  2 files changed, 20 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_context.h
> b/src/mesa/drivers/dri/i965/brw_context.h
> index 7fd15669eb..4e1682ba5c 100644
> --- a/src/mesa/drivers/dri/i965/brw_context.h
> +++ b/src/mesa/drivers/dri/i965/brw_context.h
> @@ -521,6 +521,14 @@ struct intel_batchbuffer {
>int batch_reloc_count;
>int state_reloc_count;
>int exec_count;
> +  struct {
> + GLuint vsize;
> + GLuint gsize;
> + GLuint hsize;
> + GLuint dsize;
> + bool gs_present;
> + bool tess_present;
> +  } urb;
> } saved;
>
> /** Map from batch offset to brw_state_batch data (with DEBUG_BATCH) */
> diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> index 353fcba18f..bae9f2ffed 100644
> --- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> +++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> @@ -299,6 +299,12 @@ intel_batchbuffer_save_state(struct brw_context *brw)
> brw->batch.saved.batch_reloc_count =
> brw->batch.batch_relocs.reloc_count;
> brw->batch.saved.state_reloc_count =
> brw->batch.state_relocs.reloc_count;
> brw->batch.saved.exec_count = brw->batch.exec_count;
> +   brw->batch.saved.urb.vsize = brw->urb.vsize;
> +   brw->batch.saved.urb.gs_present = brw->urb.gs_present;
> +   brw->batch.saved.urb.gsize = brw->urb.gsize;
> +   brw->batch.saved.urb.tess_present = brw->urb.tess_present;
> +   brw->batch.saved.urb.hsize = brw->urb.hsize;
> +   brw->batch.saved.urb.dsize = brw->urb.dsize;
>  }
>
>  void
> @@ -313,6 +319,12 @@ intel_batchbuffer_reset_to_saved(struct brw_context
> *brw)
> brw->batch.exec_count = brw->batch.saved.exec_count;
>
> brw->batch.map_next = brw->batch.saved.map_next;
> +   brw->urb.vsize = brw->batch.saved.urb.vsize;
> +   brw->urb.gs_present = brw->batch.saved.urb.gs_present;
> +   brw->urb.gsize = brw->batch.saved.urb.gsize;
> +   brw->urb.tess_present = brw->batch.saved.urb.tess_present;
> +   brw->urb.hsize = brw->batch.saved.urb.hsize;
> +   brw->urb.dsize = brw->batch.saved.urb.dsize;
> if (USED_BATCH(brw->batch) == 0)
>brw_new_batch(brw);
>  }
> --
> 2.17.1
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] i965: add missing rollback of URB requirements

[andrey simiklit]

On Tue, Jan 8, 2019 at 1:11 PM Chris Wilson 
wrote:

> Quoting Lionel Landwerlin (2019-01-08 11:03:26)
> > Hi Andrii,
> >
> > Although I think what these patches do makes sense, I think it's missing
> > the bigger picture.
> > There is a lot more state that gets lost if we have to revert all of the
> > emitted commands.
> > A quick look at brw_upload_pipeline_state() shows all of the programs
> > could be invalid as well, or the number of samples, etc...
> >
> > To me it seems like we need a much larger state save/restore.
> >
> > Ken: what do you think?
>
> How about not rolling back? If we accept it as currently broken, and just
> demand the kernel provide logical contexts for all i965 devices (just ack
> some patches!), and then just flush the batch (possibly with a dummy 3D
> prim if you want to be sure the 3D state is loaded) and rely on the
> context preserving state across batches.
> -Chris
>

Could you please provide a link to the patches you talking about?

At the moment as far as I understood the rollback system
helps to reduce quantity of the flush operations in some lucky cases.
When there isn't enough space for a batch aperture,
we will rollback the batch to the saved state,
when limit (means aperture_threshold) wasn't reached by it.

pseudo code (simple variant, without error handling):
   save batch state here;
   do
   {
   add primitives to the batch;
   if the batch size limit is exceeded
   {
   rollback to the saved batch state;
   flush the batch;
   }
   else
   {
   break;
   }
   } while(true);

Are you suggesting to flush the batch every time without waiting for a
nearly full filling of it?
Like this:
   add primitives to batch;
   flush batch;

Please correct me if I am wrong.

-Andrii


> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] i965: add missing rollback of URB requirements

[andrey simiklit]

On Tue, Jan 8, 2019 at 6:16 PM Chris Wilson 
wrote:

> Quoting andrey simiklit (2019-01-08 16:00:45)
> > On Tue, Jan 8, 2019 at 1:11 PM Chris Wilson 
> wrote:
> >
> > Quoting Lionel Landwerlin (2019-01-08 11:03:26)
> > > Hi Andrii,
> > >
> > > Although I think what these patches do makes sense, I think it's
> missing
> > > the bigger picture.
> > > There is a lot more state that gets lost if we have to revert all
> of the
> > > emitted commands.
> > > A quick look at brw_upload_pipeline_state() shows all of the
> programs
> > > could be invalid as well, or the number of samples, etc...
> > >
> > > To me it seems like we need a much larger state save/restore.
> > >
> > > Ken: what do you think?
> >
> > How about not rolling back? If we accept it as currently broken, and
> just
> > demand the kernel provide logical contexts for all i965 devices
> (just ack
> > some patches!), and then just flush the batch (possibly with a dummy
> 3D
> > prim if you want to be sure the 3D state is loaded) and rely on the
> > context preserving state across batches.
> > -Chris
> >
> >
> > Could you please provide a link to the patches you talking about?
>
> I just need an ack for the kernel patches to enable context support.
>
> > At the moment as far as I understood the rollback system
> > helps to reduce quantity of the flush operations in some lucky cases.
> > When there isn't enough space for a batch aperture,
> > we will rollback the batch to the saved state,
> > when limit (means aperture_threshold) wasn't reached by it.
> >
> > pseudo code (simple variant, without error handling):
> >save batch state here;
> >do
> >{
> >add primitives to the batch;
> >if the batch size limit is exceeded
> >{
> >rollback to the saved batch state;
> >flush the batch;
> >}
> >else
> >{
> >break;
> >}
> >} while(true);
> >
> > Are you suggesting to flush the batch every time without waiting for a
> nearly
> > full filling of it?
> > Like this:
> >add primitives to batch;
> >flush batch;
>
> The suggestion was just thinking about if we detect that this primitive
> would exceed the aperture, instead of rolling back the batch to before
> the primitive, unroll the objects/relocs (so that we don't trigger
> ENOSPC from the kernel) but keep the 3DSTATE without the final PRIM and
> submit that.
>
> Basically it's all about removing no_batch_wrap.
>
> Quite icky. All it saves is having to track the incidental details like
> URB, but you still have to re-emit all the surface state (but that's
> already a given as it is stored alongside the batch). However, that's
> all you have to remember.
> -Chris
>

Thanks a lot for clarifications.
-Andrii


> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] radv: remove unnecessary return in GetPhysicalDeviceMemoryProperties2()

[andrey simiklit]

Hello,

Looks like the same fix could be done in the following functions:
radv_GetPhysicalDeviceQueueFamilyProperties
radv_GetPhysicalDeviceQueueFamilyProperties2
just for case if you want to fix all these issues:)

Regards,
Andrii.

On Mon, Jan 7, 2019 at 6:35 PM Samuel Pitoiset 
wrote:

> This function returns nothing.
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/vulkan/radv_device.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
> index 53aed1a15db..39bd47348a9 100644
> --- a/src/amd/vulkan/radv_device.c
> +++ b/src/amd/vulkan/radv_device.c
> @@ -1345,8 +1345,8 @@ void radv_GetPhysicalDeviceMemoryProperties2(
> VkPhysicalDevicephysicalDevice,
> VkPhysicalDeviceMemoryProperties2KHR   *pMemoryProperties)
>  {
> -   return radv_GetPhysicalDeviceMemoryProperties(physicalDevice,
> -
>  &pMemoryProperties->memoryProperties);
> +   radv_GetPhysicalDeviceMemoryProperties(physicalDevice,
> +
> &pMemoryProperties->memoryProperties);
>  }
>
>  VkResult radv_GetMemoryHostPointerPropertiesEXT(
> --
> 2.20.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] glsl: prevent qualifiers modification of predeclared variables

[andrey simiklit]

Hello,

+ i...@freedesktop.org
and add missing bugzilla link
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108247

Regards,
Andrii.

On Thu, Oct 4, 2018 at 5:08 PM  wrote:

> From: Andrii Simiklit 
>
> GLSL 3.7 (Identifiers):
> "However, as noted in the specification, there are some cases where
> previously declared variables can be redeclared to change or add some
> property, and predeclared "gl_" names are allowed to be redeclared in a
> shader only for these specific purposes.  More generally, it is an error to
> redeclare a variable, including those starting "gl_"."
>
> This patch should fix piglit tests:
> 'clip-distance-redeclare-without-inout.frag'
> 'clip-distance-redeclare-without-inout.vert'
> and leads to regression in clip-distance-out-values.shader_test
> but probably a fix should be made in the test.
>
> As far as I understood following mailing thread:
> https://lists.freedesktop.org/archives/piglit/2013-October/007935.html
> looks like we have accepted to remove an ability to change qualifiers
> but have not done it yet. Unless I missed something)
>
> Fixes: 8e6cb9fe51a2 "glsl: Refactor AST-to-HIR code handling variable
>  redeclarations"
> Signed-off-by: Andrii Simiklit 
> ---
>  src/compiler/glsl/ast_to_hir.cpp | 13 +
>  1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/src/compiler/glsl/ast_to_hir.cpp
> b/src/compiler/glsl/ast_to_hir.cpp
> index 93e7c8ec33..e26ae6b92a 100644
> --- a/src/compiler/glsl/ast_to_hir.cpp
> +++ b/src/compiler/glsl/ast_to_hir.cpp
> @@ -4240,10 +4240,15 @@ get_variable_being_redeclared(ir_variable
> **var_ptr, YYLTYPE loc,
>  */
> if (earlier->type->is_unsized_array() && var->type->is_array()
> && (var->type->fields.array == earlier->type->fields.array)) {
> -  /* FINISHME: This doesn't match the qualifiers on the two
> -   * FINISHME: declarations.  It's not 100% clear whether this is
> -   * FINISHME: required or not.
> -   */
> +
> +  if ((strcmp("gl_ClipDistance", var->name) == 0) &&
> +  earlier->data.mode != var->data.mode) {
> + _mesa_glsl_error(&loc, state,
> +  "redeclaration of '%s %s' with incorrect
> qualifiers '%s'.",
> +  mode_string(earlier),
> +  var->name,
> +  mode_string(var));
> +  }
>
>const int size = var->type->array_size();
>check_builtin_array_max_size(var->name, size, loc, state);
> --
> 2.17.1
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] glsl: prevent qualifiers modification of predeclared variables

[andrey simiklit]

Hello,

Please find my comments below:

On Sat, Oct 6, 2018 at 1:07 AM Ian Romanick  wrote:

> On 10/05/2018 03:02 PM, Ian Romanick wrote:
> > On 10/04/2018 07:08 AM, asimiklit.w...@gmail.com wrote:
> >> From: Andrii Simiklit 
> >>
> >> GLSL 3.7 (Identifiers):
> >> "However, as noted in the specification, there are some cases where
> >> previously declared variables can be redeclared to change or add some
> >> property, and predeclared "gl_" names are allowed to be redeclared in a
> >> shader only for these specific purposes.  More generally, it is an
> error to
> >> redeclare a variable, including those starting "gl_"."
> >>
> >> This patch should fix piglit tests:
> >> 'clip-distance-redeclare-without-inout.frag'
> >> 'clip-distance-redeclare-without-inout.vert'
> >> and leads to regression in clip-distance-out-values.shader_test
> >> but probably a fix should be made in the test.
> >
> > I believe clip-distance-out-values.shader_test is incorrect.  The
> redeclaration of gl_ClipDistance should have "out".  glslang rejects it
> with:
> >
> > ERROR: 0:5: 'redeclaration' : cannot change qualification of
> gl_ClipDistance
> > ERROR: 1 compilation errors.  No code generated.
> >
> > I think Mark and Clayton would prefer it if the fix to the test landed
> first.  That way the test never shows up as "fail" to them.
> >
> > I'll send the fix for this with the new test cases that I mention below.
> >
> >> As far as I understood following mailing thread:
> >> https://lists.freedesktop.org/archives/piglit/2013-October/007935.html
> >> looks like we have accepted to remove an ability to change qualifiers
> >> but have not done it yet. Unless I missed something)
> >>
> >> Fixes: 8e6cb9fe51a2 "glsl: Refactor AST-to-HIR code handling variable
> >>   redeclarations"
> >
> > While this is technically correct, I don't think we want to add a new
> compile error to the stable branches.  On the outside chance this breaks
> some application, I'd rather have it sit on master for a bit first.
> >
> >> Signed-off-by: Andrii Simiklit 
> >> ---
> >>  src/compiler/glsl/ast_to_hir.cpp | 13 +
> >>  1 file changed, 9 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/src/compiler/glsl/ast_to_hir.cpp
> b/src/compiler/glsl/ast_to_hir.cpp
> >> index 93e7c8ec33..e26ae6b92a 100644
> >> --- a/src/compiler/glsl/ast_to_hir.cpp
> >> +++ b/src/compiler/glsl/ast_to_hir.cpp
> >> @@ -4240,10 +4240,15 @@ get_variable_being_redeclared(ir_variable
> **var_ptr, YYLTYPE loc,
> >>  */
> >> if (earlier->type->is_unsized_array() && var->type->is_array()
> >> && (var->type->fields.array == earlier->type->fields.array)) {
> >> -  /* FINISHME: This doesn't match the qualifiers on the two
> >> -   * FINISHME: declarations.  It's not 100% clear whether this is
> >> -   * FINISHME: required or not.
> >> -   */
> >> +
> >> +  if ((strcmp("gl_ClipDistance", var->name) == 0) &&
> >
> > Hmm... this fixes the specific case mentioned in the old e-mail thread,
> but this could occur with any variable.  For example, I don't think this
> shader should compile, but it does:
> >
> > #version 110
> > varying float x[];
> > uniform float x[3];
> > uniform int i;
> >
> > void main()
> > {
> > gl_Position = vec4(x[i]);
> > }
> >
> > Much to my surprise, glslang does not reject this shader.  It looks like
> glslang rejects anything that tries to change the storage qualifier on any
> built-in variable, but it seems to allow such changes on user-defined
> variables.  I think that's a bug in glslang.
> >
> > Let's do this for now.
> >
> > 1. Change Mesa to reject any storage qualifier change on a built-in
> variable.  This will match glslang.  We can do this by bringing the code by
> the comment "Allow verbatim redeclarations of built-in variables. Not
> explicitly valid, but some applications do it." up before the big
> if-then-else tree.  Around line 4235 add something like:
> >
> >if (earlier->data.how_declared == ir_var_declared_implicitly) {
> >   /* Allow verbatim redeclarations of built-in variables. Not
> explicitly
> >* valid, but some applications do it.
> >*/
> >   if (earlier->data.mode != var->data.mode &&
> >   !(earlier->data.mode == ir_var_system_value &&
> > var->data.mode == ir_var_shader_in)) {
> >  _mesa_glsl_error(&loc, state,
> >   "redeclaration cannot change qualification of
> `%s'",
> >   var->name);
>
> Oops...
>
>   } else if (earlier->type != var->type) {
>  _mesa_glsl_error(&loc, state,
>   "redeclaration of `%s' has incorrect type",
>   var->name);
>
> >   }
> >}
>

I have tried to test this version on Intel CI.

https://gitlab.freedesktop.org/asimiklit/mesa/commit/9d4f6a97568e7e2720e43601697eaf90908b7aab

but it caused many errors:

https://mesa-ci.01.org/glob

Re: [Mesa-dev] [PATCH v3 1/2] i965/batch: avoid reverting batch buffer if saved state is an empty

[andrey simiklit]

Hello,

Thanks for reviewing.
Please find my comment below.

On Thu, Oct 11, 2018 at 12:37 AM Jordan Justen 
wrote:

> On 2018-09-12 09:05:44,  wrote:
> > From: Andrii Simiklit 
> >
> > There's no point reverting to the last saved point if that save point is
> > the empty batch, we will just repeat ourselves.
> >
> > CC: Chris Wilson 
> > Fixes: 3faf56ffbdeb "intel: Add an interface for saving/restoring
> >  the batchbuffer state."
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107626
> > ---
> >  src/mesa/drivers/dri/i965/brw_compute.c   | 3 ++-
> >  src/mesa/drivers/dri/i965/brw_draw.c  | 3 ++-
> >  src/mesa/drivers/dri/i965/genX_blorp_exec.c   | 3 ++-
> >  src/mesa/drivers/dri/i965/intel_batchbuffer.c | 7 +++
> >  src/mesa/drivers/dri/i965/intel_batchbuffer.h | 1 +
> >  5 files changed, 14 insertions(+), 3 deletions(-)
> >
> > diff --git a/src/mesa/drivers/dri/i965/brw_compute.c
> b/src/mesa/drivers/dri/i965/brw_compute.c
> > index de08fc3..5c8e3a5 100644
> > --- a/src/mesa/drivers/dri/i965/brw_compute.c
> > +++ b/src/mesa/drivers/dri/i965/brw_compute.c
> > @@ -167,7 +167,7 @@ static void
> >  brw_dispatch_compute_common(struct gl_context *ctx)
> >  {
> > struct brw_context *brw = brw_context(ctx);
> > -   bool fail_next = false;
> > +   bool fail_next;
> >
> > if (!_mesa_check_conditional_render(ctx))
> >return;
> > @@ -185,6 +185,7 @@ brw_dispatch_compute_common(struct gl_context *ctx)
> > intel_batchbuffer_require_space(brw, 600);
> > brw_require_statebuffer_space(brw, 2500);
> > intel_batchbuffer_save_state(brw);
> > +   fail_next = intel_batchbuffer_saved_state_is_empty(brw);
> >
> >   retry:
> > brw->batch.no_wrap = true;
> > diff --git a/src/mesa/drivers/dri/i965/brw_draw.c
> b/src/mesa/drivers/dri/i965/brw_draw.c
> > index 8536c04..19ee396 100644
> > --- a/src/mesa/drivers/dri/i965/brw_draw.c
> > +++ b/src/mesa/drivers/dri/i965/brw_draw.c
> > @@ -885,7 +885,7 @@ brw_draw_single_prim(struct gl_context *ctx,
> >  {
> > struct brw_context *brw = brw_context(ctx);
> > const struct gen_device_info *devinfo = &brw->screen->devinfo;
> > -   bool fail_next = false;
> > +   bool fail_next;
> >
> > /* Flag BRW_NEW_DRAW_CALL on every draw.  This allows us to have
> >  * atoms that happen on every draw call.
> > @@ -898,6 +898,7 @@ brw_draw_single_prim(struct gl_context *ctx,
> > intel_batchbuffer_require_space(brw, 1500);
> > brw_require_statebuffer_space(brw, 2400);
> > intel_batchbuffer_save_state(brw);
> > +   fail_next = intel_batchbuffer_saved_state_is_empty(brw);
>
> It seems like this will cause the WARN_ONCE to be hit incorrectly.
> What about adding a 'bool empty_state', and checking that before
> fail_next in the code that follows. If empty_state is true, I guess
> you want to flush, but not emit the WARN_ONCE?
>

We just predict that first step (non-failed branch without WARN_ONCE)
which should make the batch an empty will not make sense
because it is already empty and we immediately pass into a failed branch.
All WARN_ONCE calls are conditional ('ret == -ENOSPC') there.
I guess that if we came to the failed branch (I mean branch which contains
WARN_ONCE)
then regardless a reason (due to 'empty state' or 'failed try') we rather
should log a warning
that there isn't left space to transfer a batch if it is true.

What do you think about it?
Should we log a warning if calls of
'brw_upload_render_state' + 'brw_emit_prim' functions
for an empty batch lead to ENOSPC error?

Anyway if it is unacceptable for you
I can implement the solution which you suggested.


>
> With that change,
> series Reviewed-by: Jordan Justen 
>
> As always, it could be nice to get an r-b, or acked-by from Ken. :)
>
> -Jordan
>
> >
> > if (brw->num_instances != prim->num_instances ||
> > brw->basevertex != prim->basevertex ||
> > diff --git a/src/mesa/drivers/dri/i965/genX_blorp_exec.c
> b/src/mesa/drivers/dri/i965/genX_blorp_exec.c
> > index 34bfcad..fd9ce93 100644
> > --- a/src/mesa/drivers/dri/i965/genX_blorp_exec.c
> > +++ b/src/mesa/drivers/dri/i965/genX_blorp_exec.c
> > @@ -268,7 +268,7 @@ genX(blorp_exec)(struct blorp_batch *batch,
> > assert(batch->blorp->driver_ctx == batch->driver_batch);
> > struct brw_context *brw = batch->driver_batch;
> > struct gl_context *ctx = &brw->ctx;
> > -   bool check_aperture_failed_once = false;
> > +   bool check_aperture_failed_once;
> >
> >  #if GEN_GEN >= 11
> > /* The PIPE_CONTROL command description says:
> > @@ -309,6 +309,7 @@ retry:
> > intel_batchbuffer_require_space(brw, 1400);
> > brw_require_statebuffer_space(brw, 600);
> > intel_batchbuffer_save_state(brw);
> > +   check_aperture_failed_once =
> intel_batchbuffer_saved_state_is_empty(brw);
> > brw->batch.no_wrap = true;
> >
> >  #if GEN_GEN == 6
> > diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> > index 4363b1

Re: [Mesa-dev] [PATCH] i965: consider a 'base level' when calculating width0, height0, depth0

[andrey simiklit]

Hi,

Thanks for reviewing.
This 'simple reproducer' just can cause assertion
in the debug mesa version but I don't know
how to check things which cause it using opengl api at the moment.
I mean it can be some internal mesa things inaccessible outside
but anyway I am going to try to do it.

Regards,
Andrii.
On Mon, Oct 8, 2018 at 11:46 PM Rafael Antognolli <
rafael.antogno...@intel.com> wrote:

> On Tue, Oct 02, 2018 at 07:16:01PM +0300, asimiklit.w...@gmail.com wrote:
> > From: Andrii Simiklit 
> >
> > I guess that when we calculating the width0, height0, depth0
> > to use for function 'intel_miptree_create' we need to consider
> > the 'base level' like it is done in the
> 'intel_miptree_create_for_teximage'
> > function.
>
> Hi Andrii, this makes sense to me. I'm also not familiar with this code,
> so I'm not sure this is the right way to solve the issue, but at least
> it's a way.
>
> You added a simple test case in the bug, do you think you could make
> that a piglit test?


> Thanks,
> Rafael
>
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107987
> > Signed-off-by: Andrii Simiklit 
> > ---
> >  .../drivers/dri/i965/intel_tex_validate.c | 26 ++-
> >  1 file changed, 25 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/mesa/drivers/dri/i965/intel_tex_validate.c
> b/src/mesa/drivers/dri/i965/intel_tex_validate.c
> > index 72ce83c7ce..37aa8f43ec 100644
> > --- a/src/mesa/drivers/dri/i965/intel_tex_validate.c
> > +++ b/src/mesa/drivers/dri/i965/intel_tex_validate.c
> > @@ -119,8 +119,32 @@ intel_finalize_mipmap_tree(struct brw_context *brw,
> > /* May need to create a new tree:
> >  */
> > if (!intelObj->mt) {
> > +  const unsigned level = firstImage->base.Base.Level;
> >intel_get_image_dims(&firstImage->base.Base, &width, &height,
> &depth);
> > -
> > +  /* Figure out image dimensions at start level. */
> > +  switch(intelObj->base.Target) {
> > +  case GL_TEXTURE_2D_MULTISAMPLE:
> > +  case GL_TEXTURE_2D_MULTISAMPLE_ARRAY:
> > +  case GL_TEXTURE_RECTANGLE:
> > +  case GL_TEXTURE_EXTERNAL_OES:
> > +  assert(level == 0);
> > +  break;
> > +  case GL_TEXTURE_3D:
> > +  depth = depth << level;
> > +  /* Fall through */
> > +  case GL_TEXTURE_2D:
> > +  case GL_TEXTURE_2D_ARRAY:
> > +  case GL_TEXTURE_CUBE_MAP:
> > +  case GL_TEXTURE_CUBE_MAP_ARRAY:
> > +  height = height << level;
> > +  /* Fall through */
> > +  case GL_TEXTURE_1D:
> > +  case GL_TEXTURE_1D_ARRAY:
> > +  width = width << level;
> > +  break;
> > +  default:
> > +  unreachable("Unexpected target");
> > +  }
> >perf_debug("Creating new %s %dx%dx%d %d-level miptree to handle "
> >   "finalized texture miptree.\n",
> >   _mesa_get_format_name(firstImage->base.Base.TexFormat),
> > --
> > 2.17.1
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2] i965/glsl: don't add unused aoa element to the program resource list

[andrey simiklit]

Hi all,

I have tested it on Intel CI and it just fixes test without any regression:
https://mesa-ci.01.org/global_logic/builds/27/group/63a9f0ea7bb98050796b649e85481845

This patch fixes piglit test:
https://bugs.freedesktop.org/show_bug.cgi?id=92822

At the moment it is marked as expected failure.
So it fails with message: "ERROR: This test passed when it expected failure"

It would be grate if somebody reviews this patch)

Thanks,
Andrii.
On Thu, Sep 20, 2018 at 5:03 PM  wrote:

> From: Andrii Simiklit 
>
> It fixes a bit incorrectly implemented ARB_program_interface_query.
> If input aoa element is unused in shader program
> the 'glGetProgramResourceIndex' function shouldn't
> return a valid resource index for it according to:
> ARB_program_interface_query spec:
> " For an active variable declared as an array of an aggregate data type
> (structures or arrays), a separate entry will be generated for each
> active array element"
>
> v2: - Fixed case where the non-AoA elements were removed form
> the program resource list.
> The KHR-GL46.enhanced_layouts.varying_structure_locations
> test is passed now
> - Fixed case where a dereference index is not constant:
> The proper array length stored in 'deref->array->type->length'
> not in 'deref->type->length'
> - Fixed the output AoA elements handling:
> The list of active input AoA elements should not be used for
> output AoA elements
> - Fixed the function name from 'enumiramte_active_elements' to
> 'enumerate_active_elements'
> - Fixed errors handling during active AoA elements enumeration
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92822
> Signed-off-by: Andrii Simiklit 
> ---
>  src/compiler/Makefile.sources |   4 +-
>  .../glsl/ir_collect_active_aoa_elements.cpp   | 155 ++
>  .../glsl/ir_collect_active_aoa_elements.h |  52 ++
>  src/compiler/glsl/linker.cpp  |  91 --
>  src/compiler/glsl/meson.build |   2 +
>  5 files changed, 289 insertions(+), 15 deletions(-)
>  create mode 100644 src/compiler/glsl/ir_collect_active_aoa_elements.cpp
>  create mode 100644 src/compiler/glsl/ir_collect_active_aoa_elements.h
>
> diff --git a/src/compiler/Makefile.sources b/src/compiler/Makefile.sources
> index d3b0656483..a2ba3e37f1 100644
> --- a/src/compiler/Makefile.sources
> +++ b/src/compiler/Makefile.sources
> @@ -154,7 +154,9 @@ LIBGLSL_FILES = \
> glsl/serialize.cpp \
> glsl/serialize.h \
> glsl/string_to_uint_map.cpp \
> -   glsl/string_to_uint_map.h
> +   glsl/string_to_uint_map.h \
> +   glsl/ir_collect_active_aoa_elements.cpp \
> +   glsl/ir_collect_active_aoa_elements.h
>
>  LIBGLSL_SHADER_CACHE_FILES = \
> glsl/shader_cache.cpp \
> diff --git a/src/compiler/glsl/ir_collect_active_aoa_elements.cpp
> b/src/compiler/glsl/ir_collect_active_aoa_elements.cpp
> new file mode 100644
> index 00..df0a41ad3e
> --- /dev/null
> +++ b/src/compiler/glsl/ir_collect_active_aoa_elements.cpp
> @@ -0,0 +1,155 @@
> +/*
> + * Copyright © 2018 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the
> "Software"),
> + * to deal in the Software without restriction, including without
> limitation
> + * the rights to use, copy, modify, merge, publish, distribute,
> sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the
> next
> + * paragraph) shall be included in all copies or substantial portions of
> the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT
> SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
> OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> + * DEALINGS IN THE SOFTWARE.
> + */
> +
> +#include "ir_collect_active_aoa_elements.h"
> +#include "program.h"
> +#include "linker_util.h"
> +#include "util/set.h"
> +#include "util/u_dynarray.h"
> +
> +namespace
> +{
> +/***
> + * Helps to collect the names of used aoa elements
> + * to the accessed_elements set
> + ***/
> +struct elem_inserter
> +{
> +elem_inserter(struct set *accessed_elements_)
> +: accessed_elements(accessed_elements_)
> +{}
> +bool operator ()(const char *name)
> +{
> +bool oval = true;
> +if (NULL == _mesa_set_search(accessed_elements, name)) {
> +oval

Re: [Mesa-dev] [PATCH] i965: consider a 'base level' when calculating width0, height0, depth0

[andrey simiklit]

Hi,

Thanks for your advices.
I will be on vacation from 13.10.2018 till 20.10.2018
so I will try to do it after vacation.

Thanks,
Andrii.

On Thu, Oct 11, 2018 at 6:10 PM Rafael Antognolli <
rafael.antogno...@intel.com> wrote:

> On Thu, Oct 11, 2018 at 03:12:08PM +0300, andrey simiklit wrote:
> > Hi,
> >
> > Thanks for reviewing.
> > This 'simple reproducer' just can cause assertion
> > in the debug mesa version but I don't know
> > how to check things which cause it using opengl api at the moment.
> > I mean it can be some internal mesa things inaccessible outside
> > but anyway I am going to try to do it.
>
> I don't think you need to check for the assertion. You can simply write
> the piglit test that does the same thing as your simple reproducer does,
> and if the test causes an assertion, then if I'm not wrong piglit will
> report that test as a "crash". So we would have coverage. And if your
> test gets to the end of the execution without crashing, you can assume
> it's a pass.
>
> You probably can write some comments by the end of the test stating that
> if it has reached that point, then things should be fine.
>
> As an extra thing, I think the test could additionally check that
> everything rendered correctly (check some colors from the framebuffer).
>
> Anyway, just some ideas.
>
> Thanks,
> Rafael
>
> > Regards,
> > Andrii.
> > On Mon, Oct 8, 2018 at 11:46 PM Rafael Antognolli <
> rafael.antogno...@intel.com>
> > wrote:
> >
> > On Tue, Oct 02, 2018 at 07:16:01PM +0300, asimiklit.w...@gmail.com
> wrote:
> > > From: Andrii Simiklit 
> > >
> > > I guess that when we calculating the width0, height0, depth0
> > > to use for function 'intel_miptree_create' we need to consider
> > > the 'base level' like it is done in the
> > 'intel_miptree_create_for_teximage'
> > > function.
> >
> > Hi Andrii, this makes sense to me. I'm also not familiar with this
> code,
> > so I'm not sure this is the right way to solve the issue, but at
> least
> > it's a way.
> >
> > You added a simple test case in the bug, do you think you could make
> > that a piglit test?
> >
> >
> > Thanks,
> > Rafael
> >
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107987
> > > Signed-off-by: Andrii Simiklit 
> > > ---
> > >  .../drivers/dri/i965/intel_tex_validate.c | 26
> ++-
> > >  1 file changed, 25 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/src/mesa/drivers/dri/i965/intel_tex_validate.c
> b/src/mesa/
> > drivers/dri/i965/intel_tex_validate.c
> > > index 72ce83c7ce..37aa8f43ec 100644
> > > --- a/src/mesa/drivers/dri/i965/intel_tex_validate.c
> > > +++ b/src/mesa/drivers/dri/i965/intel_tex_validate.c
> > > @@ -119,8 +119,32 @@ intel_finalize_mipmap_tree(struct brw_context
> *brw,
> > > /* May need to create a new tree:
> > >  */
> > > if (!intelObj->mt) {
> > > +  const unsigned level = firstImage->base.Base.Level;
> > >intel_get_image_dims(&firstImage->base.Base, &width,
> &height, &
> > depth);
> > > -
> > > +  /* Figure out image dimensions at start level. */
> > > +  switch(intelObj->base.Target) {
> > > +  case GL_TEXTURE_2D_MULTISAMPLE:
> > > +  case GL_TEXTURE_2D_MULTISAMPLE_ARRAY:
> > > +  case GL_TEXTURE_RECTANGLE:
> > > +  case GL_TEXTURE_EXTERNAL_OES:
> > > +  assert(level == 0);
> > > +  break;
> > > +  case GL_TEXTURE_3D:
> > > +  depth = depth << level;
> > > +  /* Fall through */
> > > +  case GL_TEXTURE_2D:
> > > +  case GL_TEXTURE_2D_ARRAY:
> > > +  case GL_TEXTURE_CUBE_MAP:
> > > +  case GL_TEXTURE_CUBE_MAP_ARRAY:
> > > +  height = height << level;
> > > +  /* Fall through */
> > > +  case GL_TEXTURE_1D:
> > > +  case GL_TEXTURE_1D_ARRAY:
> > > +  width = width << level;
> > > +  break;
> > > +  default:
> > > +  unreachable("Unexpected target");
> > > +  }
> > >perf_debug("Creating new %s %dx%dx%d %d-level miptree to
> handle "
> > >   "finalized texture miptree.\n",
> > >
>  _mesa_get_format_name(firstImage->base.Base.TexFormat),
> > > --
> > > 2.17.1
> > >
> > > ___
> > > mesa-dev mailing list
> > > mesa-dev@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> >
>
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] i965: consider a 'base level' when calculating width0, height0, depth0

[andrey simiklit]

Hello,

On Fri, Oct 19, 2018 at 15:14 Kenneth Graunke  wrote:

> On Thursday, October 11, 2018 12:12:38 PM PDT Kenneth Graunke wrote:
> > On Thursday, October 11, 2018 11:58:40 AM PDT Kenneth Graunke wrote:
> > > On Tuesday, October 2, 2018 9:16:01 AM PDT asimiklit.w...@gmail.com
> wrote:
> > > > From: Andrii Simiklit 
> > > >
> > > > I guess that when we calculating the width0, height0, depth0
> > > > to use for function 'intel_miptree_create' we need to consider
> > > > the 'base level' like it is done in the
> 'intel_miptree_create_for_teximage'
> > > > function.
> > > >
> > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107987
> > > > Signed-off-by: Andrii Simiklit 
> > > > ---
> > > >  .../drivers/dri/i965/intel_tex_validate.c | 26
> ++-
> > > >  1 file changed, 25 insertions(+), 1 deletion(-)
> > >
> > > I believe this patch is correct - we're assembling things into a new
> > > miptree, which we start at level 0 - so we need the sizes for level 0.
> > >
> > > Alternatively, we might be able to pass validate_first_level instead
> > > of 0 when calling intel_miptree_create, to make one that's only good
> > > up until the new base...and have to re-assemble it the next time they
> > > change the base.  It would save memory potentially.  But more copies.
> > > I don't have a strong preference which is better.
> > >
> > > Please do make a Piglit or dEQP test for this.
> > >
> > > Reviewed-by: Kenneth Graunke 
> >
> > Sorry, withdrawing my review. :(  Chris Forbes pointed out on IRC that
> > your reproducer case is backwards:
> >
> > miplevel 0 - 1x1
> > miplevel 1 - 2x2
> > miplevel 2 - 4x4
> >
> > That's upside down.  A proper miptree would have the base be largest:
> >
> > miplevel 0 - 4x4
> > miplevel 1 - 2x2
> > miplevel 2 - 1x1
> >
> > So, yes, I could see this tripping an assert...but such a crazy texture
> > will never be mipmap complete.  If they're expecting mipmapping, then
> > it seems like they should get a fallback black texture (which normally
> > happens for incomplete textures).  If not, maybe they should get a
> > single miplevel?  Either way, seems like we should detect insanity and
> > bail, rather than change size calculations for the normal sane case.
> >
>
> So...looked at this again.  I'm not sure why upside-down matters.
>
> At DrawArrays time, we have a single miplevel (base = 2), and are trying
> to put that single miplevel's image into a miptree.  We do properly
> ignore levels 0..1 as they're beyond the base.
>
> We appear to use level 0 as the actual base, and want to store our
> single level at level 2.  Other places (TexImage) seem to work that way
> too.
>
> But, we're creating the miplevel with level 0 as the base, but where
> level 0 has the dimensions of level 2.  This doesn't work.  And your
> patch fixes that.
>
> I tried making the actual base of the unified tree be level 2, rather
> than level 0...so that the BaseLevel is the actual base...but tons of
> things broke.
>
> So, back to Reviewed-by.  I think once we get a Piglit test, I'm happy
> to land this patch.


Thanks for reviewing :-) I will start to work on it as soon as come back
from vacation (on Monday)


>
> --Ken


Thanks,
Andrii.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] i965: consider a 'base level' when calculating width0, height0, depth0

[andrey simiklit]

Hello,

On Fri, Oct 12, 2018 at 01:52 Ian Romanick  wrote:

> On 10/11/2018 12:12 PM, Kenneth Graunke wrote:
> > On Thursday, October 11, 2018 11:58:40 AM PDT Kenneth Graunke wrote:
> >> On Tuesday, October 2, 2018 9:16:01 AM PDT asimiklit.w...@gmail.com
> wrote:
> >>> From: Andrii Simiklit 
> >>>
> >>> I guess that when we calculating the width0, height0, depth0
> >>> to use for function 'intel_miptree_create' we need to consider
> >>> the 'base level' like it is done in the
> 'intel_miptree_create_for_teximage'
> >>> function.
> >>>
> >>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107987
> >>> Signed-off-by: Andrii Simiklit 
> >>> ---
> >>>  .../drivers/dri/i965/intel_tex_validate.c | 26 ++-
> >>>  1 file changed, 25 insertions(+), 1 deletion(-)
> >>
> >> I believe this patch is correct - we're assembling things into a new
> >> miptree, which we start at level 0 - so we need the sizes for level 0.
> >>
> >> Alternatively, we might be able to pass validate_first_level instead
> >> of 0 when calling intel_miptree_create, to make one that's only good
> >> up until the new base...and have to re-assemble it the next time they
> >> change the base.  It would save memory potentially.  But more copies.
> >> I don't have a strong preference which is better.
> >>
> >> Please do make a Piglit or dEQP test for this.
> >>
> >> Reviewed-by: Kenneth Graunke 
> >
> > Sorry, withdrawing my review. :(  Chris Forbes pointed out on IRC that
> > your reproducer case is backwards:
> >
> > miplevel 0 - 1x1
> > miplevel 1 - 2x2
> > miplevel 2 - 4x4
> >
> > That's upside down.  A proper miptree would have the base be largest:
>
> It's upside down, but it's perfectly valid in two scenarios.
>
> 1. You set the level selection (not the LOD clamps) to a single level.
> GL_TEXTURE_BASE_LEVEL == GL_TEXTURE_MAX_LEVEL.  Based on the Chromium
> bug that Tapani referenced in the fd.o bug, I suspect the original WebGL
> test is changing at least GL_TEXTURE_BASE_LEVEL.
>
> 2. You're not using a mipmap min filter.  It looks like his test case
> uses GL_LINEAR, so it should be fine.
>
> It's a real corner case, but that's what most of the WebGL tests
> exercise. :(


Thanks a lot for clarification and reviewing )


>
> > miplevel 0 - 4x4
> > miplevel 1 - 2x2
> > miplevel 2 - 1x1
> >
> > So, yes, I could see this tripping an assert...but such a crazy texture
> > will never be mipmap complete.  If they're expecting mipmapping, then
> > it seems like they should get a fallback black texture (which normally
> > happens for incomplete textures).  If not, maybe they should get a
> > single miplevel?  Either way, seems like we should detect insanity and
> > bail, rather than change size calculations for the normal sane case.
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
> Thanks,
Andrii.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] nir: Divergence Analysis

[andrey simiklit]

Hello,

Please find my comment below:

On Mon, Oct 8, 2018 at 2:15 PM Daniel Schürmann <
daniel.schuerm...@campus.tu-berlin.de> wrote:

> ---
>  src/compiler/nir/meson.build   |   1 +
>  src/compiler/nir/nir.h |   2 +
>  src/compiler/nir/nir_divergence_analysis.c | 333 +
>  3 files changed, 336 insertions(+)
>  create mode 100644 src/compiler/nir/nir_divergence_analysis.c
>
> diff --git a/src/compiler/nir/meson.build b/src/compiler/nir/meson.build
> index 090aa7a628..aabfeee02c 100644
> --- a/src/compiler/nir/meson.build
> +++ b/src/compiler/nir/meson.build
> @@ -96,6 +96,7 @@ files_libnir = files(
>'nir_control_flow_private.h',
>'nir_deref.c',
>'nir_deref.h',
> +  'nir_divergence_analysis.c',
>'nir_dominance.c',
>'nir_format_convert.h',
>'nir_from_ssa.c',
> diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
> index e0df95c391..374280a1cc 100644
> --- a/src/compiler/nir/nir.h
> +++ b/src/compiler/nir/nir.h
> @@ -3010,6 +3010,8 @@ void nir_convert_loop_to_lcssa(nir_loop *loop);
>   */
>  bool nir_convert_from_ssa(nir_shader *shader, bool phi_webs_only);
>
> +bool* nir_divergence_analysis(nir_shader *shader);
> +
>  bool nir_lower_phis_to_regs_block(nir_block *block);
>  bool nir_lower_ssa_defs_to_regs_block(nir_block *block);
>  bool nir_rematerialize_derefs_in_use_blocks_impl(nir_function_impl *impl);
> diff --git a/src/compiler/nir/nir_divergence_analysis.c
> b/src/compiler/nir/nir_divergence_analysis.c
> new file mode 100644
> index 00..d91f4e55e6
> --- /dev/null
> +++ b/src/compiler/nir/nir_divergence_analysis.c
> @@ -0,0 +1,333 @@
> +/*
> + * Copyright © 2018 Valve Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the
> "Software"),
> + * to deal in the Software without restriction, including without
> limitation
> + * the rights to use, copy, modify, merge, publish, distribute,
> sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the
> next
> + * paragraph) shall be included in all copies or substantial portions of
> the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT
> SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
> OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> DEALINGS
> + * IN THE SOFTWARE.
> + *
> + * Authors:
> + *Daniel Schürmann (daniel.schuerm...@campus.tu-berlin.de)
> + *
> + */
> +
> +#include "nir.h"
> +#include "nir_worklist.h"
> +
> +/* This pass computes for each ssa definition if it is uniform.
> + * That is, the variable has the same value for all invocations
> + * of the group.
> + *
> + * This algorithm implements "The Simple Divergence Analysis" from
> + * Diogo Sampaio, Rafael De Souza, Sylvain Collange, Fernando Magno
> Quintão Pereira.
> + * Divergence Analysis.  ACM Transactions on Programming Languages and
> Systems (TOPLAS),
> + * ACM, 2013, 35 (4), pp.13:1-13:36. <10.1145/2523815>. 
> + */
> +
> +
> +static bool alu_src_is_divergent(bool *divergent, nir_alu_src src,
> unsigned num_input_components)
> +{
> +   /* If the alu src is swizzled and defined by a vec-instruction,
> +* we can check if the originating value is non-divergent. */
> +   if (num_input_components == 1 &&
> +   src.src.ssa->num_components != 1 &&
> +   src.src.parent_instr->type == nir_instr_type_alu) {
> +  nir_alu_instr *parent = nir_instr_as_alu(src.src.parent_instr);
> +  switch(parent->op) {
> + case nir_op_vec2:
> + case nir_op_vec3:
> + case nir_op_vec4: {
> +if (divergent[parent->src[src.swizzle[0]].src.ssa->index])
> +   return true;
> +return false;
>

Could it be better to just return a value from 'divergent' array here?
"return divergent[parent->src[src.swizzle[0]].src.ssa->index]"
I think it is not very matter but anyway just for case if you will make v2
patch for some reason :-)


> + }
> + default:
> +break;
> +  }
> +   }
> +   return divergent[src.src.ssa->index];
> +}
> +
> +static bool visit_alu(bool *divergent, nir_alu_instr *instr)
> +{
> +   if (divergent[instr->dest.dest.ssa.index])
> +  return false;
> +   unsigned num_src = nir_op_infos[instr->op].num_inputs;
> +   for (unsigned i = 0; i < num_src; i++) {
> +  if (alu_src_is_divergent(divergent, instr->src[i],
> nir_op_infos[instr->op].input_sizes[i])) {
> + diverge

Re: [Mesa-dev] [PATCH v3 1/2] i965/batch: avoid reverting batch buffer if saved state is an empty

[andrey simiklit]

Hi,

Could you please help me with a push. I don't have a right for it :-)

Thanks,
Andrii.

On Thu, Oct 11, 2018 at 9:22 PM Jordan Justen 
wrote:

> On 2018-10-11 03:01:56, andrey simiklit wrote:
> > Hello,
> >
> > Thanks for reviewing.
> > Please find my comment below.
> >
> > On Thu, Oct 11, 2018 at 12:37 AM Jordan Justen <
> jordan.l.jus...@intel.com>
> > wrote:
> >
> > > On 2018-09-12 09:05:44,  wrote:
> > > > From: Andrii Simiklit 
> > > >
> > > > There's no point reverting to the last saved point if that save
> point is
> > > > the empty batch, we will just repeat ourselves.
> > > >
> > > > CC: Chris Wilson 
> > > > Fixes: 3faf56ffbdeb "intel: Add an interface for saving/restoring
> > > >  the batchbuffer state."
> > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107626
> > > > ---
> > > >  src/mesa/drivers/dri/i965/brw_compute.c   | 3 ++-
> > > >  src/mesa/drivers/dri/i965/brw_draw.c  | 3 ++-
> > > >  src/mesa/drivers/dri/i965/genX_blorp_exec.c   | 3 ++-
> > > >  src/mesa/drivers/dri/i965/intel_batchbuffer.c | 7 +++
> > > >  src/mesa/drivers/dri/i965/intel_batchbuffer.h | 1 +
> > > >  5 files changed, 14 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/src/mesa/drivers/dri/i965/brw_compute.c
> > > b/src/mesa/drivers/dri/i965/brw_compute.c
> > > > index de08fc3..5c8e3a5 100644
> > > > --- a/src/mesa/drivers/dri/i965/brw_compute.c
> > > > +++ b/src/mesa/drivers/dri/i965/brw_compute.c
> > > > @@ -167,7 +167,7 @@ static void
> > > >  brw_dispatch_compute_common(struct gl_context *ctx)
> > > >  {
> > > > struct brw_context *brw = brw_context(ctx);
> > > > -   bool fail_next = false;
> > > > +   bool fail_next;
> > > >
> > > > if (!_mesa_check_conditional_render(ctx))
> > > >return;
> > > > @@ -185,6 +185,7 @@ brw_dispatch_compute_common(struct gl_context
> *ctx)
> > > > intel_batchbuffer_require_space(brw, 600);
> > > > brw_require_statebuffer_space(brw, 2500);
> > > > intel_batchbuffer_save_state(brw);
> > > > +   fail_next = intel_batchbuffer_saved_state_is_empty(brw);
> > > >
> > > >   retry:
> > > > brw->batch.no_wrap = true;
> > > > diff --git a/src/mesa/drivers/dri/i965/brw_draw.c
> > > b/src/mesa/drivers/dri/i965/brw_draw.c
> > > > index 8536c04..19ee396 100644
> > > > --- a/src/mesa/drivers/dri/i965/brw_draw.c
> > > > +++ b/src/mesa/drivers/dri/i965/brw_draw.c
> > > > @@ -885,7 +885,7 @@ brw_draw_single_prim(struct gl_context *ctx,
> > > >  {
> > > > struct brw_context *brw = brw_context(ctx);
> > > > const struct gen_device_info *devinfo = &brw->screen->devinfo;
> > > > -   bool fail_next = false;
> > > > +   bool fail_next;
> > > >
> > > > /* Flag BRW_NEW_DRAW_CALL on every draw.  This allows us to have
> > > >  * atoms that happen on every draw call.
> > > > @@ -898,6 +898,7 @@ brw_draw_single_prim(struct gl_context *ctx,
> > > > intel_batchbuffer_require_space(brw, 1500);
> > > > brw_require_statebuffer_space(brw, 2400);
> > > > intel_batchbuffer_save_state(brw);
> > > > +   fail_next = intel_batchbuffer_saved_state_is_empty(brw);
> > >
> > > It seems like this will cause the WARN_ONCE to be hit incorrectly.
> > > What about adding a 'bool empty_state', and checking that before
> > > fail_next in the code that follows. If empty_state is true, I guess
> > > you want to flush, but not emit the WARN_ONCE?
> > >
> >
> > We just predict that first step (non-failed branch without WARN_ONCE)
> > which should make the batch an empty will not make sense
> > because it is already empty and we immediately pass into a failed branch.
> > All WARN_ONCE calls are conditional ('ret == -ENOSPC') there.
> > I guess that if we came to the failed branch (I mean branch which
> contains
> > WARN_ONCE)
> > then regardless a reason (due to 'empty state' or 'failed try') we rather
> > should log a warning
> > that there isn't left space to transfer a batch if it is true.
>
> Oh. You are right. It sounds like a reasonable warning message for
> that c

Re: [Mesa-dev] [PATCH] intel/tools: fix resource leak

[andrey simiklit]

Hello,

Thanks a lot for reviewing and for quick reply.
Sorry, I forgot ( I thought that it impossible to have the feedback in a 10
minutes on Friday :-) ) to update my inbox and sent version v2,
I guess that I fix small issue in v2:
-   aub_file_finish(&aub);
+   if(aub.file) {
+  aub_file_finish(&aub);
+   } else if(aub_file) {
+  fclose(aub_file);
+   }

Thanks,
Andrii.

On Fri, Oct 26, 2018 at 5:20 PM Lionel Landwerlin <
lionel.g.landwer...@intel.com> wrote:

> On 26/10/2018 15:11, asimiklit.w...@gmail.com wrote:
> > From: Andrii Simiklit 
> >
> > Some memory and file descriptors are not freed/closed.
>
>
> Thanks a lot :
>
>
> Reviewed-by: Lionel Landwerlin 
>
>
> >
> > Signed-off-by: Andrii Simiklit 
> > ---
> >   src/intel/tools/error2aub.c | 6 ++
> >   1 file changed, 6 insertions(+)
> >
> > diff --git a/src/intel/tools/error2aub.c b/src/intel/tools/error2aub.c
> > index 8a23d5ef1e..451fd8c74a 100644
> > --- a/src/intel/tools/error2aub.c
> > +++ b/src/intel/tools/error2aub.c
> > @@ -326,6 +326,12 @@ main(int argc, char *argv[])
> >
> >  aub_write_exec(&aub, batch_addr, aub_gtt_size(&aub),
> I915_EXEC_RENDER);
> >
> > +   free(out_filename);
> > +   free(line);
> > +   if(err_file) {
> > +  fclose(err_file);
> > +   }
> > +   aub_file_finish(&aub);
> >  return EXIT_SUCCESS;
> >   }
> >
>
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v3 1/2] i965/batch: avoid reverting batch buffer if saved state is an empty

[andrey simiklit]

Hello,

Thanks a lot)

Regards,
Andrii.

On Tue, Oct 30, 2018 at 9:22 PM Jordan Justen 
wrote:

> On 2018-10-26 01:06:52, andrey simiklit wrote:
> > Hi,
> >
> > Could you please help me with a push. I don't have a right for it :-)
> >
>
> I pushed these two patches. Thanks!
>
> e4e0fd5ffe1 i965/batch: don't ignore the 'brw_new_batch' call for a 'new
> batch'
> a9031bf9b55 i965/batch: avoid reverting batch buffer if saved state is an
> empty
>
> -Jordan
>

> >
> > On Thu, Oct 11, 2018 at 9:22 PM Jordan Justen  >
> > wrote:
> >
> > > On 2018-10-11 03:01:56, andrey simiklit wrote:
> > > > Hello,
> > > >
> > > > Thanks for reviewing.
> > > > Please find my comment below.
> > > >
> > > > On Thu, Oct 11, 2018 at 12:37 AM Jordan Justen <
> > > jordan.l.jus...@intel.com>
> > > > wrote:
> > > >
> > > > > On 2018-09-12 09:05:44,  wrote:
> > > > > > From: Andrii Simiklit 
> > > > > >
> > > > > > There's no point reverting to the last saved point if that save
> > > point is
> > > > > > the empty batch, we will just repeat ourselves.
> > > > > >
> > > > > > CC: Chris Wilson 
> > > > > > Fixes: 3faf56ffbdeb "intel: Add an interface for saving/restoring
> > > > > >  the batchbuffer state."
> > > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107626
> > > > > > ---
> > > > > >  src/mesa/drivers/dri/i965/brw_compute.c   | 3 ++-
> > > > > >  src/mesa/drivers/dri/i965/brw_draw.c  | 3 ++-
> > > > > >  src/mesa/drivers/dri/i965/genX_blorp_exec.c   | 3 ++-
> > > > > >  src/mesa/drivers/dri/i965/intel_batchbuffer.c | 7 +++
> > > > > >  src/mesa/drivers/dri/i965/intel_batchbuffer.h | 1 +
> > > > > >  5 files changed, 14 insertions(+), 3 deletions(-)
> > > > > >
> > > > > > diff --git a/src/mesa/drivers/dri/i965/brw_compute.c
> > > > > b/src/mesa/drivers/dri/i965/brw_compute.c
> > > > > > index de08fc3..5c8e3a5 100644
> > > > > > --- a/src/mesa/drivers/dri/i965/brw_compute.c
> > > > > > +++ b/src/mesa/drivers/dri/i965/brw_compute.c
> > > > > > @@ -167,7 +167,7 @@ static void
> > > > > >  brw_dispatch_compute_common(struct gl_context *ctx)
> > > > > >  {
> > > > > > struct brw_context *brw = brw_context(ctx);
> > > > > > -   bool fail_next = false;
> > > > > > +   bool fail_next;
> > > > > >
> > > > > > if (!_mesa_check_conditional_render(ctx))
> > > > > >return;
> > > > > > @@ -185,6 +185,7 @@ brw_dispatch_compute_common(struct gl_context
> > > *ctx)
> > > > > > intel_batchbuffer_require_space(brw, 600);
> > > > > > brw_require_statebuffer_space(brw, 2500);
> > > > > > intel_batchbuffer_save_state(brw);
> > > > > > +   fail_next = intel_batchbuffer_saved_state_is_empty(brw);
> > > > > >
> > > > > >   retry:
> > > > > > brw->batch.no_wrap = true;
> > > > > > diff --git a/src/mesa/drivers/dri/i965/brw_draw.c
> > > > > b/src/mesa/drivers/dri/i965/brw_draw.c
> > > > > > index 8536c04..19ee396 100644
> > > > > > --- a/src/mesa/drivers/dri/i965/brw_draw.c
> > > > > > +++ b/src/mesa/drivers/dri/i965/brw_draw.c
> > > > > > @@ -885,7 +885,7 @@ brw_draw_single_prim(struct gl_context *ctx,
> > > > > >  {
> > > > > > struct brw_context *brw = brw_context(ctx);
> > > > > > const struct gen_device_info *devinfo =
> &brw->screen->devinfo;
> > > > > > -   bool fail_next = false;
> > > > > > +   bool fail_next;
> > > > > >
> > > > > > /* Flag BRW_NEW_DRAW_CALL on every draw.  This allows us to
> have
> > > > > >  * atoms that happen on every draw call.
> > > > > > @@ -898,6 +898,7 @@ brw_draw_single_prim(struct gl_context *ctx,
> > > > > > intel_batchbuffer_require_space(brw, 1500);
> > > > > > brw_require_statebuffer_space(brw, 2400);
> > > > > &

Re: [Mesa-dev] [PATCH v3 1/2] i965/batch: avoid reverting batch buffer if saved state is an empty

[andrey simiklit]

Hello,

On Tue, Oct 30, 2018 at 9:14 PM Kenneth Graunke 
wrote:

> On Friday, October 26, 2018 1:06:52 AM PDT andrey simiklit wrote:
> > Hi,
> >
> > Could you please help me with a push. I don't have a right for it :-)
> >
> > Thanks,
> > Andrii.
>
> Thanks for fixing these up!
>
> While we're here, there are several other variables where we track the
> last known state of the GPU, which can go wrong if we roll back the
> commands that actually set that state:
>
> We may have rolled back a 3DSTATE_CONSTANT_* emit, so need to set
>
> brw->*.base.push_constants_dirty = true;
>
> We may have rolled back a 3DSTATE_URB_* emit, so need to set
>
> brw->urb.{vghd}size = something that won't match so we re-emit
>
> We may have rolled back 3DSTATE_DEPTH_BUFFER & friends, so we need
> to somehow deal with:
>
> brw->no_depth_or_stencil
>
> There may be more.
>
> Bonus points if you want to fix some of those up. :)  Thanks again!
>
> --Ken
>

Thanks a lot for your advices.
I am going to investigate these issues as soon as complete my current task.

Regards,
Andrii.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2] intel/tools: fix resource leak

[andrey simiklit]

Hello,

Sorry, one more point here.
Could I ask you to push it, because I don't have a push rights :-)

Thanks a lot,
Andrii.

On Fri, Oct 26, 2018 at 6:09 PM Lionel Landwerlin <
lionel.g.landwer...@intel.com> wrote:

> On 26/10/2018 15:29, asimiklit.w...@gmail.com wrote:
> > From: Andrii Simiklit 
> >
> > Some memory and file descriptors are not freed/closed.
> >
> > v2: fixed case where we skipped the 'aub' variable initialization
> >
> > Signed-off-by: Andrii Simiklit 
>
>
> Still :
>
> Reviewed-by: Lionel Landwerlin 
>
>
> Thanks!
>
>
> > ---
> >   src/intel/tools/error2aub.c | 10 ++
> >   1 file changed, 10 insertions(+)
> >
> > diff --git a/src/intel/tools/error2aub.c b/src/intel/tools/error2aub.c
> > index 8a23d5ef1e..2b850ce885 100644
> > --- a/src/intel/tools/error2aub.c
> > +++ b/src/intel/tools/error2aub.c
> > @@ -326,6 +326,16 @@ main(int argc, char *argv[])
> >
> >  aub_write_exec(&aub, batch_addr, aub_gtt_size(&aub),
> I915_EXEC_RENDER);
> >
> > +   free(out_filename);
> > +   free(line);
> > +   if(err_file) {
> > +  fclose(err_file);
> > +   }
> > +   if(aub.file) {
> > +  aub_file_finish(&aub);
> > +   } else if(aub_file) {
> > +  fclose(aub_file);
> > +   }
> >  return EXIT_SUCCESS;
> >   }
> >
>
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH mesa] move variable-sized struct at the end of parent struct

[andrey simiklit]

Hello,

Please find my comments below:

On Thu, Nov 1, 2018 at 12:24 PM Eric Engestrom 
wrote:

>   warning: field 'base' with variable sized type 'struct
> drm_i915_query_topology_info'
>   not at the end of a struct or class is a GNU extension
> [-Wgnu-variable-sized-type-not-at-end]
>
> Signed-off-by: Eric Engestrom 
> ---
>  src/intel/dev/gen_device_info.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/intel/dev/gen_device_info.c
> b/src/intel/dev/gen_device_info.c
> index 5dbd06075722f8cc644e..242fe163447a4265acfb 100644
> --- a/src/intel/dev/gen_device_info.c
> +++ b/src/intel/dev/gen_device_info.c
> @@ -991,8 +991,8 @@ gen_device_info_update_from_masks(struct
> gen_device_info *devinfo,
>uint32_t n_eus)
>  {
> struct {
> -  struct drm_i915_query_topology_info base;
>uint8_t data[100];
> +  struct drm_i915_query_topology_info base;
> } topology;
>

I can be wrong, but it seems like here the 'data[100]' field should rather
be placed after the 'base' field
because it was done as far as I understood to allocate memory on the stack
for the 'drm_i915_query_topology_info::data[]' field. I guess that this
patch
may introduce the stack corruption on the following line:
   for (int b = 0; b < topology.base.subslice_offset; b++)
  topology.base.data[b] = (slice_mask >> (b * 8)) & 0xff;



assert((slice_mask & 0xff) == slice_mask);
> --
> Cheers,
>   Eric
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>

Regards,
Andrii.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v4 1/2] i965/batch: avoid reverting batch buffer if saved state is an empty

[andrey simiklit]

Hello,

I tested this patch few times and have the following results:
https://mesa-ci.01.org/global_logic/builds/38/group/63a9f0ea7bb98050796b649e85481845
https://mesa-ci.01.org/global_logic/builds/41/group/63a9f0ea7bb98050796b649e85481845
https://mesa-ci.01.org/global_logic/builds/43/group/63a9f0ea7bb98050796b649e85481845

All test runs are finished with the following issue on G965:

https://mesa-ci.01.org/global_logic/builds/38/results/46496330
ext_framebuffer_multisample-accuracy all_samples srgb small depthstencil
linear -auto -fbo

ERROR: This test passed when it expected failure

Note: Also I checked latest mesa master few times and there was no
regression:

https://mesa-ci.01.org/global_logic/builds/42/group/63a9f0ea7bb98050796b649e85481845

Regards,
Andrii.

On Mon, Nov 5, 2018 at 9:48 AM  wrote:

> From: Andrii Simiklit 
>
> There's no point reverting to the last saved point if that save point is
> the empty batch, we will just repeat ourselves.
>
> v2: Merge with new commits, changes was minimized, added the 'fixes' tag
> v3: Added in to patch series
> v4: Fixed the regression which was introduced by this patch
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108630
> Reported-by:  Mark Janes 
> The solution provided by: Jordan Justen 
>
> CC: Chris Wilson 
> Fixes: 3faf56ffbdeb "intel: Add an interface for saving/restoring
>  the batchbuffer state."
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107626
> Signed-off-by: Andrii Simiklit 
> ---
>  src/mesa/drivers/dri/i965/brw_compute.c   | 3 ++-
>  src/mesa/drivers/dri/i965/brw_draw.c  | 3 ++-
>  src/mesa/drivers/dri/i965/genX_blorp_exec.c   | 1 +
>  src/mesa/drivers/dri/i965/intel_batchbuffer.c | 7 +++
>  src/mesa/drivers/dri/i965/intel_batchbuffer.h | 1 +
>  5 files changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_compute.c
> b/src/mesa/drivers/dri/i965/brw_compute.c
> index de08fc3ac1..5c8e3a5d4d 100644
> --- a/src/mesa/drivers/dri/i965/brw_compute.c
> +++ b/src/mesa/drivers/dri/i965/brw_compute.c
> @@ -167,7 +167,7 @@ static void
>  brw_dispatch_compute_common(struct gl_context *ctx)
>  {
> struct brw_context *brw = brw_context(ctx);
> -   bool fail_next = false;
> +   bool fail_next;
>
> if (!_mesa_check_conditional_render(ctx))
>return;
> @@ -185,6 +185,7 @@ brw_dispatch_compute_common(struct gl_context *ctx)
> intel_batchbuffer_require_space(brw, 600);
> brw_require_statebuffer_space(brw, 2500);
> intel_batchbuffer_save_state(brw);
> +   fail_next = intel_batchbuffer_saved_state_is_empty(brw);
>
>   retry:
> brw->batch.no_wrap = true;
> diff --git a/src/mesa/drivers/dri/i965/brw_draw.c
> b/src/mesa/drivers/dri/i965/brw_draw.c
> index 8536c04010..19ee3962d7 100644
> --- a/src/mesa/drivers/dri/i965/brw_draw.c
> +++ b/src/mesa/drivers/dri/i965/brw_draw.c
> @@ -885,7 +885,7 @@ brw_draw_single_prim(struct gl_context *ctx,
>  {
> struct brw_context *brw = brw_context(ctx);
> const struct gen_device_info *devinfo = &brw->screen->devinfo;
> -   bool fail_next = false;
> +   bool fail_next;
>
> /* Flag BRW_NEW_DRAW_CALL on every draw.  This allows us to have
>  * atoms that happen on every draw call.
> @@ -898,6 +898,7 @@ brw_draw_single_prim(struct gl_context *ctx,
> intel_batchbuffer_require_space(brw, 1500);
> brw_require_statebuffer_space(brw, 2400);
> intel_batchbuffer_save_state(brw);
> +   fail_next = intel_batchbuffer_saved_state_is_empty(brw);
>
> if (brw->num_instances != prim->num_instances ||
> brw->basevertex != prim->basevertex ||
> diff --git a/src/mesa/drivers/dri/i965/genX_blorp_exec.c
> b/src/mesa/drivers/dri/i965/genX_blorp_exec.c
> index 34bfcad03e..a62b88e166 100644
> --- a/src/mesa/drivers/dri/i965/genX_blorp_exec.c
> +++ b/src/mesa/drivers/dri/i965/genX_blorp_exec.c
> @@ -309,6 +309,7 @@ retry:
> intel_batchbuffer_require_space(brw, 1400);
> brw_require_statebuffer_space(brw, 600);
> intel_batchbuffer_save_state(brw);
> +   check_aperture_failed_once |=
> intel_batchbuffer_saved_state_is_empty(brw);
> brw->batch.no_wrap = true;
>
>  #if GEN_GEN == 6
> diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> index 8b769eaf53..6207de5a06 100644
> --- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> +++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> @@ -301,6 +301,13 @@ intel_batchbuffer_save_state(struct brw_context *brw)
> brw->batch.saved.exec_count = brw->batch.exec_count;
>  }
>
> +bool
> +intel_batchbuffer_saved_state_is_empty(struct brw_context *brw)
> +{
> +   struct intel_batchbuffer *batch = &brw->batch;
> +   return (batch->saved.map_next == batch->batch.map);
> +}
> +
>  void
>  intel_batchbuffer_reset_to_saved(struct brw_context *brw)
>  {
> diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.h
> b/src/mesa/drivers/dri/i965/intel_batchbuffer.h
> index 06321

Re: [Mesa-dev] [PATCH v4 1/2] i965/batch: avoid reverting batch buffer if saved state is an empty

[andrey simiklit]

Hello,

Thanks for your quick reply.
Is it acceptable that this patch somehow fixes one more test for G965
platform:
ext_framebuffer_multisample-accuracy 
or we need to fix this to push it?

Regards,
Andrii.

On Mon, Nov 5, 2018 at 10:42 AM Jordan Justen 
wrote:

> On 2018-11-05 00:11:52, andrey simiklit wrote:
> > Hello,
> >
> > I tested this patch few times and have the following results:
> >
> https://mesa-ci.01.org/global_logic/builds/38/group/63a9f0ea7bb98050796b649e85481845
> >
> https://mesa-ci.01.org/global_logic/builds/41/group/63a9f0ea7bb98050796b649e85481845
> >
> https://mesa-ci.01.org/global_logic/builds/43/group/63a9f0ea7bb98050796b649e85481845
> >
> > All test runs are finished with the following issue on G965:
> >
> > https://mesa-ci.01.org/global_logic/builds/38/results/46496330
> > ext_framebuffer_multisample-accuracy all_samples srgb small depthstencil
> > linear -auto -fbo
> > 
> > ERROR: This test passed when it expected failure
> >
> > Note: Also I checked latest mesa master few times and there was no
> > regression:
> >
> >
> https://mesa-ci.01.org/global_logic/builds/42/group/63a9f0ea7bb98050796b649e85481845
> >
>
> It also looks like the tex3d-maxsize test is back to failing after a
> few seconds on g965, rather than running forever. (So, #108630 is
> fixed by this version.)
>
> https://mesa-ci.01.org/global_logic/builds/38/results/46492597
>
> -Jordan


> >
> > On Mon, Nov 5, 2018 at 9:48 AM  wrote:
> >
> > > From: Andrii Simiklit 
> > >
> > > There's no point reverting to the last saved point if that save point
> is
> > > the empty batch, we will just repeat ourselves.
> > >
> > > v2: Merge with new commits, changes was minimized, added the 'fixes'
> tag
> > > v3: Added in to patch series
> > > v4: Fixed the regression which was introduced by this patch
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108630
> > > Reported-by:  Mark Janes 
> > > The solution provided by: Jordan Justen  >
> > >
> > > CC: Chris Wilson 
> > > Fixes: 3faf56ffbdeb "intel: Add an interface for saving/restoring
> > >  the batchbuffer state."
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107626
> > > Signed-off-by: Andrii Simiklit 
> > > ---
> > >  src/mesa/drivers/dri/i965/brw_compute.c   | 3 ++-
> > >  src/mesa/drivers/dri/i965/brw_draw.c  | 3 ++-
> > >  src/mesa/drivers/dri/i965/genX_blorp_exec.c   | 1 +
> > >  src/mesa/drivers/dri/i965/intel_batchbuffer.c | 7 +++
> > >  src/mesa/drivers/dri/i965/intel_batchbuffer.h | 1 +
> > >  5 files changed, 13 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/src/mesa/drivers/dri/i965/brw_compute.c
> > > b/src/mesa/drivers/dri/i965/brw_compute.c
> > > index de08fc3ac1..5c8e3a5d4d 100644
> > > --- a/src/mesa/drivers/dri/i965/brw_compute.c
> > > +++ b/src/mesa/drivers/dri/i965/brw_compute.c
> > > @@ -167,7 +167,7 @@ static void
> > >  brw_dispatch_compute_common(struct gl_context *ctx)
> > >  {
> > > struct brw_context *brw = brw_context(ctx);
> > > -   bool fail_next = false;
> > > +   bool fail_next;
> > >
> > > if (!_mesa_check_conditional_render(ctx))
> > >return;
> > > @@ -185,6 +185,7 @@ brw_dispatch_compute_common(struct gl_context *ctx)
> > > intel_batchbuffer_require_space(brw, 600);
> > > brw_require_statebuffer_space(brw, 2500);
> > > intel_batchbuffer_save_state(brw);
> > > +   fail_next = intel_batchbuffer_saved_state_is_empty(brw);
> > >
> > >   retry:
> > > brw->batch.no_wrap = true;
> > > diff --git a/src/mesa/drivers/dri/i965/brw_draw.c
> > > b/src/mesa/drivers/dri/i965/brw_draw.c
> > > index 8536c04010..19ee3962d7 100644
> > > --- a/src/mesa/drivers/dri/i965/brw_draw.c
> > > +++ b/src/mesa/drivers/dri/i965/brw_draw.c
> > > @@ -885,7 +885,7 @@ brw_draw_single_prim(struct gl_context *ctx,
> > >  {
> > > struct brw_context *brw = brw_context(ctx);
> > > const struct gen_device_info *devinfo = &brw->screen->devinfo;
> > > -   bool fail_next = false;
> > > +   bool fail_next;
> > >
> > > /* Flag BRW_NEW_DRAW_CALL on every draw.  This allows us to have
> > >  * atoms that happen on every draw call.
> > > @@ -898,6 +898,7 @@ brw

Re: [Mesa-dev] [PATCH v4 1/2] i965/batch: avoid reverting batch buffer if saved state is an empty

[andrey simiklit]

Hello,

Good news, thanks :-)
One more thanks for clarification about Intel CI workflow.

Thanks,
Andrii.

On Mon, Nov 5, 2018 at 6:31 PM Mark Janes  wrote:

> andrey simiklit  writes:
>
> > Hello,
> >
> > I tested this patch few times and have the following results:
> >
> https://mesa-ci.01.org/global_logic/builds/38/group/63a9f0ea7bb98050796b649e85481845
> >
> https://mesa-ci.01.org/global_logic/builds/41/group/63a9f0ea7bb98050796b649e85481845
> >
> https://mesa-ci.01.org/global_logic/builds/43/group/63a9f0ea7bb98050796b649e85481845
> >
> > All test runs are finished with the following issue on G965:
> >
> > https://mesa-ci.01.org/global_logic/builds/38/results/46496330
> > ext_framebuffer_multisample-accuracy all_samples srgb small depthstencil
> > linear -auto -fbo
> > 
> > ERROR: This test passed when it expected failure
>
> If you test the exact same revision twice in i965 CI, it will simply
> publish the results from the previous run.  Often, a single machine
> fails in a run, and we send the build a second time to re-test only that
> machine (all other results are re-used for faster results).  We re-use
> results based the commits of the source projects.
>
> Instead of alternating two commits through the CI, you should trivially
> amend the commit message of the patch you want to test, so it gets a
> different sha.  This will cause a complete re-test of the patch.
>
> For this test, it may be that you are looking at an intermittent result.
> However, it is never a problem to unexpectedly fix a test.
>
> > Note: Also I checked latest mesa master few times and there was no
> > regression:
> >
> >
> https://mesa-ci.01.org/global_logic/builds/42/group/63a9f0ea7bb98050796b649e85481845
> >
> > Regards,
> > Andrii.
> >
> > On Mon, Nov 5, 2018 at 9:48 AM  wrote:
> >
> >> From: Andrii Simiklit 
> >>
> >> There's no point reverting to the last saved point if that save point is
> >> the empty batch, we will just repeat ourselves.
> >>
> >> v2: Merge with new commits, changes was minimized, added the 'fixes' tag
> >> v3: Added in to patch series
> >> v4: Fixed the regression which was introduced by this patch
> >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108630
> >> Reported-by:  Mark Janes 
> >> The solution provided by: Jordan Justen 
> >>
> >> CC: Chris Wilson 
> >> Fixes: 3faf56ffbdeb "intel: Add an interface for saving/restoring
> >>  the batchbuffer state."
> >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107626
> >> Signed-off-by: Andrii Simiklit 
> >> ---
> >>  src/mesa/drivers/dri/i965/brw_compute.c   | 3 ++-
> >>  src/mesa/drivers/dri/i965/brw_draw.c  | 3 ++-
> >>  src/mesa/drivers/dri/i965/genX_blorp_exec.c   | 1 +
> >>  src/mesa/drivers/dri/i965/intel_batchbuffer.c | 7 +++
> >>  src/mesa/drivers/dri/i965/intel_batchbuffer.h | 1 +
> >>  5 files changed, 13 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/src/mesa/drivers/dri/i965/brw_compute.c
> >> b/src/mesa/drivers/dri/i965/brw_compute.c
> >> index de08fc3ac1..5c8e3a5d4d 100644
> >> --- a/src/mesa/drivers/dri/i965/brw_compute.c
> >> +++ b/src/mesa/drivers/dri/i965/brw_compute.c
> >> @@ -167,7 +167,7 @@ static void
> >>  brw_dispatch_compute_common(struct gl_context *ctx)
> >>  {
> >> struct brw_context *brw = brw_context(ctx);
> >> -   bool fail_next = false;
> >> +   bool fail_next;
> >>
> >> if (!_mesa_check_conditional_render(ctx))
> >>return;
> >> @@ -185,6 +185,7 @@ brw_dispatch_compute_common(struct gl_context *ctx)
> >> intel_batchbuffer_require_space(brw, 600);
> >> brw_require_statebuffer_space(brw, 2500);
> >> intel_batchbuffer_save_state(brw);
> >> +   fail_next = intel_batchbuffer_saved_state_is_empty(brw);
> >>
> >>   retry:
> >> brw->batch.no_wrap = true;
> >> diff --git a/src/mesa/drivers/dri/i965/brw_draw.c
> >> b/src/mesa/drivers/dri/i965/brw_draw.c
> >> index 8536c04010..19ee3962d7 100644
> >> --- a/src/mesa/drivers/dri/i965/brw_draw.c
> >> +++ b/src/mesa/drivers/dri/i965/brw_draw.c
> >> @@ -885,7 +885,7 @@ brw_draw_single_prim(struct gl_context *ctx,
> >>  {
> >> struct brw_context *brw = brw_context(ctx);
> >> const struct gen_device_info *devinfo = &brw->screen->devinfo;
>

Re: [Mesa-dev] [PATCH] miptree: test ability to use upside down miptree

[andrey simiklit]

Hi all,

Have somebody some suggestions for this test?
This patch is needed to test an issue (assertion in mesa) which will be
fixed by this mesa patch:
https://patchwork.freedesktop.org/patch/254397/

Regards,
Andrii.

On Tue, Oct 23, 2018 at 4:44 PM  wrote:

> From: Andrii Simiklit 
>
> Test that usage of upside down miptree doesn't cause assertion
>
> The miptree:
>
> level 0 = 1x1
> level 1 = 2x2
> level 2 = 4x4
> ...
> level n = NxN
>
> should be acceptable for case when we don't use a min filter.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107987
> Signed-off-by: Andrii Simiklit 
> ---
>  tests/opengl.py   |   1 +
>  tests/texturing/CMakeLists.gl.txt |   1 +
>  tests/texturing/tex-upside-down-miptree.c | 171 ++
>  3 files changed, 173 insertions(+)
>  create mode 100644 tests/texturing/tex-upside-down-miptree.c
>
> diff --git a/tests/opengl.py b/tests/opengl.py
> index f7e408cd5..f6a38e40e 100644
> --- a/tests/opengl.py
> +++ b/tests/opengl.py
> @@ -704,6 +704,7 @@ with profile.test_list.group_manager(
>  g(['getteximage-targets', '1D'])
>  g(['getteximage-targets', '2D'])
>  g(['teximage-scale-bias'])
> +g(['tex-upside-down-miptree'])
>  add_msaa_visual_plain_tests(g, ['draw-pixels'])
>  add_msaa_visual_plain_tests(g, ['read-front'], run_concurrent=False)
>  add_msaa_visual_plain_tests(g, ['read-front', 'clear-front-first'],
> diff --git a/tests/texturing/CMakeLists.gl.txt
> b/tests/texturing/CMakeLists.gl.txt
> index e5d41e432..02b572c79 100644
> --- a/tests/texturing/CMakeLists.gl.txt
> +++ b/tests/texturing/CMakeLists.gl.txt
> @@ -98,5 +98,6 @@ piglit_add_executable (texture-al texture-al.c)
>  piglit_add_executable (texture-rg texture-rg.c)
>  piglit_add_executable (teximage-colors teximage-colors.c)
>  piglit_add_executable (zero-tex-coord zero-tex-coord.c)
> +piglit_add_executable (tex-upside-down-miptree tex-upside-down-miptree.c)
>
>  # vim: ft=cmake:
> diff --git a/tests/texturing/tex-upside-down-miptree.c
> b/tests/texturing/tex-upside-down-miptree.c
> new file mode 100644
> index 0..2d10fb49a
> --- /dev/null
> +++ b/tests/texturing/tex-upside-down-miptree.c
> @@ -0,0 +1,171 @@
> +/*
> + * Copyright (c) 2018 Andrii Simiklit
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the
> "Software"),
> + * to deal in the Software without restriction, including without
> limitation
> + * the rights to use, copy, modify, merge, publish, distribute,
> sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the
> next
> + * paragraph) shall be included in all copies or substantial portions of
> the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT
> SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
> OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> DEALINGS
> + * IN THE SOFTWARE.
> + *
> + * Authors:
> + *Andrii Simiklit 
> + *
> + */
> +
> +/**
> + * Test what there no an assertion when we use upside down miptree and
> + * GL_TEXTURE_MIN_FILTER is GL_LINEAR, base level is not 0
> + * Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107987
> + */
> +
> +#include "piglit-util-gl.h"
> +#define TW 64
> +#define TH 64
> +
> +PIGLIT_GL_TEST_CONFIG_BEGIN
> +
> +   config.supports_gl_compat_version = 10;
> +
> +   config.window_visual = PIGLIT_GL_VISUAL_RGBA |
> PIGLIT_GL_VISUAL_DOUBLE;
> +   config.khr_no_error_support = PIGLIT_NO_ERRORS;
> +
> +PIGLIT_GL_TEST_CONFIG_END
> +
> +static unsigned nlevels = 0;
> +
> +static void
> +get_rect_bounds(int pos, int *x, int *y, int *w, int *h)
> +{
> +   *x = pos * (piglit_width / 3) + 5;
> +   *y = 5;
> +   *w = piglit_width / 3 - 10;
> +   *h = piglit_height - 10;
> +}
> +
> +
> +static void
> +draw_rect(int pos)
> +{
> +   int x, y, w, h;
> +   get_rect_bounds(pos, &x, &y, &w, &h);
> +   piglit_draw_rect_tex(x, y, w, h, 0, 0, 1, 1);
> +}
> +
> +
> +static GLboolean
> +probe_pos(int pos, const GLfloat expected[4])
> +{
> +   int x, y, w, h;
> +   get_rect_bounds(pos, &x, &y, &w, &h);
> +   return piglit_probe_rect_rgba(x, y, w, h, expected);
> +}
> +
> +
> +enum piglit_result
> +piglit_display(void)
> +{
> +   GLboolean pass = GL_TRUE;
> +   unsigned level;
> +   static const char *fragShaderText =
> +   "uniform sampler2D tex;\n"
> +   "void main(

Re: [Mesa-dev] [PATCH v2] egl: doesn't allow egl to create a forward-compatible context with req ver < 3

[andrey simiklit]

Hello,

Any updates here? :-)
This test is needed to check issue which should be fixed by the following
mesa patch:
https://patchwork.freedesktop.org/patch/256063/

This issue mentioned in this bug by Ian Romanick :
https://bugzilla.freedesktop.org/show_bug.cgi?id=92552#c9

Regards,
Andrii.

On Fri, Oct 12, 2018 at 3:11 PM  wrote:

> From: Andrii Simiklit 
>
> EGL_KHR_create_context spec says:
>"The default values for EGL_CONTEXT_MAJOR_VERSION_KHR and
> EGL_CONTEXT_MINOR_VERSION_KHR are 1 and 0 respectively."
>
> requesting a forward-compatible context for OpenGL
> versions less than 3.0 will generate an error.
>
>  "* If an OpenGL context is requested and the values for attributes
> EGL_CONTEXT_MAJOR_VERSION_KHR and EGL_CONTEXT_MINOR_VERSION_KHR,
> when considered together with the value for attribute
> EGL_CONTEXT_OPENGL_FORWARD_COMPATIBLE_BIT_KHR, specify an OpenGL
> version and feature set that are not defined, than an
> EGL_BAD_MATCH error is generated.
>
> The defined versions of OpenGL at the time of writing are OpenGL
> 1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 2.0, 2.1, 3.0, 3.1, 3.2, 4.0, 4.1,
> 4.2, and 4.3. Feature deprecation was introduced with OpenGL
> 3.0, so forward-compatible contexts may only be requested for
> OpenGL 3.0 and above. Thus, examples of invalid combinations of
> attributes include:
>
>   - Major version < 1 or > 4
>   - Major version == 1 and minor version < 0 or > 5
>   - Major version == 2 and minor version < 0 or > 1
>   - Major version == 3 and minor version < 0 or > 2
>   - Major version == 4 and minor version < 0 or > 3
>   - Forward-compatible flag set and major version < 3
>
> Because the purpose of forward-compatible contexts is to allow
> application development on a specific OpenGL version with the
> knowledge that the app will run on a future version, context
> creation will fail if
> EGL_CONTEXT_OPENGL_FORWARD_COMPATIBLE_BIT_KHR is set and the
> context version returned cannot implement exactly the requested
> version."
>
> v2: (Matt Turner) - The 'piglit_report_result' calls are moved to 'main'
>   - The variable oresult => result
>   - Fixed whitespace errors
>   - Fixed missing spaces after 'for'
>
> Signed-off-by: Andrii Simiklit 
> ---
>  .../valid-flag-forward-compatible-gl.c| 74 +++
>  1 file changed, 59 insertions(+), 15 deletions(-)
>
> diff --git
> a/tests/egl/spec/egl_khr_create_context/valid-flag-forward-compatible-gl.c
> b/tests/egl/spec/egl_khr_create_context/valid-flag-forward-compatible-gl.c
> index 42feb54d6..6d2bd0d9f 100644
> ---
> a/tests/egl/spec/egl_khr_create_context/valid-flag-forward-compatible-gl.c
> +++
> b/tests/egl/spec/egl_khr_create_context/valid-flag-forward-compatible-gl.c
> @@ -23,16 +23,30 @@
>  #include "piglit-util-egl.h"
>  #include "common.h"
>
> -int gl_version;
> +int gl_version = 0;
>
> -static bool try_flag(int flag)
> +static bool try_flag(int req_version, int flag)
>  {
> -   const EGLint attribs[] = {
> -   EGL_CONTEXT_FLAGS_KHR, flag,
> -   EGL_NONE
> -   };
> +   bool result = true;
> +   const unsigned vidx = req_version < 0 ? 0 : (req_version == 0) ? 1
> : 2;
> +   const bool is_forward_compatible =
> +   (0 != (flag &
> EGL_CONTEXT_OPENGL_FORWARD_COMPATIBLE_BIT_KHR));
>
> -   ctx = eglCreateContext(egl_dpy, cfg, EGL_NO_CONTEXT, attribs);
> +   const EGLint attribs[][5] = {
> +   /*req_version-before-case*/
> +   { EGL_CONTEXT_MAJOR_VERSION_KHR, abs(req_version),
> + EGL_CONTEXT_FLAGS_KHR, flag,
> + EGL_NONE },
> +   /*no-req_version-case*/
> +   { EGL_CONTEXT_FLAGS_KHR, flag,
> + EGL_NONE },
> +   /*req_version-after-case-*/
> +   { EGL_CONTEXT_FLAGS_KHR, flag,
> + EGL_CONTEXT_MAJOR_VERSION_KHR, abs(req_version),
> + EGL_NONE }
> +   };
> +   assert(vidx < 3);
> +   ctx = eglCreateContext(egl_dpy, cfg, EGL_NO_CONTEXT,
> attribs[vidx]);
> if (ctx != NULL) {
> /* Get GL version in order to know whether we can test
>  * EGL_CONTEXT_OPENGL_FORWARD_COMPATIBLE_BIT_KHR.
> @@ -47,6 +61,17 @@ static bool try_flag(int flag)
>
> gl_version = piglit_get_gl_version();
> }
> +   if (abs(req_version) < 3 && is_forward_compatible) {
> +   /* The EGL_KHR_create_context spec says:
> +*
> +* requesting a forward-compatible context for
> OpenGL
> +  

Re: [Mesa-dev] [PATCH] egl: return correct error code for a case req ver < 3 with forward-compatible

[andrey simiklit]

Hello,

Any updates here?

I think that I missed tag:
Reported-by: Ian Romanick 
Here: https://bugzilla.freedesktop.org/show_bug.cgi?id=92552#c9

The patch for the test which will check it:
https://patchwork.freedesktop.org/patch/256432/

Thanks,
Andrii.

On Thu, Oct 11, 2018 at 2:12 PM  wrote:

> From: Andrii Simiklit 
>
> The EGL_KHR_create_context spec says:
>"If an OpenGL context is requested and the values for attributes
> EGL_CONTEXT_MAJOR_VERSION_KHR and EGL_CONTEXT_MINOR_VERSION_KHR,
> when considered together with the value for attribute
> EGL_CONTEXT_OPENGL_FORWARD_COMPATIBLE_BIT_KHR, specify an OpenGL
> version and feature set that are not defined, than an
> EGL_BAD_MATCH error is generated."
>
> This case will be correctly handled
> a bit below after a 'for' loop when we
> remove this handling.
>
> Fixes: 11cabc45b712 "egl: rework handling EGL_CONTEXT_FLAGS"
> Bugzilla: https://bugzilla.freedesktop.org/show_bug.cgi?id=92552
> Signed-off-by: Andrii Simiklit 
> ---
>  src/egl/main/eglcontext.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/egl/main/eglcontext.c b/src/egl/main/eglcontext.c
> index ecc546e113..44a4469a97 100644
> --- a/src/egl/main/eglcontext.c
> +++ b/src/egl/main/eglcontext.c
> @@ -179,7 +179,7 @@ _eglParseContextAttribList(_EGLContext *ctx,
> _EGLDisplay *dpy,
>* will generate an error."
>*/
>   if ((val & EGL_CONTEXT_OPENGL_FORWARD_COMPATIBLE_BIT_KHR) &&
> - (api != EGL_OPENGL_API || ctx->ClientMajorVersion < 3)) {
> +  api != EGL_OPENGL_API) {
>  err = EGL_BAD_ATTRIBUTE;
>  break;
>   }
> --
> 2.17.1
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 11/13] anv: introduce device compatibility checks for format query

[andrey simiklit]

Hello,

Please find my comment below:

On Mon, Nov 5, 2018 at 5:36 PM Lionel Landwerlin <
lionel.g.landwer...@intel.com> wrote:

> We add a function that allows us to check whether a particular
> description of a Vulkan format is available for a given device.
>
> Signed-off-by: Lionel Landwerlin 
> ---
>  src/intel/vulkan/anv_formats.c| 65 ---
>  src/intel/vulkan/anv_image.c  |  4 +-
>  src/intel/vulkan/anv_private.h|  4 +-
>  src/intel/vulkan/vk_format_info.h |  2 +-
>  4 files changed, 57 insertions(+), 18 deletions(-)
>
> diff --git a/src/intel/vulkan/anv_formats.c
> b/src/intel/vulkan/anv_formats.c
> index 250af958d2e..c23fc1c5b1f 100644
> --- a/src/intel/vulkan/anv_formats.c
> +++ b/src/intel/vulkan/anv_formats.c
> @@ -42,6 +42,16 @@
>ISL_CHANNEL_SELECT_##a, \
>  }
>
> +static bool all_gens_compatible(const struct gen_device_info *devinfo)
> +{
> +   return true;
> +}
> +
> +static bool gen11_compatible(const struct gen_device_info *devinfo)
> +{
> +   return devinfo->gen >= 11;
> +}
> +
>  #define RGBA _ISL_SWIZZLE(RED, GREEN, BLUE, ALPHA)
>  #define BGRA _ISL_SWIZZLE(BLUE, GREEN, RED, ALPHA)
>  #define RGB1 _ISL_SWIZZLE(RED, GREEN, BLUE, ONE)
> @@ -55,6 +65,7 @@
>   }, \
>},\
>.n_planes = 1,\
> +  .compatible = all_gens_compatible,\
> }
>
>  #define fmt1(__hw_fmt) \
> @@ -69,6 +80,7 @@
>   },  \
>}, \
>.n_planes = 1, \
> +  .compatible = all_gens_compatible, \
> }
>
>  #define s_fmt(__hw_fmt)  \
> @@ -80,6 +92,7 @@
>   },  \
>}, \
>.n_planes = 1, \
> +  .compatible = all_gens_compatible, \
> }
>
>  #define ds_fmt(__fmt1, __fmt2)   \
> @@ -95,6 +108,7 @@
>   },  \
>}, \
>.n_planes = 2, \
> +  .compatible = all_gens_compatible, \
> }
>
>  #define fmt_unsupported \
> @@ -130,6 +144,17 @@
>}, \
>.n_planes = __n_planes,\
>.can_ycbcr = true, \
> +  .compatible = all_gens_compatible, \
> +   }
> +
> +#define ycbcr_gen_fmt(__n_planes, __compatible, ...)\
> +   {\
> +  .planes = {   \
> + __VA_ARGS__,   \
> +  },\
> +  .n_planes = __n_planes,   \
> +  .can_ycbcr = true,\
> +  .compatible = __compatible,   \
> }
>
>  #define fmt_list(__vk_fmt, ...) \
> @@ -335,12 +360,22 @@ static const struct anv_format *main_formats[] = {
>  };
>
>  static const struct anv_format *ycbcr_formats[] = {
> +   /**
> +* On Gen10 and below, the HW sampler won't allow us to have 2
> different
> +* view of a same buffer. This was changed on Gen11, so we can now
> make the
> +* 2 format below use 2 planes. This gives more flexibility in terms
> of how
> +* we want to same chroma components.
> +*/
> fmt_list(VK_FORMAT_G8B8G8R8_422_UNORM,
> -ycbcr_fmt(1,
> -  y_plane(ISL_FORMAT_YCRCB_SWAPUV, RGBA,
> _ISL_SWIZZLE(BLUE, GREEN, RED, ZERO,
> +ycbcr_gen_fmt(2, gen11_compatible,
> +  y_plane(ISL_FORMAT_R8G8_UNORM, RGBA,
> _ISL_SWIZZLE(GREEN, ZERO, ZERO, ZERO)),
> +  chroma_plane(0, ISL_FORMAT_R8G8B8A8_UNORM,
> RGBA, _ISL_SWIZZLE(ZERO, BLUE, ZERO, RED), 2, 1)),
> +ycbcr_fmt(1, y_plane(ISL_FORMAT_YCRCB_SWAPUV, RGBA,
> _ISL_SWIZZLE(BLUE, GREEN, RED, ZERO,
> fmt_list(VK_FORMAT_B8G8R8G8_422_UNORM,
> -ycbcr_fmt(1,
> -  y_plane(ISL_FORMAT_YCRCB_SWAPUVY, RGBA,
> _ISL_SWIZZLE(BLUE, GREEN, RED, ZERO,
> +ycbcr_gen_fmt(2, gen11_compatible,
> +  y_plane(ISL_FORMAT_R8G8_UNORM, RGBA,
> _ISL_SWIZZLE(ZERO, GREEN, ZERO, ZERO)),
> +  chroma_plane(0, ISL_FORMAT_R8G8B8A8_UNORM,
> RGBA, _ISL_SWIZZLE(BLUE, ZERO, RED, ZERO), 2, 1)),
> +ycbcr_fmt(1, y_plane(ISL_FORMAT_YCRCB_SWAPUVY, RGBA,
> _ISL_SWIZZLE(BLUE

Re: [Mesa-dev] [PATCH v4 1/2] i965/batch: avoid reverting batch buffer if saved state is an empty

[andrey simiklit]

Hello,

I don't know how we usually do in such cases.
Could I just restore back the 'review-by' tags here due to trivial changes
or this patch should pass review process once again?

Thanks,
Andrii.

On Mon, Nov 5, 2018 at 10:42 AM Jordan Justen 
wrote:

> On 2018-11-05 00:11:52, andrey simiklit wrote:
> > Hello,
> >
> > I tested this patch few times and have the following results:
> >
> https://mesa-ci.01.org/global_logic/builds/38/group/63a9f0ea7bb98050796b649e85481845
> >
> https://mesa-ci.01.org/global_logic/builds/41/group/63a9f0ea7bb98050796b649e85481845
> >
> https://mesa-ci.01.org/global_logic/builds/43/group/63a9f0ea7bb98050796b649e85481845
> >
> > All test runs are finished with the following issue on G965:
> >
> > https://mesa-ci.01.org/global_logic/builds/38/results/46496330
> > ext_framebuffer_multisample-accuracy all_samples srgb small depthstencil
> > linear -auto -fbo
> > 
> > ERROR: This test passed when it expected failure
> >
> > Note: Also I checked latest mesa master few times and there was no
> > regression:
> >
> >
> https://mesa-ci.01.org/global_logic/builds/42/group/63a9f0ea7bb98050796b649e85481845
> >
>
> It also looks like the tex3d-maxsize test is back to failing after a
> few seconds on g965, rather than running forever. (So, #108630 is
> fixed by this version.)
>
> https://mesa-ci.01.org/global_logic/builds/38/results/46492597
>
> -Jordan
>
> >
> > On Mon, Nov 5, 2018 at 9:48 AM  wrote:
> >
> > > From: Andrii Simiklit 
> > >
> > > There's no point reverting to the last saved point if that save point
> is
> > > the empty batch, we will just repeat ourselves.
> > >
> > > v2: Merge with new commits, changes was minimized, added the 'fixes'
> tag
> > > v3: Added in to patch series
> > > v4: Fixed the regression which was introduced by this patch
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108630
> > > Reported-by:  Mark Janes 
> > > The solution provided by: Jordan Justen  >
> > >
> > > CC: Chris Wilson 
> > > Fixes: 3faf56ffbdeb "intel: Add an interface for saving/restoring
> > >  the batchbuffer state."
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107626
> > > Signed-off-by: Andrii Simiklit 
> > > ---
> > >  src/mesa/drivers/dri/i965/brw_compute.c   | 3 ++-
> > >  src/mesa/drivers/dri/i965/brw_draw.c  | 3 ++-
> > >  src/mesa/drivers/dri/i965/genX_blorp_exec.c   | 1 +
> > >  src/mesa/drivers/dri/i965/intel_batchbuffer.c | 7 +++
> > >  src/mesa/drivers/dri/i965/intel_batchbuffer.h | 1 +
> > >  5 files changed, 13 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/src/mesa/drivers/dri/i965/brw_compute.c
> > > b/src/mesa/drivers/dri/i965/brw_compute.c
> > > index de08fc3ac1..5c8e3a5d4d 100644
> > > --- a/src/mesa/drivers/dri/i965/brw_compute.c
> > > +++ b/src/mesa/drivers/dri/i965/brw_compute.c
> > > @@ -167,7 +167,7 @@ static void
> > >  brw_dispatch_compute_common(struct gl_context *ctx)
> > >  {
> > > struct brw_context *brw = brw_context(ctx);
> > > -   bool fail_next = false;
> > > +   bool fail_next;
> > >
> > > if (!_mesa_check_conditional_render(ctx))
> > >return;
> > > @@ -185,6 +185,7 @@ brw_dispatch_compute_common(struct gl_context *ctx)
> > > intel_batchbuffer_require_space(brw, 600);
> > > brw_require_statebuffer_space(brw, 2500);
> > > intel_batchbuffer_save_state(brw);
> > > +   fail_next = intel_batchbuffer_saved_state_is_empty(brw);
> > >
> > >   retry:
> > > brw->batch.no_wrap = true;
> > > diff --git a/src/mesa/drivers/dri/i965/brw_draw.c
> > > b/src/mesa/drivers/dri/i965/brw_draw.c
> > > index 8536c04010..19ee3962d7 100644
> > > --- a/src/mesa/drivers/dri/i965/brw_draw.c
> > > +++ b/src/mesa/drivers/dri/i965/brw_draw.c
> > > @@ -885,7 +885,7 @@ brw_draw_single_prim(struct gl_context *ctx,
> > >  {
> > > struct brw_context *brw = brw_context(ctx);
> > > const struct gen_device_info *devinfo = &brw->screen->devinfo;
> > > -   bool fail_next = false;
> > > +   bool fail_next;
> > >
> > > /* Flag BRW_NEW_DRAW_CALL on every draw.  This allows us to have
> > >  * atoms that happen on every draw call.
> > > @@ -8

Re: [Mesa-dev] [PATCH v3] intel/decoder: Engine parameter for instructions

[andrey simiklit]

Hello,

Please find my comment below:

On Wed, Nov 7, 2018 at 4:49 PM Toni Lönnberg 
wrote:

> Preliminary work for adding handling of different pipes to gen_decoder.
> Each
> instruction needs to have a definition describing which engine it is meant
> for.
> If left undefined, by default, the instruction is defined for all engines.
>
> v2: Changed to use the engine class definitions from UAPI
>
> v3: Changed I915_ENGINE_CLASS_TO_MASK to use BITSET_BIT, change engine to
> engine_mask, added check for incorrect engine and added the possibility to
> define an instruction to multiple engines using the "|" as a delimiter in
> the
> engine attribute.
> ---
>  src/intel/common/gen_decoder.c | 23 +++
>  src/intel/common/gen_decoder.h |  6 ++
>  2 files changed, 29 insertions(+)
>
> diff --git a/src/intel/common/gen_decoder.c
> b/src/intel/common/gen_decoder.c
> index 8148b2f1489..79404660f56 100644
> --- a/src/intel/common/gen_decoder.c
> +++ b/src/intel/common/gen_decoder.c
> @@ -165,6 +165,9 @@ create_group(struct parser_context *ctx,
> group->fixed_length = fixed_length;
> group->dword_length_field = NULL;
> group->dw_length = 0;
> +   group->engine_mask =
> I915_ENGINE_CLASS_TO_MASK(I915_ENGINE_CLASS_RENDER) |
> +
> I915_ENGINE_CLASS_TO_MASK(I915_ENGINE_CLASS_VIDEO) |
> +I915_ENGINE_CLASS_TO_MASK(I915_ENGINE_CLASS_COPY);
> group->bias = 1;
>
> for (int i = 0; atts[i]; i += 2) {
> @@ -173,6 +176,26 @@ create_group(struct parser_context *ctx,
>   group->dw_length = strtoul(atts[i + 1], &p, 0);
>} else if (strcmp(atts[i], "bias") == 0) {
>   group->bias = strtoul(atts[i + 1], &p, 0);
> +  } else if (strcmp(atts[i], "engine") == 0) {
> + void *mem_ctx = ralloc_context(NULL);
> + char *tmp = ralloc_strdup(mem_ctx, atts[i + 1]);
> + char *save_ptr;
> + char *tok = strtok_r(tmp, "|", &save_ptr);
> +
> + group->engine_mask = 0;
> + while (tok != NULL) {
> +if (strcmp(tok, "render") == 0) {
> +   group->engine_mask |=
> I915_ENGINE_CLASS_TO_MASK(I915_ENGINE_CLASS_RENDER);
> +} else if (strcmp(tok, "video") == 0) {
> +   group->engine_mask |=
> I915_ENGINE_CLASS_TO_MASK(I915_ENGINE_CLASS_VIDEO);
> +} else if (strcmp(tok, "blitter") == 0) {
> +   group->engine_mask |=
> I915_ENGINE_CLASS_TO_MASK(I915_ENGINE_CLASS_COPY);
> +} else {
> +   fprintf(stderr, "unknown engine class defined for
> instruction \"%s\": %s\n", name, atts[i + 1]);
> +}
> +
> +tok = strtok_r(NULL, "|", &save_ptr);
> + }
>

Seems like 'ralloc_free(mem_ctx)' is missing here :-)

Regards,
- Andrii


>}
> }
>
> diff --git a/src/intel/common/gen_decoder.h
> b/src/intel/common/gen_decoder.h
> index 4beed22d729..4311f58b4eb 100644
> --- a/src/intel/common/gen_decoder.h
> +++ b/src/intel/common/gen_decoder.h
> @@ -30,6 +30,9 @@
>
>  #include "dev/gen_device_info.h"
>  #include "util/hash_table.h"
> +#include "util/bitset.h"
> +
> +#include "drm-uapi/i915_drm.h"
>
>  #ifdef __cplusplus
>  extern "C" {
> @@ -40,6 +43,8 @@ struct gen_group;
>  struct gen_field;
>  union gen_field_value;
>
> +#define I915_ENGINE_CLASS_TO_MASK(x) BITSET_BIT(x)
> +
>  static inline uint32_t gen_make_gen(uint32_t major, uint32_t minor)
>  {
> return (major << 8) | minor;
> @@ -102,6 +107,7 @@ struct gen_group {
> struct gen_field *dword_length_field; /*  specific */
>
> uint32_t dw_length;
> +   uint32_t engine_mask; /*  specific */
> uint32_t bias; /*  specific */
> uint32_t group_offset, group_count;
> uint32_t group_size;
> --
> 2.17.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/4] compiler: avoid 'unused variable' and 'may be used uninitialized' warnings

[andrey simiklit]

Hello,

Thanks for review.
Please find my comments below:

On Fri, Nov 9, 2018 at 2:52 PM Eric Engestrom 
wrote:

> On Tuesday, 2018-09-11 15:42:05 +0300, asimiklit.w...@gmail.com wrote:
> > From: Andrii Simiklit 
> >
> > 1. nir/nir_lower_vars_to_ssa.c:691:21: warning:
> >unused variable ‘var’
> >nir_variable *var = path->path[0]->var;
> >
> > 2. nir_types.cpp:558:31: warning:
> > ‘elem_align’ may be used uninitialized in this function
> >unsigned elem_size, elem_align;
> >nir_types.cpp:558:20: warning:
> >‘elem_size’ may be used uninitialized in this function
> >unsigned elem_size, elem_align;
> >
> > Signed-off-by: Andrii Simiklit 
> > ---
> >  src/compiler/nir/nir_lower_vars_to_ssa.c | 2 +-
> >  src/compiler/nir_types.cpp   | 4 ++--
> >  2 files changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/src/compiler/nir/nir_lower_vars_to_ssa.c
> b/src/compiler/nir/nir_lower_vars_to_ssa.c
> > index cd679be..96de261 100644
> > --- a/src/compiler/nir/nir_lower_vars_to_ssa.c
> > +++ b/src/compiler/nir/nir_lower_vars_to_ssa.c
> > @@ -688,7 +688,7 @@ nir_lower_vars_to_ssa_impl(nir_function_impl *impl)
> >nir_deref_path *path = &node->path;
> >
> >assert(path->path[0]->deref_type == nir_deref_type_var);
> > -  nir_variable *var = path->path[0]->var;
> > +  MAYBE_UNUSED nir_variable *var = path->path[0]->var;
> >
> >/* We don't build deref nodes for non-local variables */
> >assert(var->data.mode == nir_var_local);
>
> Sure, or you could simply remove the single-use extra local variable and
> just fold it into the assert :)
>

I agree,will fix :)


>
> > diff --git a/src/compiler/nir_types.cpp b/src/compiler/nir_types.cpp
> > index d24f094..d39d87b 100644
> > --- a/src/compiler/nir_types.cpp
> > +++ b/src/compiler/nir_types.cpp
> > @@ -542,7 +542,7 @@ glsl_get_natural_size_align_bytes(const struct
> glsl_type *type,
> > }
> >
> > case GLSL_TYPE_ARRAY: {
> > -  unsigned elem_size, elem_align;
> > +  unsigned elem_size = 0, elem_align = 0;
>
> Not really keen on these ones; it looks like your compiler is ignoring the
> unreachable() in glsl_get_natural_size_align_bytes() and mis-computing the
> possible code-paths, resulting in it wrongly printing a warning.
>

You are right when I added the 'default:' case to the switch the warning is
disappeared:

case GLSL_TYPE_INTERFACE:
case GLSL_TYPE_FUNCTION:
+default:
   unreachable("type does not have a natural size");

What do you think about such solution? Is it acceptable for you?


> I'd prefer to keep these two hunks as is, so that real issue in
> glsl_get_natural_size_align_bytes() would get flagged appropriately.
>
> >glsl_get_natural_size_align_bytes(type->fields.array,
> >  &elem_size, &elem_align);
> >*align = elem_align;
> > @@ -554,7 +554,7 @@ glsl_get_natural_size_align_bytes(const struct
> glsl_type *type,
> >*size = 0;
> >*align = 0;
> >for (unsigned i = 0; i < type->length; i++) {
> > - unsigned elem_size, elem_align;
> > + unsigned elem_size = 0, elem_align = 0;
> >
>  glsl_get_natural_size_align_bytes(type->fields.structure[i].type,
> > &elem_size, &elem_align);
> >   *align = MAX2(*align, elem_align);
> > --
> > 2.7.4
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/4] intel/tools: avoid 'ignoring return value' and 'unused variable' warnings

[andrey simiklit]

On Fri, Nov 9, 2018 at 2:45 PM Eric Engestrom 
wrote:

> On Tuesday, 2018-09-11 15:42:04 +0300, asimiklit.w...@gmail.com wrote:
> > From: Andrii Simiklit 
> >
> > 1. tools/i965_disasm.c:58:4: warning:
> > ignoring return value of ‘fread’,
> > declared with attribute warn_unused_result
> > fread(assembly, *end, 1, fp);
> >
> > 2. tools/aub_read.c:271:31: warning: unused variable ‘end’
> > const uint32_t *p = data, *end = data + data_len, *next;
> >
> > 3. tools/aub_mem.c:292:13: warning: unused variable ‘res’
> >void *res = mmap((uint8_t *)bo.map + map_offset, 4096, PROT_READ,
> >tools/aub_mem.c:357:13: warning: unused variable ‘res’
> >void *res = mmap((uint8_t *)bo.map + (page - bo.addr), 4096,
> PROT_READ,
> >
> > Signed-off-by: Andrii Simiklit 
> > ---
> >  src/intel/tools/aub_mem.c | 10 ++
> >  src/intel/tools/aub_read.c|  2 +-
> >  src/intel/tools/i965_disasm.c |  3 ++-
> >  3 files changed, 9 insertions(+), 6 deletions(-)
> >
> > diff --git a/src/intel/tools/aub_mem.c b/src/intel/tools/aub_mem.c
> > index 58b51b7..98e1421 100644
> > --- a/src/intel/tools/aub_mem.c
> > +++ b/src/intel/tools/aub_mem.c
> > @@ -289,8 +289,9 @@ aub_mem_get_ggtt_bo(void *_mem, uint64_t address)
> >   continue;
> >
> >uint32_t map_offset = i->virt_addr - address;
> > -  void *res = mmap((uint8_t *)bo.map + map_offset, 4096, PROT_READ,
> > -   MAP_SHARED | MAP_FIXED, mem->mem_fd,
> phys_mem->fd_offset);
> > +  MAYBE_UNUSED void *res =
> > +mmap((uint8_t *)bo.map + map_offset, 4096, PROT_READ,
> > +  MAP_SHARED | MAP_FIXED, mem->mem_fd,
> phys_mem->fd_offset);
> >assert(res != MAP_FAILED);
> > }
> >
> > @@ -354,8 +355,9 @@ aub_mem_get_ppgtt_bo(void *_mem, uint64_t address)
> > for (uint64_t page = address; page < end; page += 4096) {
> >struct phys_mem *phys_mem = ppgtt_walk(mem, mem->pml4, page);
> >
> > -  void *res = mmap((uint8_t *)bo.map + (page - bo.addr), 4096,
> PROT_READ,
> > -   MAP_SHARED | MAP_FIXED, mem->mem_fd,
> phys_mem->fd_offset);
> > +  MAYBE_UNUSED void *res =
> > +mmap((uint8_t *)bo.map + (page - bo.addr), 4096, PROT_READ,
> > +  MAP_SHARED | MAP_FIXED, mem->mem_fd,
> phys_mem->fd_offset);
> >assert(res != MAP_FAILED);
> > }
> >
>
> R-b on the above
>

> > diff --git a/src/intel/tools/aub_read.c b/src/intel/tools/aub_read.c
> > index 5b704e8..0a1f84a 100644
> > --- a/src/intel/tools/aub_read.c
> > +++ b/src/intel/tools/aub_read.c
> > @@ -268,7 +268,7 @@ handle_memtrace_mem_write(struct aub_read *read,
> const uint32_t *p)
> >  int
> >  aub_read_command(struct aub_read *read, const void *data, uint32_t
> data_len)
> >  {
> > -   const uint32_t *p = data, *end = data + data_len, *next;
> > +   MAYBE_UNUSED const uint32_t *p = data, *end = data + data_len, *next;
>
> You're flagging all of them as MAYBE_UNUSED; please split out the one
> variable for which it applies?
>

I agree, will fix.


>
> > uint32_t h, header_length, bias;
> >
> > assert(data_len >= 4);
> > diff --git a/src/intel/tools/i965_disasm.c
> b/src/intel/tools/i965_disasm.c
> > index 73a6760..e207def 100644
> > --- a/src/intel/tools/i965_disasm.c
> > +++ b/src/intel/tools/i965_disasm.c
> > @@ -55,7 +55,8 @@ i965_disasm_read_binary(FILE *fp, size_t *end)
> > if (assembly == NULL)
> >return NULL;
> >
> > -   fread(assembly, *end, 1, fp);
> > +   MAYBE_UNUSED size_t size = fread(assembly, *end, 1, fp);
> > +   assert((size == *end) && "error: unable to read all elements!");
>
> Please split this out in a separate patch, and I don't think this
> `size == *end` is right
>
> From `man 3 fread`:
> > On success, fread() and fwrite() return the number of items read or
> > written. This number equals the number of bytes transferred only when
> > size is 1.
>
> but here, size is `*end` and nmemb is `1`, so I would expect fread to
> return 1 on success and 0 on failure.
> Have you tested this? What value did you see?
>
> You can test the complete EOF failure path by adding this just before
> fread():
>   fseek(fp, 0, SEEK_END);
>
> And the more insidious "just a bit too short" failure path with:
>   fseek(fp, 1, SEEK_CUR);
>

Ops, I didn't notice that they are swapped. Thanks a lot :)
I will test it before fix :)


>
> > fclose(fp);
> >
> > return assembly;
> > --
> > 2.7.4
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/4] i965: avoid 'unused variable' and 'may be used uninitialized' warnings

[andrey simiklit]

On Fri, Nov 9, 2018 at 3:19 PM Eric Engestrom 
wrote:

> On Tuesday, 2018-09-11 15:42:06 +0300, asimiklit.w...@gmail.com wrote:
> > From: Andrii Simiklit 
> >
> > 1. brw_blorp.c:1502:4: warning:
> > ‘num_layers’ may be used uninitialized in this function
> > 2. brw_blorp.c:1502:4: warning:
> > ‘start_layer’ may be used uninitialized in this function
> > 3. brw_blorp.c:1502:4: warning:
> > ‘level’ may be used uninitialized in this function
> > 4. brw_pipe_control.c:311:34: warning:
> > unused variable ‘devinfo’
> > 5. brw_program_binary.c:209:19: warning:
> > unused variable ‘gen_size’
> > 6. brw_program_binary.c:216:19: warning:
> > unused variable ‘nir_size’
> > 7. intel_mipmap_tree.c:1698:10: warning:
> > ‘initial_state’ may be used uninitialized in this function
> >
> > Signed-off-by: Andrii Simiklit 
> > ---
> >  src/mesa/drivers/dri/i965/brw_blorp.c  | 2 +-
> >  src/mesa/drivers/dri/i965/brw_pipe_control.c   | 2 +-
> >  src/mesa/drivers/dri/i965/brw_program_binary.c | 4 ++--
> >  src/mesa/drivers/dri/i965/intel_mipmap_tree.c  | 4 ++--
> >  4 files changed, 6 insertions(+), 6 deletions(-)
> >
> > diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c
> b/src/mesa/drivers/dri/i965/brw_blorp.c
> > index ad747e0..a6e0f02 100644
> > --- a/src/mesa/drivers/dri/i965/brw_blorp.c
> > +++ b/src/mesa/drivers/dri/i965/brw_blorp.c
> > @@ -1443,7 +1443,7 @@ brw_blorp_clear_depth_stencil(struct brw_context
> *brw,
> > if (x0 == x1 || y0 == y1)
> >return;
> >
> > -   uint32_t level, start_layer, num_layers;
> > +   uint32_t level = 0, start_layer = 0, num_layers = 0;
>
> It would be cleaner to promote the assert() a few lines below into
> assume():
>   assert((mask & BUFFER_BIT_DEPTH) || stencil_mask);
>
>
I tried to reproduce this warnings but it is not reproducible for some
reason.
Possible due to upgrade from Ubuntu 16.04 to 18.04 (Maybe due to some GCC
changes) or some mesa config changes
I can't say for sure. So I would like to remove these changes from this
patch due to it.
Is it acceptable for you?


> > struct isl_surf isl_tmp[4];
> > struct blorp_surf depth_surf, stencil_surf;
> >
> > diff --git a/src/mesa/drivers/dri/i965/brw_pipe_control.c
> b/src/mesa/drivers/dri/i965/brw_pipe_control.c
> > index 122ac26..a3f521b 100644
> > --- a/src/mesa/drivers/dri/i965/brw_pipe_control.c
> > +++ b/src/mesa/drivers/dri/i965/brw_pipe_control.c
> > @@ -308,7 +308,7 @@ brw_emit_depth_stall_flushes(struct brw_context *brw)
> >  void
> >  gen7_emit_vs_workaround_flush(struct brw_context *brw)
> >  {
> > -   const struct gen_device_info *devinfo = &brw->screen->devinfo;
> > +   MAYBE_UNUSED const struct gen_device_info *devinfo =
> &brw->screen->devinfo;
> >
> > assert(devinfo->gen == 7);
> > brw_emit_pipe_control_write(brw,
> > diff --git a/src/mesa/drivers/dri/i965/brw_program_binary.c
> b/src/mesa/drivers/dri/i965/brw_program_binary.c
> > index db03332..1298d9e 100644
> > --- a/src/mesa/drivers/dri/i965/brw_program_binary.c
> > +++ b/src/mesa/drivers/dri/i965/brw_program_binary.c
> > @@ -206,14 +206,14 @@ brw_program_deserialize_driver_blob(struct
> gl_context *ctx,
> >   break;
> >switch ((enum driver_cache_blob_part)part_type) {
> >case GEN_PART: {
> > - uint32_t gen_size = blob_read_uint32(&reader);
> > + MAYBE_UNUSED uint32_t gen_size = blob_read_uint32(&reader);
> >   assert(!reader.overrun &&
> >  (uintptr_t)(reader.end - reader.current) > gen_size);
> >   deserialize_gen_program(&reader, ctx, prog, stage);
> >   break;
> >}
> >case NIR_PART: {
> > - uint32_t nir_size = blob_read_uint32(&reader);
> > + MAYBE_UNUSED uint32_t nir_size = blob_read_uint32(&reader);
> >   assert(!reader.overrun &&
> >  (uintptr_t)(reader.end - reader.current) > nir_size);
> >   const struct nir_shader_compiler_options *options =
>
> R-b on this two MAYBE_UNUSED hunks.
>
> > diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > index 3668135..31e8122 100644
> > --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > @@ -1769,8 +1769,8 @@ intel_miptree_alloc_aux(struct brw_context *brw,
> > assert(mt->aux_buf == NULL);
> >
> > /* Get the aux buf allocation parameters for this miptree. */
> > -   enum isl_aux_state initial_state;
> > -   uint8_t memset_value;
> > +   enum isl_aux_state initial_state = ISL_AUX_STATE_AUX_INVALID;
> > +   uint8_t memset_value = 0;
>
> Again, maybe promote assert(aux_surf_ok); to assume(), but this just
> would just hide issues if there ever were any added.
>
>
The similar results for this change, I unable to reproduce it.
So I would like to remove it too )


> > struct isl_surf aux_surf;
> > MAYBE_UNUSED bool aux_surf_ok = false;
> >
> > --
> > 2.7.4
> >
> > 

Re: [Mesa-dev] [PATCH 1/3 v2] glsl: prevent qualifiers modification of predeclared variables

[andrey simiklit]

Hello,

Thanks a lot for review.

Regards,
Andrii.


On Sat, Nov 10, 2018 at 5:38 AM Timothy Arceri 
wrote:

> Nice! Series is:
>
> Reviewed-by: Timothy Arceri 
>
> On 10/10/18 9:07 am, Ian Romanick wrote:
> > From: Ian Romanick 
> >
> > Section 3.7 (Identifiers) of the GLSL spec says:
> >
> >  However, as noted in the specification, there are some cases where
> >  previously declared variables can be redeclared to change or add
> >  some property, and predeclared "gl_" names are allowed to be
> >  redeclared in a shader only for these specific purposes.  More
> >  generally, it is an error to redeclare a variable, including those
> >  starting "gl_".
> >
> > This patch should fix piglit tests:
> > clip-distance-redeclare-without-inout.frag
> > clip-distance-redeclare-without-inout.vert
> >
> > However, this causes a regression in
> > clip-distance-out-values.shader_test.  A fix for that test has been sent
> > to the piglit list for review:
> >
> >  https://patchwork.freedesktop.org/patch/255201/
> >
> > As far as I understood following mailing thread:
> > https://lists.freedesktop.org/archives/piglit/2013-October/007935.html
> > looks like we have accepted to remove an ability to change qualifiers
> > but have not done it yet. Unless I missed something)
> >
> > v2 (idr): Move 'earlier->data.mode != var->data.mode' test much earlier
> > in the function.  Add special handling for gl_LastFragData.
> >
> > Signed-off-by: Andrii Simiklit 
> > Signed-off-by: Ian Romanick 
> > ---
> >   src/compiler/glsl/ast_to_hir.cpp | 51
> +---
> >   1 file changed, 27 insertions(+), 24 deletions(-)
> >
> > diff --git a/src/compiler/glsl/ast_to_hir.cpp
> b/src/compiler/glsl/ast_to_hir.cpp
> > index 1082d6c91cf..2e4c9ef6776 100644
> > --- a/src/compiler/glsl/ast_to_hir.cpp
> > +++ b/src/compiler/glsl/ast_to_hir.cpp
> > @@ -4238,6 +4238,29 @@ get_variable_being_redeclared(ir_variable
> **var_ptr, YYLTYPE loc,
> >
> >  *is_redeclaration = true;
> >
> > +   if (earlier->data.how_declared == ir_var_declared_implicitly) {
> > +  /* Verify that the redeclaration of a built-in does not change the
> > +   * storage qualifier.  There are a couple special cases.
> > +   *
> > +   * 1. Some built-in variables that are defined as 'in' in the
> > +   *specification are implemented as system values.  Allow
> > +   *ir_var_system_value -> ir_var_shader_in.
> > +   *
> > +   * 2. gl_LastFragData is implemented as a ir_var_shader_out, but
> the
> > +   *specification requires that redeclarations omit any
> qualifier.
> > +   *Allow ir_var_shader_out -> ir_var_auto for this one
> variable.
> > +   */
> > +  if (earlier->data.mode != var->data.mode &&
> > +  !(earlier->data.mode == ir_var_system_value &&
> > +var->data.mode == ir_var_shader_in) &&
> > +  !(strcmp(var->name, "gl_LastFragData") == 0 &&
> > +var->data.mode == ir_var_auto)) {
> > + _mesa_glsl_error(&loc, state,
> > +  "redeclaration cannot change qualification of
> `%s'",
> > +  var->name);
> > +  }
> > +   }
> > +
> >  /* From page 24 (page 30 of the PDF) of the GLSL 1.50 spec,
> >   *
> >   * "It is legal to declare an array without a size and then
> > @@ -4246,11 +4269,6 @@ get_variable_being_redeclared(ir_variable
> **var_ptr, YYLTYPE loc,
> >   */
> >  if (earlier->type->is_unsized_array() && var->type->is_array()
> >  && (var->type->fields.array == earlier->type->fields.array)) {
> > -  /* FINISHME: This doesn't match the qualifiers on the two
> > -   * FINISHME: declarations.  It's not 100% clear whether this is
> > -   * FINISHME: required or not.
> > -   */
> > -
> > const int size = var->type->array_size();
> > check_builtin_array_max_size(var->name, size, loc, state);
> > if ((size > 0) && (size <= earlier->data.max_array_access)) {
> > @@ -4342,28 +4360,13 @@ get_variable_being_redeclared(ir_variable
> **var_ptr, YYLTYPE loc,
> > earlier->data.precision = var->data.precision;
> > earlier->data.memory_coherent = var->data.memory_coherent;
> >
> > -   } else if (earlier->data.how_declared == ir_var_declared_implicitly
> &&
> > -  state->allow_builtin_variable_redeclaration) {
> > +   } else if ((earlier->data.how_declared == ir_var_declared_implicitly
> &&
> > +   state->allow_builtin_variable_redeclaration) ||
> > +  allow_all_redeclarations) {
> > /* Allow verbatim redeclarations of built-in variables. Not
> explicitly
> >  * valid, but some applications do it.
> >  */
> > -  if (earlier->data.mode != var->data.mode &&
> > -  !(earlier->data.mode == ir_var_system_value &&
> > -var->data.mode == ir_var_shader_in)) {
> > - _mesa_glsl_error(&loc, state,
> > -   

Re: [Mesa-dev] [PATCH v2 3/5] i965: avoid 'unused variable'

[andrey simiklit]

On Tue, Nov 13, 2018 at 6:35 PM Eric Engestrom 
wrote:

> On Tuesday, 2018-11-13 14:19:30 +0200, asimiklit.w...@gmail.com wrote:
> > From: Andrii Simiklit 
> >
> > 1. brw_pipe_control.c:311:34: warning:
> > unused variable ‘devinfo’
> > 2. brw_program_binary.c:209:19: warning:
> > unused variable ‘gen_size’
> > 3. brw_program_binary.c:216:19: warning:
> > unused variable ‘nir_size’
> >
> > v2: Changes for unreproducible issues were removed
> >
> > Signed-off-by: Andrii Simiklit 
> > ---
> >  src/mesa/drivers/dri/i965/brw_pipe_control.c   | 2 +-
> >  src/mesa/drivers/dri/i965/brw_program_binary.c | 4 ++--
> >  2 files changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/src/mesa/drivers/dri/i965/brw_pipe_control.c
> b/src/mesa/drivers/dri/i965/brw_pipe_control.c
> > index 122ac26070..a3f521b5ae 100644
> > --- a/src/mesa/drivers/dri/i965/brw_pipe_control.c
> > +++ b/src/mesa/drivers/dri/i965/brw_pipe_control.c
> > @@ -308,7 +308,7 @@ brw_emit_depth_stall_flushes(struct brw_context *brw)
> >  void
> >  gen7_emit_vs_workaround_flush(struct brw_context *brw)
> >  {
> > -   const struct gen_device_info *devinfo = &brw->screen->devinfo;
> > +   MAYBE_UNUSED const struct gen_device_info *devinfo =
> &brw->screen->devinfo;
> >
> > assert(devinfo->gen == 7);
>
> This could've just been folded into the assert, but this works.
>
> Patches 1-3 are:
> Reviewed-by: Eric Engestrom 
>

Thanks a lot for review.


>
> I assume you want me to push them for you?
>

Yes, it would be great. Thanks )


>
> > brw_emit_pipe_control_write(brw,
> > diff --git a/src/mesa/drivers/dri/i965/brw_program_binary.c
> b/src/mesa/drivers/dri/i965/brw_program_binary.c
> > index db03332241..1298d9e765 100644
> > --- a/src/mesa/drivers/dri/i965/brw_program_binary.c
> > +++ b/src/mesa/drivers/dri/i965/brw_program_binary.c
> > @@ -206,14 +206,14 @@ brw_program_deserialize_driver_blob(struct
> gl_context *ctx,
> >   break;
> >switch ((enum driver_cache_blob_part)part_type) {
> >case GEN_PART: {
> > - uint32_t gen_size = blob_read_uint32(&reader);
> > + MAYBE_UNUSED uint32_t gen_size = blob_read_uint32(&reader);
> >   assert(!reader.overrun &&
> >  (uintptr_t)(reader.end - reader.current) > gen_size);
> >   deserialize_gen_program(&reader, ctx, prog, stage);
> >   break;
> >}
> >case NIR_PART: {
> > - uint32_t nir_size = blob_read_uint32(&reader);
> > + MAYBE_UNUSED uint32_t nir_size = blob_read_uint32(&reader);
> >   assert(!reader.overrun &&
> >  (uintptr_t)(reader.end - reader.current) > nir_size);
> >   const struct nir_shader_compiler_options *options =
> > --
> > 2.17.1
> >
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] i965/tex: ignore the diff between GL_TEXTURE_2D and GL_TEXTURE_RECTANGLE

[andrey simiklit]

Hi,

> Ugh... not so good.  According to Oliver on the bug, this just make the
assert go away and doesn't actually fix anything.  Likely this is needed
but not sufficient.

So as far as I understand Oliver found the bad commit in xorg glamor:
https://bugs.freedesktop.org/show_bug.cgi?id=107287

So at the moment we should fix just this "assertion" issue for Intel
because "rendering" issue came from xorg/glamor and there is no "rendering"
issue in Intel part.
Please correct me if I incorrect.

Regards,
Andrii.

On Tue, Jul 10, 2018 at 8:04 PM, Olivier Fourdan  wrote:

> Hi,
>
> On Tue, 10 Jul 2018 at 18:56, Jason Ekstrand  wrote:
> >
> > Ugh... not so good.  According to Oliver on the bug, this just make the
> assert go away and doesn't actually fix anything.  Likely this is needed
> but not sufficient.
>
> Well, maybe not even needed, at least in my case I don't hit that
> assert() with the current Mesa code (from either master and 18.1),
> I've just seen that happening with past commits while doing the
> bisection in git... So adding this now wouldn't help with bisection
> (again, in my case, not sure about others).
>
> All I meant pointing at this assert() failure is that it breaks the
> bisection in git as I am unable to tell if the rendering is correct or
> not as it makes the test program abort.
>
> Cheers,
> Olivier
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] intel/decoder: fix the possible out of bounds group_iter

[andrey simiklit]

Hi,

Sorry I missed the main thought here.
The "gen_group_get_length" function returns *int*
but the "iter_group_offset_bits" function returns *uint32_t*
So *uint32_t*(*int*(-32)) = *0xFFE0U* and it looks like unexpected
behavior for me:
iter_group_offset_bits(iter, iter->group_iter + 1) < *0xFFE0U*;

Regards,
Andrii.

On Thu, Aug 9, 2018 at 2:35 PM, Andrii Simiklit 
wrote:

> The "gen_group_get_length" function can return a negative value
> and it can lead to the out of bounds group_iter.
>
> Signed-off-by: Andrii Simiklit 
> ---
>  src/intel/common/gen_decoder.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/src/intel/common/gen_decoder.c b/src/intel/common/gen_decoder
> .c
> index ec0a486..f09bd87 100644
> --- a/src/intel/common/gen_decoder.c
> +++ b/src/intel/common/gen_decoder.c
> @@ -803,8 +803,10 @@ static bool
>  iter_more_groups(const struct gen_field_iterator *iter)
>  {
> if (iter->group->variable) {
> -  return iter_group_offset_bits(iter, iter->group_iter + 1) <
> -  (gen_group_get_length(iter->group, iter->p) * 32);
> +  const int length = gen_group_get_length(iter->group, iter->p);
> +  return length > 0 &&
> + iter_group_offset_bits(iter, iter->group_iter + 1) <
> +  (length * 32);
> } else {
>return (iter->group_iter + 1) < iter->group->group_count ||
>   iter->group->next != NULL;
> --
> 2.7.4
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2] intel/decoder: fix the possible out of bounds group_iter

[andrey simiklit]

Hi all,

Thanks for your reply.

We shouldn't even get to use the iterator if it's an unknown instruction.
> The decoder should just advance dword by dword until it finds something
> that
> makes sense again.
>

Got it)
So this is an expected behavior there:

return iter_group_offset_bits(iter, iter->group_iter + 1) <
>   (gen_group_get_length(iter->group, iter->p) * 32);
>

when we convert a negative *int* to *uint* to return true to continue our
loop.

return iter_group_offset_bits(iter, iter->group_iter + 1) <
>   (*0xFFE0U*);
>

Do you think it is good idea to add comment or something like this into the
"iter_more_groups" function:

int *length* = gen_group_get_length(iter->group, iter->p);
>
return *length < 0 ||*
>iter_group_offset_bits(iter, iter->group_iter + 1) <
> (*length* * 32);
>

to show more explicitly here that we want to return true to continue our
loop
when the -1 is returned from the "gen_group_get_length" function
because at the moment it is a bit implicit)
Please let me know if I am incorrect.

Regards,
Andrii.

On Tue, Aug 14, 2018 at 7:08 PM, Lionel Landwerlin <
lionel.g.landwer...@intel.com> wrote:

> On 14/08/18 16:16, Rafael Antognolli wrote:
>
>> On Tue, Aug 14, 2018 at 03:36:18PM +0100, Lionel Landwerlin wrote:
>>
>>> On 14/08/18 12:55, asimiklit.work wrote:
>>>
 Hi Lionel,

> Hi Andrii,
>
> Again sorry, I don't think this is the right fix.
> I'm sending another patch to fix the parsing of
> MI_BATCH_BUFFER_START which seems to be the actual issue.
>
> Thanks for working on this,
>
 Thanks for your fast reply.
 I agree that it is not correct patch for this issue but anyway
 "iter_more_groups" function will still work incorrectly
 for unknown instructions when the "iter->group->variable" field is true.
 I guess that this case should be fixed.
 Please let me know if I am incorrect.

>>> Hey Andrii,
>>>
>>> We shouldn't even get to use the iterator if it's an unknown instruction.
>>> The decoder should just advance dword by dword until it finds something
>>> that
>>> makes sense again.
>>>
>>> If we run into that problem, I think we should fix the caller.
>>>
>> In that case, would an unreachable() or assert be a good thing to do?
>>
>
> Yep, I guess assert in gen_field_iterator_init() should be a good thing.
>
>
>> Regards,
 Andrii.

 On 2018-08-14 1:26 PM, Lionel Landwerlin wrote:

> Hi Andrii,
>
> Again sorry, I don't think this is the right fix.
> I'm sending another patch to fix the parsing of
> MI_BATCH_BUFFER_START which seems to be the actual issue.
>
> Thanks for working on this,
>
> -
> Lionel
>
> On 14/08/18 10:04, asimiklit.w...@gmail.com wrote:
>
>> From: Andrii Simiklit 
>>
>> The "gen_group_get_length" function can return a negative value
>> and it can lead to the out of bounds group_iter.
>>
>> v2: printing of "unknown command type" was added
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107544
>> Signed-off-by: Andrii Simiklit 
>> ---
>>src/intel/common/gen_decoder.c | 13 +++--
>>1 file changed, 11 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/intel/common/gen_decoder.c
>> b/src/intel/common/gen_decoder.c
>> index ec0a486..b36facf 100644
>> --- a/src/intel/common/gen_decoder.c
>> +++ b/src/intel/common/gen_decoder.c
>> @@ -770,6 +770,13 @@ gen_group_get_length(struct gen_group
>> *group, const uint32_t *p)
>>return -1;
>>  }
>>   }
>> +   default: {
>> +  fprintf(stderr, "Unknown command type %u in '%s::%s'\n",
>> +type,
>> +(group->parent && group->parent->name) ?
>> group->parent->name : "UNKNOWN",
>> +group->name ? group->name : "UNKNOWN");
>> +  break;
>> +   }
>>   }
>> return -1;
>> @@ -803,8 +810,10 @@ static bool
>>iter_more_groups(const struct gen_field_iterator *iter)
>>{
>>   if (iter->group->variable) {
>> -  return iter_group_offset_bits(iter, iter->group_iter + 1) <
>> -  (gen_group_get_length(iter->group, iter->p) * 32);
>> +  const int length = gen_group_get_length(iter->group, iter->p);
>> +  return length > 0 &&
>> +iter_group_offset_bits(iter, iter->group_iter + 1) <
>> +  (length * 32);
>>   } else {
>>  return (iter->group_iter + 1) < iter->group->group_count ||
>> iter->group->next != NULL;
>>
>
> ___
 mesa-dev mailing list
 mesa-dev@lists.freedesktop.org
 https://lists.freedesktop.org/mailman/listinfo/mesa-dev

>>>
>>>
>
___
mesa-dev mailing list
mesa-dev@lists.freedes

Re: [Mesa-dev] [PATCH] i965/gen6/xfb: handle case where transform feedback is not active

[andrey simiklit]

Hi all,

This workaround just helps me to avoid the graphical corruption on SNB but
I not sure is it good idea.

Regards,
Andrii.

On Wed, Aug 15, 2018 at 6:20 PM,  wrote:

> From: Andrii Simiklit 
>
> When the SVBI Payload Enable is false I guess the register R1.4
> which contains the Maximum Streamed Vertex Buffer Index is filled by zero
> and GS stops to write transform feedback when the transform feedback
> is not active.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107579
> Signed-off-by: Andrii Simiklit 
> ---
>  src/mesa/drivers/dri/i965/genX_state_upload.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/mesa/drivers/dri/i965/genX_state_upload.c
> b/src/mesa/drivers/dri/i965/genX_state_upload.c
> index ea5ad55..0f82500 100644
> --- a/src/mesa/drivers/dri/i965/genX_state_upload.c
> +++ b/src/mesa/drivers/dri/i965/genX_state_upload.c
> @@ -2806,7 +2806,7 @@ genX(upload_gs_state)(struct brw_context *brw)
>  #if GEN_GEN < 7
>   gs.SOStatisticsEnable = true;
>   if (gs_prog->info.has_transform_feedback_varyings)
> -gs.SVBIPayloadEnable = true;
> +gs.SVBIPayloadEnable = _mesa_is_xfb_active_and_unpaused(ctx);
>
>   /* GEN6_GS_SPF_MODE and GEN6_GS_VECTOR_MASK_ENABLE are enabled
> as it
>* was previously done for gen6.
> --
> 2.7.4
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] Why my account and all my MRs were removed from gitlab.freedesktop.org?

[andrey simiklit]

Hi all,

Today I faced a problem regarding my account @asimiklit on
gitlab.freedesktop.org, I can't sign in. It looks like user @asimiklit was
removed as well as my MRs. Something went wrong and I would like to sort
out the reason. Does somebody know something about this?


Additionally: My colleagues received messages like the following one:

> Merge request !6663
 was closed
by Daniel Stone

Regards,

Andrii.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] i965/tex: ignore the diff between GL_TEXTURE_2D and GL_TEXTURE_RECTANGLE

[andrey simiklit]

Hi,

I opened MR to fix this issue and started a discussion about the proper
solution:
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1258

Thanks,
Andrii.

On Wed, Jul 24, 2019 at 10:32 AM Olivier Fourdan  wrote:

> Hi,
>
> On Wed, May 22, 2019 at 4:01 AM Ian Romanick  wrote:
> > > On Thu, Jul 19, 2018 at 12:08 PM andrey simiklit
> > >
> > > Jason, can we reconsider Andrii's patch? It still applies cleanly
> > > (https://patchwork.freedesktop.org/patch/237490/)
> >
> > Looking at the patch and the "Simple reproducer" in the bug, I think
> > this just papers over the issue.  It seems like the problem is somewhere
> > down inside the driver's handling of glXBindTexImageEXT.  My best guess
> > is that the texture is GL_TEXTURE_2D but the miptree backing it is
> > GL_TEXTURE_RECTANGLE.  It seems that the glXBindTexImageEXT handling
> > should mark the miptree as GL_TEXTURE_2D when binding the image to a
> > texture that is GL_TEXTURE_2D.  Or is that not possible for some
> > non-obvious reason?
>
> Sorry to be a pain, but I still get bug reports in xfce for this, for
> everyone using a Mesa build with debug enabled (or a pre-release for
> that matter) on Intel, the `assert()` are enabled and this bug occurs
> with the xfce compositor.
>
> Maybe Andrii's patch is just hiding the issue, but that's already the
> case without the `assert()` enabled (i.e. all stable releases of
> Mesa), so I guess it's not such a big deal anyway.
>
> Can we agree on a fix on this?
>
> Cheers,
> Olivier
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] i965: add missing rollback of URB requirements

[andrey simiklit]

On Tue, Jan 8, 2019 at 11:01 PM Chris Wilson 
wrote:

> Quoting Kenneth Graunke (2019-01-08 20:17:01)
> > On Tuesday, January 8, 2019 3:11:37 AM PST Chris Wilson wrote:
> > > Quoting Lionel Landwerlin (2019-01-08 11:03:26)
> > > > Hi Andrii,
> > > >
> > > > Although I think what these patches do makes sense, I think it's
> missing
> > > > the bigger picture.
> > > > There is a lot more state that gets lost if we have to revert all of
> the
> > > > emitted commands.
> > > > A quick look at brw_upload_pipeline_state() shows all of the
> programs
> > > > could be invalid as well, or the number of samples, etc...
> > > >
> > > > To me it seems like we need a much larger state save/restore.
> > > >
> > > > Ken: what do you think?
> > >
> > > How about not rolling back? If we accept it as currently broken, and
> just
> > > demand the kernel provide logical contexts for all i965 devices (just
> ack
> > > some patches!), and then just flush the batch (possibly with a dummy 3D
> > > prim if you want to be sure the 3D state is loaded) and rely on the
> > > context preserving state across batches.
> > > -Chris
> >
> > I'm not sure precisely what you're proposing, but every scenario I can
> > think of is breaking in some subtle way.
> >
> > Option 1: Submit batch at last 3DPRIMITIVE, re-call emit in a new batch.
> >
> > This is what we do today; it doesn't work since brw_upload_render_state
> > implicitly sets CPU-side fields for "current state of the GPU", which
> > become inaccurate at rollback, so the next state upload would do the
> > wrong thing.  We'd need to roll all those back as well, or only commit
> > them when we finish uploading state.  Atoms also flag other new atoms,
> > and that's not getting rolled back, but extra flagging is harmless.
> >
> > Fixing this means disentangling some of our code, saving and restoring
> > more values, and so on.  Maybe dropping a few CPU micro-optimizations.
> >
> > Option 2: Submit batch at last 3DPRIMITIVE (A), memcpy commands for
> >   for failing primitive (B) into a new batch.
> >
> > This doesn't work either.  Let's say (A) issued a 3DSTATE_INDEX_BUFFER
> > command with a pointer to the index buffer.  (B) didn't change index
> > buffer state, so it doesn't emit one, intending to reuse the old value.
>
> This with all relocs with BRW_NEW_BATCH, and iirc the rule is that they
> are already tied into that BRW_NEW_BATCH flag. Except you don't need to
> memcpy, since you already have the 3DSTATE equivalent to the cpu state
> tracker in the batch, emit that, and it will be recorded in the context
> for the next batch. (You just don't tell the kernel about the
> buffers/relocs that cause the aperture exhaustion and it won't do
> anything about them. The GPU may load stale addresses, but never uses
> them, exactly like the context state on the next batch anyway.)
>
> It's not a great argument, but the argument is that there's less you
> need to fixup, than having to remember to every single comparison in
> order to rollback the cpu state tracker.
> -Chris
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>

So, have we a plan as to it?
This patch was sent 1 year ago and I almost forgot it.
Maybe it was fixed by somebody and this patch can be just rejected/closed)
- Andrii
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] piglit merge access

[andrey simiklit]

Hi,

I would like to request merge access for piglit gitlab. I have contributed
a number of commits for mesa/piglit. It would help in my work because
sometimes even already reviewed MRs remain not pushed for months.

Regards,
Andrii (asimiklit).
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] i965/tex: ignore the diff between GL_TEXTURE_2D and GL_TEXTURE_RECTANGLE

[andrey simiklit]

>
> Hi all,
>
> On Thu, Jul 19, 2018 at 12:08 PM andrey simiklit
>  wrote:
> > > Ugh... not so good.  According to Oliver on the bug, this just make
> the assert go away and doesn't actually fix anything.  Likely this is
> needed but not sufficient.
> >
> > So as far as I understand Oliver found the bad commit in xorg glamor:
> > https://bugs.freedesktop.org/show_bug.cgi?id=107287
> >
> > So at the moment we should fix just this "assertion" issue for Intel
> because "rendering" issue came from xorg/glamor and there is no "rendering"
> issue in Intel part.
> > Please correct me if I incorrect.
>
> Reviving an old thread/patch here.
>
> Andrey, I reckon your patch here is still much needed as it fixes the
> assert() issue:
>
> intel_mipmap_tree.c:1301: intel_miptree_match_image: Assertion
> `image->TexObject->Target == mt->target' failed.
>
> Which is still occurring even with current master.
>
> My patch was to fix the rendering issue (landed a while ago before
> 18.1 iirc), but yours was never merged and is still needed, I can
> reproduce the assert() at will with the reproducer from
> https://bugs.freedesktop.org/show_bug.cgi?id=107117
>
>
I could re-create this changes as MR instead of patch unless nobody against
it.

I fixed a bit the style of this patch to avoid new local variables:
https://gitlab.freedesktop.org/asimiklit/mesa/commit/c11aae1cd403dde240c3877974f6a4b467cc83f5



> Jason, can we reconsider Andrii's patch? It still applies cleanly
> (https://patchwork.freedesktop.org/patch/237490/)
>
> Cheers,
> Olivier
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev