[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