On Tue, Feb 2, 2010 at 7:38 PM, Olivier Galibert <galib...@pobox.com> wrote: > 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. Exactly, and that's why we should be able to support it efficiently. The current Gallium architecture doesn't do that because semantic indices are integers, and there is no way to specify linking without creating different shaders.
Of course we could also decide we don't care about separate shaders, and just have a Gallium CSO for a whole complete vertex+geometry+fragment pipeline. This makes things much simpler, but I'm afraid that some applications could suffer catastrophic performance degradation. A good place to find inspiration for this choice could be the nVidia and ATI proprietary driver. Since app/game developers test with those, if they always recompile for each (fs, vs) pair, then we can safely do so too. On the nVidia front, they on one hand patented inter-shader optimization (patent 7426724, filed in 2004), but on the other hand wrote GL_EXT_separate_shader_objects (written in 2009), which doesn't provide significant benefits if the driver always does inter-shader optimization. Thus it seems they may be using a mix of the two techniques, possibly depending driver version and on the shader API being used. What do you think? Is separate compilation important, and we should thus try to fully support it, or can we just drop it? In the first case, we would want a Gallium interface to support specifying routing separately from shaders. In the second case, we would be better off dropping the separate VS/GS/FS shader CSOs and just having a CSO for the whole shader pipeline. ------------------------------------------------------------------------------ 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
