On Fri, Jan 29, 2010 at 11:09 PM, Corbin Simpson <mostawesomed...@gmail.com> wrote: > 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.
The problem with implicit handling is that you can't match by name. You can have the driver automatically bind vs output 34134 to fs input 34134, but that isn't really helpful if you want to bind vs output variable "foo" to fs input variable "foo". And this is what GLSL and HLSL really want. Of course one could replace the semantic index integer with a string, but at this point hardware clearly won't accelerate that, so it seems better to have the state tracker send an explicit list of (vs output, fs input) pairs. It could be a CSO that the state tracker keeps indexed by (vs, fs) pair. However note that, unless I'm mistaken, no state tracker _needs_ to expose this functionality right now. We could however expose it as an additional GLSL extension based on GL_EXT_separate_shader_objects, that would allow to link by user-defined varying values too We could also use it to make GLSL linking a no-op on hardware supporting routing tables. In other words, it seems to me that this approach could both fix nv30/nv40, simplify drivers and provide additional, useful, functionality. [As already mentioned, we have geometry shaders too so probably it's actually going to be (vs, gs) and (gs, fs)] ------------------------------------------------------------------------------ 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
