subject:"\[RFC\] Remove AGP support from Radeon\/Nouveau\/TTM"

On Wed, 13 May 2020 at 14:44, Christian Zigotzky  wrote:
>
> OpenGL version string: 1.5 Mesa 7.6
> OpenGL version string: 1.3 Mesa 7.2
>
> Screenshots:
>
> - http://www.supertuxkart.de/stk07ubuntu910ppc.png
> - http://www.supertuxkart.de/opensuse111-stk073.jpg

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". ;)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC] Remove AGP support from Radeon/Nouveau/TTM

On Wed, 13 May 2020 at 11:58, Michel Dänzer  wrote:
>
> How do you know you're hitting that particular issue?

Sorry, somehow I misread that. I was still thinking of the AGP hangs.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC] Remove AGP support from Radeon/Nouveau/TTM

On Wed, 13 May 2020 at 08:19, Daniel Vetter  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.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC] Remove AGP support from Radeon/Nouveau/TTM

On Wed, 13 May 2020 at 11:27, Michel Dänzer  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.)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC] Remove AGP support from Radeon/Nouveau/TTM

2020-05-13 Thread John Paul Adrian Glaubitz

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/?id=037d1a66ae640ca2723f47c0115ffa9e603699b3
> [2] https://bugs.freedesktop.org/show_bug.cgi?id=95017

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@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

Re: [Nouveau] [RFC] Remove AGP support from Radeon/Nouveau/TTM

2020-05-13 Thread Thomas Zimmermann

Hi

Am 13.05.20 um 11:27 schrieb Emil Velikov:
> On Tue, 12 May 2020 at 20:48, Alex Deucher  wrote:
> 
>
> There's some AGP support code in the DRM core. Can some of that declared
> as legacy?
>
> Specifically, what about these AGP-related ioctl calls? Can they be
> declared as legacy? It would appear to me that KMS-based drivers don't
> have to manage AGP by themselves. (?)

 The old drm core AGP code is mainly (only?) for the non-KMS drivers.
 E.g., mach64, r128, sis, savage, etc.
>>>
>>> Exactly my point. There's one drm_agp_init() call left in radeon. The
>>> rest of the AGP code is apparently for legacy non-KMS drivers. Should
>>> the related ioctl calls be declared as legacy (i.e., listed with
>>> DRM_LEGACY_IOCTL_DEF instead of DRM_IOCTL_DEF)? If so, much of the AGP
>>> core code could probably be moved behind CONFIG_DRM_LEGACY as well.
>>
>> Ah, I forgot about drm_agp_init().  I was just thinking the other AGP
>> stuff.  Yeah, I think we could make it legacy.
>>
> Fwiw I've got local patches a) removing drm_agp_init() from radeon and
> b) making the core drm code legacy only.
> Will try to finish them over the weekend and send out.
> 
> Even if AGP GART gets dropped the b) patches will be good ;-)

Fantastic! Please see one of my other comments in this thread. There's
still drm_agp_init() somewhere in radeon_drv.c. So patch a) might still
be useful.

Best regards
Thomas

> 
> -Emil
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer



signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Nouveau] [RFC] Remove AGP support from Radeon/Nouveau/TTM

2020-05-13 Thread Thomas Zimmermann

Hi

Am 11.05.20 um 19:17 schrieb Christian König:
> Hi guys,
> 
> 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...
> 
> 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.

It's probably not much of a problem in practice.

I guess everyone who plays 3d games has upgraded to something newer.

Wrt desktops, I found that some components of modern desktops (KDE,
Gnome) now have a hard requirement on SSE2. [1][2] But AGP is mostly
used in old 32-bit systems, which don't have SSE2.* So remaining users
of the GART functionality probably don't use any of these desktops.

The simpler WMs are usually usable with only little VRAM. At least they
should not be hit by any performance penalty.

Best regards
Thomas

[1] https://bugzilla.opensuse.org/show_bug.cgi?id=1162283
[2] https://bugzilla.opensuse.org/show_bug.cgi?id=1077870

* First-generation Athlon 64 have SSE2 and AGP support. But there are
few systems. Around that time AGP was replaced by PCIe.

> 
> Regards,
> Christian.
> 
> 
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer



signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC] Remove AGP support from Radeon/Nouveau/TTM

2020-05-13 Thread Michel Dänzer

On 2020-05-13 12:39 p.m., Rui Salvaterra wrote:
> On Wed, 13 May 2020 at 11:27, Michel Dänzer  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?


