> 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.
Yes, this will require all drivers to be changed. However, this is only relatively hard for drivers that support DirectX 10 semantics in hardware but not OpenGL ones. Those doing it in software only need to conditionally adjust the constants, and those with hardware support can just use it. 1. nv30/nv40 need to changed anyway as the hardware has OpenGL semantics 2. r300 is easy to fix, because it already generates wpos on its own and it only needs to alter the constants it sets 3. nv50 apparently also has a similar software scheme 4. softpipe is easy to fix, because it's enough to change the constants 5. cell and llvmpipe also are presumably easy since they are software 5. No idea about i915, i965 and svga. > 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? Yes, this is the easiest fix, but it means that TGSI semantics start to be driver-dependent. For instance, you wouldn't be able to store a TGSI shader using POSITION to disk and have it produce the same results on all drivers. This seems contrary to the principles embodied by the current design. ------------------------------------------------------------------------------ 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
