[NTLUG:Discuss] AGP Gart de-mystified (long)

[Matthew R. Pavlovich]

>Or is agpgart something I can take advantage of with a normal
>Glide/Mesa installation and my 2.2.16 kernel?

I saw a bunch of notes on AGP support and ppl wondering what the
real-deal is.. (i get msg's digested, so I appologize about starting a
new thread).

BACKGROUND:
AGP does some really cool things(tm).  First off, it has an increased
bus speed, so it improves performance (66Mhz - 1x mode; 133Mhz - 2x
mode, etc) of moving data from main memory to the video card.  The
second really cool thing, is its ability to utilize main memory as video
memory.  Some of you may have seen this on some of the new low end atx
boards that have video chips on board, in the BIOS you specify how much
system memory you wish to set aside as frame buffer memory.  The third
(and most useful IMHO) is the ability for the AGP chipset to represent
fragmented sections of memory as one contiguous space.  This is most
useful when optimizing DMA transfers for moving textures from disk to
memory.  Linux doesn't (yet) have a real clean way to allocate
contiguous amounts of memory for things like handling of 3d textures, or
capturing large video streams.  AGP provides a work around.  [TECHIE
NOTE: kiobuf's are planned for 2.5.x development, and they provide a
means for allocating large amounts of memory, think of it as a software
implementation of the 3rd really cool thing AGP does.]

Kernel support:
During the development of the Utah-GLX project, we realized that one of
the major bottlenecks was PCI throughput.  Carmack developed the mem=XX
hack, which you set aside ($SYSTEM_MEMORY_SIZE - XX) for use by the 3d
driver.  This allowed a contiguous area of memory for texture
transfers.  Next, the PCI bus became the limitation, so Jeff Hartman (in
a weekend**) reverse engineered the AGP chipset found on BX mobo's, this
enabled us to utilize the higher transfer rates.  Later, memory usage
(3rd cool thing) and AGP 2x support was incorporated, as well as support
for all the major chipsets (VIA, etc), as well as being much more
stable***.  He started creating patches for the various kernel versions,
and distributing them so ppl could test/use it.  Since all this took
place during the 2.3.x devel cycle, it was picked up and deamed stable
enough to be incorporated.  That is why ppl are seeing AGP support in
the 2.4.0-pre kernels.  The patches that are in the Utah-GLX CVS, are
for 2.2.x series kernels and do the same thing.

DRI Support:
Currently, the Utah-GLX drivers are being ported to use DRI (instead of
just being a GLX module).  The Matrox and ATI Rage support should be
included when the DRI merge is complete in X 4.0.1 (real-soon-now). 
Additionally, their kernel DRI support will come around in later 2.4.x
kernels.  This is in addition to having AGP support.  DRI allows direct
rendering to the frame buffer (hence the name), and is independant of
the bus interface (PCI vs AGP).  

In a nutshell:
3dfx users- use 2.4.x (DRI module and AGP module) and X 4.0.1 you will
have really good 3d.
Matrox users- you can either wait for 2.4.x support, or patch kernel for
AGP support (From Utah-GLX CVS) and use X 3.3.6 w/ the Utah-GLX driver.
ATI Rage- same as Matrox
SiS- I am sorry
Nvidia- You are stuck using whatever nvidia releases, b/c they have not
opened their device docs.  Their solution is a BINARY ONLY X 4.0 module
that does not use DRI.  I am still trying to lobby Nvidia into changing
their mind, but unfortunetely they have better driver programmers than
anyone, and so they can actually afford to support Linux by themselves. 
(Makes the Open Source arguement more difficult).

Hope this helps-
Matthew R. Pavlovich


**The first incarnation of AGP support only worked for the BX rev that
Hartman had, which, to my dismay, was different than the rev on my Dual
Proc Tyan 1836DLU.  Needless to say, it was successful in frying my
motherboard and I have yet to have it replaced by Tyan.

***Stable drivers are available earlier than having your motherboard
replaced.  I highly recommend waiting for stable drivers, over testing
the early drivers.