-- 
Earthling Michel Dänzer   |   https://redhat.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC] Remove AGP support from Radeon/Nouveau/TTM

2020-05-13 Thread Michel Dänzer

On 2020-05-13 12:29 p.m., Daniel Vetter wrote:
> On Wed, May 13, 2020 at 12:26 PM Michel Dänzer  wrote:
>>
>> On 2020-05-13 11:28 a.m., Rui Salvaterra wrote:
>>> On Wed, 13 May 2020 at 08:19, Daniel Vetter  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.


-- 
Earthling Michel Dänzer   |   https://redhat.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC] Remove AGP support from Radeon/Nouveau/TTM

2020-05-13 Thread Daniel Vetter

On Wed, May 13, 2020 at 12:26 PM Michel Dänzer  wrote:
>
> On 2020-05-13 11:28 a.m., Rui Salvaterra wrote:
> > On Wed, 13 May 2020 at 08:19, Daniel Vetter  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
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC] Remove AGP support from Radeon/Nouveau/TTM

2020-05-13 Thread Michel Dänzer

On 2020-05-13 11:28 a.m., Rui Salvaterra wrote:
> On Wed, 13 May 2020 at 08:19, Daniel Vetter  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.

-- 
Earthling Michel Dänzer   |   https://redhat.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC] Remove AGP support from Radeon/Nouveau/TTM

2020-05-13 Thread Daniel Vetter

On Wed, May 13, 2020 at 9:55 AM Christian König
 wrote:
>
> Am 13.05.20 um 09:19 schrieb Daniel Vetter:
> > On Tue, May 12, 2020 at 8:22 PM Alex Deucher  wrote:
> >> On Tue, May 12, 2020 at 12:38 PM Daniel Vetter  wrote:
> >>> On Tue, May 12, 2020 at 3:22 PM Alex Deucher  
> >>> wrote:
>  On Tue, May 12, 2020 at 5:40 AM Karoly Balogh (Charlie/SGR)
>   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 emb

Re: [Nouveau] [RFC] Remove AGP support from Radeon/Nouveau/TTM

2020-05-13 Thread Emil Velikov

On Tue, 12 May 2020 at 20:48, Alex Deucher  wrote:

> > >>
> > >> There's some AGP support code in the DRM core. Can some of that declared
> > >> as legacy?
> > >>
> > >> Specifically, what about these AGP-related ioctl calls? Can they be
> > >> declared as legacy? It would appear to me that KMS-based drivers don't
> > >> have to manage AGP by themselves. (?)
> > >
> > > The old drm core AGP code is mainly (only?) for the non-KMS drivers.
> > > E.g., mach64, r128, sis, savage, etc.
> >
> > Exactly my point. There's one drm_agp_init() call left in radeon. The
> > rest of the AGP code is apparently for legacy non-KMS drivers. Should
> > the related ioctl calls be declared as legacy (i.e., listed with
> > DRM_LEGACY_IOCTL_DEF instead of DRM_IOCTL_DEF)? If so, much of the AGP
> > core code could probably be moved behind CONFIG_DRM_LEGACY as well.
>
> Ah, I forgot about drm_agp_init().  I was just thinking the other AGP
> stuff.  Yeah, I think we could make it legacy.
>
Fwiw I've got local patches a) removing drm_agp_init() from radeon and
b) making the core drm code legacy only.
Will try to finish them over the weekend and send out.

Even if AGP GART gets dropped the b) patches will be good ;-)

-Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC] Remove AGP support from Radeon/Nouveau/TTM

2020-05-13 Thread Karoly Balogh (Charlie/SGR)

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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC] Remove AGP support from Radeon/Nouveau/TTM

2020-05-13 Thread Rui Salvaterra

On Tue, 12 May 2020 at 08:58, Michel Dänzer  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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC] Remove AGP support from Radeon/Nouveau/TTM

2020-05-13 Thread Rui Salvaterra

On Tue, 12 May 2020 at 17:38, Daniel Vetter  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… :)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC] Remove AGP support from Radeon/Nouveau/TTM

2020-05-13 Thread Christian König


Am 13.05.20 um 09:19 schrieb Daniel Vetter:

On Tue, May 12, 2020 at 8:22 PM Alex Deucher  wrote:

On Tue, May 12, 2020 at 12:38 PM Daniel Vetter  wrote:

On Tue, May 12, 2020 at 3:22 PM Alex Deucher  wrote:

