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

Brian Paul brianp at vmware.com
Wed Jan 8 12:04:03 PST 2014


On 01/08/2014 12:51 PM, Marek Olšák wrote:
> 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.

OK, sounds good.

Reviewed-by: Brian Paul <brianp at vmware.com>



More information about the mesa-dev mailing list