Peter Zijlstra wrote:
On Tue, 2007-08-21 at 16:05 +1000, Dave Airlie wrote:
So you can see why some sort of uncached+writecombined page cache
would be useful, I could just allocate a bunch of pages at startup as
uncached+writecombined, and allocate pixmaps from them and when I
bind/free the
There is an uncached allocator in IA64 arch code
(linux/arch/ia64/kernel/uncached.c). Maybe having a look at
that will help? Jes wrote it.
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to
Blame intel ;)
Any other ideas and suggestions?
Without knowing exactly what you are doing:
- Copies to uncached memory are very expensive on an x86 processor
(so it might be faster not to write and flush)
- Its not clear from your description how intelligent your transfer
system is.
On Tue, 2007-08-21 at 16:05 +1000, Dave Airlie wrote:
So you can see why some sort of uncached+writecombined page cache
would be useful, I could just allocate a bunch of pages at startup as
uncached+writecombined, and allocate pixmaps from them and when I
bind/free the pixmap I don't need the
allocate pixmap gets cached memory
copy data into the pixmap
pre-use from hardware we flush the cache lines and tlb
use the pixmap in hardware
pre-free we need to set the page back to cached so we flush the tlb
free the memory.
Now the big issue here on SMP is that the cache and/or tlb
Hi all,
I've started doing some work with using the new DRM memory manager
from TG for pixmaps in the X server using Intel 9xx series hardware.
The intel hardware pretty much requires pages to be uncached for the
GPU to access them. It can use cached memory for some operations but
it isn't very
