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?
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
