Thread (101 messages) 101 messages, 14 authors, 2005-03-17

Re: radeon, apertures & memory mapping

flat view

From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: 2005-03-13 21:49:13

On Sun, 2005-03-13 at 11:19 -0500, Jon Smirl wrote:
On Sun, 13 Mar 2005 23:04:59 +1100, Benjamin Herrenschmidt
[off-list ref] wrote:
quoted
quoted
AGP as it's currently used is pretty much pointless for software fallbacks
since reading from AGP memory is nearly as slow as reading from video
memory.
Hrm.. I wouldn't expect _that_ slow. It's uncacheable, right, but still
on a faster bus. Especially if we use it the way we do on ppc where we
actually map the RAM pages directly instead of having processes go
through the GART.
I asked at the Xdev conference if there were page table tricks that
would work for accessing GART memory.  Everybody said no but I'm still
wondering if there are any.

For example the ppc has an instruction for flushing specific pages
from cache, unlike the x86 where you can only flush everything.

So on the ppc you could leave the GART memory mapped normally and
cached. Do all of your fallback calculations, then flush the address
range from cache. Now tell the GPU to go use it.

Can't GART memory be normally cached RAM as long as we flush the cache
before telling the GPU to use it?
For CPU -> GPU transfers, yes, but I'm not sure it would be that
efficient to do so. We have instructions to flush a cache line. A whole
page would require a bunch of them, not sure i would be that efficient
but worth benching maybe.
If you are doing fallback calculations in a 6MB buffer that is 1,500
pages. Accessing all of this effectively flushes the data cache. Once
you are done with it you probably don't want those pages in the cache
anyway.
I wouldn't count on it flushing anything

Ben.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help