[Mesa-dev] [PATCH 2/7] st/mesa: bind NULL colorbuffers as specified by glDrawBuffers

[Marek Olšák]

On Wed, Jan 8, 2014 at 8:21 PM, Brian Paul <brianp at vmware.com> wrote:
> On 01/08/2014 10:23 AM, Marek Olšák wrote:
>>
>> From: Marek Olšák <marek.olsak at amd.com>
>>
>> An example why it is required:
>>
>>      Let's say there's a fragment shader writing to gl_FragData[0..1].
>>      The user calls: glDrawBuffers(2, {GL_NONE, GL_COLOR_ATTACHMENT0});
>>
>>      That means gl_FragData[0] is unused and gl_FragData[1] is written
>>      to GL_COLOR_ATTACHMENT0.
>>
>> st/mesa was skipping the GL_NONE draw buffer, therefore gl_FragData[0]
>> was written to GL_COLOR_ATTACHMENT0, which was wrong.
>>
>> This commit fixes it, but drivers must also be fixed not to crash when
>> binding NULL colorbuffers. There is also a new set of piglit tests for
>> this.
>> ---
>>   src/gallium/auxiliary/util/u_framebuffer.c   | 21 +++++++++++++++++++++
>>   src/gallium/auxiliary/util/u_framebuffer.h   |  4 ++++
>>   src/mesa/state_tracker/st_atom_framebuffer.c | 14 ++++++++------
>>   src/mesa/state_tracker/st_atom_msaa.c        |  8 ++------
>>   src/mesa/state_tracker/st_cb_clear.c         |  2 +-
>>   src/mesa/state_tracker/st_cb_fbo.c           |  5 ++++-
>
>
> It looks like there's some MSAA changes mixed in here.  AFAICT, that's a
> separate piece of work.

Not really. It's there to not crash with NULL colorbuffers. The MSAA
state uses framebuffer->cbufs[0]->texture->nr_samples, but cbufs[0]
can be NULL with this patch. I fixed the code by adding a new util
function which returns the sample count from pipe_framebuffer_state.
The util function is also used by the other patches, so I put it in
the common gallium code.

Marek