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
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.