On Tue, May 12, 2020 at 5:40 AM Karoly Balogh (Charlie/SGR)
 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
l

Re: [RFC] Remove AGP support from Radeon/Nouveau/TTM

2020-05-13 Thread Christian König


Am 12.05.20 um 22:12 schrieb Dave Airlie:

On Wed, 13 May 2020 at 04:21, Alex Deucher  wrote:

On Tue, May 12, 2020 at 1:02 PM Rui Salvaterra  wrote:

On Tue, 12 May 2020 at 17:38, Daniel Vetter  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.


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC] Remove AGP support from Radeon/Nouveau/TTM

2020-05-13 Thread Daniel Vetter

On Tue, May 12, 2020 at 8:22 PM Alex Deucher  wrote:
>
> On Tue, May 12, 2020 at 12:38 PM Daniel Vetter  wrote:
> >
> > On Tue, May 12, 2020 at 3:22 PM Alex Deucher  wrote:
> > >
> > > On Tue, May 12, 2020 at 5:40 AM Karoly Balogh (Charlie/SGR)
> > >  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
>

Re: [RFC] Remove AGP support from Radeon/Nouveau/TTM

2020-05-12 Thread Dave Airlie

On Wed, 13 May 2020 at 04:21, Alex Deucher  wrote:
>
> On Tue, May 12, 2020 at 1:02 PM Rui Salvaterra  wrote:
> >
> > On Tue, 12 May 2020 at 17:38, Daniel Vetter  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.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Nouveau] [RFC] Remove AGP support from Radeon/Nouveau/TTM

On Tue, May 12, 2020 at 3:10 PM Thomas Zimmermann  wrote:
>
> Hi Alex
>
> Am 12.05.20 um 20:32 schrieb Alex Deucher:
> > On Tue, May 12, 2020 at 2:29 PM Thomas Zimmermann  
> > wrote:
> >>
> >> Hi
> >>
> >> Am 11.05.20 um 19:17 schrieb Christian König:
> >>> Hi guys,
> >>>
> >>> 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...
> >>>
> >>> 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.
> >>
> >> There's some AGP support code in the DRM core. Can some of that declared
> >> as legacy?
> >>
> >> Specifically, what about these AGP-related ioctl calls? Can they be
> >> declared as legacy? It would appear to me that KMS-based drivers don't
> >> have to manage AGP by themselves. (?)
> >
> > The old drm core AGP code is mainly (only?) for the non-KMS drivers.
> > E.g., mach64, r128, sis, savage, etc.
>
> Exactly my point. There's one drm_agp_init() call left in radeon. The
> rest of the AGP code is apparently for legacy non-KMS drivers. Should
> the related ioctl calls be declared as legacy (i.e., listed with
> DRM_LEGACY_IOCTL_DEF instead of DRM_IOCTL_DEF)? If so, much of the AGP
> core code could probably be moved behind CONFIG_DRM_LEGACY as well.

Ah, I forgot about drm_agp_init().  I was just thinking the other AGP
stuff.  Yeah, I think we could make it legacy.

Alex


>
> Best regards
> Thomas
>
> >
> > Alex
> >
> >>
> >> Best regards
> >> Thomas
> >>
> >>>
> >>> Regards,
> >>> Christian.
> >>>
> >>>
> >>> ___
> >>> Nouveau mailing list
> >>> nouv...@lists.freedesktop.org
> >>> https://lists.freedesktop.org/mailman/listinfo/nouveau
> >>>
> >>
> >> --
> >> Thomas Zimmermann
> >> Graphics Driver Developer
> >> SUSE Software Solutions Germany GmbH
> >> Maxfeldstr. 5, 90409 Nürnberg, Germany
> >> (HRB 36809, AG Nürnberg)
> >> Geschäftsführer: Felix Imendörffer
> >>
> >> ___
> >> amd-gfx mailing list
> >> amd-...@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Felix Imendörffer
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Nouveau] [RFC] Remove AGP support from Radeon/Nouveau/TTM

2020-05-12 Thread Thomas Zimmermann

Hi Alex

Am 12.05.20 um 20:32 schrieb Alex Deucher:
> On Tue, May 12, 2020 at 2:29 PM Thomas Zimmermann  wrote:
>>
>> Hi
>>
>> Am 11.05.20 um 19:17 schrieb Christian König:
>>> Hi guys,
>>>
>>> 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...
>>>
>>> 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.
>>
>> There's some AGP support code in the DRM core. Can some of that declared
>> as legacy?
>>
>> Specifically, what about these AGP-related ioctl calls? Can they be
>> declared as legacy? It would appear to me that KMS-based drivers don't
>> have to manage AGP by themselves. (?)
> 
> The old drm core AGP code is mainly (only?) for the non-KMS drivers.
> E.g., mach64, r128, sis, savage, etc.

