> 2. Compile assembly shaders to GLSL IR (possibly via Mesa IR -> GLSL IR > translation). This will allow support of other NV assembly extensions > for free on more advanced GLSL hardware. This will give better support > for applications that use Cg. The GLSL backend for Cg generates some > ugly, ugly code.
How about doing the work to support Cg directly instead of that of supporting the assembly extensions? (which may actually be easier) nVidia for instance has a compiler that supports both Cg and GLSL. As far as I know, only nVidia's own demos require the assembly extensions, and everything else just use ARB_vp/fp or GLSL since that's the only way to run on non-nVidia hardware. Also, while NV_fragment_program_option/2 and NV_vertex_program1-3 match nVidia GeForce FX/6/7 hardware closely, NV_gpu_program4/5 don't even have that advantage, since the later nVidia hardware is scalar and not at all like those extensions. That said, the idea of using a complex language like GLSL as the API interface is one of the usual bad design decisions of OpenGL (since, for instance, it essentially guarantees incompatibilities, and forces everyone implementing it do a lot of unnecessary work), and it would be much better if OpenGL just specified a binary bytecode format (like, say, Direct3D 11), but unfortunately this is what the current situation is. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
