Re: [Dri-devel] Patch to enable 3rd TMU on R100

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

Ian Romanick wrote:
> On Fri, Sep 27, 2002 at 07:53:22PM +0100, Keith Whitwell wrote:
> 
> 
>>One option is to have the kernel actually do the fixup of the buffers when 
>>they are submitted by the client, so the driver never knows really where it's 
>>textures are, but talks about them via. some indirection.
>>
> 
> I've been looking into this to assess the difficulty of such an
> implementation.  The back patching would be done in radeon_emit_state /
> radeon_emit_packets, yes?
> 
> In radeon_emit_packets you have some code like:
> 
>     if ( packet is RADEON_PP_TXFILTER_? or R200_PP_TXOFFSET_? )
>     {
>         texture_id = data[ offset_of_texture_id ];
> 	address = address of texture_id;
>         if ( address is not in texturable memory )
> 	{
> 	    address = get space for texture;
> 	    copy_texture( from user memory to address );
> 	}
> 
> 	data[ offset_of_texture_id ] = address of texture_id;
>     }
> 
> Is that basically what you had in mind?  There would be similar code in
> radeon_emit_state.

Yes, effectively.  The only other choice is to have the client emit data about 
where to find values in the command stream that need to be fixed up.

> Ignoring issues of SGIS_generate_mipmaps or glCopyPixels for a moment, a
> system like this would need some sort of fencing.  Basically, reference
> counting for packets that set a texture.  When a texture is bound to a
> texture unit, increment the counter.  When another texture is bound, put a
> command in the stream to trigger an interrupt.  When the interrupt is
> received, decrement the counter.  If the counter is zero, then the texture
> is not in use and can be taken out of memory.

Interrupts are much to expensive to use each time a texture is bound...  It 
will be necessary to think about this at a lower time frequency, or find some 
mechanism other than irq's to acheive it.


> This would also allow proper synchronization of glTexSubImage?D.
> 
> This also raises the question of NV_fence.  If we go down this path, we will
> have already implemented most of the infrastructure for NV_fence.  Should we
> go the final mile and export it?

We should do this anyway.

Keith