Exactly my point. There's one drm_agp_init() call left in radeon. The
rest of the AGP code is apparently for legacy non-KMS drivers. Should
the related ioctl calls be declared as legacy (i.e., listed with
DRM_LEGACY_IOCTL_DEF instead of DRM_IOCTL_DEF)? If so, much of the AGP
core code could probably be moved behind CONFIG_DRM_LEGACY as well.

Best regards
Thomas

> 
> Alex
> 
>>
>> Best regards
>> Thomas
>>
>>>
>>> Regards,
>>> Christian.
>>>
>>>
>>> ___
>>> Nouveau mailing list
>>> nouv...@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/nouveau
>>>
>>
>> --
>> Thomas Zimmermann
>> Graphics Driver Developer
>> SUSE Software Solutions Germany GmbH
>> Maxfeldstr. 5, 90409 Nürnberg, Germany
>> (HRB 36809, AG Nürnberg)
>> Geschäftsführer: Felix Imendörffer
>>
>> ___
>> amd-gfx mailing list
>> amd-...@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer



signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Nouveau] [RFC] Remove AGP support from Radeon/Nouveau/TTM

On Tue, May 12, 2020 at 2:29 PM Thomas Zimmermann  wrote:
>
> Hi
>
> Am 11.05.20 um 19:17 schrieb Christian König:
> > Hi guys,
> >
> > 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...
> >
> > 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.
>
> There's some AGP support code in the DRM core. Can some of that declared
> as legacy?
>
> Specifically, what about these AGP-related ioctl calls? Can they be
> declared as legacy? It would appear to me that KMS-based drivers don't
> have to manage AGP by themselves. (?)

The old drm core AGP code is mainly (only?) for the non-KMS drivers.
E.g., mach64, r128, sis, savage, etc.

Alex

>
> Best regards
> Thomas
>
> >
> > Regards,
> > Christian.
> >
> >
> > ___
> > Nouveau mailing list
> > nouv...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/nouveau
> >
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Felix Imendörffer
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Nouveau] [RFC] Remove AGP support from Radeon/Nouveau/TTM

2020-05-12 Thread Thomas Zimmermann

Hi

Am 11.05.20 um 19:17 schrieb Christian König:
> Hi guys,
> 
> 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...
> 
> 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.

There's some AGP support code in the DRM core. Can some of that declared
as legacy?

Specifically, what about these AGP-related ioctl calls? Can they be
declared as legacy? It would appear to me that KMS-based drivers don't
have to manage AGP by themselves. (?)

Best regards
Thomas

> 
> Regards,
> Christian.
> 
> 
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer



signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC] Remove AGP support from Radeon/Nouveau/TTM

On Tue, May 12, 2020 at 12:38 PM Daniel Vetter  wrote:
>
> On Tue, May 12, 2020 at 3:22 PM Alex Deucher  wrote:
> >
> > On Tue, May 12, 2020 at 5:40 AM Karoly Balogh (Charlie/SGR)
> >  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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC] Remove AGP support from Radeon/Nouveau/TTM

On Tue, May 12, 2020 at 1:02 PM Rui Salvaterra  wrote:
>
> On Tue, 12 May 2020 at 17:38, Daniel Vetter  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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC] Remove AGP support from Radeon/Nouveau/TTM

2020-05-12 Thread Daniel Vetter

On Tue, May 12, 2020 at 3:22 PM Alex Deucher  wrote:
>
> On Tue, May 12, 2020 at 5:40 AM Karoly Balogh (Charlie/SGR)
>  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
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC] Remove AGP support from Radeon/Nouveau/TTM

On Tue, May 12, 2020 at 5:40 AM Karoly Balogh (Charlie/SGR)
 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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC] Remove AGP support from Radeon/Nouveau/TTM

2020-05-12 Thread John Paul Adrian Glaubitz

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

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@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

Re: [RFC] Remove AGP support from Radeon/Nouveau/TTM

2020-05-12 Thread Christian König


Am 11.05.20 um 22:56 schrieb Al Dunsmuir:

Hello Dave,

On Monday, May 11, 2020, 4:43:01 PM, Dave Airlie wrote:

