On Tue, Feb 02, 2010 at 07:09:12PM +0100, Luca Barbieri wrote: > 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.
"Slower shader switching" is what caches are for. And if you have n VS and m FS, and a large subset of the n*m combinations (that's where your quadratic comes from, right?) are actually used, then it's rather obvious that inter-shader constant propagation and dead code removal is going to be a must. Incidentally, you can multiply by the number of geometry shaders while you're at it. As for link-by-name, it's pretty obvious it's going to become to norm and not the exception. Numbers are opaque, names aren't, and shaders are a bitch to write and debug. In addition "color" and "texture coords" is way too specific and is pretty sure to morph into "int" and "float", or even float only, given HDR, and how easier it is hardware wise and shader compiler wise to just have large-n parallel float interpolation units. That with link-time shared types. So you'd better ensure your approach is ready for a more dynamic world where you can't decide a lot of things until link time. OG. ------------------------------------------------------------------------------ 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
