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

[Stéphane Marchesin]

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