On Wed, 2010-01-20 at 12:05 -0800, Luca Barbieri wrote: > > On the other hand, part of the reason this is acceptable in r300 is > > that we do SSA and DCE during shader compile, so a double inversion > > doesn't hurt us as much. :3 > > nv30/nv40 mostly do 1:1 mapping to the hardware, and it would be great > to keep it that way as much as possible. > > What if we add the ability to set shader fragment coord conventions to TGSI? > Then things should be easy: > 1. GL_ARB_fragment_coord_conventions is easily implemented > 2. The state tracker no longer needs to invert > 3. r300 can easily implement this by y-flipping the WPOS you generate > 4. nv50 also can just y-flip > 5. nv30/nv40 need to have support added for inverting in case DirectX > conventions are selected > 6. No idea about intel and vmware
I think I'd prefer to avoid pushing new requirements into drivers - intel, vmware-svga, etc, to implement something which is handled pretty easily in the state tracker. For nv, could this be exposed as a hardware capability which the state-tracker could take advantage of, and if not present fall back to the current shader modification in the state-tracker? > BTW, there is also ARB_fragment_coord_pixel_center_integer, which is > also related to the "gl rasterization rules" in the rasterizer, and > that we may be doing incorrectly in several drivers, as it's probably > hard to notice and very easy to overlook. Indeed, you won't really notice this until you start looking at conformance or particularly demanding applications. > Concatenating shaders with different conventions becomes a problem if > you don't know the window height, though. > However, we are not concatenating at the TGSI level right now, and > there may be no use case for it. Keith ------------------------------------------------------------------------------ Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
