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.