[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: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.

Dave.