AGP GART clarifications, please!
Dave Airlie
airlied at gmail.com
Thu Jun 19 17:06:20 PDT 2014
On 20 June 2014 03:17, Émeric MASCHINO <emeric.maschino at gmail.com> wrote:
> DRI gurus,
>
> If I'm not mistaken, the current Linux graphics stack is as follows
> (excluding Wayland protocol and LLVM or GLAMOR-based approaches):
>
> X11/OpenGL app -> libX/Mesa -> DDX driver/Mesa DRI module -> kernel
> DRM -> hardware
>
> What's unclear to me is, in the case of an AGP graphics adapter, where
> does the AGP GART takes place in this stack (if applicable)?
>
AGP support is just by the kernel drivers now with KMS.
AGP is just a GART that sits on the chipset side of the AGP port, along
with faster lanes speed than plain PCI and wierd enhancement like fastwrite.
With early PCI GPUs they couldn't access data in main memory like
textures you had to DMA stuff to the GPU. Some GPUs got PCI GARTs
which were very simple lookup tables from GPU linear to host page address,
however these suffered from lots of bandwidth issues when updating them,
so AGP put a GART on the chipset side to do the same. PCIE uses GARTs
back on the GPU side.
So to run in AGP mode you need a chipset specific driver to manage the
chipsets AGP GART and other features, that the GPU drivers can talk
to.
> Obviously, this AGP graphics adapter nevertheless works flawlessly
> without AGP GART compiled in kernel or as module. This is at least
> true for the open source stack, I've tested it. Is my AGP graphics
> adapter thus running in what's known as PCI/PCIe mode? I've read all
> the AGP scatter/gather, texturing and fast writes things, but I can't
> see any difference performance-wise between having AGP GART compiled
> in kernel or as a module and no AGP GART. Is it because my usage
> doesn't stress the graphics subsystem enough or is it because PCI/PCIe
> mode is so amazing that AGP GART doesn't provide any performance
> enhancements? AGP GART however provides me nice stability issues ;-)
I'm not sure how best to measure a speed difference, it should be noticable with
games and stuff, maybe not with plain desktop usage, anything that up
or downloads
lots of stuff or uses main RAM for textures.
Dave.
More information about the dri-devel
mailing list