On Fri, Dec 11, 2015 at 6:56 PM, Eric Anholt <[email protected]> wrote: > Ilia Mirkin <[email protected]> writes: > >> On Fri, Dec 11, 2015 at 3:37 PM, Eric Anholt <[email protected]> wrote: >>> It's not just whether GL_MULTISAMPLE is 1 that determines if multisample >>> framebuffer operations happen, it's also whether SAMPLE_BUFFERS > 1. >>> Noticed with my broken sample_mask support when ETQW traces that were only >>> using a single sampled buffer crashed. >>> --- >>> src/mesa/state_tracker/st_atom_blend.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/src/mesa/state_tracker/st_atom_blend.c >>> b/src/mesa/state_tracker/st_atom_blend.c >>> index 6bb4077..812b2a7 100644 >>> --- a/src/mesa/state_tracker/st_atom_blend.c >>> +++ b/src/mesa/state_tracker/st_atom_blend.c >>> @@ -265,7 +265,7 @@ update_blend( struct st_context *st ) >>> >>> blend->dither = ctx->Color.DitherFlag; >>> >>> - if (ctx->Multisample.Enabled) { >>> + if (ctx->Multisample._Enabled) { >> >> Does this need _NEW_BUFFERS in the atom definition then? > > Good point. I'll fix that.
BTW, there's other crazy rules this doesn't encode... I noticed we got those wrong on nouveau, and saw that radeon also did them in the driver, so I did that too. But ostensibly it should be done in the st if we're willing to make blend depend on _NEW_BUFFERS? Or alternatively, we don't want to make the blend atom depend on _NEW_BUFFERS in which case this fixup needs to be done in your driver? http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/nv50/nv50_state_validate.c#n320 -ilia _______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
