lkml.org 
[lkml]   [2021]   [May]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: On disabling AGP without working alternative (PCI and PCIe are also affected)
Date
[AMD Public Use]

> -----Original Message-----
> From: Thomas “illwieckz“ Debesse <dev@illwieckz.net>
> Sent: Thursday, May 13, 2021 2:42 PM
> To: Deucher, Alexander <Alexander.Deucher@amd.com>; Koenig, Christian
> <Christian.Koenig@amd.com>; LKML <linux-kernel@vger.kernel.org>
> Subject: Re: On disabling AGP without working alternative (PCI and PCIe are
> also affected)
>
> Erratum: In my previous e-mail I forgot to remove that sentence about Intel
> platform:
>
> > If I'm right, AGP cards seems to work as PCI ones as well. That may
> > makes sense because previously I did not test AGP Radeon cards on
> > Intel platforms.
>
> I first wrote that after having beeing fooled by a lucky hardware combination.
> It exchanged immediate failure at desktop load for later computer reboot at
> game load (but with successfully loaded desktop, hence the illusion it worked
> at first).
>
> The valid statement, after more testing, is (quoted from the previous mail
> which had then contradictory statements):
>
> > Note: on some very old cards (like the 9700 Pro from 2002) with
> > radeon.agpmode -1 (AGP as PCI), the symptom is different, the desktop
> > loads properly, but loading a game (Unvanquished) leads to a GPU
> > lockup.
> > While on newer hardware like ATI Radeon HD 4670 AGP (which was still
> > sold as new in 2012), the desktop won't load, displaying the exact
> > same symptoms as ATI/AMD PCI on ATI/AMD CPU. If I'm right, the old
> > ones like the 9700 Pro is likely to be a native AGP card, while the
> > latest ones like the HD 4670 may be natively PCIe with a bridge on the
> > AGP card.
> > Maybe that can ring a bell…
>
> Not only the GPU can lockup, but the computer may also crash and reboot in
> that scenario. The same hardware and software combination works perfectly
> when AGP is enabled.
>
> Those AMD/ATI AGP cards are then known to be affected on both AMD and
> Intel host platforms.

I don't think I have a functional AGP system anymore, but I do have PCIe capable systems and they work fine.
Does this patch[1], help by any chance? The change to add support for root ports with addressing limitations seemed to break a lot of old systems,
but never really got resolved. If not, your best bet is probably to try and bisect if something broke your system(s).

Alex

[1] - https://www.spinics.net/lists/amd-gfx/msg52961.html

