On Wed, 23 Feb 2005 15:03:38 -0500 (EST) Vladimir Dergachev <[EMAIL PROTECTED]> wrote:
> With regard to state switching, it might be worth it to simply hash > various configuration (fog on /fog off, etc) and just upload state > difference on such changes. Could work reasonably well. Problem with hashing all programs is that we would most likely have so many different programs that it would be undesirable to keep them in memory. Take for example omiting tex coord transforms, rescaling of normals, normalization of normals.. Sure we could just start dropping them but that might lead to instable framerates if we constantly translate new programs. I cant say I knew any really good way to handle this at the moment so its probably best to try something and see what problems arise. Attached tarball contains test code I extracted from that paper and bunch of modifications. Jerome Glisse(if im not mistaken) rolled up a lot cleaner version of it (see vprogram.c). Spotlights should work as of todays Mesa cvs and software vertex shading as bug #3087 is resolved. Keys 1, 2 and 3 switch between them. > > This would not be too complicated to implement, whatever the mechanism > of shader generation. > > Btw, another interesting link would be: > > http://ati.com/developer/samples/dx9/FixedFuncShader.html Branching could be interesting if older radeons would support such a thing. > What worked for ATI will not necessarily work for us, as getting the last > fps is not as important as having a stable and maintainable driver. Thus > we can (and do need to) experiment. I dont think we need to sacrifice framerates here. There are some one instruction saves like writing directly into result instead of using MOV from temp but those can probably be worked out with small hacks. > best > > Vladimir Dergachev > -- Aapo Tahkola
fpl2.tar.bz2
Description: Binary data
