> > Yes, with a 1-1 mapping between GPU objects and file objects. You can > use the normal read/write/mmap API on them. The reason we aren't using > fds now is just that the kernel cannot handle this many fds per process.
Well it can now, we just need to fix the X server :) > > I want to map these pages in two different ways, the first way is > through normal WB mapping which provides the expected memory semantics > (cached reads and writes). The second is to map them through the GTT > which offers two important benefits: > > 1) WC mapping which avoids the need to clflush when passing data from > application to GPU. > > 2) Linearized access to tiled surfaces. This uses the tile swizzling > HW in the GPU to construct a synthetic linear view of the tiled > surface which is currently required when doing SW rendering from > inside the X server. > > > however that means a do_mmap you don't intend on ever changing > > to a real mmap call. Now you need to justify that to the vfs people. > > Nope, I can use a 'normal' mmap call and have two different address > ranges within my object, one which maps the pages directly and one which > maps them through the GTT. No flags needed here. Well bit-31 is now a flag, just under an assumed named with a fake passport. The question is whether this matters at all, or whether Intel driver can just do it that way and have intel specific hooks into the shmem mmap/fault code. For radeon this interface would suck, an object can be VRAM, main RAM, GTT, tiled, endian swapped, etc. but if I don't care about that, if Intel were to use mmap2 then in theory you could use an even higher bit than bit 31. Dave ------------------------------------------------------------------------- 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
