On Thu, Jul 11, 2013 at 11:05 AM, Stéphane Marchesin <stephane.marche...@gmail.com> wrote: > On Wed, Jul 10, 2013 at 6:02 PM, Kenneth Graunke <kenn...@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 <e...@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. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
