Nouveau - May 2020 - [RFC] Remove AGP support from Radeon/Nouveau/TTM

On Tue, 12 May 2020 at 06:28, Alex Deucher <alexdeucher at gmail.com>
wrote:
>
> On Mon, May 11, 2020 at 4:22 PM Al Dunsmuir <al.dunsmuir at
sympatico.ca> 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.

Hello Dave,

On Monday, May 11, 2020, 4:43:01 PM, Dave Airlie wrote:
> On Tue, 12 May 2020 at 06:28, Alex Deucher <alexdeucher at gmail.com>
wrote:
>>
>> On Mon, May 11, 2020 at 4:22 PM Al Dunsmuir <al.dunsmuir at
sympatico.ca> 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

On Mon, 11 May 2020 at 21:43, Dave Airlie <airlied at gmail.com>
wrote:
>
> On Tue, 12 May 2020 at 06:28, Alex Deucher <alexdeucher at gmail.com>
wrote:
> >
> > On Mon, May 11, 2020 at 4:22 PM Al Dunsmuir <al.dunsmuir at
sympatico.ca> 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

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 <alexdeucher at
gmail.com> 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
>
>