[Mesa-dev] [PATCH] gen7: fix GPU hang on WebGL texture-size test

Eric Anholt eric at anholt.net
Tue Jun 18 13:13:15 PDT 2013


Paul Berry <stereotype441 at gmail.com> writes:

> On 18 June 2013 01:09, Jordan Justen <jordan.l.justen at intel.com> wrote:
>
>> When rendering to a texture with BaseLevel set, the miptree may be laid
>> out such that BaseLevel is in level 0 of the miptree (to avoid wasting
>> memory on unused levels between 0 and BaseLevel-1).  In that case, we
>> have to shift our render target's level down to the appropriate level of
>> the smaller miptree.
>>
>> The WebGL test in combination with a meta code relating to
>> glGenerateMipmap also triggered a similar failure scenario.
>>
>> This GPU hang regression was introduced by c754f7a8.
>>
>> Bugzilla: http://bugs.freedesktop.org/show_bug.cgi?id=65324
>> Signed-off-by: Jordan Justen <jordan.l.justen at intel.com>
>> Cc: Eric Anholt <eric at anholt.net>
>> Cc: Kenneth Graunke <kenneth at whitecape.org>
>> Cc: Paul Berry <stereotype441 at gmail.com>
>> ---
>> Given all of Eric's help, this is probably more his patch than mine... :)
>>
>>  src/mesa/drivers/dri/i965/gen7_wm_surface_state.c |    2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
>> b/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
>> index 22ceaa5..620eafe 100644
>> --- a/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
>> +++ b/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
>> @@ -595,7 +595,7 @@ gen7_update_renderbuffer_surface(struct brw_context
>> *brw,
>>
>>     assert(brw->has_surface_tile_offset);
>>
>> -   surf[5] = irb->mt_level;
>> +   surf[5] = irb->mt_level - irb->mt->first_level;
>>
>>     surf[2] = SET_FIELD(irb->mt->logical_width0 - 1, GEN7_SURFACE_WIDTH) |
>>               SET_FIELD(irb->mt->logical_height0 - 1, GEN7_SURFACE_HEIGHT);
>> --
>> 1.7.10.4
>>
>>
> How difficult would it be to make a Piglit test to validate this,
> preferably one that verifies that depth/stencil rendering properly accounts
> for first_level != 0?  I want to make sure that when we make the
> corresponding changes to depth/stencil rendering we don't accidentally
> introduce the same bug.
>
> In any case, this patch is:
>
> Reviwed-by: Paul Berry <stereotype441 at gmail.com>

There's this really twitchy code for guessing an appropriate first_level
based on various GL state set at the moment you glTexImage() (or similar
calls, such as those baked into GenerateMipmaps()).  I found a field in
i915's HW state that I think I'd missed before when I tried to rip this
crap out, and there's a similar one in 855+, so I think I can go kill
it.

I think a test that would have broken would be: gen the texture, set the
base level to >0, set the filters to NEAREST, then TexImage(), then
render to that teximage using an FBO, then texture out of it to the
screen.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20130618/21f64fc2/attachment.pgp>


More information about the mesa-dev mailing list