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