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.
I think the issue is that I was creating the structures directly rather than calling ctx->Driver.NewProgram() to do this, as is the case with all other fragment & vertex programs.
I've changed this now and converted the i915 driver to use ctx->_TexEnvProgram (ie the fragment program) if MESA_TEX_PROG=t is set. This seems to work fine.
The issue of creating/destroying the programs should probably be done at a higher level, ie in mesa/main/texenvprogram.c, so that drivers don't all end up with similar different hashing schemes.
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
