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

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

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.

On Monday, May 11, 2020, 4:27:55 PM, Alex Deucher 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.
> 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