On Sat, 2008-10-18 at 22:37 +0200, Ingo Molnar wrote: > But i think the direction of the new GEM code is subtly wrong here, > because it tries to manage memory even on 64-bit systems. IMO it should > just map the _whole_ graphics aperture (non-cached) and be done with it. > There's no faster method at managing pages than the CPU doing a TLB fill > from pagetables.
Yeah, we're stuck thinking that we "can't" map the aperture because it's too large, but with a 64-bit kernel, we should be able to keep it mapped permanently. Of course, the io_reserve_pci_resource and io_map_atomic functions could do precisely that, as kmap_atomic does on non-HIGHMEM systems today. > The only real API need i see is on 32-bit: with a 1GB or 2GB graphics > aperture we just cannot map that permanently, so kmap_atomic() is a > necessity. We can certainly extend that to non-highmem as well. Yes, this is where exposing an io-specific atomic mapping function will remain necessary for some time. > And if i understood your > workload correctly you want to do tens of thousand of map/unmap/remap > events per frame generated - depending on the type of the 3D app/engine. Yeah, data transfer from CPU to GPU is through a pwrite interface, and we perform the transfer within the kernel using map/unmap operations on the aperture as those are WC and hence do not require clflush. > Or am i missing something subtle? Why do you want the overhead of kmap > on 64-bit? We don't, but I think it would be nice to have a common API that works across all 32-bit configurations as well as 64-bit systems. -- [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
