Re: [Dri-devel] Updated texmem-0-0-2 design document (24-Feb-03)

[Alan C. <al...@lx...>]

On Mon, 2003-02-24 at 19:24, Ian Romanick wrote:
>     uint_fast32_t    actual_flags; /** Memory property flags of the memory
>                                     * holding the buffer.
> 				    */
>     uintptr_t        offset;   /** Offset of the buffer within the memory
>                                 * heap.

Means careful checking is needed so someone doesnt load bogon values
into an offset or object id and have fun.

> 3.3 How does a process map from a memory address to a block ID? (open)

Surely its now file_handle->block not pid ?

> 3.4 How are block IDs reclaimed if a process crashes? (open)
> 

if its file handle by handle close

> 3.15 How are pinned blocks reclaimed when a process dies? (open)
> 
> Each process can have numerous block pinned.  These can either be
> framebuffer type objects or other objects that are temporarily pinned so
> that a fence can be set.  The whole point of pinning an object is to prevent
> it from being reclaimed.  However, if the process dies without releasing the
> blocks, the system must reclaim them.

The kernel has to track these anyway, and deal with making sure claiming
the wrong blocks isnt fatal (consider one process corrupting anothers
data in the shared space)

With regards to the bitmaps. You can speed stuff up a lot by doing


	if(test_bit(foo, uppervector))
	{
		for(i=0;i<32;i++)
		{
			if(!test_bit(i, realvector[foo]))
			{
				set_bit(i, realvector[foo]);
				if(realvector[foo]=0xFFFFFFFF)
					set_bit(foo, uppervector):
			}
		}
	}

and cut the search down. There are other structures that work safely too