[Mesa-dev] [PATCH 3/4] mesa: Track the TexImage being rendered to in the gl_renderbuffer.

[Dave Airlie]

On Thu, Jul 11, 2013 at 11:31 AM, Stéphane Marchesin
<stephane.marchesin at gmail.com> wrote:
> On Wed, Jul 10, 2013 at 6:27 PM, Dave Airlie <airlied at gmail.com> wrote:
>> On Thu, Jul 11, 2013 at 11:05 AM, Stéphane Marchesin
>> <stephane.marchesin at gmail.com> wrote:
>>> On Wed, Jul 10, 2013 at 6:02 PM, Kenneth Graunke <kenneth at whitecape.org> wrote:
>>>> On 07/09/2013 04:33 PM, Stéphane Marchesin wrote:
>>>>>
>>>>> On Fri, May 10, 2013 at 11:37 PM, Eric Anholt <eric at anholt.net> wrote:
>>>>>>
>>>>>> We keep having to pass the attachments around with our gl_renderbuffers
>>>>>> because that's the only way to find what the gl_renderbuffer actually
>>>>>> refers to.  This is a step toward removing that (though drivers still
>>>>>> need
>>>>>> the Zoffset as well).
>>>>>
>>>>>
>>>>> Hi Eric,
>>>>>
>>>>> This change regresses WebGL in Chrome.
>>>>>
>>>>> Stéphane
>>>>
>>>>
>>>> Could you elaborate?  I just tried some WebGL demos in Chrome 27 on i965,
>>>> and they're working fine...so clearly not everything is broken.
>>>>
>>>
>>> On Chrome 29 on Chrome OS on sandy bridge, if I try something simple like:
>>> https://www.khronos.org/registry/webgl/sdk/demos/webkit/SpinningBox.html
>>> it says webgl crashed.
>>>
>>> It seems like reverting the following bit fixes it:
>>>
>>>     for (i = 0; i < BUFFER_COUNT; i++) {
>>>        struct gl_renderbuffer_attachment *att = fb->Attachment + i;
>>> -      if (att->Texture && att->Renderbuffer->TexImage) {
>>> +      if (att->Texture &&
>>> att->Texture->Image[att->CubeMapFace][att->TextureLevel]) {
>>>           ctx->Driver.RenderTexture(ctx, fb, att);
>>>        }
>>>     }
>>
>> I've had a crash in an internal app on mesa master with nouveau, in
>> the same place.
>>
>> att->Texture exists, att->Renderbuffer is NULL, I haven't had time to
>> track it down yet.
>
> Yup I see the same thing.
>
> Stéphane

http://people.freedesktop.org/~airlied/scratch/fbo-regression.c

is a hacked up piglit test that segfaults in the area, if it runs
it'll probably fail anyways, I'm not sure if its doing the same thing
as my app, but I don't think it should segfault. (my app is probably
doing a lot of dumb things).

Dave.