On Wed, Jan 8, 2014 at 8:21 PM, Brian Paul <bri...@vmware.com> wrote:
> On 01/08/2014 10:23 AM, Marek Olšák wrote:
>>
>> From: Marek Olšák <marek.ol...@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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
