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.
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.
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?
--
Smile! http://antwrp.gsfc.nasa.gov/apod/ap990315.html
-------------------------------------------------------
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
