> -- > > This flags are different from gl_rasterization_rules, as they only > affect fragment.position as seen by the shader, while > gl_rasterization_rules affects the "trigger point" for rasterization > itself only. I quoted the answer to this I already gave at the end of > the message. > > OpenGL makes the convention part of the shader. > > Of course, we could design Gallium in a different way, but I don't see > any advantage that would justify the inconvenience. > Also, since the flags only affect the fragment shader (as discussed > below), it makes sense for it to be part of it.
I think this is the most convincing point -- no other API than GL will make this configurable, and GL puts it in the shader. Unless implementing it this way runs us into major problems, I don't see any justification for introducing an extra gap between GL and gallium semantics, which means I'm basically OK with Luca's approach. Keith ------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev