The drm-ttm-0-2-branch about to be merged.

[<th...@tu...>]

Hi, All.

I am about to merge the drm-ttm-0-2 branch into git master.
It's a fair amount of code and to summarize added features:

1) Support for generic user-space objects / refcounting and removal on 
client exit. If you have a kernel object and want to make it visible to 
one or more user-space processes using a 32-bit hashed handle, this is 
very useful.

2) ttms, Translation table maps. These are like shared-memory maps with 
on-demand-allocated physical pages that can be flipped in and out of a 
GART/GATT/GTT, with all caching and mapping operations taken care of. 
User space transparently accesses the memory through a single virtual 
mapping regardless of where the memory is currently located. Full AGP 
flipping is unfortunately somewhat slow due to TLB flushing operations, 
but this might be improved in the future.

The ttm functionality requires a modified AGP driver. It can be found at

git://anongit.freedesktop.org/git/mesa/linux-agp-compat

3) Fence objects. A somewhat generic fence object implementation built 
on top of the user-space object implementation with a driver for intel 
hardware. Fence objects are used for GPU command stream synchronization 
and to signal GPU command completion.

4) Buffer objects built on top of the object / TTM / memory manager 
implementation with a driver for intel hardware. There have been 
attempts to move more of the functionality to user space (the 
drm-ttm-0-1-branch) but in the end the overhead of an IOCTL here and 
there was not really noticeable, so these efforts were discointinued. 
The current speed bottleneck is that allocating an AGP buffer requires 
flipping of a number of pages into the AGP aperture and a TLB flush, 
which is slow.  Thus the buffer object manager should typically be used 
to allocate memory chunks that in turn can be managed in user space 
using a simple memory manager that can always assume the memory is 
present and it's content never lost. Currently only AGP functionality is 
implemented. VRAM is not functional yet.

Caveats:
a) libdrm now requires support for 64-bit file offsets, since mapping of 
buffer objects uses 64-bit file-handles, even on 32-bit hardware.

b) Some changes have been made to the drm locking mechanism that greatly 
improves scheduling of multiple DRI clients, that could previously be 
starved. The DRM will also complain about locking / unlocking errors 
that were masked by the previous implementation. In particular when a 
client unlocks another client's lock.
This comes with a small overhead: Clients that obtained the lock using a 
kernel call will always return to the kernel to unlock.

Otherwise the DRM should be fully backwards compatible.
If anybody sees a problem with the merge, please let me know ASAP.

/Thomas