Date: Sat, 15 Feb 2003 15:27:06 -0800 From: Marcel Moolenaar <marcel@xcllnt.net> To: Peter Wemm <peter@wemm.org> Cc: Eric Anholt <eta@lclark.edu>, src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/modules Makefile Message-ID: <20030215232706.GA621@athlon.pn.xcllnt.net> In-Reply-To: <20030215192142.E79BE2A89E@canning.wemm.org> References: <20030214061708.GA2109@athlon.pn.xcllnt.net> <20030215192142.E79BE2A89E@canning.wemm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Feb 15, 2003 at 11:21:42AM -0800, Peter Wemm wrote: > Marcel Moolenaar wrote: > > On Thu, Feb 13, 2003 at 09:32:33PM -0800, Eric Anholt wrote: > > > > > > > > In that case, we'd better make sure there's cache coherency. Do we > > > > actually have the code structured in a way that allows having the > > > > flushing chipset dependent (not to mention dependent on the address)? > > > > > > No, currently all the cache flushes (four in agp.c, three in i810 and > > > amd code) are unconditional agp_flush_cache calls after modifying the > > > gatt entries. They aren't tied to a specific memory range, but could be > > > pretty easily, if not the most efficiently, by pushing some of them into > > > the (un)bind_pages. There's probably a better way. > > > > I wonder: do we actually need to flush at all? GART updates are PCI/AGP > > writes and should be coherent, right? > > Consider the remap table. It is external to the cpu, on the far side of > the writeback cache. Changing remap entries with pending writes would > be interesting. AGP isn't necessarily coherent either. Isn't this a synchronisation issue more than a coherency issue? See also below. > > Also, on ia64 bus I/O is done with a virtual address that has the > > non-cacheable property. Flushing would not be required irrespective. > > What about user mmaped IO? eg: when the Xserver has got stuff remapped > down into user memory? And what if the remap table is changed underneath > that? On i386, the MTRR stuff is used to control cache behavior so that > the userland portions can be in writeback mode. I dont recall what happens > on ia64. We don't have any FreeBSD experience with that on ia64, because we don't have AGP nor X :-) I was about to try the upcoming 4.3.0 and I should be able to hack up AGP support for the BigSur so we could try if we really want to. My first guess is that you use the acceptance form of the memory fence instruction (ie mf.a). The CPU will wait until prior memory reads have returned data and prior memory writes are accepted by the platform, before it will initiate a new transaction on the bus. You may want to add another memory fence for ordering... > I really dont understand this stuff well enough. I built the following (possibly wrong, likely incomplete) picture: o Memory accesses between the AGP device and memory are generally not visible on the system bus (FSB). Hence coherency is not guaranteed. o The GART (remapping table) is accessed in a chipset dependent way and/or stored in a chipset dependent way. The GART is controlled by the "core logic" (=chipset) and thus coherent with system memory, but not coherent with the AGP device. Since the remapping is performed by the chipset, coherency should be guaranteed (???) o AGP is relatively platform specific due to performance requirements and may behave differently between different chipsets. To me this means that updating the GART in principle only requires special interaction on the AGP bus itself. No cache flushes are needed. Coherency between main memory and the AGP device is something that's between the AGP device and the driver. The only thing the driver has to worry about is to make sure memory accesses made by the processor are visible by the AGP device by making sure the access actually hits memory, before kicking the AGP device. This is platform and chipset dependent and may sometimes requires a cache flush. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-src" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030215232706.GA621>