Jon Smirl wrote:
On Fri, 01 Oct 2004 18:54:50 +0100, Keith Whitwell
<[EMAIL PROTECTED]> wrote:

Jon Smirl wrote:

On Fri, 01 Oct 2004 18:05:29 +0100, Keith Whitwell
<[EMAIL PROTECTED]> wrote:


Second the DRM code always treats the framebuffer as if it is in
IOMEM. But what about IGP type devices where the framebuffer is in
main memory? These only exist on the x86 so treating their framebuffer
as IOMEM works since there is no difference between IOMEM and normal
memory access on an x86.

The framebuffer lives in agp memory on those devices, presumably this is iomem as it appears to be memory of the agp device.


On normal AGP/PCI cards the memory is on the card. It is accessed over
the AGP/PCI bus which requires special IO instructions on non-x86
hardware. IGP cards use the normal system memory for their buffers.
You don't use the special IO instructions to access this memory. The
key is where the memory lives, on the graphics card or on the
motherboard.

On x86 both types of memory use the same access instructions since the
x86 makes AGP/PCI memory look like normal system memory. So we don't
have a problem.

I understand this. I'm pointing out that agp memory, ie. system memory mapped into the GART table, though it is backed by system memory, is typically accessed through an io range of the gart device. So what sort of memory is that?


GART memory is system memory. The GART is used by the graphics chip to
access the main system memory. Accesses from the main CPU never travel
through the GART. Only memory access cycles initiated by the GPU use
the GART.

Maybe there's a problem with terminology, but when we write to agp memory in the drivers, we are definitely using the GART.


Keith


------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to