On Tue, Sep 30, 2014 at 5:00 PM, Matt Turner <[email protected]> wrote:
> On Tue, Sep 30, 2014 at 4:24 PM, Matt Turner <[email protected]> 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 > Not sure what you're talking about here. I just threw in a quick assert to that effect with no piglit regressions. --Jason > > 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 > [email protected] > http://lists.freedesktop.org/mailman/listinfo/mesa-dev >
_______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