On Tue, 12 May 2020 at 06:28, Alex Deucher  wrote:

[SNIP]

Maybe we can find some way to compartmentalise AGP further?
Dave.

Significantly   reduced  caching  on memory accesses definitely sounds
like something that would be noticeable and objectionable.

I would speculate that this would also vary a lot across chipsets,
depending on the capabilities of the PCI MMU vs the AGP MMU.

In the end, it may be best to leave things as is, or as Dave suggested
try to keep AGP in the picture.


The problem is that AGP was never really supported/implemented that well 
in the first place.


The fact that the core linux kernel and the DMA API doesn't support 
uncached memory and we had to change the caching attributes of pages 
under the hood has resulted in a huge number of problems over the years.


Keeping it as it is is also not a really doable option because TTM 
already has major problems keeping up with the requirements for modern 
hardware, see my presentation here as well: 
https://fosdem.org/2020/schedule/event/ttm/


Redesigning the old AGP support into something which isn't so ugly and 
doesn't blocks the new requirements has the huge risk of breaking things 
even harder, e.g. black screen instead of just reduced performance.


So removing/disabling AGP by default still sounds like the best option 
to me for end users.



Nothing is ever simple, is it?


At least not with AGP, no :) It has been a total beast to support and 
keep working.


Do I get this right that I can ping you to test things?

Thanks for the feedback,
Christian.


Al




___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC] Remove AGP support from Radeon/Nouveau/TTM

2020-05-12 Thread Michel Dänzer

On 2020-05-11 10:51 p.m., Alex Deucher wrote:
> On Mon, May 11, 2020 at 4:25 PM Rui Salvaterra  wrote:
>> A segunda, 11/05/2020, 21:21, Alex Deucher  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).


-- 
Earthling Michel Dänzer   |   https://redhat.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC] Remove AGP support from Radeon/Nouveau/TTM

2020-05-12 Thread Christian König

Am 11.05.20 um 22:46 schrieb Alex Deucher:

On Mon, May 11, 2020 at 4:41 PM John Paul Adrian Glaubitz
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/?id=037d1a66ae640ca2723f47c0115ffa9e603699b3

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 - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@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

Re: [RFC] Remove AGP support from Radeon/Nouveau/TTM

2020-05-11 Thread Gerhard Pircher

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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC] Remove AGP support from Radeon/Nouveau/TTM

2020-05-11 Thread Rui Salvaterra

A segunda, 11/05/2020, 21:21, Alex Deucher  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)?

>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC] Remove AGP support from Radeon/Nouveau/TTM

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/?id=037d1a66ae640ca2723f47c0115ffa9e603699b3

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

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@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

Re: [RFC] Remove AGP support from Radeon/Nouveau/TTM

2020-05-11 Thread Emil Velikov

On Mon, 11 May 2020 at 21:43, Dave Airlie  wrote:
>
> On Tue, 12 May 2020 at 06:28, Alex Deucher  wrote:
> >
> > On Mon, May 11, 2020 at 4:22 PM Al Dunsmuir  
> > wrote:
> > >
> > > On Monday, May 11, 2020, 1:17:19 PM, "Christian König" wrote:
> > > > Hi guys,
> > >
> > > > 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...
> > >
> > > > 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.
> > >
> > > > Regards,
> > > > Christian.
> > >
> > > Christian,
> > >
> > > I would respectfully ask that this change be rejected.
> > >
> > > I'm  currently  an  end user on both Intel (32-bit and 64-bit) and PPC
> > > (Macs, IBM Power - BE and LE).
> > >
> > > Linux is not just used for modern hardware. There is also a subset of
> > > the user base that uses it for what is often termed retro-computing.
> > > No it's not commercial usage, but no one can seriously claim that that
> > > Linux is for business only.
> > >
> > > Often the old hardware is built far batter than the modern junk, and
> > > will continue to run for years to come. This group of folks either has
> > > existing hardware they wish to continue to use, or are acquiring the
> > > same because they are tired of generic locked-down hardware.
> > >
> > > A significant percentage of the video hardware that falls in the retro
> > > category uses the AGP video bus. Removing that support for those cases
> > > where it works would severely limit performance and in some cases
> > > functionality. This can mean the difference between being able to run
> > > an application, or having it fail.
> > >
> >
> > 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 AGP
> > has been disabled by default on radeon on powerpc for years now.  In
> > fact, this will probably make older hardware more reliable as it takes
> > AGP out of the equation.
> >
>
> From memory there is quite a loss in speed though, like pretty severe.
>
> The radeon PCI GART has a single slot TLB, if memory serves.
>
> I think this is going to be a hard sell at this stage, I'm guessing
> users will crawl out of the woodwork, I'm sure with 2 hours after I'm
> able to access the office, I can boot the 865 AGP box with an rv350 in
> it on a modern distro.
>
I have a system with nforce2 motherboard and Nvidia fx5500 GPU. I
could dust it off and some quick performance tests over the weekend.

