On Tue, Sep 30, 2014 at 4:24 PM, Matt Turner <matts...@gmail.com> wrote:
> The compiler isn't privy to the knowledge that we're doing at least one
> framebuffer write.
> ---
> src/mesa/drivers/dri/i965/brw_fs.cpp | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
> b/src/mesa/drivers/dri/i965/brw_fs.cpp
> index 19e9cb9..d113812 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
> @@ -2599,6 +2599,7 @@ fs_visitor::emit_repclear_shader()
> write->header_present = false;
> write->mlen = 1;
> } else {
> + assume(key->nr_color_regions > 0);
> for (int i = 0; i < key->nr_color_regions; ++i) {
> write = emit(FS_OPCODE_REP_FB_WRITE);
> write->saturate = key->clamp_fragment_color;
> --
> 1.8.5.5
I assumed that 'write' must actually be non-NULL after this block, but
a bunch of piglit tests fail if this patch is applied, like
spec/EXT_framebuffer_object/fbo-drawbuffers-blend-add
which is a little worrying, because the uninitialized variable warning
is complaining about 'write' being uninitialized in the statement
write->eot = true;
So this seems bad, but now I'm not convinced I understand what's going
on. How can we emit a repclear shader without an FB write?
I think the assume macro in patch 1/2 is potentially useful, but I'll
shelve it until we have a use.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
