Falling back to CPU rendering, while respecting the OpenGL spec, is likely going to be unusably slow in most cases and thus not really better for real usage than just not rendering.
I think the only way to have an usable fallback mechanism is to do fallbacks with the GPU, by automatically introducing multiple rendering passes. For instance, if you were to run each fragment shader instruction in a separate pass (using floating point targets), then you would never have more than two texture operands. If the render targets are too large, you can also just split them in multiple portions, and you can limit texture size so that 2 textures plus a render target portion always fit in memory. Alternatively, you can split textures too, try to statically deduce the referenced portion and KIL if you guessed wrong, combined with occlusion queries to check if you KILled. Control flow complicates things, but you can probably just put the execution mask in a stencil buffer or secondary render target/texture, and use occlusion queries to find out if it is empty. Of course, this requires to write and test a very significant amount of complex code (probably including a TGSI->LLVM->TGSI infrastructure, since you likely need nontrivial compiler techniques to do this optimally). However, we may need part of this anyway to support multi-GPU configurations, and it also allows to emulate advanced shader capabilities on less capable hardware (e.g. shaders with more instructions or temporaries than the hardware limitations, or SM3+/GLSL shaders on SM2 hardware), with some hope of getting usable performance. ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
