On 02/20/2013 05:34 PM, Eric Anholt wrote:
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
Also, the correct way to say this is:
Bugzilla: 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:
That makes sense. The probably means the other place that uses
ctx->DrawBuffer->Visual should get changed too.
Reviewed-by: Eric Anholt <e...@anholt.net>
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
