Aapo Tahkola wrote:
On Tue, 03 May 2005 14:59:53 +0100
Keith Whitwell <[EMAIL PROTECTED]> wrote:
Aapo Tahkola wrote:
On Thu, 21 Apr 2005 09:57:48 -0400 (EDT)
Vladimir Dergachev <[EMAIL PROTECTED]> wrote:
On Thu, 21 Apr 2005, Aapo Tahkola 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.
Well, we know that the register space we are interested in is less than 4K.
A megabyte would hold 256 such configurations - should be plenty, no ?
Maybe for average case but not for worst.
Heres a list of problems that prevent r300 driver from using Keith's ffp program generator:
1. _TnlProgram is of fixed size type and smaller than r300_vertex_program
What's the actual issue here? In what circumstances does this cause a
problem?
Mesa is holding drivers private data bound to programs in containers just like
in i915NewProgram.
I suggest this to be sorted out by adding PrivatePrt to vertex and fragment
program structures in Mesa.
This way drivers can allocate their private structures at translation stage and
more better estimate needed memory.
Also this fits well into the hashing scheme when arb programs generated by
t_vp_build.c could be destroyed once no longer needed.
Sounds reasonable - would you like to submit a patch for this?
2. Programs generated are incomplete in sense that they dont move input color to output(also applies to texture coords)
The programs share the semantics of regular vertex programs - which
don't do this copying either. So, if you need to add this sort of
copying when you encode a regular vertex program for the r300, you'll
need to do the same thing with the generated programs. If not, I don't
understand what's going on.
According to issue 16 of vertex_progra spec, initial values of temps and results are undefined unless written to.
Hmm, I think you're right... I'll fix this up.
3. Number of temps exceeds 32 in some cases.
Can you give some details? I'm sure this can be pared down a little.
Happened with ut2k4. Ill look into this at better time.
Sounds like it's probably a leak somewhere.
Keith
-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
