On Wed, 2010-01-27 at 09:24 -0800, Brian Paul wrote: > 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.
It appears everybody was in agreement after all. I really don't have an opinion on this, as I don't understand the different rules. From what I could gather it seems that even in the most limited hardware it is always possible to expose this new functionality either by tweaking shaders or flushing contexts before switching hardware global device settings. I'm a bit confused what will pipe_rasterizer_state::gl_rasterization_rules mean at the end of the day. Is it still necessary? Jose ------------------------------------------------------------------------------ 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
