Re: radeon, apertures & memory mapping
flat view
From: Ville Syrjälä <syrjala@sci.fi>
Date: 2005-03-13 23:27:35
On Sun, Mar 13, 2005 at 06:00:01PM -0500, Jon Smirl wrote:
On Mon, 14 Mar 2005 09:20:01 +1100, Benjamin Herrenschmidt [off-list ref] wrote:quoted
Though the flushes may be fast if there is no actual hit in the cache, I agree. Again, that should be benched. In fact, i would _love_ to be able to mark AGP memory as cacheable on ppc, even if there is no performance benefit in the end. The issue is that currently, we end up having both a cacheable and a non-cacheable mapping for those pages (the kernel linear mapping still maps those pages cacheable, and it's almost impossible to get rid of that unless you are prepared to disable the large pages mapping of kernel space or the BATs on ppc32, which would harm kernel performances significantly). It works, but it's illegal. That means that the CPU might well speculate a load from one of these pages in kernel-land just because it happens to be next to a page where you are iterating an array, and may then bring a bit in the cache from that page.That shouldn't matter the page brought in would be for a speculative read and never accessed. It should just fall out of the cache and not be written back. There is only one cachable mapping. In this model writes are always followed by a flush before telling the GPU to access the memory that has just been written.
What about this scenario? Speculative read -> AGP master writes new data -> CPU has invalid data in cache :( -- Ville Syrjälä syrjala@sci.fi http://www.sci.fi/~syrjala/