On 01/08/2014 12:51 PM, Marek Olšák wrote:
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.
OK, sounds good.
Reviewed-by: Brian Paul <bri...@vmware.com>
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
