[Mesa-dev] [PATCH] st/mesa: Don't apply multsample FB rasterization to non-multisample FBs.

[Ilia Mirkin]

On Fri, Dec 11, 2015 at 6:56 PM, Eric Anholt <eric at anholt.net> wrote:
> Ilia Mirkin <imirkin at alum.mit.edu> writes:
>
>> On Fri, Dec 11, 2015 at 3:37 PM, Eric Anholt <eric at anholt.net> 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