> At least for SM3.0, one can specify a vertex shader output semantic like > COLOR15 and have it running as long as one has also a pixel shader with a > matching input semantic. Though I agree with you we don't really want to go > this route and have something more sensible.
Do you know of any official Microsoft documentation that clearly indicates that COLOR (and other) semantic indices are not limited? The documentation I found seems to support to opposite statement, as the following line: << n is an optional integer between 0 and the number of resources supported. For example, POSITION0, TEXCOOR1, etc. >> in "Semantics (DirectX HLSL)" on MSDN seems to indicate that if only 2 COLORs are supported, they are denoted by COLOR0 and COLOR1, and that COLOR15 being valid would implying support for simultaneously using at least 16 COLOR semantics. As I understand it, the difference between SM2 and SM3 is that SM2 programs essentially directly use the semantics in instructions, because they have c## registers for colors, t## registers for texcoords, etc. SM3 programs instead use generic i## or o## input/output registers, which are associated to semantics with a declaration. Note that this difference is orthogonal to the issue of whether semantic indices are limited or not. > As for the routing table thing, I am not really convinced. The GLSL > mechanism to link shaders based on varying names is GL-specific and thus > should stay inside Mesa state tracker Surely. However, if we want to support compiling the shaders separately, variable "foo" may have been assigned output #2 in the vertex shader, but input #1 in the fragment shader. Thus, we need a way for Mesa to tell Gallium to map output #2 to input #1. Of course, deciding to map #2 to #1 by consulting the GLSL shader compiler symbol tables should be the state tracker's job. Otherwise, we will need to recompile either of the shaders at link time, so that "foo" is assigned the same slot in both shaders, which is what we do now in GLSL linking, but is somewhat inefficient and in particular can lead to compilation time growing quadratically in the number of shaders, and slower shader switching. ------------------------------------------------------------------------------ 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
