Patches Proceed For Disabling Radeon AGP GART, Deprecating TTM AGP

[starshipeleven]

I hope somebody like NetBSD keeps the AGP support so there is a high performant OS for these old cards.

What for, it's not like you can actually run applications that use it in NetBSD anyway

[Tomin]

I'm going on a limb and take a bind stab in the dark with the following statement:
That graphics chip is complete garbage and can't saturate PCI bandwith anyway (which is what this patch falls back the bandwith to), it would be hard to notice any difference.

I understood that this keeps AGP bandwidth but MMU behaviour is changed. I agree that it probably doesn't affect that chip much at all, though.

[MrCooper]

All of you have the same idea that it going to be loss in performance. PCI on a AGP is still a gets the clock speed boosts on transfer of AGP. In the case of Radeon 7500 Mobillity you still have the agp x4 transfer speeds in PCI mode so it not that crippling on the card performance.

[Citation needed]

Due to removing the system wide MMU conflit AGP GART causes when you use PCI GART you may in fact see higher performance with the AGP GART feature removed.

Keep dreaming.

Whenever I tried PCI GART with a native AGP Radeon (which was quite often), it was a big performance hit, even with relatively light workloads. There's no reason to believe this has somehow magically disappeared. It *might* be possible to reduce the gap by better optimizing the drivers for PCI GART, but it'd be a lot of hard work, I wouldn't hold my breath for it happening at this point.

It might not be as bad with less-ancient AGP cards with native PCIe Radeons sitting behind AGP-to-PCIe bridges, but even then it's hard to imagine how it could actually improve performance.

Dropping AGP support may be worth it for stability and code maintenance benefits, but everybody needs to be clear that it'll be a big hit, on setups where performance is already weak by today's standards to begin with.

[oiaohm]

I'm going on a limb and take a bind stab in the dark with the following statement:
That graphics chip is complete garbage and can't saturate PCI bandwith anyway (which is what this patch falls back the bandwith to), it would be hard to notice any difference.

https://www.hardwaresecrets.com/everything-you-need-to-know-about-the-pci-express/

To be correct this patch does not fall back to 32 bit PCI bandwidth speed as AGP cannot because it has a fixed clock of 66Mhz and 32 bit PCI runs with a clock of 33mhz. So AGPx1 port in PCI mode is twice as fast as a 32 bit PCI port.

AGP x2-8 multipliers on transfer also don't go away just because AGP card is being driven PCI mode as those are done transparently in the chipset even in PCI mode. So up to 16 times more bandwidth than a normal 32 bit PCI port. Yes with overhead max AGP x8 throughput matches that of a pcie 1.0 x8 slot even in PCI mode.

https://www.dlsweb.rmit.edu.au/set/Courses/Content/CSIT/oua/cpt160/2014sp4/chapter/06/DataBuses.html

The fact that the AGP port is a decanted direct port not shared with other items in the system also does not change either..

The only thing in performance that really goes way is the AGP cards means to access MMU in the northbridge to give copy of data memory when agp card wants. PCI mode means the host CPU sets up what data to transfer to the graphics card and when.

Basically AGP port even without AGP special stuff still a PCI port running at insane speed that a lot faster than general PCI you are looking at something in PCI-X or PCIe 1.0 to have the same speed PCI as what AGP port will give in PCI GART.

starshipeleven Something to remember for over 2 decades all powerpc system including apple stuff drive AGP in PCI GART mode not the x86 AGP GART mode that is being removed. There was no sign of performance trouble all this time with AGP in PCI GART mode.

If you are right that chipset cannot saturate a 33 Mhz 32 bit PCI slot bandwidth its going to be no where near close to AGP slot in PCI GART mode.

AGP PCI GART mode is not slow its quite fast in fact.

AGP in AGP GART mode in some cases can go a little faster than AGP PCI GART mode due to not need cpu time for particular transfers from chipset MMU to AGP GPU MMU but this comes with risk of conflict resulting chipset MMU throwing hissy fit when CPU and GPU ask to perform a memory operation on the same section on memory at the same time that happens a little more often than people think. We are not talking big performance difference. Lot of general cases it will be absolutely nothing different in performance.

Some corner cases AGP in AGP GART will be faster but some of those corner cases will also be causes of complete system lockups. AGP GART is not universally faster.

Its really simple to forgot how AGP is in fact processed after all these years. Fun right that AGP ports transfer speed is not linked to the mode it in. Speed of AGP port transfer speed is set by its fixed 66Mhz clock and the multiplier nothing else is a factor for transfer speed for AGP..

[oiaohm]

