On Sun, 2005-03-13 at 11:19 -0500, Jon Smirl wrote: > On Sun, 13 Mar 2005 23:04:59 +1100, Benjamin Herrenschmidt > <[EMAIL PROTECTED]> wrote: > > > > > 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. ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
