On 10/29/2014 11:13 PM, Mathias Fröhlich wrote:
Hi Neil,
On Tuesday, October 28, 2014 18:22:33 Neil Roberts wrote:
On inspection it looks like this would potentially break
_mesa_meta_Clear when it is using GLSL because that does not save the
MESA_META_TRANSFORM state.
I wonder if MESA_META_TRANSFORM is not the right state flag for this
because all of the other state in it is about fixed-function stuff which
is irrelevant for shaders. It would be a shame for shader-based meta ops
to suddenly have to save all of that state too. Maybe it would make more
sense in MESA_META_VIEWPORT?
That moved to MESA_META_TRANSFORM due to a review request. As I
understood the rationale, it's already connected to the gl_context::Transform
variable by the GL spec, so it belongs into transform also for meta operations.
Brian, or what was there an other reason for moving this to MESA_META_TRANSFORM?
We've always put GL state into the attribute group specified by the GL
specification. Putting the new clip control state anywhere but in the
gl_context::Transform group would be inconsistent.
-Brian
Initially I had that saved if either MESA_META_VIEWPORT or
MESA_META_DEPTH_TEST is requested since the origin argument affects
the viewport transform and the depth mode affects the mapping of depth
values into the depth buffer.
I have at that time also thought about introducing a completely new
MESA_META_CLIP_CONTROL since clip control does not exactly fit anywhere.
Or as a third alternative split out a _mesa_clip_control_origin(origin)
and a _mesa_clip_control_mode(mode) from _mesa_ClipControl(mode, origin)
and use the mesa internal functions in meta.c to save if either
MESA_META_VIEWPORT or MESA_META_DEPTH_TEST was requested.
Greetings
Mathias
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