>
> Best regards,
>
> PS: I wish to be personally CC'ed the answers/comments posted to the list in
> response to my posting.
>
> --
> Thomas “illwieckz” Debesse
>
> Le 06/05/2021 à 07:37, Thomas “illwieckz“ Debesse a écrit :
> > Hi! First, thank you both Alex and Christian for your answers. Since
> > that time I did more experiments with more hardware. And… the new
> > knowledge is that the bug affects PCIe cards on PCIe slot when the
> > host also offers AGP slot, meaning those computers have to rely on AGP
> > cards (or PCI ones) instead of PCIe ones to get a working and usable
> desktop.
> > This bug is older than the AGP disablement that happened with 5.9-rc1
> > (out of curiosity I also reproduced the bug on Linux 4.15 from Ubuntu
> > Xenial, for example).
> >
> > We now know the issue affects both AGP, PCI, and PCIe. We know that
> > the issue affects both ATI/AMD and Nvidia hardware. The bugs occur
> > given this or that host / card combination, while everything works
> > with other combinations of the same hosts and cards (all of them being
> > validated to be working at some point). We know that, for PCI-related
> > issues, it even affects post-AGP AMD platforms like Bulldozer/Piledriver.
> >
> > The PCIe issue affects both ATI/AMD and Nvidia GPUs and the symptoms
> > are consistent with the ones experienced with legacy PCI ATI/AMD and
> > Nvidia GPUs on platform we know PCI GPUs do not work. When I talk
> > about GPUs with legacy PCI port I talk about TeraScale/Tesla ones with
> > GL3 support, 512MB of VRAM and HDMI support, not ones from the Rage
> > era, just to make sure this is clear enough.
> >
> > Among the PCIe GPUs I managed to reproduce the bug with, I can name:
> >
> > - ATI Radeon HD 5870 Eyefinity 6 (RV870 Cypress XT, TeraScale 2,
> > OpenGL 4.3, 2GB of VRAM, 6 miniDP, released 2010-03).
> > - AMD FirePro 3D V4800 (RV830 Redwood XT GL, Terascale2, OpenGL 3.3,
> > 1GB VRAM, 1 DVI-I + 2 DP, released 2010-04).
> > - AMD Radeon HD 6970 (RV910 Caicos, TeraScale 3, OpenGL 4.3, 2GB VRAM,
> > 2 DVI-D + 1 HDMI + 2 miniDP, released 2010-12).
> >
> > Those GPUs don't have PCI or AGP counterparts anyway. And we know
> some
> > Linux PCI bugs can even affect TeraScale 3 PCIe GPUs with OpenGL 4 and
> > OpenCL support.
> >
> > We also know some Nvidia GPU (PCI and PCIe) can be affected.
> >
> > It looks like the problems are less on the GPU side, but more on the
> > PCI platform (bridge? chipset? I don't know). So while AMD is more
> > affected, and maybe AMD specific code is affected since AMD symptoms
> > are different than Nvidia symptoms, even combinations to reproduce
> > bugs may differ given the brand, my attention is now focused on PCI.
> >
> > ## What we already knew at the time of previous emails ##
> >
> > 1. PCI ATI/AMD Radeon and PCI Nvidia GPUs don't work on AMD platform,
> > this was verified on K8 (AMD Athlon 64 3200+, AMD Athlon 64 X2), K10
> > (AMD Phenom II X4 970 8 core) and Piledriver (FX-9590 8 core), so we
> > can probably assume all AMD64 platforms before Ryzen, Ryzen-based
> > motherboard usually don't have legacy PCI anyway (I've heard of the
> > Biostar Racing X470GTA motherboard but well, it's more rare than
> > legacy PCI and AGP).
> >
> > So there are known issues with legacy PCI on pre-Ryzen architecture,
> > including bulldozer ones, which is far more recent than AGP.
> >
> > At the same time, those PCI ATI/AMD Radeon and PCI Nvidia GPUs work
> on
> > Intel platforms, this was verified on multiple hosts including ones
> > with Pentium E5200 dual core (with Intel 82801) and Core 2 Quad Q6600
> > (with VIA PT880/VT82xx) to name somes.
> >
> > The brokenness of PCI ATI/AMD Radeon GPU on AMD platform is
> unrelated
> > to the platform offering AGP or PCIe. Both K8 with AGP and K8 with
> > PCIe behaves the same when a PCI ATI/AMD Radeon GPU is plugged in.
> The
> > PCI Radeon sample used for the test is a Radeon HD 4350 which is
> > fairly
> > capable: TeraScale, GL 3.3, 512M VRAM, HDMI.
> >
> > 2. AGP Radeon cards stopped to work on AMD platforms when AGP was
> > disabled by default in 5.9-rc1. The only way to make them work is to
> > use
> > radeon.agpmode=1 kernel command line option. Because distributions
> > like Ubuntu LTS distributed the patch backported on 5.8 kernel (either
> > because they backported it themselves or kernel developers did it
> > upstream, I don't know), after the update the computers were not able
> > to complete the boot because they never reached the desktop. This
> > affected pretty capable computers like the one I previously quoted,
> > which runs the quad core AMD AM3 Phenom II CPU X4 970 (3.5GHz) with
> > 16GB of RAM and featuring AGP Radeon HD 4600 (TeraScale, GL 3.3, 1GB
> VRAM, HDMI).
> >
> > If I use startx with lxsession I can get a working X.org environement,
> > but that is super slow and not really usable. Very slow disk IO are
> > reported and audio glitches are experienced, this has side-effects on
> > a wider scale than the sole display. Starting a more complexe
> > environment like GNOME will just make the computer unusable.
> >
> > 3. AGP Radeon cards running as PCI cards on AMD platforms display the
> > same broken behaviour we can see with PCI Radeon cards, which is not
> > surprising given it is expected they would run the same way. At least
> > this prediction got verified. ATI/AMD AGP as PCI on AMD platform is as
> > broken as ATI/AMD PCI on AMD platform.
> >
> > 4. Some problems were said to have been noticed by kernel developers
> > with latest AMD Radeon hardware and it was said disabling AGP improved
> > the support for those recent cards, that's why AGP was disabled
> > starting with 5.9-rc1 in hope to fix the latest AMD Radeon hardware
> > (but that brokes older ones in the process).
> >
> > ## What is new knowledge since that time ##
> >
> > 1. PCIe ATI/AMD Radeon GPUs running on Intel host having both AGP and
> > PCIe slots do not work and displays the same broken behaviour we can
> > see with AGP Radeon cards running as PCI cards, or PCI Radeon cards on
> > AMD platform.
> >
> > This was verified with a wide range of AMD/ATI PCIe GPUs, both
> > consumer Radeon or professionnal FirePro cards.
> >
> > Interestingly, the testbed is an Intel-based platform (Core 2 Quad
> > Q6600) and then PCI Radeon cards work as we seen with other Intel
> > based hosts. If I'm right, AGP cards seems to work as PCI ones as
> > well. That may makes sense because previously I did not test AGP
> > Radeon cards on Intel platforms.
> >
> > But then, as I said, the PCIe Radeon cards just fails as AGP ones
> > running as PCI and PCI ones on AMD platforms. But for them,
> > radeon.agpmode=1 does not make sense, so there is no solution.
> >
> > By failing I mean grub displays things correctly, then linux displays
> > things correctly, including framebuffer, but when X.org starts and
> > open the desktop, some background is painted but the desktop never
> > complete the startup. The mouse pointer can be moved with the mouse
> > but that's all. The tested desktop is GNOME, and the shell itself does not
> display.
> >
> > So, with all those experiments done, and with all that knowledge, it
> > appears there is some serious issues in the PCI code.
> >
> > Note: on some very old cards (like the 9700 Pro from 2002) with
> > radeon.agpmode -1 (AGP as PCI), the symptom is different, the desktop
> > loads properly, but loading a game (Unvanquished) leads to a GPU lockup.
> > While on newer hardware like ATI Radeon HD 4670 AGP (which was still
> > sold as new in 2012), the desktop won't load, displaying the exact
> > same symptoms as ATI/AMD PCI on ATI/AMD CPU. If I'm right, the old
> > ones like the 9700 Pro is likely to be a native AGP card, while the
> > latest ones like the HD 4670 may be natively PCIe with a bridge on the AGP
> card.
> > Maybe that can ring a bell…
> >
> > 2. PCIe Ndidia GPUs on Intel host having both AGP and PCIe slots do
> > not work and displays the same broken behaviour we can see with PCI
> > Nvidia card running on AMD host. The graphical glitches are exactly
> > the sames with Nvidia PCI on the AMD host and Nvidia PCIe on the Intel
> > host (but not the same as PCI and AGP-as-PCI and PCIe Radeon
> symptoms).
> >
> > So, we can reproduce the Nvidia-specific glitches with both PCI and
> > PCIe, and we can reproduce the ATI/AMD-specific symptoms with both
> > PCI, AGP, and PCIe.
> >
> > ## Various answers and questions ##
> >
> > Christian Köning said:
> >
> >> That is interesting but doesn't make much sense from the technical
> > perspective.
> >> See AGP is build on top of PCI, if PCI doesn't work AGP won't work
> > either. So why should AGP work while PCI doesn't?
> >
> > Now we know that both PCI, AGP and PCIe are affected. Which makes
> sense.
> >
> > What's makes hard to track the bugs is that the bugs may occur or not
> > occur given the host and cards combination. This is probably about
> > GPU/PCI bridge combination (and motherboard chipset when it makes
> > sense) or things like that.
> >
> > Alex Deucher said:
> >
> >> For newer AGP hardware like the RV730 you point out (or anything
> >> newer
> > than R300), there is no reason to run AGP mode. The on chip GART is
> > far superior.
> >
> > So, on paper, AGP-as-PCI is expected to work, and on paper again, some
> > of those card may even work better this way. Experience currently
> > displays the exact opposite, which not only means there is bugs
> > somewhere, but also that the behaviour of the PCI code is
> > unpredictable, because predictions fail.
> >
> > Christian Köning said:
> >
> >> We simply don't have the time to support that older GPU and disabling
> > AGP fixed quite a number of them.
> >
> > Was disabling AGP motivated by some issues with identified causes and
> > it was decided to not fix them, or was disabling AGP motivated by the
> > observation it fixed some other issues but without identifying the causes?
> >
> > What's now interesting is that on some PCIe-compatible platforms, PCIe
> > is broken and AGP is the working fallback, and now that AGP is
> > disabled by default in code, none work out of the box.
> >
> > I can understand how it would be easier to not support older hardware,
> > but on the other hand what's the purpose of Mesa/RadeonSI supporting
> > them on the userland side if the kernel can't host the hardware to
> > begin with?
> >
> > Also, that may be seen as unfortunate, but AGP is not only about Rage
> > 128 cards or those very very old thing that would not fullfill current
> > needs. Unlike Nvidia, there was AMD/ATI AGP hardware that were
> > produced and sold very lately and those are still capable to fullfill
> > current needs. At the same time, AMD ensured very good compatibility
> > of it's hardware, that's why it was possible to have the quoted quad
> > core AM3 Phenom II on an AM2 motherboard with AGP for example. This is
> > precisely why AMD is appreciated by customers, not like Intel with
> > frustrating market segmentation where, for example (real use case),
> > one Pentium
> > E5200 with IGP can support OpenGL 3 but not virtualization, while
> > another Pentium E5200 with IGP cannot support OpenGL 3 but supports
> > virtualization, or (another real example), supporting PAE while hiding
> > it to the operating system. Buying AMD is all about not having to
> > choose between this or this feature, and buying AMD is all about being
> > able to get hardware that works over multiple hardware generations.
> >
> > But anyway, outside of those considerations, it now appears the PCI
> > code has serious issues and the behaviour can't be predicted. Newer
> > hardware may be working, but do we know how much luck is involved?
> >
> > I may be busy, doing those extra tests and reporting the results took
> > me some extra months, but at least, I have access to a wide range of
> > hardware to test any patch that would aim to fix the
> > PCI/AGP/PCIe-related bugs. I would be happy to help on that topic. AGP
> > is just one aspect of it, now we know those PCI-related bugs affect
> > legacy PCI and PCI express as well.
> >
> > Christian Köning said:
> >
> >> We simply can't invest time maintaining a technology which is
> > deprecated for nearly 15 years now.
> >
> > It now appears that the bugs not only affect AGP and PCI but also PCI
> > Express. AGP disclosed those bugs, but PCI seems to be at fault there.
> >
> > One interesting thing is that some ATI/AMD cards on AMD hosts are more
> > buggy than the same ATI/AMD cards on Intel hosts. The underlying bugs
> > may even not be related to the cards themselves but on the host PCI
> > code (chipsets, PCI bridges or things like that).
> >
> > Note: one interesting thing is that I have access to two Radeon HD
> > 4670, one AGP model, one PCIe model, from the same vendor, exact same
> > generation, vendor and model, just one being AGP and one being PCIe
> > variant. On the same Intel-based motherboard supporting both AGP and
> > PCIe, only the AGP model works. The PCIe model is not faulty, it works
> > as expected on AMD-based motherboards only having an AGP port and no
> > PCIe port. Getting things working seems to be about luck, not about
> > what the implementation is said to do.
> >
> > I also have access to two X1950 pro, one PCIe, one AGP, from different
> > vendors, though this one is less interesting because not a TeraScale
> > one. But this may be useful for testing because I can test both on the
> > same motherboard having both an AGP and a PCIe slot. Currently, only
> > AGP works on that host anyway because when using AMD/ATI or Nvidia
> > PCIe GPUs on that Intel host I reproduce the issues I get with AMD/ATI
> > or Nvidia PCI GPUs on AMD host…
> >
> > Who are the ones working on the PCI platform code? Maybe those would
> > be better interlocutors, it looks like the issue is not AMD specific,
> > it affects Nvidia GPUs and Intel platforms as well.
> >
> > Is there options similar to radeon.agpmode but for PCI / PCI Express I
> > can experiment with?
> >
> > I'll build one day the latest vanilla kernel to reproduce the issues
> > and probably open a ticket on the kernel bugzilla regarding
> > PCI-related problems in general (even if there is AMD-specific variants of
> the bug).
> > That would be a good start.
> >
> > Thank your very much for your attention, best regards,
> >
> > PS: I wish to be personally CC'ed the answers/comments posted to the
> > list in response to my posting.
> >
> > --
> > Thomas “illwieckz” Debesse
> > Le 09/11/2020 à 18:37, Deucher, Alexander a écrit :
> >> [AMD Public Use]
> >>
> >>> -----Original Message-----
> >>> From: Thomas “illwieckz“ Debesse <dev@illwieckz.net>
> >>> Sent: Monday, November 9, 2020 6:41 AM
> >>> To: LKML <linux-kernel@vger.kernel.org>
> >>> Cc: Koenig, Christian <Christian.Koenig@amd.com>; Deucher, Alexander
> >>> <Alexander.Deucher@amd.com>
> >>> Subject: On disabling AGP without working alternative (PCI fallback
> >>> is broken for years)
> >>>
> >>> Hi, on May 12 2020, a commit (ba806f9) was merged disabling AGP in
> >>> default build.
> >>>
> >>> It was signed-off by Christian König and Reviewed by Alex Deucher.
> >>> Distributions started to backport this commit, and it seems to have
> >>> happened with 5.4.0-48-generic on Ubuntu 20.04 LTS side, which was
> >>> built on Sep 10 2020.
> >>>
> >>> Around that time I noticed AGP computers experiencing lock-ups and
> >>> other problems making them unusable after the upgrade. After
> >>> investigating what was happening bisecting Linux versions, I
> >>> reverted the commit and those computers were working again.
> >>>
> >>> Commit message was:
> >>>
> >>>> This means a performance regression for some GPUs, but also a bug
> >>>> fix for some others.
> >>>
> >>> Unfortunately, this commit does not only introduce a performance
> >>> regression but makes some computers unusable, maybe all computers
> >>> with AMD CPUs.
> >>>
> >>> One of the root cause may be that PCI GPUs are broken for years on
> >>> AMD platforms, it was tested and verified on:
> >>>
> >>> - K8-based computer with AGP
> >>> - K8-based computer with PCI Express
> >>> - K10-based computer with AGP
> >>> - Piledriver-based computer with PCI Express
> >>>
> >>> The breakage was tested and reproduced from Linux 4.4 to Linux
> >>> 5.10-rc2 (I have not tried older than 4.4).
> >>>
> >>> PCI GPUs may be broken on some other platforms, but I have found
> >>> that testing on an Intel PC (with PCI Express) does not reproduce
> >>> the issue when the PCI GPU hardware is plugged in.
> >>>
> >>> There is two patches I'm requesting comments for:
> >>>
> >>> ## drm/radeon: make all PCI GPUs use 32 bits DMA bit mask
> >>>
> >>>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flk
> >>>
> ml.org%2Flkml%2F2020%2F11%2F5%2F307&amp;data=04%7C01%7CAlexand
> er.Deu
> >>>
> cher%40amd.com%7C24731393d8ef426b573e08d9163ed4ae%7C3dd8961fe48
> 84e60
> >>>
> 8e11a82d994e183d%7C0%7C0%7C637565282618094458%7CUnknown%7CTW
> FpbGZsb3
> >>>
> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
> %3D
> >>>
> %7C2000&amp;sdata=ttmqSG4h28zhGya9KRnHkK7ftzmHVdrGsZDvTFiuX10%
> 3D&amp
> >>> ;reserved=0
> >>>
> >>> This one is not enough to fix PCI GPUs but it is enough to prevent
> >>> to fail r600_ring_test on ATI PCI devices. Note that Nvidia PCI GPUs
> >>> can't be fixed by this, and this uncovers other bug with AGP GPUs
> >>> when AGP is disabled at build time. Also, this patch may makes PCI
> >>> GPUs working on a non-optimal way on platform that accepts them with
> >>> 40-bit DMA bit mask (like Intel- based computers that already work
> without any patch).
> >>>
> >>> This patch is inspired from the patch made to solve that issue from
> >>> 2012 on kernel 3.5:
> >>>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbu
> >>>
> gzilla.redhat.com%2Fshow_bug.cgi%3Fid%3D785375&amp;data=04%7C01%7
> CAl
> >>>
> exander.Deucher%40amd.com%7C24731393d8ef426b573e08d9163ed4ae%7
> C3dd89
> >>>
> 61fe4884e608e11a82d994e183d%7C0%7C0%7C637565282618313502%7CUnkn
> own%7
> >>>
> CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi
> LCJ
> >>>
> XVCI6Mn0%3D%7C2000&amp;sdata=7uF7JHP9LQnD6yJsZBhT9Tzwo%2BoM2
> bnaxxXKk
> >>> jpRfbw%3D&amp;reserved=0
> >>>
> >>> At the time, such change may have been enough to fix the issue, it's
> >>> not true any more. More breakage may have been introduced since.
> >>>
> >>> Also, maybe this patch becomes useless when other PCI bugs are
> >>> fixed, who knows? At least, this is an entry-point for investigations.
> >>
> >> I think you may be seeing fallout from this patch:
> >>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
> >>
> .kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git
> >>
> %2Fcommit%2F%3Fid%3D33b3ad3788aba846fc8b9a065fe2685a0b64f713&am
> p;data
> >>
> =04%7C01%7CAlexander.Deucher%40amd.com%7C24731393d8ef426b573e0
> 8d9163e
> >>
> d4ae%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C6375652826183
> 13502%
> >>
> 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC
> JBTiI6I
> >>
> k1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=FYFOtp1DYw1RU%2BxdJcV
> NNpyk5NMr
> >> GPjDSEFiM3kvx8k%3D&amp;reserved=0 That patch lead to screen
> >> corruption and other issues on older radeons. It seemed to be related to
> AGP and/or HIMEM. Disabling either of those fixes the issues.
> >> I proposed reverting the change, but there was push back to find the root
> cause:
> >>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> w
> >>
> .spinics.net%2Flists%2Fstable%2Fmsg413960.html&amp;data=04%7C01%7CA
> le
> >>
> xander.Deucher%40amd.com%7C24731393d8ef426b573e08d9163ed4ae%7C3
> dd8961
> >>
> fe4884e608e11a82d994e183d%7C0%7C0%7C637565282618313502%7CUnkno
> wn%7CTW
> >>
> FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX
> VCI
> >>
> 6Mn0%3D%7C2000&amp;sdata=XPVqb5fLOb7os1uz6sizBCKNiI2OfaNzYjy5fkq
> XlqM%
> >> 3D&amp;reserved=0
> >>
> >>
> >>>
> >>> ## Revert "drm/radeon: disable AGP by default"
> >>>
> >>>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flk
> >>>
> ml.org%2Flkml%2F2020%2F11%2F5%2F308&amp;data=04%7C01%7CAlexand
> er.Deu
> >>>
> cher%40amd.com%7C24731393d8ef426b573e08d9163ed4ae%7C3dd8961fe48
> 84e60
> >>>
> 8e11a82d994e183d%7C0%7C0%7C637565282618313502%7CUnknown%7CTW
> FpbGZsb3
> >>>
> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
> %3D
> >>>
> %7C2000&amp;sdata=LEOPG4tHCHYtehnG3orDvb0FBEwMBd%2FYkhhpAvBo
> nTM%3D&a
> >>> mp;reserved=0
> >>>
> >>> This is the simple fix but currently only solution to make AMD hosts
> >>> with AGP port to get a display again, as without this reverts, those
> >>> computers do not have any alternative to run a display (even not PCI
> GPUs).
> >>>
> >>> I'm asking for comments on those patches. I may have reached my own
> >>> skill cap on kernel development anyway. I can repurpose hardware to
> >>> test any other patch and can contribute time for such testing.
> >>> Unlike AGP GPUs, PCI GPUs are hard to find, so you may appreciate
> >>> the time and availability offered.
> >>>
> >>> The PCI GPU on AMD CPU issue was verified with both Nvidia (GS
> >>> 8400GS
> >>> rev.2) and ATI (Radeon HD 4350) PCI GPUs, such GPU sample not being
> >>> old cards from the previous millennial but capable
> >>> ones: TeraScale RV710 architecture on ATI side and Tesla 1.0 NV98 on
> >>> Nvidia side. They can both do OpenGL 3.3 and feature both 512M of
> >>> VRAM. The ATI one had HDMI port, and it is known some variant of the
> >>> Nvidia one (not the one I own but same specification) had HDMI port
> too.
> >>>
> >>> Also, fixing PCI GPUs may not be enough to fix AGP GPUs running as
> >>> PCI ones, since fixing some issues (not all) on PCI side raises new
> >>> issues with AGP GPUs running as PCI ones but not on native PCI GPUs
> (see below).
> >>>
> >>> Bugs aside, one thing that is important to consider against the AGP
> >>> disablement is that there is such hardware that is very capable and
> >>> not that old out there. For example the ATI Radeon HD 4670 AGP
> >>> (RV730 XT) was still sold brand new after 2010 and is a powerful and
> >>> featureful GPUs with 1GB of VRAM and HDMI port. Performance with it
> >>> is still pretty decent on competitive games. To compare with other
> >>>  open source drivers mainlined in Linux, to outperform this GPU an
> >>>  user has to get an Intel UHD 600 or an Nvidia GTX 1060 from 2016.
> >>>
> >>> Also, yet another thing that is important to consider against AGP
> >>> disablement is that if PCI Express was introduced in 2004, there was
> >>> still AGP compatible hardware being designed, produced and sold very
> >>> lately, especially on AMD side. Computers with quad core 64-bit CPUs
> >>> with virtualisation, 16GB of RAM and AGPs exist, and this is widely
> >>> distributed consumer hardware, not specific esoteric hardware.
> >>>
> >>> So, not only powerful AGP GPUs were still sold brand new in the
> >>> current decade, but there was also very capable computers to host
> >>> them. Because of those AGP computers, fixing PCI GPUs fallback is
> >>> not a solution because PCI fallback is not a solution.
> >>>
> >>
> >> For newer AGP hardware like the RV730 you point out (or anything newer
> than R300), there is no reason to run AGP mode. The on chip GART is far
> superior. The only chips where performance may be a problem is the older
> R1xx/R2xx radeons, and the issue there is more around the size of the TLB on
> the on chip GART vs the TLB in the AGP bridge. Also as Christian mentioned,
> AGP is PCI so if PCI doesn't work, you have bigger problems.
> >>
> >> Alex
> >>
> >>
> >>> All that range of hardware became unusable with that commit
> >>> disabling AGP, without alternative.
> >>>
> >>> Not only those AGP GPUs don't work with kernel's PCI fallback, but
> >>> unplugging those AGP GPUs and plugging physical PCI-native GPUs
> >>> instead does not work.
> >>>
> >>> You'll find more details about the various issues on those bugs,
> >>> I've invested multiple full time day to test and reproduce bugs on a
> >>> wide range of hardware, I've attached, quoted and commented a lot of
> logs:
> >>>
> >>> -
> >>>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbu
> >>>
> gs.launchpad.net%2Fbugs%2F1899304&amp;data=04%7C01%7CAlexander.D
> euch
> >>>
> er%40amd.com%7C24731393d8ef426b573e08d9163ed4ae%7C3dd8961fe4884
> e608e
> >>>
> 11a82d994e183d%7C0%7C0%7C637565282618313502%7CUnknown%7CTWFp
> bGZsb3d8
> >>>
> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
> D%7
> >>>
> C2000&amp;sdata=Kh1pP0j%2BNGZL9tXcCz8kU3rqhvfS%2BRfCJ8HX12%2Bg
> Mf0%3D
> >>> &amp;reserved=0
> >>>> AGP disablement leaves GPUs without working alternative (PCI
> >>>> fallback is broken), makes very-capable ATI TeraScale GPUs unusable
> >>>
> >>> -
> >>>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbu
> >>>
> gs.launchpad.net%2Fbugs%2F1902981&amp;data=04%7C01%7CAlexander.D
> euch
> >>>
> er%40amd.com%7C24731393d8ef426b573e08d9163ed4ae%7C3dd8961fe4884
> e608e
> >>>
> 11a82d994e183d%7C0%7C0%7C637565282618313502%7CUnknown%7CTWFp
> bGZsb3d8
> >>>
> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
> D%7
> >>>
> C2000&amp;sdata=Oe0vd4XdPqiqwkUYAY9UGNkZx%2BWfweCMgnkIbn5Gx
> q0%3D&amp
> >>> ;reserved=0
> >>>> AGP GPUs driven as PCI ones (when AGP is disabled at kernel build
> >>>> time) are known to fail on K8 and K10 platforms
> >>>
> >>> -
> >>>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbu
> >>>
> gs.launchpad.net%2Fbugs%2F1902795&amp;data=04%7C01%7CAlexander.D
> euch
> >>>
> er%40amd.com%7C24731393d8ef426b573e08d9163ed4ae%7C3dd8961fe4884
> e608e
> >>>
> 11a82d994e183d%7C0%7C0%7C637565282618313502%7CUnknown%7CTWFp
> bGZsb3d8
> >>>
> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
> D%7
> >>>
> C2000&amp;sdata=ddgbHRV99Xike%2F4weyiQmH9gfcmHXl21yusU9jdw6QA
> %3D&amp
> >>> ;reserved=0
> >>>> PCI graphics broken on AMD K8/K10/Piledriver platform (while it
> >>>> works on Intel) verified from Linux 4.4 to 5.10-rc2
> >>>
> >>> I wish to be personally CC'ed the answers/comments posted to the
> >>> list in response to my posting.
> >>>
> >>> Thank you for your attention.
> >>>
> >>> --
> >>> Thomas “illwieckz” Debesse

\
 
 \ /
  Last update: 2021-05-13 21:03    [W:0.125 / U:0.836 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site