-the AGP bandwidth problems are not an XFree86 bug, but are a GATOS bug, right? Because I only have problems with display speed when using the GATOS drivers. -I've got a Pentium III, so it is not just an Athlon/Duron problem.
No, GATOS code does not mess with AGP or mtrr. There was some issue with mtrr settings - whereby the framebuffer region was not properly marked, this manifested (due to different causes) with both Athlons and Pentiums. I don't remember the details..
However, I would have expected that this has been fixed in new kernels.
best
Vladimir Dergachev
There was an issue with Athlon/Duron AGP bandwidth issues that arose in Xfree 4.3.0, and was unaffected by GATOS drivers. A later kernel update made it a bit better, but I do still get better xv throughput on my PCI Rage128 card, than my AGP(4x) Radeon8500 card. The AGP bandwidth issue affects only Athlon systems using older <=266 MHz chipsetsmade by Via, and does not affect DRI bandwidth.
It sounds as if your problem is something different.
If remember right the problem was that AGP space and framebuffer space could both be referenced by CPU in more than one way. It had something to do with O_SYNC flag being added when opening /dev/mem which effectively turned off mtrr settings. The problem was first noticed on Athlons, but then a similar effect was noticed with Pentiums.
XFree86 4.2.0 does not exhibit this problem because (AFAIK.. ) it did not use O_SYNC flag when opening /dev/mem.
My understanding is that with O_SYNC flag we describe two kinds of behaviour: when data is written right away and when the write can be delayed by the kernel.
However, with mttr the meaning of "written right away" splits in two parts "written right away, even a single byte" (used for access to registers) and "written right away, grouped into blocks for fast transfer" (used for access to framebuffer memory). Note that grouping into blocks is done by the hardware, not the kernel.
So, when XFree86 4.3.0 uses O_SYNC flag to open /dev/mem l-k sets mtrr to "written right away, even a single byte" and direct writes to framebuffer (as needed for transfer of Xv images) become a lot slower.
Now that I have written all this it occurred to me that I too seen some slowdown after installing GATOS drivers. It might be that whatever workaround is employed breaks when GATOS reprograms the memory controller on Radeons. Now how this could happen I have no idea, as Radeon memory controller is completely separate from mtrr.
Could someone correct me please ? (CC'd to [EMAIL PROTECTED])
best
Vladimir Dergachev
I noticed the slowdown most profoundly on this 3D game called Chromium. It acts like I'm not getting acceleration. DVD playback was also a bit finicky. I'm using an ATI All-In-Wonder Radeon. Then again, I'm also using the Red Hat kernel. Although this kernel variant generally performs better because of low latency patches and 2.6 DRM, may not be 100% GATOS friendly. I'll try the latest standard 2.4 kernel and report.
Peace, William
_______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
