AGP Graphics Card Support Proposed For Removal From Linux Radeon/NVIDIA Drivers

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • oiaohm
    replied
    Originally posted by wyatt8740 View Post
    My machine does hang if I don't force it down to PCI clock speeds, it seems. So I am stuck like that for now but I think I'm starting to understand what you're saying. Sorry for my ignorance, I'm pretty young and AGP was on the way out by the time I was getting into this sort of thing.
    No problem I would not have known this stuff if I had made a lot the same screw ups in logic when deal with powerpc hardware like 20 years ago. I was like hey if AGP cards on my powerpc system are going to be locked in PCI MMU its going to perform bad because I had the wrong idea that PCI MMU mode on AGP card equal run at PCI speeds .

    When PCI MMU really equals use PCI memory management at AGP speeds I saw the speed loses back then 10 to 20% at worst as long as card is still running at correct AGP clock speeds.

    Yes forcing AGP gpu down to PCI clock speeds is a really big way to make lots of them very unhappy. PCI MMU and AGP GART both you can attempt to run at PCI clock speeds and have them spit chips on AGP cards.

    Transfer method with AGP(PCI MMU and AGP GART) is something different to operation clockspeed and transfer speeds. I was having a hard time explaining the mess.

    Leave a comment:


  • wyatt8740
    replied
    Originally posted by oiaohm View Post

    There is a little bit of yes and no here. PCI MMU mode on agp technically can transfer as fast a AGP GART by standard. The transfer speed over the agp wires technically is meant to have nothing todo with if card is in PCI MMU or AGP GART mode. But you do have issues where some graphic cards will not clock up the PCI MMU mode that is not the majority of AGP cards made.

    AGP in PCI mode is meant to be like 8x faster than normal PCI because its meant to be running at AGP clock rates using AGP over wire transfer methods. There are some performance hits using the PCI MMU mode but this should not be transfer speed loss. Having to wait for host in PCI MMU mode to push data to graphics card instead of in AGP Gart mode the card just pulling that data out of memory is the performance problem you are dealing with 10/20 percent loss at worst side.
    My machine does hang if I don't force it down to PCI clock speeds, it seems. So I am stuck like that for now but I think I'm starting to understand what you're saying. Sorry for my ignorance, I'm pretty young and AGP was on the way out by the time I was getting into this sort of thing.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by wyatt8740 View Post
    I've done research since my last post and you are pretty much on-point. Looks like KMS broke a lot of stuff in PPC radeon as well. Sorry for jumping to conclusions.

    Apparently you can set 'agpmode' to -1 when booting and get PCI-clocked acceleration as well (the "PCI MMU mode" you mentioned?) - Far less than ideal (1/8th the maximum transfer rate, I think) but it apparently works.
    There is a little bit of yes and no here. PCI MMU mode on agp technically can transfer as fast a AGP GART by standard. The transfer speed over the agp wires technically is meant to have nothing todo with if card is in PCI MMU or AGP GART mode. But you do have issues where some graphic cards will not clock up the PCI MMU mode that is not the majority of AGP cards made.

    AGP in PCI mode is meant to be like 8x faster than normal PCI because its meant to be running at AGP clock rates using AGP over wire transfer methods. There are some performance hits using the PCI MMU mode but this should not be transfer speed loss. Having to wait for host in PCI MMU mode to push data to graphics card instead of in AGP Gart mode the card just pulling that data out of memory is the performance problem you are dealing with 10/20 percent loss at worst side.

    Leave a comment:


  • wyatt8740
    replied
    Originally posted by oiaohm View Post
    Powerpc users have not had the AGP GART/MMU feature now removed from x86 complete since 1998 when it was removed from the powerpc kernel code so anyone with a powerpc system this recent change in fact changes nothing because the same change for your was over a 2 decade ago.
    I've done research since my last post and you are pretty much on-point. Looks like KMS broke a lot of stuff in PPC radeon as well. Sorry for jumping to conclusions.

    Apparently you can set 'agpmode' to -1 when booting and get PCI-clocked acceleration as well (the "PCI MMU mode" you mentioned?) - Far less than ideal (1/8th the maximum transfer rate, I think) but it apparently works.
    Originally posted by Zan Lynx View Post

    Here's a torrent link to download Ubuntu 18.04 LTS for PPC64. Yes it requires a Power8 or Power9 for little endian support. Big endian mode is still possible but hardly anyone builds Linux systems that way because it breaks almost everything, and where it does work it slows everything down. For example, GPUs are mostly designed to work in little endian. So if you write CPU data to the GPU all of it has to be rotated on each copy and you can't just memory map it. Big endian is pretty much dead.

    magnet:?xt=urn:btih:44cd2445b218ef8b...com%2Fannou nce
    I'm already running Debian on it, thanks, but I have to run "unstable."

    And I mentioned "powerbook G4." What about that makes you expect I have a POWER8 machine? I sincerely wish I could afford a Talos or something.
    Last edited by wyatt8740; 24 September 2020, 06:52 PM.

    Leave a comment:


  • rogerx
    replied
    Originally posted by eydee View Post
    It's been 2 days and the article hasn't been corrected yet. It still implies all AGP hardware just stops working entirely. Apparently, clicks are more important than facts.

    Remember this when the Next Big Begging For Donations happens.
    Ditto. Notice the number of people slamming any justified opposition.

    Posted to the newer article, dated May 16, my results are a 30-40% drop in performance along with having hard freezes/lock-ups with using the PCI GART method rather than the usual AGP driver on my Intel 815 & likely my Intel 440BX chipsets. These graphics cards are likely in the modest ~64-128MB memory range, so likely having little to no memory problems, versus those having the >128MB AGP graphics cards on non-Intel platforms.

    I'm thinking, the majority with issues are those who've had AMD cards or non-Intel chipsets; and/or long abandoned the problematic cheap hardware versus those of us spending wisely on good hardware.
    Last edited by rogerx; 18 May 2020, 10:15 PM.

    Leave a comment:


  • M@GOid
    replied
    Originally posted by caligula View Post
    I've never seen any Atom system that was a joy to use.
    I just remembered a recent Atom budget laptop with a fixed 32 GB of storage, that a colleague asked me to look at. Win10 updates simply occupied the entire space, making the poor thing crawn to a stop. The only solution was to reinstall the OS and ask her to not save anything there, and to reinstall the OS from time to time, since you cannot stop Windows Update on W10...

    Leave a comment:


  • HyperDrive
    replied
    Originally posted by Zan Lynx View Post
    Big endian mode is still possible but hardly anyone builds Linux systems that way because it breaks almost everything, and where it does work it slows everything down.
    You have Debian powerpc and ppc64 (both big-endian) ports. I'm running both, on G4 (PowerBook6,7) and G5 (PowerMac11,2) systems.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by wyatt8740 View Post
    I want accelerated graphics. Not fbdev.
    If a AGP card is in a linux powerpc system has not in recent time used the AGP GART/MMU system always driven the card in PCI MMU mode with accelerated graphics this is the mode that is going to remain. AGP GART/MMU usage has been restricted to x86 platforms. Before this patch particular x86 systems by Linux quirks(as in we detected hardware issue here we will do special behaviour) when you put AGP card in them they also only drive the card in PCI MMU mode as well and also by quirks particular AGP cards will only drive in PCI MMU no matter what X86 system they in.

    The reality is you have a x86 system with a AGP card in it running Linux you have less than a 50% chance before this patch that is using AGP GART/MMU and have greater than 50% chance is being driven in PCI MMU mode. If you have a powerpc system before this patch you have a 0% chance that you are using AGP GART/MMU and 100% that you have been using PCI MMU mode on the AGP card this complete time.

    The reality here is quite a few people for quite a long time have been using their AGP cards in PCI MMU mode and have not reported performance problems or any other issues.

    Now even recently people have been reporting AGP cards in AGP GART/MMU mode causing system wide lock-ups you don't get much worse of a performance problem when you have just lost all your work to driver issue.

    So this is not no acceleration removing the AGP modes. Yes in particular programs AGP GART/MMU mode may be faster but this comes at a major risk to system stability. Developers having to maintain a growing quirk entries with more and more entries reading disable AGP GART use PCI MMU mode for system stability is not really a productive usage of developers time when there is not a major documented performance difference. The difference is small enough that users have not notice or complain when all the past quirks that disabled AGP GART have been set heck some reported result in faster speeds after the prior quirk fixs that were just use PCI MMU because the person stops having system wide MMU stalls.

    Its one thing if the feature worked with documented performance benefit large enough to justify the risk. Powerpc kernel developers way back in early days decided that AGP GART/MMU was not worth the problems due to not enough performance gain to justify it this was 1998 one year into AGP existance.

    Powerpc users have not had the AGP GART/MMU feature now removed from x86 complete since 1998 when it was removed from the powerpc kernel code so anyone with a powerpc system this recent change in fact changes nothing because the same change for your was over a 2 decade ago.

    Leave a comment:


  • Zan Lynx
    replied
    Originally posted by wyatt8740 View Post
    And good luck finding an LTS PPC distro.
    Here's a torrent link to download Ubuntu 18.04 LTS for PPC64. Yes it requires a Power8 or Power9 for little endian support. Big endian mode is still possible but hardly anyone builds Linux systems that way because it breaks almost everything, and where it does work it slows everything down. For example, GPUs are mostly designed to work in little endian. So if you write CPU data to the GPU all of it has to be rotated on each copy and you can't just memory map it. Big endian is pretty much dead.

    magnet:?xt=urn:btih:44cd2445b218ef8b...com%2Fannounce
    Last edited by Zan Lynx; 13 May 2020, 10:56 AM.

    Leave a comment:


  • wyatt8740
    replied
    Oh, so now they're coming to murder my PowerBook G4.
    Well I'll be commenting on the RFC.

    Originally posted by eydee View Post
    It's been 2 days and the article hasn't been corrected yet. It still implies all AGP hardware just stops working entirely. Apparently, clicks are more important than facts.

    Remember this when the Next Big Begging For Donations happens.
    I want accelerated graphics. Not fbdev.
    Originally posted by Xaero_Vincent View Post
    So if someone had an AMD Radeon HD 4670 AGP card, it should continue to work in PCI mode but slower? If so, it doesn't seem like a bad trade off. I mean if the slower performance was a deal breaker, they could stick to a LTS distro like RHEL or CentOS 8 and be good support wise until May 2029 and get some software updates via 3rd party repos and Flatpak.
    Flatpak is a codeword for developer laziness and "works on my machine."

    And good luck finding an LTS PPC distro.
    Last edited by wyatt8740; 13 May 2020, 09:56 AM.

    Leave a comment:

Working...
X