On Wed, Jul 10, 2013 at 6:27 PM, Dave Airlie <airl...@gmail.com> wrote: > 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.
Yup I see the same thing. Stéphane _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
