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...
Jerome Glisse
-------------------------------------------------------
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
