I was thinking about how we will implement our OpenGL pipeline, mostly by looking at other implementations and the OpenGL spec. I don't think we were planning on having programmable shader on the OGA, but then I stumbled across this software, ShaderGen: http://developer.3dlabs.com/downloads/shadergen/index.htm Using something like that (that we port to or write for Linux, or even the embedded cpu), we could simply load a "standard OpenGL pipeline" from ROM, and if a programmed shader is requested then we can load it in place of the "fixed function" pipeline.
This could easily reduce the silicon area needed to implement the pipeline, since it combines many stages into a simple floating point processor. The problems that I see are: 1) Context Switches. How can we load a programmable shader without disrupting pixel output? 2) It could reduce pixel output, since pipelining doesn't really work. It could also increase output because we can have a bunch of parallel vertex/fragment shaders. 3) This is a very nonstandard way to implement the OpenGL pipeline. We would need to design a (very) simple shader if this could happen. We might even be able to run it at a faster clock speed than a FF pipeline if we fiddle with it. Is this a possibility? What blatant implementation problems am I missing? Feel free to ignore this. I just wanted to get it out before I forgot it - I imagine this will be more relevant much later on. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
