Re: r300 fixed pipeline design

[Keith W. <ke...@tu...>]

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.

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