Dirk Reiners wrote: > > Hi All, > > trying to think about what to do for OpenSG2 I've been thinking about Allen's > idea of requiring a certain OpenGL version (like 2.0) to avoid having to deal > with the extension cruft. Talking to Johannes at VR brought up the idea of > going > beyond that by going full-out shader, in anticipation of OpenGL 3. > > I don't want to require OpenGL 3(especially since it's very unclear when > drivers > will be available), but conceptually going full-blown shader by removing > support > for the fixed function pipeline has some appeal. It would add complexity by > having to have the shader composition framework up and running (Gerrit, can > you > give us an update on how that is coming along?), but it would simplify > probably > pretty much everything else. My goal would be to support an equivalent of > pretty > much the full fixed function pipeline, i.e. have most of the existing apps > still > working (for obvious reasons ;), but do it completely shader-based. > > In that step I would also remove immediate mode from the codebase. > Multi-indexing will be supported, but by creating temporary VBOs. > > It's a pretty radical step, though, and might delay moving forward on 2 even > more than it is delayed right now, so I need some opinions on this one.
How much will it really delay the release? It seems to me that this change would add features that we already need to add anyway and would reduce the legacy cruft supported. Now, that said, the real reason I suggested requiring OpenGL 2.0 was to remove all the extension detection and loading. Will this help us at all with this part? Could we use a 3rd party project to help out with this so OpenSG doesn't have to manage extensions itself? > I would be very interested in getting on what we would lose by going shader > only. Does anybody know platforms that have no shader support right now? What > about ES? Other comments? > > Dirk > Dirk Reiners wrote: > HI All, > > Thomas Beer wrote: >> I don't think that will be that much of a problem with upcoming hardware >> generations. >> >> I can imagine that upcoming cards/drivers won't have hardware fixed-function >> pipelines any longer but emulating those in the driver anyway (via shaders). >> >> It's only an assumption but for me this would be the straight-forward way of >> graphics-hardware-evolution ;) > > that was my understanding, too. AFAIK the ATI boards haven't had any silicon > dedicated to fixed function in a few generations, they generate a shader on > the > fly. I assume nVidia does the same thing by now. > > Dirk That was my understanding as well. Also when you take into account that a fully shaderized framework could limit the amount of fixed functionality emulated to only the parts needed by the current scene, I could see performance actually increasing. To answer Antonio's concern though: Does anyone have some code sitting around or some time to create some code that we could use to compare performance? If we could just benchmark a couple of standard cases on a variety of hardware then maybe we could get to a better understanding of the current state of things. -Allen ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Opensg-core mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-core
