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
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
