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 2. Programs generated are incomplete in sense that they dont move input color to output(also applies to texture coords) 3. Number of temps exceeds 32 in some cases. Attached patch temporarily fixes first two issues. Problems on r300 side(that im aware of): 1. Multitexturing is broken on r300 side as texcoords regs arent properly asigned in r300_setup_rs_unit 2. Problems with colors applied to textures(see dinoshade). Ill add something that allows to switch between hw and sw tnl on the fly using magic keys later today. -- Aapo Tahkola
r300-fpl-mesa.patch
Description: Binary data
