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

[Dave Airlie]

On Thu, Jul 11, 2013 at 8:44 PM, Dave Airlie <airlied at gmail.com> wrote:
> 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).

on 9.1 that test fails with erroneous incomplete fbo, which is the
wrong msg since test is crap and it isn't erroneous but it doesn't
segfault.

Dave.