Keith Whitwell wrote: > On Wed, 2010-01-27 at 09:09 -0800, José Fonseca wrote: >> On Wed, 2010-01-27 at 08:49 -0800, Brian Paul wrote: >>> Luca Barbieri wrote: >>>> Changes in v2: >>>> - Caps are added in a separate, subsequent patch >>>> >>>> This adds two TGSI fragment program properties that indicate the >>>> fragment coord conventions. >>>> >>>> The properties behave as described in the extension spec for >>>> GL_ARB_fragment_coord_conventions, but the default origin in >>>> upper left instead of lower left as in OpenGL. >>>> >>>> The syntax is: >>>> PROPERTY FS_COORD_ORIGIN [UPPER_LEFT|LOWER_LEFT] >>>> PROPERTY FS_COORD_PIXEL_CENTER [HALF_INTEGER|INTEGER] >>>> >>>> The names have been chosen for consistency with the GS properties >>>> and the OpenGL extension spec. >>>> >>>> The defaults are of course the previously assumed conventions: >>>> UPPER_LEFT and HALF_INTEGER. >>> Sorry for the slow reply on this. >>> >>> It looks like you've solved the fragcoord problems in a clean/logical >>> way. I haven't seen any objections, so I think we can move forward >>> with this. >> Didn't Keith had objections on this, on another thread? Luca re-sent the >> patch but I don't see the remark being addressed. > > I don't think my concerns are fatal to this approach, I just need to > understand the issues a bit better before signing off on it.
I meant I didn't see objections to Luca's latest patch series. After studying the issues for a while I think Luca's on the right track. I'll try to summarize. Re: coord origin upper/lower-left: A GPU may natively implement lower-left origin or upper-left origin (or both). With GL_ARB_fragment_coord_conventions, the user may want to use either of those origins. By asking the driver what it supports we can avoid extra Y-inversion code in the shader. Drivers don't have to do anything special other than tell the state tracker (via new cap bits) what it can do. Re: pixel center integer: Again, depending on what the GPU implements we may need to add/subtract a 0.5 bias to the fragment coord register in a fragment shader. This is orthogonal to pipe_rasterizer_state:: gl_rasterization_rules. With Luca's patch we query what the GPU can support and submit TGSI shaders which either tell the driver which convention to use, or submit shaders that implement the bias themselves. The new TGSI shader properties are needed because the origin/center state can change per-shader (it's not per-context) and for the sake of drivers that can support both conventions. I too was concerned whether this was all really needed but I think it is. -Brian ------------------------------------------------------------------------------ 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
