On Wed, 2008-05-14 at 12:09 +0200, Thomas Hellström wrote: > 1) The inability to map device memory. The design arguments and proposed > solution for VRAM are not really valid. Think of this, probably not too > uncommon, scenario of a single pixel fallback composite to a scanout > buffer in vram. Or a texture or video frame upload:
Nothing prevents you from mapping device memory; it's just that on a UMA device, there's no difference, and some significant advantages to using the direct mapping. I wrote the API I needed for my device; I think it's simple enough that other devices can add the APIs they need. But, what we've learned in the last few months is that mapping *any* pages into user space is a last-resort mechanism. Mapping pages WC or UC requires inter-processor interrupts, and using normal WB pages means invoking clflush on regions written from user space. The glxgears "benchmark" demonstrates this with some clarity -- using pwrite to send batch buffers is nearly three times faster (888 fps using pwrite vs 300 fps using mmap) than mapping pages to user space and then clflush'ing them in the kernel. > A) Page in all GEM pages, because they've been paged out. > B) Copy the complete scanout buffer to GEM because it's dirty. Untile. > C) Write the pixel. > D) Copy the complete buffer back while tiling. First off, I don't care about fallbacks; any driver using fallbacks is broken. Second, if you had to care about fallbacks on non-UMA hardware, you'd compute the pages necessary for the fallback and only map/copy those anyway. > 2) Reserving pages when allocating VRAM buffers is also a very bad > solution particularly on systems with a lot of VRAM and little system > RAM. (Multiple card machines?). GEM basically needs to reserve > swap-space when buffers are created, and put a limit on the pinned > physical pages. We basically should not be able to fail memory > allocation during execbuf, because we cannot recover from that. As far as I know, any device using VRAM will not save it across suspend/resume. From my perspective, this means you don't get a choice about allocating backing store for that data Because GEM has backing store, we can limit pinned memory to only those pages needed for the current operation, waiting to pin pages until the device is ready to execute the operation. As I said in my earlier email, that part of the kernel driver is not written yet. I was hoping to get that finished before launching into this discussion as it is always better to argue with running code. > This means that the dependency on SHMEMFS propably needs to be dropped > and replaced with some sort of DRMFS that allows overloading of mmap and > a correct swap handling, address the caching issue and also avoids the > driver do_mmap(). Because GEM doesn't expose the use of shmfs to the user, there's no requirement that all objects use this abstraction. You could even have multiple object creation functions if that made sense in your driver. -- [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
-- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
