On 4/21/05, Aapo Tahkola <[EMAIL PROTECTED]> wrote:
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.
I was working on this too but my new study keep me busy a bit. Anyway i got a improved version of this and i think that the following solution might well fit this problem.
We have to selected program according to this : - if no light of shade model = flat no lighting and so a simple program could do the work for all case (not looked at fog but i think that when we have flat shading fog haven't to be computed in the vertex shader (will look at spec for this)) - if light then we have to have something that hash all possible configuration.
Thus i think we better split the problem to choose this for each enabled light and have invariant program part.
-coordinate transformation and onfly texture coordinate transformation (should't consume too much time i think) -normalize or rescale of normal (one state to parse) -then for each enabled light we select the approriate routine add it -we have an invariant program part at the end (which basicly compute the final color from all light computation previously done).
Moreover to have less state to parse we should choose to always separate specular & diffuse (Any reason to not do so ?)
Anyway here to make a decision, testing is definitly
needed.
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.
I have a new version of this vprogram which is even simpler at least i think. I will post it tomorrow. And if i get enought time i will try come up with an implementation in r300 to test my proposal.
Btw can we share things accross different context ? Basicly with my proposal we would end up to have only 2-4 differente routine corresponding to each possible case for a light. And some common code at start & end, better to share but doesn't consume so much memory less than 1ko i think...
I have been thinking to some similar think for the pixel shader, but vertex first...
Seems like everyone's working on the same thing. I've just committed a file which implements most of this internally in Mesa. I've got a few other commits to make before it can be turned on, but it should be pretty much the facility you're looking for.
Keith
------------------------------------------------------- This SF.Net email is sponsored by: New Crystal Reports XI. Version 11 adds new functionality designed to reduce time involved in creating, integrating, and deploying reporting solutions. Free runtime info, new features, or free trial, at: http://www.businessobjects.com/devxi/728 -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