Unless someone beats me to it, of course :-)

-Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC] Remove AGP support from Radeon/Nouveau/TTM

2020-05-11 Thread Al Dunsmuir

Hello Dave,

On Monday, May 11, 2020, 4:43:01 PM, Dave Airlie wrote:
> On Tue, 12 May 2020 at 06:28, Alex Deucher  wrote:
>>
>> On Mon, May 11, 2020 at 4:22 PM Al Dunsmuir  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 AGP
>> has been disabled by default on radeon on powerpc for years now.  In
>> fact, this will probably make older hardware more reliable as it takes
>> AGP out of the equation.
>>

> From memory there is quite a loss in speed though, like pretty severe.

> The radeon PCI GART has a single slot TLB, if memory serves.

> I think this is going to be a hard sell at this stage, I'm guessing
> users will crawl out of the woodwork, I'm sure with 2 hours after I'm
> able to access the office, I can boot the 865 AGP box with an rv350 in
> it on a modern distro.

> Maybe we can find some way to compartmentalise AGP further?

> Dave.

Significantly   reduced  caching  on memory accesses definitely sounds
like something that would be noticeable and objectionable.

I would speculate that this would also vary a lot across chipsets,
depending on the capabilities of the PCI MMU vs the AGP MMU.

In the end, it may be best to leave things as is, or as Dave suggested
try to keep AGP in the picture.  

Nothing is ever simple, is it?
Al


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC] Remove AGP support from Radeon/Nouveau/TTM

On Mon, May 11, 2020 at 4:25 PM Rui Salvaterra  wrote:
>
>
>
> A segunda, 11/05/2020, 21:21, Alex Deucher  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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC] Remove AGP support from Radeon/Nouveau/TTM

2020-05-11 Thread Al Dunsmuir

On Monday, May 11, 2020, 4:27:55 PM, Alex Deucher wrote:
> On Mon, May 11, 2020 at 4:22 PM Al Dunsmuir  wrote:
>>
>> On Monday, May 11, 2020, 1:17:19 PM, "Christian König" wrote:
>> > Hi guys,
>>
>> > 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...
>>
>> > 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.

> 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 AGP
> has been disabled by default on radeon on powerpc for years now.  In
> fact, this will probably make older hardware more reliable as it takes
> AGP out of the equation.

Alex,

Thanks for the clarification.

If the actual performance impact is little to none, and we end up with
more reliable operation that is certainly beneficial then the change
is indeed for the good.

The  Phoronix  title screaming "AGP Graphics Card Support Proposed For
Removal  From  Linux  Radeon/NVIDIA Drivers" was neither accurate, nor
helpful.

Al

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC] Remove AGP support from Radeon/Nouveau/TTM

On Mon, May 11, 2020 at 4:41 PM John Paul Adrian Glaubitz
 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/?id=037d1a66ae640ca2723f47c0115ffa9e603699b3

Alex

>
> Thanks,
> Adrian
>
> --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaub...@debian.org
> `. `'   Freie Universitaet Berlin - glaub...@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

Re: [RFC] Remove AGP support from Radeon/Nouveau/TTM

2020-05-11 Thread Dave Airlie

On Tue, 12 May 2020 at 06:28, Alex Deucher  wrote:
>
> On Mon, May 11, 2020 at 4:22 PM Al Dunsmuir  wrote:
> >
> > On Monday, May 11, 2020, 1:17:19 PM, "Christian König" wrote:
> > > Hi guys,
> >
> > > 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...
> >
> > > 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.
> >
> > > Regards,
> > > Christian.
> >
> > Christian,
> >
> > I would respectfully ask that this change be rejected.
> >
> > I'm  currently  an  end user on both Intel (32-bit and 64-bit) and PPC
> > (Macs, IBM Power - BE and LE).
> >
> > Linux is not just used for modern hardware. There is also a subset of
> > the user base that uses it for what is often termed retro-computing.
> > No it's not commercial usage, but no one can seriously claim that that
> > Linux is for business only.
> >
> > Often the old hardware is built far batter than the modern junk, and
> > will continue to run for years to come. This group of folks either has
> > existing hardware they wish to continue to use, or are acquiring the
> > same because they are tired of generic locked-down hardware.
> >
> > A significant percentage of the video hardware that falls in the retro
> > category uses the AGP video bus. Removing that support for those cases
> > where it works would severely limit performance and in some cases
> > functionality. This can mean the difference between being able to run
> > an application, or having it fail.
> >
>
> 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 AGP
> has been disabled by default on radeon on powerpc for years now.  In
> fact, this will probably make older hardware more reliable as it takes
> AGP out of the equation.
>

