An overview of the possible options. Let's call vertex shader outputs "v" and fragment shader inputs "f" Let v -> f mean that v connects to f. NUM_INTERPOLATORS is the number of available interpolators. It is usually between 8 and 32.
1. Current Gallium v -> f if and only if v == f Any values of v and f are legal 2. My proposal, basic version v -> f if and only if v == f v >= NUM_INTERPOLATORS and f >= NUM_INTERPOLATORS are illegal 3. My proposal plus with routing tables (Corbin Simpson's idea) v -> f if and only if (v, f) is an entry in the routing table v >= NUM_INTERPOLATORS and f >= NUM_INTERPOLATORS are illegal If no routing table is set, (2) is used instead The routing table is set via a new ->set_routing_table() entry point, taking the processor linkage affected, and an array of pairs of registers to link. This may be made a CSO (it is constant for each pair of state tracker shaders). The problem with (1) is that if the hardware has no routing support, there is no way to implement it except by recompiling either the vertex or fragment shader when the other changes. Furthermore, no known user of Gallium actually needs (1) except the current GLSL linker, but only due to the particular implementation and not due to the OpenGL/GLSL API itself. Only (2) is actually needed by the APIs, and it is also supported trivially by all hardware. Additionally there is no way to implement "bind by name" (i.e. having GLSL varyings with the same name be linked) with either (1) or (2) without recompiling one shader in response to changing the other. With (3) instead, the state tracker can look at the symbol tables of both programs, build a routing table, and set it independently of the shaders. Functionality provided by (1) can also be emulated in this way. Thus, I propose replacing (1) with (2) and later expand to (3) if we desire to do so. I think that in particular, the "bind by name" argument is decisive, since binding by name is what GLSL and high level languages really want, and the added flexibility of (1) is useless for that, while coming at significant driver complexity and performance cost. What do you think? ------------------------------------------------------------------------------ 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
