On Fri, Aug 1, 2008 at 6:17 AM, Keith Packard <[EMAIL PROTECTED]> wrote: > Ok, we clearly need to deal with mapping subsets of the graphics > aperture, both for discrete graphics cards and for 2D on tiled surfaces. > Plus, there are reasons for using WC object mappings which is easily > done through the aperture. > > I haven't spend a huge amount of time thinking about this, but I figured > I'd prod people into discussion to try and sort things out. > > First off, here's what I think I want. > > We expose mmap ioctls on the gem objects, and I'd like to use the same > basic mechanism; when (if?) gem objects become "real" files, we would > want to continue using the same interface. I suggest creating two mmap > windows for main memory objects: > > 0x00000000-0x7fffffff: map the backing pages directly > 0x80000000-0xffffffff: map the object through the aperture > > I don't quite know what to do with discrete card memory; suggestions > here are welcome from people who've thought about this more than I. > > Using these two per-object windows means there isn't any need to manage > a synthetic linear address space for some global object (like the DRM > fd). > > Next, we need to hook the mmap path in the driver so that our code can > get a chance to play. I attached something that might work. > > Once we've got an mmap request, here's what I think we want to do: > > 1. Detect an aperture mapping request (bit 31) > 2. Map the object to the aperture (speculating that the app will > actually use it) > 3. Initialize the vma to point at the aperture physical address > range > > If the object remains mapped to the GTT, there's nothing else to do > until the unmap request comes along at which point we tear down the vma. > > If the object gets unmapped from the GTT, we need to go find every VMA > mapping it and fix up their PTEs to be unreadable/writable. I'm hoping > this won't kill performance, but I'm fairly sure this will require an > IPI to get the TLBs flushed on every core. Right? At least there won't > be a cache flush as well. > > Now, if the application touches any one of those pages, we should map > the whole object back to the GTT and rewrite the PTEs again. We could do > this a page at a time, but I don't see any real benefit as we have to > allocate the aperture space anyways, and it shouldn't be that much more > expensive to fix up a lot of PTEs than to fix up just one. > > I think that's the whole story here; am I missing any big pieces?
The basic fault here is that you have added a driver specific flag to a generic ioctl/syscall. Which the last time I checked we didn't want. For example on PCIE Radeon there is no GTT to map, so bit 31 makes no sense there. Cheers Jakob. ------------------------------------------------------------------------- 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