Whenever I tried PCI GART with a native AGP Radeon (which was quite often), it was a big performance hit, even with relatively light workloads. There's no reason to believe this has somehow magically disappeared. It *might* be possible to reduce the gap by better optimizing the drivers for PCI GART, but it'd be a lot of hard work, I wouldn't hold my breath for it happening at this point.

Dropping the AGP GART has some advantages. Optimisations from the PCIe GART and PCI-x GART can be applied to the x86 PCI GART they did not make sense when PCI GART was locked at 33 Mhz. Optimising those 4 driver of PCI GART(x86,powerpc), PCI-x GART and PCI-e GART can give code base reductions. Yes PCI GART(x86,powerpc) are in fact referring to different driver code in the Linux kernel meant to be doing the same thing.

It might not be as bad with less-ancient AGP cards with native PCIe Radeons sitting behind AGP-to-PCIe bridges, but even then it's hard to imagine how it could actually improve performance.

How it can improve performance is not all chipsets with AGP support in fact in the chipset MMU handle AGP GPU requesting memory from it directly in a nice high performing way this can in fact becausing system wide chipset MMU stalls.

Dropping AGP support may be worth it for stability and code maintenance benefits, but everybody needs to be clear that it'll be a big hit, on setups where performance is already weak by today's standards to begin with.

No its a mixed bag. Some AGP chipsets will be faster because chipset MMU will function better with the AGP GART gone. The merging of support code between PCI/PCI-x and PCI-e GARTs will bring optimisations back to the PCI GART that were not there on x86. Interesting enough there are a lot of optimisations in the PCI GART for powerpc that are not in the x86 code in the Linux kernel because that was being used to drive AGP cards in PCI GART. Yes optimisations from PCI-X GART where already applied to the PCI GART for powerpc.

Why do we have 2 versions of PCI GART one for powerpc and one for x86 that really does not make much sense right

There is a lot of clean up here. As this clean up complete don't expect the difference to be as big as you first expect.

I guess something that did not cross your mind is that the powerpc version of PCI GART is already optimised. Its now basically getting x86 and powerpc on the same page that will result in less code to maintain as well.

[agd5f]

Using PCI GART vs AGP GART does not affect the bus speed. It's not like the bus speed changes from 66 to 33 mhz depending on which one you use. In fact, you can (and probably should) use both at the same time in order to support both cached and uncached system memory. The performance limitations, I think, largely come from the fact that PCI GART (at least on the the oldest radeons), only had like one TLB entry so there were a lot more page table walks. That said, depending on the AGP vendor, they may have had varying TLB sizes in the chipset as well, so performance may vary across AGP chipset vendors independent of the GPU.

Also there is no architecture specific PCI GART. PCI GART is just another name for the MMU on the GPU (as opposed to the MMU in the chipset -- AGP GART). Both AGP GART and PCI GART are handled by architecture independent drivers. The AGP bridge drivers for AGP GART and the GPU drivers for PCI(e) GART.

[jabl]

How do modern (PCIe) GPUs work? Do they all use a local IOMMU?

[torsionbar28]

I'm going on a limb and take a bind stab in the dark with the following statement:
That graphics chip is complete garbage

How is it garbage? IIRC the first gen Radeon, and the later die shrink that this 7500 is based on, were well received in their day. They were head to head with the GeForce 2 Ti when gaming in 32 bit color. A feat the 3dfx Voodoo 3 cards couldn't manage. Unless you meant "performance of the Radeon 7500 is complete garbage by modern performance standards", which is of course true of any hardware manufactured nearly 2 decades ago.

[kylew77]

What for, it's not like you can actually run applications that use it in NetBSD anyway

NetBSD supports Wine like FreeBSD and unlike OpenBSD as well as many open source games. No one is playing a modern AAA game with Steam or Proton on an AGP graphics card nowadays. My old AGP socket A system the most it ever plays is an old game of Civilization 3 on Windows XP. The only perk I can see of running a modern OS on a likely 32 bit system with AGP graphics is for newer emulators for console games or for the various open source games and having the latest versions of them.

[starshipeleven]

How is it garbage?

Laptop part from 2 decades ago, supporting up to directx 7 and OpenGL 1.3.
It's comparable to a GMA3150, which is also complete garbage.
The only reason it was placed on AGP was because AGP has dedicated bandwith (while PCI bus is shared with all other cards), it would run fine on PCI bandwith too.

Unless you meant

Of course I meant that. I said IS, present tense, not WAS, past tense.
That card RIGHT NOW is barely more than a 2D chip, it will not run heavy DEs like GNOME or KDE because it does not support OpenGL 2.0, go figure running any modern application that needs any form of 3D acceleration.