Ian Romanick <i...@freedesktop.org> writes: > On 02/19/2013 04:27 PM, Carl Worth wrote: >> This fixes a bug introduced in commit 258453716f001eab1288d99765213 and >> triggered whenever "rb" is NULL. >> >> Fixes bug #59445: >> >> [SNB/IVB/HSW Bisected]Oglc draw-buffers2(advanced.blending.none) >> segfault >> https://bugs.freedesktop.org/show_bug.cgi?id=59445 >> --- >> >> I don't know under what conditions "rb" might be NULL, but it's clear that >> it's possible and expected as there is earlier code in this function that >> checks it, (and sets rb_type specifically in that case). So if someone could >> help me write a more descriptive commit message, that would be great. >> >> Also, I notice that similar code in brw_cc.c uses a different condition here: >> >> if (ctx->DrawBuffer->Visual.alphaBits == 0) { > > I don't know what cases could cause rb to be NULL either. There is code > earlier that checks this case (near the top of the function), so it > doesn't seem to be an error condition. Could this be for the window? > Ken or Eric should know for sure.
rb == NULL comes from the nr_draw_buffers == 0 workaround above. > Either way, ctx->DrawBuffer->Visual contains either the window > configuration or a mirror of the state for the current FBO. It should > always be safe to use that. Using ctx->DrawBuffer->Visual.alphaBits > will ensure that you get the correct answer even when rb is NULL. ctx->DrawBuffer->Visual doesn't know about your alpha bits when you have MRT some with alpha and some without. I prefer the first patch, which would get my: Reviewed-by: Eric Anholt <e...@anholt.net>
pgpwFm4bikWvs.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
