On Sun, 2008-08-03 at 10:53 +0200, Thomas Hellström wrote: > With the current GEM implementation, the address space is per buffer > object, and if this were done > correctly you'd duplicate the shmemfs filesystem to make a drmfs > filesystem where you have complete control over creation and mmap-ing > and do not need to create special cases to work around the shmemfs > implementation.
I am not working around the shmem implementation at all; I'm using regular shmem objects just as they are. The only thing I'm working around at this point is the artificial kernel limit of 1024 fds. With more fds, I could simply allocate shmem objects and pass them into my environment. Once the objects are allocated, I use regular kernel APIs to map those pages to my device. > I'd strongly > recommend avoiding trying to manipulate ptes from the driver. I don't touch the shmem PTEs at all. The mapping I'm adding is entirely separate from shmem and involves mapping portions of the GTT aperture which just happen to contain pointers to shmem-allocated pages. > The other approach is to use one address space per device. This would require constructing an entirely artificial linear space for my objects. You then have to track this per-device linear address for each object and pass that into the mmap call. And, what does it mean when you ask to mmap a range spanning multiple objects? > 1) Hack ptes from the driver. Nope, not doing this; the GTT-based mapping would allocate separate PTEs using the existing standard device mapping APIs. > 2) Try to overload the shmemfs mmap / fault methods. I don't need to do this either; shmem handles its pages just fine. > 3) Implement a new drmfs filesystem. I would prefer to use the existing shmem mechanisms instead of precisely duplicating them. -- [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
-- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
