Hi Christian!
Well let's face it AGP is a total headache to maintain and dead for at least 10+ years.
We have a lot of x86 specific stuff in the architecture independent graphics memory management to get the caching right, abusing the DMA API on multiple occasions, need to distinct between AGP and driver specific page tables etc etc...
AGP isn't exclusively used on x86 but there are also a lot of PowerPC desktop machines (Apple PowerMac, Pegasos etc) that employ AGP graphics.
So the idea here is to just go ahead and remove the support from Radeon and Nouveau and then drop the necessary code from TTM. For Radeon this means that we just switch over to the driver specific page tables and everything should more or less continue to work.
For Nouveau I'm not 100% sure, but from the code it of hand looks like we can do it similar to Radeon.
Please comment what you think about this.
I would be against such a move as AGP graphics is still used by people running the powerpc and ppc64 Debian ports on their vintage hardware [1].
I have also CC'ed the debian-powerpc mailing list so that other users can voice their opinion.
Thanks, Adrian
On Mon, May 11, 2020 at 4:02 PM John Paul Adrian Glaubitz glaubitz@physik.fu-berlin.de wrote:
Hi Christian!
Well let's face it AGP is a total headache to maintain and dead for at least 10+ years.
We have a lot of x86 specific stuff in the architecture independent graphics memory management to get the caching right, abusing the DMA API on multiple occasions, need to distinct between AGP and driver specific page tables etc etc...
AGP isn't exclusively used on x86 but there are also a lot of PowerPC desktop machines (Apple PowerMac, Pegasos etc) that employ AGP graphics.
So the idea here is to just go ahead and remove the support from Radeon and Nouveau and then drop the necessary code from TTM. For Radeon this means that we just switch over to the driver specific page tables and everything should more or less continue to work.
For Nouveau I'm not 100% sure, but from the code it of hand looks like we can do it similar to Radeon.
Please comment what you think about this.
I would be against such a move as AGP graphics is still used by people running the powerpc and ppc64 Debian ports on their vintage hardware [1].
I have also CC'ed the debian-powerpc mailing list so that other users can voice their opinion.
Note there is no loss of functionality here, at least on radeon hardware. It just comes down to which MMU gets used for access to system memory, the AGP MMU on the chipset or the MMU built into the GPU. On powerpc hardware, AGP has been particularly unstable, and IIRC, AGP has been disabled by default on radeon on powerpc for a while.
Alex
Thanks, Adrian
-- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz@debian.org `. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
A segunda, 11/05/2020, 21:21, Alex Deucher alexdeucher@gmail.com escreveu:
Note there is no loss of functionality here, at least on radeon hardware. It just comes down to which MMU gets used for access to system memory, the AGP MMU on the chipset or the MMU built into the GPU. On powerpc hardware, AGP has been particularly unstable, and IIRC, AGP has been disabled by default on radeon on powerpc for a while.
So this basically just drops support for the AGP GART? What happens to the AGP signalling rates (beyond the base rate)?
On Mon, May 11, 2020 at 4:25 PM Rui Salvaterra rsalvaterra@gmail.com wrote:
A segunda, 11/05/2020, 21:21, Alex Deucher alexdeucher@gmail.com escreveu:
Note there is no loss of functionality here, at least on radeon hardware. It just comes down to which MMU gets used for access to system memory, the AGP MMU on the chipset or the MMU built into the GPU. On powerpc hardware, AGP has been particularly unstable, and IIRC, AGP has been disabled by default on radeon on powerpc for a while.
So this basically just drops support for the AGP GART? What happens to the AGP signalling rates (beyond the base rate)?
I don't remember enough of the details, but I strongly doubt it was related to which MMU was used per se. On r1xx/r2xx parts, AGP was effectively the non-snooped route to memory and the internal MMU only provided snooped (coherent) access to memory. That and the limited TLB space are probably want limited performance in that case. I don't recall what sort of TLBs the chipset GART tables provided. On r3xx and newer the, on-chip MMU supported both snooped and unsnooped transactions and had more TLB space so the difference wasn't significant IIRC.
Alex
On 2020-05-11 10:51 p.m., Alex Deucher wrote:
On Mon, May 11, 2020 at 4:25 PM Rui Salvaterra rsalvaterra@gmail.com wrote:
A segunda, 11/05/2020, 21:21, Alex Deucher alexdeucher@gmail.com escreveu:
Note there is no loss of functionality here, at least on radeon hardware. It just comes down to which MMU gets used for access to system memory, the AGP MMU on the chipset or the MMU built into the GPU. On powerpc hardware, AGP has been particularly unstable, and IIRC, AGP has been disabled by default on radeon on powerpc for a while.
So this basically just drops support for the AGP GART? What happens to the AGP signalling rates (beyond the base rate)?
I don't remember enough of the details, but I strongly doubt it was related to which MMU was used per se. On r1xx/r2xx parts, AGP was effectively the non-snooped route to memory and the internal MMU only provided snooped (coherent) access to memory. That and the limited TLB space are probably want limited performance in that case. I don't recall what sort of TLBs the chipset GART tables provided. On r3xx and newer the, on-chip MMU supported both snooped and unsnooped transactions and had more TLB space so the difference wasn't significant IIRC.
FWIW, on my last-generation PowerBook with RV350 (IIRC), there was a big performance difference between AGP and PCI GART. The latter was sort of usable for normal desktop operation, but not so much for OpenGL apps (which were usable with AGP).
On Tue, 12 May 2020 at 08:58, Michel Dänzer michel@daenzer.net wrote:
FWIW, on my last-generation PowerBook with RV350 (IIRC), there was a big performance difference between AGP and PCI GART. The latter was sort of usable for normal desktop operation, but not so much for OpenGL apps (which were usable with AGP).
I never really understood what were the issues with AGP on PowerPC (well, Apple, the only ones I've tested) machines. I mean, did OS X also disable AGP entirely, or did it have workarounds somewhere else on the stack nobody was able to figure out?
Anyway, not meaning to hijack this thread, but since we're mostly on the R3xx+ hardware page, this might be a good opportunity to take a look at #389 [1] and #2780 [2] (cc'ing airlied, since he seems to have access to the hardware). I could be wrong, but it seems to be a stride calculation issue, easy enough to solve for someone familiar with the driver (which I'm not :)). This would get us usable DRI3/GLAMOR support on R3xx+ hardware.
[1] https://gitlab.freedesktop.org/mesa/mesa/-/issues/389 [2] https://gitlab.freedesktop.org/mesa/mesa/-/issues/2780
Hi,
On Tue, 12 May 2020, Rui Salvaterra wrote:
FWIW, on my last-generation PowerBook with RV350 (IIRC), there was a big performance difference between AGP and PCI GART. The latter was sort of usable for normal desktop operation, but not so much for OpenGL apps (which were usable with AGP).
I never really understood what were the issues with AGP on PowerPC (well, Apple, the only ones I've tested) machines. I mean, did OS X also disable AGP entirely, or did it have workarounds somewhere else on the stack nobody was able to figure out?
I don't know about OS X, but I doubt there is a major/blocker hardware issue, at least not one which affects every AGP machine.
MorphOS' own Radeon driver uses the AGP facilities to some degree on all AGP PowerPC Macs supported by that OS, which is from PMac AGP Graphics (3,1) all the way up to the AGP G5 (7,3), including the various portables and the Mac mini G4. For example it can utilize it to stream video data directly from mainboard RAM, so you don't have to copy it with the CPU, allowing reasonably good 720p h264 video playback on most systems above the 1Ghz mark with the native MPlayer port. I'm sure the 3D part of the driver also use it to some degree, given the performance improvement we experienced when the AGP support was enabled (initially the system was running without it), but to which extent I can't say.
Charlie
On Tue, May 12, 2020 at 5:40 AM Karoly Balogh (Charlie/SGR) charlie@scenergy.dfmk.hu wrote:
Hi,
On Tue, 12 May 2020, Rui Salvaterra wrote:
FWIW, on my last-generation PowerBook with RV350 (IIRC), there was a big performance difference between AGP and PCI GART. The latter was sort of usable for normal desktop operation, but not so much for OpenGL apps (which were usable with AGP).
I never really understood what were the issues with AGP on PowerPC (well, Apple, the only ones I've tested) machines. I mean, did OS X also disable AGP entirely, or did it have workarounds somewhere else on the stack nobody was able to figure out?
I don't know about OS X, but I doubt there is a major/blocker hardware issue, at least not one which affects every AGP machine.
MorphOS' own Radeon driver uses the AGP facilities to some degree on all AGP PowerPC Macs supported by that OS, which is from PMac AGP Graphics (3,1) all the way up to the AGP G5 (7,3), including the various portables and the Mac mini G4. For example it can utilize it to stream video data directly from mainboard RAM, so you don't have to copy it with the CPU, allowing reasonably good 720p h264 video playback on most systems above the 1Ghz mark with the native MPlayer port. I'm sure the 3D part of the driver also use it to some degree, given the performance improvement we experienced when the AGP support was enabled (initially the system was running without it), but to which extent I can't say.
The problem is AGP doesn't support CPU cache snooping. Technically PCI must support coherent device access to system memory. Unsnooped access is an optional feature and some platforms may not support it at all. Unfortunately, AGP required unsnooped access. x8t generally provides a way to do this, but other platforms, not so much. I don't recall to what extent PowerPC supported this. The Linux DMA API doesn't really have a way to get uncached memory for DMA so there is that too. Windows and Mac may provide a way to do this depending on the platforms. What probably should have been done on AGP boards was to use both the AGP GART and the device GART. The former for uncached memory (if the platform supported it) and the latter for cached memory. That never happened.
Alex
On Tue, May 12, 2020 at 3:22 PM Alex Deucher alexdeucher@gmail.com wrote:
On Tue, May 12, 2020 at 5:40 AM Karoly Balogh (Charlie/SGR) charlie@scenergy.dfmk.hu wrote:
Hi,
On Tue, 12 May 2020, Rui Salvaterra wrote:
FWIW, on my last-generation PowerBook with RV350 (IIRC), there was a big performance difference between AGP and PCI GART. The latter was sort of usable for normal desktop operation, but not so much for OpenGL apps (which were usable with AGP).
I never really understood what were the issues with AGP on PowerPC (well, Apple, the only ones I've tested) machines. I mean, did OS X also disable AGP entirely, or did it have workarounds somewhere else on the stack nobody was able to figure out?
I don't know about OS X, but I doubt there is a major/blocker hardware issue, at least not one which affects every AGP machine.
MorphOS' own Radeon driver uses the AGP facilities to some degree on all AGP PowerPC Macs supported by that OS, which is from PMac AGP Graphics (3,1) all the way up to the AGP G5 (7,3), including the various portables and the Mac mini G4. For example it can utilize it to stream video data directly from mainboard RAM, so you don't have to copy it with the CPU, allowing reasonably good 720p h264 video playback on most systems above the 1Ghz mark with the native MPlayer port. I'm sure the 3D part of the driver also use it to some degree, given the performance improvement we experienced when the AGP support was enabled (initially the system was running without it), but to which extent I can't say.
The problem is AGP doesn't support CPU cache snooping. Technically PCI must support coherent device access to system memory. Unsnooped access is an optional feature and some platforms may not support it at all. Unfortunately, AGP required unsnooped access. x8t generally provides a way to do this, but other platforms, not so much. I don't recall to what extent PowerPC supported this. The Linux DMA API doesn't really have a way to get uncached memory for DMA so there is that too. Windows and Mac may provide a way to do this depending on the platforms. What probably should have been done on AGP boards was to use both the AGP GART and the device GART. The former for uncached memory (if the platform supported it) and the latter for cached memory. That never happened.
Slight correction on the dma-api side of things: The dma-api very much can give you uncached memory, but only on some platforms, and the dma-api is very opinionated about which those are. And it refuses to tell you whether your memory ends up being uncached or cached. That's all done in the name of platform portability, which is good for most drivers, but just too much pain for gpu drivers.
Otherwise all agree, agp is a mighty mess and essentially just crapshot outside of x86. It kinda worked for the much more static allocations for dri1, but with in-kernel memory managers all the cache flushing issues showed up big time and it all fell to pieces. Plus a lot of these host chipset back then where designed for the rather static windows gpu managers, so even on x86 the coherency issues for agp mode when used together with ttm or something else really dynamic is pretty bad because the hw just doesn't really cope and has all kinds of flushing troubles and races. I think the later agp chipsets were better. -Daniel
On Tue, 12 May 2020 at 17:38, Daniel Vetter daniel@ffwll.ch wrote:
Otherwise all agree, agp is a mighty mess and essentially just crapshot outside of x86. It kinda worked for the much more static allocations for dri1, but with in-kernel memory managers all the cache flushing issues showed up big time and it all fell to pieces. Plus a lot of these host chipset back then where designed for the rather static windows gpu managers, so even on x86 the coherency issues for agp mode when used together with ttm or something else really dynamic is pretty bad because the hw just doesn't really cope and has all kinds of flushing troubles and races. I think the later agp chipsets were better.
That was rather insightful, thanks. I was starting to doubt my own memory, as I was almost sure I never had any hangs with AGP on PowerPC before KMS was a thing. But even on x86, I distinctly remember never being able to get sideband addressing working with any AGP cards, my system would randomly hang too. I'm starting to believe AGP was shoehorned into PCI the same way VLB was shoehorned into ISA (and for the same reason). History repeats itself… :)
On Tue, May 12, 2020 at 1:02 PM Rui Salvaterra rsalvaterra@gmail.com wrote:
On Tue, 12 May 2020 at 17:38, Daniel Vetter daniel@ffwll.ch wrote:
Otherwise all agree, agp is a mighty mess and essentially just crapshot outside of x86. It kinda worked for the much more static allocations for dri1, but with in-kernel memory managers all the cache flushing issues showed up big time and it all fell to pieces. Plus a lot of these host chipset back then where designed for the rather static windows gpu managers, so even on x86 the coherency issues for agp mode when used together with ttm or something else really dynamic is pretty bad because the hw just doesn't really cope and has all kinds of flushing troubles and races. I think the later agp chipsets were better.
That was rather insightful, thanks. I was starting to doubt my own memory, as I was almost sure I never had any hangs with AGP on PowerPC before KMS was a thing. But even on x86, I distinctly remember never being able to get sideband addressing working with any AGP cards, my system would randomly hang too. I'm starting to believe AGP was shoehorned into PCI the same way VLB was shoehorned into ISA (and for the same reason). History repeats itself… :)
Pre-KMS, the kernel just allocated a static relatively small (e.g., 8 MB) AGP buffer which never changed. In that case, things were somewhat more reliable.
Alex
On Wed, 13 May 2020 at 04:21, Alex Deucher alexdeucher@gmail.com wrote:
On Tue, May 12, 2020 at 1:02 PM Rui Salvaterra rsalvaterra@gmail.com wrote:
On Tue, 12 May 2020 at 17:38, Daniel Vetter daniel@ffwll.ch wrote:
Otherwise all agree, agp is a mighty mess and essentially just crapshot outside of x86. It kinda worked for the much more static allocations for dri1, but with in-kernel memory managers all the cache flushing issues showed up big time and it all fell to pieces. Plus a lot of these host chipset back then where designed for the rather static windows gpu managers, so even on x86 the coherency issues for agp mode when used together with ttm or something else really dynamic is pretty bad because the hw just doesn't really cope and has all kinds of flushing troubles and races. I think the later agp chipsets were better.
That was rather insightful, thanks. I was starting to doubt my own memory, as I was almost sure I never had any hangs with AGP on PowerPC before KMS was a thing. But even on x86, I distinctly remember never being able to get sideband addressing working with any AGP cards, my system would randomly hang too. I'm starting to believe AGP was shoehorned into PCI the same way VLB was shoehorned into ISA (and for the same reason). History repeats itself… :)
Pre-KMS, the kernel just allocated a static relatively small (e.g., 8 MB) AGP buffer which never changed. In that case, things were somewhat more reliable.
This is why the AGP hw on Macs has issues I believe. It was designed and only tested around the one static early allocation, I'm not sure OSX ever did dynamic.
When it went dynamic I think the AGP bits had some problems with coherency of the GART tables that we never figured out.
Dave.
Am 12.05.20 um 22:12 schrieb Dave Airlie:
On Wed, 13 May 2020 at 04:21, Alex Deucher alexdeucher@gmail.com wrote:
On Tue, May 12, 2020 at 1:02 PM Rui Salvaterra rsalvaterra@gmail.com wrote:
On Tue, 12 May 2020 at 17:38, Daniel Vetter daniel@ffwll.ch wrote:
Otherwise all agree, agp is a mighty mess and essentially just crapshot outside of x86. It kinda worked for the much more static allocations for dri1, but with in-kernel memory managers all the cache flushing issues showed up big time and it all fell to pieces. Plus a lot of these host chipset back then where designed for the rather static windows gpu managers, so even on x86 the coherency issues for agp mode when used together with ttm or something else really dynamic is pretty bad because the hw just doesn't really cope and has all kinds of flushing troubles and races. I think the later agp chipsets were better.
That was rather insightful, thanks. I was starting to doubt my own memory, as I was almost sure I never had any hangs with AGP on PowerPC before KMS was a thing. But even on x86, I distinctly remember never being able to get sideband addressing working with any AGP cards, my system would randomly hang too. I'm starting to believe AGP was shoehorned into PCI the same way VLB was shoehorned into ISA (and for the same reason). History repeats itself… :)
Pre-KMS, the kernel just allocated a static relatively small (e.g., 8 MB) AGP buffer which never changed. In that case, things were somewhat more reliable.
This is why the AGP hw on Macs has issues I believe. It was designed and only tested around the one static early allocation, I'm not sure OSX ever did dynamic.
When it went dynamic I think the AGP bits had some problems with coherency of the GART tables that we never figured out.
To make things even worse AGP used two different voltages in the standard. Before 2002 only 3.3V was used, after 2002 this got reduced to 1.5V.
To avoid frying the new cards in the old boards or other way around you had a notch at a different place depending on the voltage. Unfortunately quite a bunch of manufacturers didn't got that right.
So it wasn't just problematic on the software level, but had a rather bad hardware specification as well.
Christian.
Dave.
On Tue, May 12, 2020 at 12:38 PM Daniel Vetter daniel@ffwll.ch wrote:
On Tue, May 12, 2020 at 3:22 PM Alex Deucher alexdeucher@gmail.com wrote:
On Tue, May 12, 2020 at 5:40 AM Karoly Balogh (Charlie/SGR) charlie@scenergy.dfmk.hu wrote:
Hi,
On Tue, 12 May 2020, Rui Salvaterra wrote:
FWIW, on my last-generation PowerBook with RV350 (IIRC), there was a big performance difference between AGP and PCI GART. The latter was sort of usable for normal desktop operation, but not so much for OpenGL apps (which were usable with AGP).
I never really understood what were the issues with AGP on PowerPC (well, Apple, the only ones I've tested) machines. I mean, did OS X also disable AGP entirely, or did it have workarounds somewhere else on the stack nobody was able to figure out?
I don't know about OS X, but I doubt there is a major/blocker hardware issue, at least not one which affects every AGP machine.
MorphOS' own Radeon driver uses the AGP facilities to some degree on all AGP PowerPC Macs supported by that OS, which is from PMac AGP Graphics (3,1) all the way up to the AGP G5 (7,3), including the various portables and the Mac mini G4. For example it can utilize it to stream video data directly from mainboard RAM, so you don't have to copy it with the CPU, allowing reasonably good 720p h264 video playback on most systems above the 1Ghz mark with the native MPlayer port. I'm sure the 3D part of the driver also use it to some degree, given the performance improvement we experienced when the AGP support was enabled (initially the system was running without it), but to which extent I can't say.
The problem is AGP doesn't support CPU cache snooping. Technically PCI must support coherent device access to system memory. Unsnooped access is an optional feature and some platforms may not support it at all. Unfortunately, AGP required unsnooped access. x8t generally provides a way to do this, but other platforms, not so much. I don't recall to what extent PowerPC supported this. The Linux DMA API doesn't really have a way to get uncached memory for DMA so there is that too. Windows and Mac may provide a way to do this depending on the platforms. What probably should have been done on AGP boards was to use both the AGP GART and the device GART. The former for uncached memory (if the platform supported it) and the latter for cached memory. That never happened.
Slight correction on the dma-api side of things: The dma-api very much can give you uncached memory, but only on some platforms, and the dma-api is very opinionated about which those are. And it refuses to tell you whether your memory ends up being uncached or cached. That's all done in the name of platform portability, which is good for most drivers, but just too much pain for gpu drivers.
Out of curiosity how do you do that without manually messing around with PAT or MTRRs?
Alex
Otherwise all agree, agp is a mighty mess and essentially just crapshot outside of x86. It kinda worked for the much more static allocations for dri1, but with in-kernel memory managers all the cache flushing issues showed up big time and it all fell to pieces. Plus a lot of these host chipset back then where designed for the rather static windows gpu managers, so even on x86 the coherency issues for agp mode when used together with ttm or something else really dynamic is pretty bad because the hw just doesn't really cope and has all kinds of flushing troubles and races. I think the later agp chipsets were better.
-Daniel
Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
On Tue, May 12, 2020 at 8:22 PM Alex Deucher alexdeucher@gmail.com wrote:
On Tue, May 12, 2020 at 12:38 PM Daniel Vetter daniel@ffwll.ch wrote:
On Tue, May 12, 2020 at 3:22 PM Alex Deucher alexdeucher@gmail.com wrote:
On Tue, May 12, 2020 at 5:40 AM Karoly Balogh (Charlie/SGR) charlie@scenergy.dfmk.hu wrote:
Hi,
On Tue, 12 May 2020, Rui Salvaterra wrote:
FWIW, on my last-generation PowerBook with RV350 (IIRC), there was a big performance difference between AGP and PCI GART. The latter was sort of usable for normal desktop operation, but not so much for OpenGL apps (which were usable with AGP).
I never really understood what were the issues with AGP on PowerPC (well, Apple, the only ones I've tested) machines. I mean, did OS X also disable AGP entirely, or did it have workarounds somewhere else on the stack nobody was able to figure out?
I don't know about OS X, but I doubt there is a major/blocker hardware issue, at least not one which affects every AGP machine.
MorphOS' own Radeon driver uses the AGP facilities to some degree on all AGP PowerPC Macs supported by that OS, which is from PMac AGP Graphics (3,1) all the way up to the AGP G5 (7,3), including the various portables and the Mac mini G4. For example it can utilize it to stream video data directly from mainboard RAM, so you don't have to copy it with the CPU, allowing reasonably good 720p h264 video playback on most systems above the 1Ghz mark with the native MPlayer port. I'm sure the 3D part of the driver also use it to some degree, given the performance improvement we experienced when the AGP support was enabled (initially the system was running without it), but to which extent I can't say.
The problem is AGP doesn't support CPU cache snooping. Technically PCI must support coherent device access to system memory. Unsnooped access is an optional feature and some platforms may not support it at all. Unfortunately, AGP required unsnooped access. x8t generally provides a way to do this, but other platforms, not so much. I don't recall to what extent PowerPC supported this. The Linux DMA API doesn't really have a way to get uncached memory for DMA so there is that too. Windows and Mac may provide a way to do this depending on the platforms. What probably should have been done on AGP boards was to use both the AGP GART and the device GART. The former for uncached memory (if the platform supported it) and the latter for cached memory. That never happened.
Slight correction on the dma-api side of things: The dma-api very much can give you uncached memory, but only on some platforms, and the dma-api is very opinionated about which those are. And it refuses to tell you whether your memory ends up being uncached or cached. That's all done in the name of platform portability, which is good for most drivers, but just too much pain for gpu drivers.
Out of curiosity how do you do that without manually messing around with PAT or MTRRs?
i915 is even worse, we manually mess around with clflush. In userspace. So really there's 2 axis for dma memory: coherent vs. non-coherent (which is something the dma-api somewhat exposed), i.e. do you need to clflush or not, and cached vs uncached, i.e. are the PAT entries wc or wb.
But yeah if you dont have PAT real uncached isn't possible, can't frob MTTR for individual pages. That also, to my understanding, why the dma api doesn't want to expose this to driver, but abstract it all away: On many tiny soc platforms all you have for uncached is an mttr (well the equivalent on that platform), so you anything you get from dma_alloc_coherent needs to come from there.
But then no one is ever going to plug in a big gpu into such a system and expect anything to work, so we really need an abstraction that works on a bit more than just x86 (so we don't dig around in platform stuff like updating PAT or issusing clflush anymore), but doesn't try to work everywhere linux runs, just on the few platforms people expect big gpus to work on. For all the kms-only drivers we have the dma api seems actually perfectly fine (essentially the cma helpes we have should be called dma helpers, since that's what they're using underneath for all buffer management).
Cheers, Daniel
Alex
Otherwise all agree, agp is a mighty mess and essentially just crapshot outside of x86. It kinda worked for the much more static allocations for dri1, but with in-kernel memory managers all the cache flushing issues showed up big time and it all fell to pieces. Plus a lot of these host chipset back then where designed for the rather static windows gpu managers, so even on x86 the coherency issues for agp mode when used together with ttm or something else really dynamic is pretty bad because the hw just doesn't really cope and has all kinds of flushing troubles and races. I think the later agp chipsets were better.
-Daniel
Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
Am 13.05.20 um 09:19 schrieb Daniel Vetter:
On Tue, May 12, 2020 at 8:22 PM Alex Deucher alexdeucher@gmail.com wrote:
On Tue, May 12, 2020 at 12:38 PM Daniel Vetter daniel@ffwll.ch wrote:
On Tue, May 12, 2020 at 3:22 PM Alex Deucher alexdeucher@gmail.com wrote:
On Tue, May 12, 2020 at 5:40 AM Karoly Balogh (Charlie/SGR) charlie@scenergy.dfmk.hu wrote:
Hi,
On Tue, 12 May 2020, Rui Salvaterra wrote:
> FWIW, on my last-generation PowerBook with RV350 (IIRC), there was a > big performance difference between AGP and PCI GART. The latter was > sort of usable for normal desktop operation, but not so much for > OpenGL apps (which were usable with AGP). I never really understood what were the issues with AGP on PowerPC (well, Apple, the only ones I've tested) machines. I mean, did OS X also disable AGP entirely, or did it have workarounds somewhere else on the stack nobody was able to figure out?
I don't know about OS X, but I doubt there is a major/blocker hardware issue, at least not one which affects every AGP machine.
MorphOS' own Radeon driver uses the AGP facilities to some degree on all AGP PowerPC Macs supported by that OS, which is from PMac AGP Graphics (3,1) all the way up to the AGP G5 (7,3), including the various portables and the Mac mini G4. For example it can utilize it to stream video data directly from mainboard RAM, so you don't have to copy it with the CPU, allowing reasonably good 720p h264 video playback on most systems above the 1Ghz mark with the native MPlayer port. I'm sure the 3D part of the driver also use it to some degree, given the performance improvement we experienced when the AGP support was enabled (initially the system was running without it), but to which extent I can't say.
The problem is AGP doesn't support CPU cache snooping. Technically PCI must support coherent device access to system memory. Unsnooped access is an optional feature and some platforms may not support it at all. Unfortunately, AGP required unsnooped access. x8t generally provides a way to do this, but other platforms, not so much. I don't recall to what extent PowerPC supported this. The Linux DMA API doesn't really have a way to get uncached memory for DMA so there is that too. Windows and Mac may provide a way to do this depending on the platforms. What probably should have been done on AGP boards was to use both the AGP GART and the device GART. The former for uncached memory (if the platform supported it) and the latter for cached memory. That never happened.
Slight correction on the dma-api side of things: The dma-api very much can give you uncached memory, but only on some platforms, and the dma-api is very opinionated about which those are. And it refuses to tell you whether your memory ends up being uncached or cached. That's all done in the name of platform portability, which is good for most drivers, but just too much pain for gpu drivers.
Out of curiosity how do you do that without manually messing around with PAT or MTRRs?
i915 is even worse, we manually mess around with clflush. In userspace. So really there's 2 axis for dma memory: coherent vs. non-coherent (which is something the dma-api somewhat exposed), i.e. do you need to clflush or not, and cached vs uncached, i.e. are the PAT entries wc or wb.
But yeah if you dont have PAT real uncached isn't possible, can't frob MTTR for individual pages. That also, to my understanding, why the dma api doesn't want to expose this to driver, but abstract it all away: On many tiny soc platforms all you have for uncached is an mttr (well the equivalent on that platform), so you anything you get from dma_alloc_coherent needs to come from there.
IIRC I once got it explained like this: On some platforms all you have a register with a value and if your address is above that value it is uncached and wc if it is below it is cached and wb.
But then no one is ever going to plug in a big gpu into such a system and expect anything to work, so we really need an abstraction that works on a bit more than just x86 (so we don't dig around in platform stuff like updating PAT or issusing clflush anymore), but doesn't try to work everywhere linux runs, just on the few platforms people expect big gpus to work on. For all the kms-only drivers we have the dma api seems actually perfectly fine (essentially the cma helpes we have should be called dma helpers, since that's what they're using underneath for all buffer management).
That is unfortunately not true for AMD GPUs, people tend to put them into those embedded ARM or PowerPC boxes and just expect them to work.
On the other hand we have hardware/firmware engineers which assumed you always have USWC and we wonder for weeks why firmware loaded doesn't work....
Regards, Christian.
Cheers, Daniel
Alex
Otherwise all agree, agp is a mighty mess and essentially just crapshot outside of x86. It kinda worked for the much more static allocations for dri1, but with in-kernel memory managers all the cache flushing issues showed up big time and it all fell to pieces. Plus a lot of these host chipset back then where designed for the rather static windows gpu managers, so even on x86 the coherency issues for agp mode when used together with ttm or something else really dynamic is pretty bad because the hw just doesn't really cope and has all kinds of flushing troubles and races. I think the later agp chipsets were better.
-Daniel
Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
On Wed, May 13, 2020 at 9:55 AM Christian König ckoenig.leichtzumerken@gmail.com wrote:
Am 13.05.20 um 09:19 schrieb Daniel Vetter:
On Tue, May 12, 2020 at 8:22 PM Alex Deucher alexdeucher@gmail.com wrote:
On Tue, May 12, 2020 at 12:38 PM Daniel Vetter daniel@ffwll.ch wrote:
On Tue, May 12, 2020 at 3:22 PM Alex Deucher alexdeucher@gmail.com wrote:
On Tue, May 12, 2020 at 5:40 AM Karoly Balogh (Charlie/SGR) charlie@scenergy.dfmk.hu wrote:
Hi,
On Tue, 12 May 2020, Rui Salvaterra wrote:
>> FWIW, on my last-generation PowerBook with RV350 (IIRC), there was a >> big performance difference between AGP and PCI GART. The latter was >> sort of usable for normal desktop operation, but not so much for >> OpenGL apps (which were usable with AGP). > I never really understood what were the issues with AGP on PowerPC > (well, Apple, the only ones I've tested) machines. I mean, did OS X also > disable AGP entirely, or did it have workarounds somewhere else on the > stack nobody was able to figure out? I don't know about OS X, but I doubt there is a major/blocker hardware issue, at least not one which affects every AGP machine.
MorphOS' own Radeon driver uses the AGP facilities to some degree on all AGP PowerPC Macs supported by that OS, which is from PMac AGP Graphics (3,1) all the way up to the AGP G5 (7,3), including the various portables and the Mac mini G4. For example it can utilize it to stream video data directly from mainboard RAM, so you don't have to copy it with the CPU, allowing reasonably good 720p h264 video playback on most systems above the 1Ghz mark with the native MPlayer port. I'm sure the 3D part of the driver also use it to some degree, given the performance improvement we experienced when the AGP support was enabled (initially the system was running without it), but to which extent I can't say.
The problem is AGP doesn't support CPU cache snooping. Technically PCI must support coherent device access to system memory. Unsnooped access is an optional feature and some platforms may not support it at all. Unfortunately, AGP required unsnooped access. x8t generally provides a way to do this, but other platforms, not so much. I don't recall to what extent PowerPC supported this. The Linux DMA API doesn't really have a way to get uncached memory for DMA so there is that too. Windows and Mac may provide a way to do this depending on the platforms. What probably should have been done on AGP boards was to use both the AGP GART and the device GART. The former for uncached memory (if the platform supported it) and the latter for cached memory. That never happened.
Slight correction on the dma-api side of things: The dma-api very much can give you uncached memory, but only on some platforms, and the dma-api is very opinionated about which those are. And it refuses to tell you whether your memory ends up being uncached or cached. That's all done in the name of platform portability, which is good for most drivers, but just too much pain for gpu drivers.
Out of curiosity how do you do that without manually messing around with PAT or MTRRs?
i915 is even worse, we manually mess around with clflush. In userspace. So really there's 2 axis for dma memory: coherent vs. non-coherent (which is something the dma-api somewhat exposed), i.e. do you need to clflush or not, and cached vs uncached, i.e. are the PAT entries wc or wb.
But yeah if you dont have PAT real uncached isn't possible, can't frob MTTR for individual pages. That also, to my understanding, why the dma api doesn't want to expose this to driver, but abstract it all away: On many tiny soc platforms all you have for uncached is an mttr (well the equivalent on that platform), so you anything you get from dma_alloc_coherent needs to come from there.
IIRC I once got it explained like this: On some platforms all you have a register with a value and if your address is above that value it is uncached and wc if it is below it is cached and wb.
But then no one is ever going to plug in a big gpu into such a system and expect anything to work, so we really need an abstraction that works on a bit more than just x86 (so we don't dig around in platform stuff like updating PAT or issusing clflush anymore), but doesn't try to work everywhere linux runs, just on the few platforms people expect big gpus to work on. For all the kms-only drivers we have the dma api seems actually perfectly fine (essentially the cma helpes we have should be called dma helpers, since that's what they're using underneath for all buffer management).
That is unfortunately not true for AMD GPUs, people tend to put them into those embedded ARM or PowerPC boxes and just expect them to work.
I thought arm64 had proper PAT-style per-page caching attributes, because servers don't like the hard split with the address limit or whatever other unflexible trickery. But not sure.
And ppc I thought was defacto always coherent, at least on modern machines.
But yeah the older stuff is pure horrors. The problem is also that afaik arm defaults to uncached (and on some arm platforms it's impossible to get a wc/coherent mapping of a random system page) and ppc defaults to cached&coherent. So we can't even have a reasonable default for non-x86.
On the other hand we have hardware/firmware engineers which assumed you always have USWC and we wonder for weeks why firmware loaded doesn't work....
Fun. -Daniel
Regards, Christian.
Cheers, Daniel
Alex
Otherwise all agree, agp is a mighty mess and essentially just crapshot outside of x86. It kinda worked for the much more static allocations for dri1, but with in-kernel memory managers all the cache flushing issues showed up big time and it all fell to pieces. Plus a lot of these host chipset back then where designed for the rather static windows gpu managers, so even on x86 the coherency issues for agp mode when used together with ttm or something else really dynamic is pretty bad because the hw just doesn't really cope and has all kinds of flushing troubles and races. I think the later agp chipsets were better.
-Daniel
Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
On Wed, 13 May 2020 at 08:19, Daniel Vetter daniel@ffwll.ch wrote:
i915 is even worse, we manually mess around with clflush. In userspace. So really there's 2 axis for dma memory: coherent vs. non-coherent (which is something the dma-api somewhat exposed), i.e. do you need to clflush or not, and cached vs uncached, i.e. are the PAT entries wc or wb.
So, the PowerPC AGP GART ends up being cached and non-coherent, right (assuming there's no way to set the page attributes MTRR/PAT-style)? Would something like a fixed memory carve-out help in these cases (like CMA, but not allowing the CPU to access the reserved area)? Not that I expect something like that to ever be implemented, of course, just curious to understand the requirements.
On 2020-05-13 11:28 a.m., Rui Salvaterra wrote:
On Wed, 13 May 2020 at 08:19, Daniel Vetter daniel@ffwll.ch wrote:
i915 is even worse, we manually mess around with clflush. In userspace. So really there's 2 axis for dma memory: coherent vs. non-coherent (which is something the dma-api somewhat exposed), i.e. do you need to clflush or not, and cached vs uncached, i.e. are the PAT entries wc or wb.
So, the PowerPC AGP GART ends up being cached and non-coherent, right (assuming there's no way to set the page attributes MTRR/PAT-style)?
It was uncached when I was using my last-gen PowerBook (until a few years ago), though it's possible that broke since then. I don't remember the details how it's done offhand though.
The only theoretical problem there was that the kernel still had a cacheable mapping of the same memory, and any access via that (e.g. prefetch due to access to a neighbouring page) could trigger a machine check. But I don't remember ever hitting that. Maybe I was just lucky all those years.
On Wed, May 13, 2020 at 12:26 PM Michel Dänzer michel@daenzer.net wrote:
On 2020-05-13 11:28 a.m., Rui Salvaterra wrote:
On Wed, 13 May 2020 at 08:19, Daniel Vetter daniel@ffwll.ch wrote:
i915 is even worse, we manually mess around with clflush. In userspace. So really there's 2 axis for dma memory: coherent vs. non-coherent (which is something the dma-api somewhat exposed), i.e. do you need to clflush or not, and cached vs uncached, i.e. are the PAT entries wc or wb.
So, the PowerPC AGP GART ends up being cached and non-coherent, right (assuming there's no way to set the page attributes MTRR/PAT-style)?
It was uncached when I was using my last-gen PowerBook (until a few years ago), though it's possible that broke since then. I don't remember the details how it's done offhand though.
The only theoretical problem there was that the kernel still had a cacheable mapping of the same memory, and any access via that (e.g. prefetch due to access to a neighbouring page) could trigger a machine check. But I don't remember ever hitting that. Maybe I was just lucky all those years.
At least on arm this has been a big topic, since it indeed randomly kills machines. That's why you can't remap random pages as wc, they have to be in highmem. I thought ppc is equally easily angered. And the trouble is that just the existance of the mapping is enough to cause a machine check exception iirc. So down to pure luck. -Daniel
On 2020-05-13 12:29 p.m., Daniel Vetter wrote:
On Wed, May 13, 2020 at 12:26 PM Michel Dänzer michel@daenzer.net wrote:
On 2020-05-13 11:28 a.m., Rui Salvaterra wrote:
On Wed, 13 May 2020 at 08:19, Daniel Vetter daniel@ffwll.ch wrote:
i915 is even worse, we manually mess around with clflush. In userspace. So really there's 2 axis for dma memory: coherent vs. non-coherent (which is something the dma-api somewhat exposed), i.e. do you need to clflush or not, and cached vs uncached, i.e. are the PAT entries wc or wb.
So, the PowerPC AGP GART ends up being cached and non-coherent, right (assuming there's no way to set the page attributes MTRR/PAT-style)?
It was uncached when I was using my last-gen PowerBook (until a few years ago), though it's possible that broke since then. I don't remember the details how it's done offhand though.
The only theoretical problem there was that the kernel still had a cacheable mapping of the same memory, and any access via that (e.g. prefetch due to access to a neighbouring page) could trigger a machine check. But I don't remember ever hitting that. Maybe I was just lucky all those years.
At least on arm this has been a big topic, since it indeed randomly kills machines. That's why you can't remap random pages as wc, they have to be in highmem. I thought ppc is equally easily angered. And the trouble is that just the existance of the mapping is enough to cause a machine check exception iirc. So down to pure luck.
Either myself and others were very lucky then with PowerMacs, or it's not actually that bad.
On Wed, 13 May 2020 at 11:27, Michel Dänzer michel@daenzer.net wrote:
The only theoretical problem there was that the kernel still had a cacheable mapping of the same memory, and any access via that (e.g. prefetch due to access to a neighbouring page) could trigger a machine check. But I don't remember ever hitting that. Maybe I was just lucky all those years.
If that's the issue, I assure you nowadays you can hit it quite reliably, at least on my iBook G4. (Which, by the way is also hanging randomly on 5.7-rc5, for apparently unrelated reasons; I haven't bisected yet, but fortunately I can do it on the G5 while keeping what's left of my sanity.)
On 2020-05-13 12:39 p.m., Rui Salvaterra wrote:
On Wed, 13 May 2020 at 11:27, Michel Dänzer michel@daenzer.net wrote:
The only theoretical problem there was that the kernel still had a cacheable mapping of the same memory, and any access via that (e.g. prefetch due to access to a neighbouring page) could trigger a machine check. But I don't remember ever hitting that. Maybe I was just lucky all those years.
If that's the issue, I assure you nowadays you can hit it quite reliably, at least on my iBook G4.
How do you know you're hitting that particular issue?
On Wed, 13 May 2020 at 11:58, Michel Dänzer michel@daenzer.net wrote:
How do you know you're hitting that particular issue?
Sorry, somehow I misread that. I was still thinking of the AGP hangs.
Hi All,
AGP mode/support is deactivated on PowerPC and it doesn't work reliable????
And what does these lines mean:
PowerMac G5 Dual:
OpenGL vendor string: DRI R300 Project OpenGL renderer string: Mesa DRI R300 (RV350 4152) 20090101 AGP 8x PowerPC 64/Altivec TCL OpenGL version string: 1.5 Mesa 7.6
Mac Mini G4:
OpenGL vendor string: Tungsten Graphics. Inc. OpenGL renderer string: Mesa DRI R200 20060602 AGP 4x PowerPC/Altivec TCL OpenGL version string: 1.3 Mesa 7.2
Screenshots:
- http://www.supertuxkart.de/stk07ubuntu910ppc.png - http://www.supertuxkart.de/opensuse111-stk073.jpg
Cheers, Christian
Hello Christian!
On 5/13/20 3:44 PM, Christian Zigotzky wrote:
AGP mode/support is deactivated on PowerPC and it doesn't work reliable????
And what does these lines mean:
AGP mode is actually disabled in the Radeon driver for PowerPC as Alex has pointed out earlier in this thread [1]. Your graphics cards are basically running in PCI mode.
I don't know, however, what the performance impact is when AGP mode is turned off. But it was turned off because it made PowerPC systems unstable.
It also seems that AGP mode poses an additional maintenance burden for the KMS/DRM maintainers of the kernel so I understand the reasoning behind such a change.
I wonder though whether it would make sense to move the support for older GPUs in legacy drivers, similar to what nVidia does with their commercial drivers.
Thanks, Adrian
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i... [2] https://bugs.freedesktop.org/show_bug.cgi?id=95017
On Wed, 13 May 2020 at 14:44, Christian Zigotzky chzigotzky@xenosoft.de wrote:
OpenGL version string: 1.5 Mesa 7.6 OpenGL version string: 1.3 Mesa 7.2
Screenshots:
Those are *extremely old* (and I mean over ten years old) kernels and userspaces. Of course old UMS distros will work fine. Try installing the current Debian powerpc (on the G4) and ppc64 (on the G5) ports and force-enable AGP on the Radeon kernel driver (radeon.agpmode=0), you'll understand what we mean by "unstable". ;)
Mine is not so old : debian jessie, with kms and agp mode enabled. 3D works reliably and is very stable on this powerbook G4 1,67 and radeon 9700. It's not bug free, mostly endianess problems with colors. Not all programm using 3D work, but kodi does very well. Overall, the whole interface (mate) is much more fluid than without 3D acceleration. Without it i slow.
I didn't install latest unstable yet because this system is very stable and enjoyable. I did it on a powermac G5 and could'nt enable agp mode because of a bug in the driver (already reported here). Without AGP mode, mate is painfully slow.
Le mer. 13 mai 2020 à 16:02, Rui Salvaterra rsalvaterra@gmail.com a écrit :
On Wed, 13 May 2020 at 14:44, Christian Zigotzky chzigotzky@xenosoft.de wrote:
OpenGL version string: 1.5 Mesa 7.6 OpenGL version string: 1.3 Mesa 7.2
Screenshots:
Those are *extremely old* (and I mean over ten years old) kernels and userspaces. Of course old UMS distros will work fine. Try installing the current Debian powerpc (on the G4) and ppc64 (on the G5) ports and force-enable AGP on the Radeon kernel driver (radeon.agpmode=0), you'll understand what we mean by "unstable". ;)
On Wed, 13 May 2020 at 21:20, Bertrand Dekoninck bertrand.dekoninck@gmail.com wrote:
Mine is not so old : debian jessie, with kms and agp mode enabled. 3D works reliably and is very stable on this powerbook G4 1,67 and radeon 9700. It's not bug free, mostly endianess problems with colors. Not all programm using 3D work, but kodi does very well.
Linux 3.16 is still painfully old, I'm sorry to say. Below is a screenshot of my system.
I didn't install latest unstable yet because this system is very stable and enjoyable. I did it on a powermac G5 and could'nt enable agp mode because of a bug in the driver (already reported here). Without AGP mode, mate is painfully slow.
Debian Sid is very stable, in my experience, as long as you know what you're doing.
On 5/11/20 10:05 PM, Alex Deucher wrote:
For Nouveau I'm not 100% sure, but from the code it of hand looks like we can do it similar to Radeon.
Please comment what you think about this.
I would be against such a move as AGP graphics is still used by people running the powerpc and ppc64 Debian ports on their vintage hardware [1].
I have also CC'ed the debian-powerpc mailing list so that other users can voice their opinion.
Note there is no loss of functionality here, at least on radeon hardware. It just comes down to which MMU gets used for access to system memory, the AGP MMU on the chipset or the MMU built into the GPU. On powerpc hardware, AGP has been particularly unstable, and IIRC, AGP has been disabled by default on radeon on powerpc for a while.
Do you have a code reference at hand for this bit of information (AGP being disabled on Macs)?
Thanks, Adrian
On Mon, May 11, 2020 at 4:41 PM John Paul Adrian Glaubitz glaubitz@physik.fu-berlin.de wrote:
On 5/11/20 10:05 PM, Alex Deucher wrote:
For Nouveau I'm not 100% sure, but from the code it of hand looks like we can do it similar to Radeon.
Please comment what you think about this.
I would be against such a move as AGP graphics is still used by people running the powerpc and ppc64 Debian ports on their vintage hardware [1].
I have also CC'ed the debian-powerpc mailing list so that other users can voice their opinion.
Note there is no loss of functionality here, at least on radeon hardware. It just comes down to which MMU gets used for access to system memory, the AGP MMU on the chipset or the MMU built into the GPU. On powerpc hardware, AGP has been particularly unstable, and IIRC, AGP has been disabled by default on radeon on powerpc for a while.
Do you have a code reference at hand for this bit of information (AGP being disabled on Macs)?
It was disabled 2 years ago: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i...
Alex
Thanks, Adrian
-- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz@debian.org `. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Hi Alex!
On 5/11/20 10:46 PM, Alex Deucher wrote:
Note there is no loss of functionality here, at least on radeon hardware. It just comes down to which MMU gets used for access to system memory, the AGP MMU on the chipset or the MMU built into the GPU. On powerpc hardware, AGP has been particularly unstable, and IIRC, AGP has been disabled by default on radeon on powerpc for a while.
Do you have a code reference at hand for this bit of information (AGP being disabled on Macs)?
It was disabled 2 years ago: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i...
Ok, that makes less dramatic then than I initially thought.
I would still like to collect some voices from the debian-powerpc list though and maybe some comments from other directions.
In any case, I agree with Christian's stance that if the code is supposed to be removed, it should be deprecated first.
Adrian
Am 11.05.20 um 22:46 schrieb Alex Deucher:
On Mon, May 11, 2020 at 4:41 PM John Paul Adrian Glaubitz glaubitz@physik.fu-berlin.de wrote:
On 5/11/20 10:05 PM, Alex Deucher wrote:
For Nouveau I'm not 100% sure, but from the code it of hand looks like we can do it similar to Radeon.
Please comment what you think about this.
I would be against such a move as AGP graphics is still used by people running the powerpc and ppc64 Debian ports on their vintage hardware [1].
I have also CC'ed the debian-powerpc mailing list so that other users can voice their opinion.
Note there is no loss of functionality here, at least on radeon hardware. It just comes down to which MMU gets used for access to system memory, the AGP MMU on the chipset or the MMU built into the GPU. On powerpc hardware, AGP has been particularly unstable, and IIRC, AGP has been disabled by default on radeon on powerpc for a while.
Do you have a code reference at hand for this bit of information (AGP being disabled on Macs)?
It was disabled 2 years ago: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i...
To be honest from the hacks we have in there to get this working I'm even surprised that this ever worked at all on PowerPC.
Going to extend this patch for now and add a config option to not compile in AGP GART support for TTM any more instead of removing it.
Christian.
Alex
Thanks, Adrian
-- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz@debian.org `. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Am 11.05.20 um 21:55 schrieb John Paul Adrian Glaubitz:
Hi Christian!
Well let's face it AGP is a total headache to maintain and dead for at least 10+ years.
We have a lot of x86 specific stuff in the architecture independent graphics memory management to get the caching right, abusing the DMA API on multiple occasions, need to distinct between AGP and driver specific page tables etc etc...
AGP isn't exclusively used on x86 but there are also a lot of PowerPC desktop machines (Apple PowerMac, Pegasos etc) that employ AGP graphics.
I unfortunately only have an x86 Mac to test this on, but as far as I know the Radeon AGP support for PowerPC is disabled for years already because it didn't worked reliable.
So the idea here is to just go ahead and remove the support from Radeon and Nouveau and then drop the necessary code from TTM. For Radeon this means that we just switch over to the driver specific page tables and everything should more or less continue to work.
For Nouveau I'm not 100% sure, but from the code it of hand looks like we can do it similar to Radeon.
Please comment what you think about this.
I would be against such a move as AGP graphics is still used by people running the powerpc and ppc64 Debian ports on their vintage hardware [1].
Please note that at least the Mac I was able to test with Radeon hardware just continuous to work. But it is certainly possible that some pre r3xx generation hardware will break with this.
We just stop using this bogus idea of trying to use uncached system memory as "extension" of the on board video memory and instead switch to the reliable device internal GART.
Maybe we should just deprecate the configuration option first?
I have also CC'ed the debian-powerpc mailing list so that other users can voice their opinion.
Thanks for that.
Regards, Christian.
Thanks, Adrian
On 5/11/20 10:12 PM, Christian König wrote:
I unfortunately only have an x86 Mac to test this on, but as far as I know the Radeon AGP support for PowerPC is disabled for years already because it didn't worked reliable.
I have a current Debian unstable running on an iBook G4 with Radeon graphics enabled on a current kernel and graphics stack and it runs fine. Not sure though whether it currently employs all AGP features, but I would like to be able to continue using it and so are the users on the debian-powerpc mailing list.
So the idea here is to just go ahead and remove the support from Radeon and Nouveau and then drop the necessary code from TTM. For Radeon this means that we just switch over to the driver specific page tables and everything should more or less continue to work.
For Nouveau I'm not 100% sure, but from the code it of hand looks like we can do it similar to Radeon.
Please comment what you think about this.
I would be against such a move as AGP graphics is still used by people running the powerpc and ppc64 Debian ports on their vintage hardware [1].
Please note that at least the Mac I was able to test with Radeon hardware just continuous to work. But it is certainly possible that some pre r3xx generation hardware will break with this.
We just stop using this bogus idea of trying to use uncached system memory as "extension" of the on board video memory and instead switch to the reliable device internal GART.
Well, the title "Remove AGP support" in the subject implied something else to me which is why I wrote this mail. If this just applies to the mechanism to allow system memory to be used as graphics memory, the results may be different.
Maybe we should just deprecate the configuration option first?
Would this change imply the removal of CONFIG_AGP_*? If yes, I assume that would kill CONFIG_AGP_UNINORTH which we have enabled on our PowerPC kernels for powerpc and ppc64.
Adrian
Am 11.05.20 um 22:24 schrieb John Paul Adrian Glaubitz:
On 5/11/20 10:12 PM, Christian König wrote:
I unfortunately only have an x86 Mac to test this on, but as far as I know the Radeon AGP support for PowerPC is disabled for years already because it didn't worked reliable.
I have a current Debian unstable running on an iBook G4 with Radeon graphics enabled on a current kernel and graphics stack and it runs fine. Not sure though whether it currently employs all AGP features, but I would like to be able to continue using it and so are the users on the debian-powerpc mailing list.
I didn't have much luck with agp_uninorth and radeon DRM on my MacMini G4 (2xx) with current Debian unstable (yet have to send an installation report, sorry!). The X server didn't even come up with AGP enabled. The only thing that works is, if the radeon driver is forced to use PCIGART, which was even the default after install, if I remember correctly. Problem is that graphics acceleration over PCI is very, very slow... :-(
So the idea here is to just go ahead and remove the support from Radeon and Nouveau and then drop the necessary code from TTM. For Radeon this means that we just switch over to the driver specific page tables and everything should more or less continue to work.
For Nouveau I'm not 100% sure, but from the code it of hand looks like we can do it similar to Radeon.
Please comment what you think about this.
I would be against such a move as AGP graphics is still used by people running the powerpc and ppc64 Debian ports on their vintage hardware [1].
Please note that at least the Mac I was able to test with Radeon hardware just continuous to work. But it is certainly possible that some pre r3xx generation hardware will break with this.
We just stop using this bogus idea of trying to use uncached system memory as "extension" of the on board video memory and instead switch to the reliable device internal GART.
Well, the title "Remove AGP support" in the subject implied something else to me which is why I wrote this mail. If this just applies to the mechanism to allow system memory to be used as graphics memory, the results may be different.
I was also following the discussion about AGP some time ago on the PowerPC Linux mailing list and honestly also understood it in the way that AGP would be entirely removed. :-)
But I guess what is planned is to use the radeon/TTM drivers PCIGART functionality while preserving the setup of the fast AGP transfer modes (maybe by using a static AGPGART, if necessary?). Is that what Linux developers have in mind with "Remove AGP support"?
Maybe we should just deprecate the configuration option first?
Would this change imply the removal of CONFIG_AGP_*? If yes, I assume that would kill CONFIG_AGP_UNINORTH which we have enabled on our PowerPC kernels for powerpc and ppc64.
Adrian
Gerhard
I have also CC'ed the debian-powerpc mailing list so that other users can voice their opinion.
Hello,
Im happy now that after your work, Debian and GRUB install fine on my iMac G3. But Xserver doesn't start, I've got an AMD Rage 128 Pro AGP 4x (see joined screenshot).
Hi David!
On 5/12/20 7:04 AM, David VANTYGHEM wrote:
Im happy now that after your work, Debian and GRUB install fine on my iMac G3. But Xserver doesn't start, I've got an AMD Rage 128 Pro AGP 4x (see joined screenshot).
This is an unrelated problem as the reason why you don't have a working graphics driver at the moment is because Debian's X.org maintainers removed a couple of older drivers from the package archive - without knowing these drivers are still used by PowerPC users.
I will take over package maintainership of these drivers soon and re-upload them to the Debian archive.
Adrian
dri-devel@lists.freedesktop.org
-
Alex Deucher -
Bertrand Dekoninck -
Christian König -
Christian Zigotzky -
Daniel Vetter -
Dave Airlie -
David VANTYGHEM -
Gerhard Pircher -
John Paul Adrian Glaubitz -
Karoly Balogh (Charlie/SGR) -
Michel Dänzer -
Rui Salvaterra