From: Keith W. <ke...@tu...> - 2005-05-09 18:09:56
|
Aapo Tahkola wrote: > On Tue, 03 May 2005 14:59:53 +0100 > Keith Whitwell <ke...@tu...> wrote: > > >>Aapo Tahkola wrote: >> >>>On Thu, 21 Apr 2005 09:57:48 -0400 (EDT) >>>Vladimir Dergachev <vo...@mi...> wrote: >>> >>> >>> >>>>On Thu, 21 Apr 2005, Aapo Tahkola wrote: >>>> >>>> >>>> >>>>>On Wed, 23 Feb 2005 15:03:38 -0500 (EST) >>>>>Vladimir Dergachev <vo...@mi...> 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 |