From memory there is quite a loss in speed though, like pretty severe.

The radeon PCI GART has a single slot TLB, if memory serves.

I think this is going to be a hard sell at this stage, I'm guessing
users will crawl out of the woodwork, I'm sure with 2 hours after I'm
able to access the office, I can boot the 865 AGP box with an rv350 in
it on a modern distro.

Maybe we can find some way to compartmentalise AGP further?

Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC] Remove AGP support from Radeon/Nouveau/TTM

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

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@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

Re: [RFC] Remove AGP support from Radeon/Nouveau/TTM

On Mon, May 11, 2020 at 4:22 PM Al Dunsmuir  wrote:
>
> On Monday, May 11, 2020, 1:17:19 PM, "Christian König" wrote:
> > Hi guys,
>
> > 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...
>
> > 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.
>
> > Regards,
> > Christian.
>
> Christian,
>
> I would respectfully ask that this change be rejected.
>
> I'm  currently  an  end user on both Intel (32-bit and 64-bit) and PPC
> (Macs, IBM Power - BE and LE).
>
> Linux is not just used for modern hardware. There is also a subset of
> the user base that uses it for what is often termed retro-computing.
> No it's not commercial usage, but no one can seriously claim that that
> Linux is for business only.
>
> Often the old hardware is built far batter than the modern junk, and
> will continue to run for years to come. This group of folks either has
> existing hardware they wish to continue to use, or are acquiring the
> same because they are tired of generic locked-down hardware.
>
> A significant percentage of the video hardware that falls in the retro
> category uses the AGP video bus. Removing that support for those cases
> where it works would severely limit performance and in some cases
> functionality. This can mean the difference between being able to run
> an application, or having it fail.
>

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 AGP
has been disabled by default on radeon on powerpc for years now.  In
fact, this will probably make older hardware more reliable as it takes
AGP out of the equation.

Alex


> There are multiple active Linux distributions for PPC Macs. Many folks
> are moving from running an original Mac OS X because of the recent
> migration of most Web services to new encryption protocols (TLS 1.2,
> SSL, etc.) which can not be practically supported by browsers on that
> OS - even the open source ones. Linux on that same hardware provides
> the opportunity to work online with current protocols and ensure that
> they are reasonably secure.
>
> Another group that fits in the retro category is those folks with
> older PC hardware who are not migrating to the latest Microsoft OS,
> but instead want to move to Linux.
>
> Some folks suggest the retro folks use an older unmaintained Linux
> version. That's just not appropriate nor reasonable, again from either
> a security and protocol point of view.
>
> Myself? I'm a full-time C programmer and Electrical Engineer. My
> current work project is about 400KLOC. I've done some work on PC and
> embedded video hardware and software in the past.
>
> My aim is to start out by helping to test the video drivers (on both
> PC and MAC hardware), and as I gain more knowledge become part of the
> effort to bring the drivers to the older hardware into a better form
> (in kernel drivers VS user-space).
>
> Over the last few years I have been collecting a significant (~40)
> number of video cards of various flavors. Some PCI, but the majority
> evenly divided between AGP and PCI-X. Most are ATI/Radeon (Mach64+
> through R7) with some Nvidia, Matrox and a few others (Chrome and even
> a Number Nine). I try to have both PC and Mac variants of the same
> card where-ever possible to make comparisons across architectures
> easier. This year I have acquired some of the last Sapphire Radeon AGP
> cards (HD3xxx, HD4xxx). I'm a frequent flyer on eBay and Kijiji.
>
> I've got lots of Macs (PCI, AGP and PCI-X) and a number of full PC
> systems. I'm setting up a number of dedicated test bench rigs (and
> full systems) specifically for the video testing. Most are AMD 64-bit
> capable, but also Intel. Finally, there are a few embedded systems
> (AMD and a C3).
>
> From the programming side, Amazon has been a good source on older
> editions of computer graphics books, which should provide background
> knowledge to help me in my journey.
>
> One glitch is that I'm partway through eye surgery (cornea + cataracts),
> and my final operation is held up due to COVID-19.  After things get
> back to more of a normal state and that can be completed, my progress
> should be a lot smoother.
>
> I ho

