Originally posted by kylew77
View Post
Announcement
Collapse
No announcement yet.
Patches Proceed For Disabling Radeon AGP GART, Deprecating TTM AGP
Collapse
X
-
Originally posted by starshipeleven View PostI'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.
Comment
-
Originally posted by oiaohm View Post
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.
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.
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.
Comment
-
Originally posted by starshipeleven View PostI'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.Take a look at our thorough overview of everything PCI Express, AGP, and old-school PCI. You'll have a lot to learn in our detailed editorial.
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.
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..
- Likes 1
Comment
-
Originally posted by MrCooper View PostWhenever 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.
Originally posted by MrCooper View PostIt 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.
Originally posted by MrCooper View PostDropping 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.
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.
- Likes 1
Comment
-
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.
- Likes 2
Comment
-
Originally posted by starshipeleven View PostI'm going on a limb and take a bind stab in the dark with the following statement:
That graphics chip is complete garbage
- Likes 1
Comment
-
Originally posted by starshipeleven View PostWhat for, it's not like you can actually run applications that use it in NetBSD anyway
Comment
-
Originally posted by torsionbar28 View PostHow is it garbage?
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
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.
Comment
Comment