I would say that the routing table really needs to be handled by the driver implicitly. When you're told to draw things, you do your shader routing/linking before you draw.
If the routing table really does depend on the shaders and only the shaders, then I wouldn't be opposed to some CSO, but I don't think it's horribly necessary. And no, pre-optimizing TGSI is stupid. Every single backend does something different with its shaders. You can't deliver something besides TGSI to drivers, either; it will suck badly for out-of-tree drivers and compat. Just write a real compiler for your HW. ~ C. On Fri, Jan 29, 2010 at 12:47 PM, Luca Barbieri <l...@luca-barbieri.com> wrote: > On Fri, Jan 29, 2010 at 8:49 PM, Keith Whitwell <kei...@vmware.com> wrote: >> So the nv40 code is doing the wrong thing... :) >> >> The rule currently is that the generic tags are just tags and are used only >> to establish mapping between fragment shader and vertex shader. Additionaly >> the vertex shader should always supply at least the inputs required by the >> fragment shader. Taking a guess, without specific hardware support for >> routing, nv40 should translate the fragment shader inputs into successive >> SRC_TC slots, and build a mapping from semantic-index -> SRC_TC slot that >> can be applied when translating the vertex shader. >> >> You might complain that in this world a vertex shader will require multiple >> translations depending on which fragment shader is bound, as one taking >> fewer inputs will have different numberings. That's true, but you also get >> the opportunity to specialize the vertex shader as a result, eliminating >> dead code in each case - which may be worth the effort. >> >> Anyway, it sounds like what you really want is to change the linkage rules. >> This is possible, of course, but we should discuss it in those terms. > And >> then if we do revisit those rules, we should take a deeper look at linkage >> and figure out if anything else can be changed. > > Yes, this is what I'm proposing. > > Actually, those rules do not seem to be documented, so I was not sure > whether they were a requirement or were just a "bonus" feature of some > drivers. > > Right now it seems to me that no users of Gallium require this functionality. > In particular: > 1. GLSL and anything with similar link-by-name can of course be > modified to use sequential indices > 2. ARB fragment program and vertex program use index-limited texcoord slots > 3. g3dvl needs and uses 8 texcoord slots, indices 0-7 > 4. vega and xorg use indices 0-1 > 5. DX10 seems to restrict semantics to 0-N range, if I'm not mistaken > 6. The GL_EXT_separate_shader_objects extension does not provide > arbitrary index matching for GLSL, but merely lets it use a model > similar to ARB fp/vp > > Thus, unless I am mistaken, no current API needs this feature. > > In addition, note that current rules do *not* allow to bind inputs and > outputs by name, since the semantic index is an integer and not a > screen. > However, the hardware implementation could probably allow that, since > it most likely works by specifying the fragment shader input a given > vertex shader output maps to. > > Thus, I propose to: > 1. Change the rules to require semantic indices to be in a 0-N range. > Document this appropriately. > 2. Fix GLSL to respect that using the patch I posted. Everything else > should be already fine. > 3. If necessary, add a ->set_routing_table function that takes pairs > of vertex shader outputs and fragment shader inputs to associate > > This allows to state tracker to support seamless "link by variable > name string" by packing the indices in sequential numbers, and then > using a dictionary kept in the state tracker to build an appropriate > routing table. > > There are also geometry programs, so both vs->gs and gs->fs routing > tables are probably needed. > > What do you think? > > > As an aside, regarding shader optimization, I would suggest a > driver-independent LLVM-based middle layer that takes TGSI as input > and can provide either optimized LLVM bytecode or optimized TGSI to > the driver (letting the driver choose with appropriate caps). > > ------------------------------------------------------------------------------ > 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 > -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson <mostawesomed...@gmail.com> ------------------------------------------------------------------------------ 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