Re: [RFC] Remove AGP support from Radeon/Nouveau/TTM

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

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@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

Re: [RFC] Remove AGP support from Radeon/Nouveau/TTM

2020-05-11 Thread Al Dunsmuir

On Monday, May 11, 2020, 1:17:19 PM, "Christian König" wrote:
> Hi guys,

> 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...

> 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.

> Regards,
> Christian.

Christian,

I would respectfully ask that this change be rejected.

I'm  currently  an  end user on both Intel (32-bit and 64-bit) and PPC
(Macs, IBM Power - BE and LE).

Linux is not just used for modern hardware. There is also a subset of
the user base that uses it for what is often termed retro-computing.
No it's not commercial usage, but no one can seriously claim that that
Linux is for business only.

Often the old hardware is built far batter than the modern junk, and
will continue to run for years to come. This group of folks either has
existing hardware they wish to continue to use, or are acquiring the
same because they are tired of generic locked-down hardware.

A significant percentage of the video hardware that falls in the retro
category uses the AGP video bus. Removing that support for those cases
where it works would severely limit performance and in some cases
functionality. This can mean the difference between being able to run
an application, or having it fail.

There are multiple active Linux distributions for PPC Macs. Many folks
are moving from running an original Mac OS X because of the recent
migration of most Web services to new encryption protocols (TLS 1.2,
SSL, etc.) which can not be practically supported by browsers on that
OS - even the open source ones. Linux on that same hardware provides
the opportunity to work online with current protocols and ensure that
they are reasonably secure.

Another group that fits in the retro category is those folks with
older PC hardware who are not migrating to the latest Microsoft OS,
but instead want to move to Linux.

Some folks suggest the retro folks use an older unmaintained Linux
version. That's just not appropriate nor reasonable, again from either
a security and protocol point of view.

Myself? I'm a full-time C programmer and Electrical Engineer. My
current work project is about 400KLOC. I've done some work on PC and
embedded video hardware and software in the past.

My aim is to start out by helping to test the video drivers (on both
PC and MAC hardware), and as I gain more knowledge become part of the
effort to bring the drivers to the older hardware into a better form
(in kernel drivers VS user-space).

Over the last few years I have been collecting a significant (~40)
number of video cards of various flavors. Some PCI, but the majority
evenly divided between AGP and PCI-X. Most are ATI/Radeon (Mach64+
through R7) with some Nvidia, Matrox and a few others (Chrome and even
a Number Nine). I try to have both PC and Mac variants of the same
card where-ever possible to make comparisons across architectures
easier. This year I have acquired some of the last Sapphire Radeon AGP
cards (HD3xxx, HD4xxx). I'm a frequent flyer on eBay and Kijiji.

I've got lots of Macs (PCI, AGP and PCI-X) and a number of full PC
systems. I'm setting up a number of dedicated test bench rigs (and
full systems) specifically for the video testing. Most are AMD 64-bit
capable, but also Intel. Finally, there are a few embedded systems
(AMD and a C3).

From the programming side, Amazon has been a good source on older
editions of computer graphics books, which should provide background
knowledge to help me in my journey.

One glitch is that I'm partway through eye surgery (cornea + cataracts),
and my final operation is held up due to COVID-19.  After things get
back to more of a normal state and that can be completed, my progress
should be a lot smoother.

I hope this puts another prospective on your suggested change, from a
Linux enthusiast and programmer whose usage set is far different from
your own. For that group of Linux users, I ask that you NOT go ahead
with this change as it would be far more impactful to that groups than
you might think.

Respectfully,
Al Dunsmuir

Al

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC] Remove AGP support from Radeon/Nouveau/TTM

2020-05-11 Thread Christian König


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


[1] https://cdimage.debian.org/cdimage/ports/2020-04-19/


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC] Remove AGP support from Radeon/Nouveau/TTM

On Mon, May 11, 2020 at 4:02 PM John Paul Adrian Glaubitz
 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
>
> > [1] https://cdimage.debian.org/cdimage/ports/2020-04-19/
>
> --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaub...@debian.org
> `. `'   Freie Universitaet Berlin - glaub...@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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC] Remove AGP support from Radeon/Nouveau/TTM