On Dec 15, 2007 5:47 PM, <[EMAIL PROTECTED]> wrote: > > > --- [EMAIL PROTECTED] wrote: > > I don't speak on generic terme, i speak about real world example of > > current complexe vector shader and pixel shader. > > > I speak of the actual code which we intend to use; it contains a lot of > vector and matrix operations. > --- > We aren't trying to make a programmable shader with these SIMD units, are > we? I think we can easily use the SIMD units in a pseudo-fixed pipeline. > > Look at some previous posts on the subject: > http://article.gmane.org/gmane.comp.graphics.opengraphics/2445 > http://article.gmane.org/gmane.comp.graphics.opengraphics/2553 > http://article.gmane.org/gmane.comp.graphics.opengraphics/2461 > These are two shader examples and an analysis of various functions used.
People might hate me to feed an IMHO fruitless discussion but previous threads(including those cited above) don't exactly show how "real world shaders" translate into scalar operations: 1-You have shader examples written in high-level(ogsl) language 2-You have some compiled into a specific(arbvp1 or arbfp1) architecture assembly [1] 3-You have a dataflow profiling of DirectX shaders, I assume already compiled into the architecture assembly. The way I see it, the device driver get those arbvp assembly code and translate them into your own architecture code. So can arbvp be efficiently translated into a systolic/SIMD/multi-core architecture?(stalls, dependency, etc)[*] After that, can said architecture be implemented efficiently in FPGA? (complexity,space,etc) There are two efficiency issues here: adequation of shader code into an architecture and complexity of said architecture. People are jumping from one issue to another leaving questions unanswered. This whole discussion doesn't change a couple of facts: 1-As Timothy pointed out, there is already a tested model for OGA1. It might be interesting that future versions are improvements on that. (ie. OGA2 adds more reconfigurability to the fixed pipeline, instead of a whole new architecture) 2-OGD1 isn't released yet, so people can't hack with it to figure out its limits in any of the propositions. 3-Any of the models will have to be able to handle compiz and high-resolution efficiently. Might be a limiting factor for programmable shaders(at least in FPGA). [1]http://lists.duskglow.com/open-graphics/2006-April/005480.html [*] IIRC you don't always have access to the ogsl source, in which case you could compile it more efficiently. > > Just looking at that list, it is almost all dot products. Taking a previous > quote from Nicolas: > > All of this show me that GPU are almost like normal CPU that manage more > > complexe DATA (vect4 rather than int). > > Looking at those posts, I think that vector operations are used in a GPU > (if we ignore the whole shader issue). Why not use the very efficient SIMD > units that have already been designed by Sun? This does _not_ mean using the > whole FPU, CPU, or even any more of the design -- I just want the SIMD unit > architecture. > > I perused the ogsim code and it appears to be filled with vector operations -- > there is no getting around that. I honestly don't care if there aren't even > vector instructions for programmable shaders -- if we can exploit vector ops > to make our pipeline faster, I think we should do it. > > _______________________________________________ > Open-graphics mailing list > [email protected] > http://lists.duskglow.com/mailman/listinfo/open-graphics > List service provided by Duskglow Consulting, LLC (www.duskglow.com) > _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
