On 12/07/2011 04:31 AM, Jose Fonseca wrote:
I wrote a testsuite for apitrace, and one of the tests checks the default GL
state against a reference, and it is failing on all Gallium DRI drivers because
{
parameters: {
GL_DRAW_BUFFER: "GL_BACK" -> "GL_BACK_LEFT",
GL_DRAW_BUFFER0: "GL_BACK" -> "GL_BACK_LEFT",
GL_READ_BUFFER: "GL_BACK" -> "GL_BACK_LEFT",
},
}
This looks like a bug as glDrawBuffer/glReadBuffer manpages are quite clear:
GL_BACK on double buffer visual, GL_
And the odd thing is that Mesa gets it right, but st_visual_to_default_buffer()
function goes out of its way to put the wrong values and this fixes it
diff --git a/src/mesa/state_tracker/st_manager.c
b/src/mesa/state_tracker/st_manager.c
index d5228d3..c64e175 100644
--- a/src/mesa/state_tracker/st_manager.c
+++ b/src/mesa/state_tracker/st_manager.c
@@ -414,6 +414,8 @@ st_visual_to_default_buffer(const struct st_visual *visual,
GLenum buf;
gl_buffer_index idx;
+ return;
+
statt = visual->render_buffer;
/* do nothing if an invalid render buffer is specified */
if (statt == ST_ATTACHMENT_INVALID ||
No other DRI driver changes these GL_BACK/GL_FRONT values.
Does this st_visual_to_default_buffer() server any purpose?
If it really does then, then at least GL_(BACK|FRONT)_(LEFT|RIGHT should be
replaced with GL_(BACK|FRONT) there.
AFAICT, we don't need st_visual_to_default_buffer() at all either.
Mesa always checks the gl_config/visual to determine whether to
initialize GL_READ/DRAW_BUFFER to GL_FRONT or GL_BACK. AFAICT, the
st_manager code initialized the visual correctly so I don't see why
the st_manager code needs to touch those vars.
Maybe Olv can take a look...
-Brian
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
