[PATCH 1/3] drm/radeon: remove AGP support

[Émeric MASCHINO]

> On Tue, May 12, 2020 at 4:16 AM Michel Dänzer  wrote:
> >
> > On 2020-05-11 10:12 p.m., Alex Deucher wrote:
> > > On Mon, May 11, 2020 at 1:17 PM Christian König
> > >  wrote:
> > >>
> > >> AGP is deprecated for 10+ years now and not used any more on modern 
> > >> hardware.
> > >>
> > >> Old hardware should continue to work in PCI mode.
> > >
> > > Might want to clarify that there is no loss of functionality here.
> > > Something like:
> > >
> > > "There is no loss of functionality here.  GPUs will continue to
> > > function.  This just drops the use of the AGP MMU in the chipset in
> > > favor of the MMU on the device which has proven to be much more
> > > reliable.  Due to its unreliability, AGP support has been disabled on
> > > PowerPC for years already so there is no change on PowerPC."
> >
> > There's a difference between something being disabled by default or not
> > being available at all. We may decide it's worth it anyway, but let's do
> > it based on facts.
> >
>
> I didn't mean to imply that AGP GART support was already removed.  But
> for the vast majority of users the end result is the same.  If you
> knew enough re-enable AGP GART, you probably wouldn't have been as
> confused about what this patch set does either.  To reiterate, this
> patch set does not remove support for AGP cards, it only removes the
> support for AGP GART.  The cards will still be functional using the
> device GART.  There may be performance tradeoffs there in some cases.
>
> Alex

Back in the fglrx days, the fglrxconfig utility proposed:


==
Advanced OS Settings
==

External AGPGART module:

It is possible (but not recommended) to turn off the usage of
built-in agp support of the provided fglrx kernel module and
use the external AGP GART module (agpgart.o) of the Linux kernel.
If you want to use the external module then ensure that it loads
prior to the drivers full startup. In order to manually load the
external agpgart module execute this on the commandline (as root):
/sbin/insmod agpgart
or alternatively configure your system to auto load the module.

Do you want to use the external AGP GART module (y/n)? [n]


By "built-in agp support of the provided fglrx kernel module", was
fglrxconfig referring to the "device GART"? So the device-side IOMMU
allowing to "work in PCI mode", somewhat dubbed as "PCI GART" (even
for AGP graphics adapters?!??) in some messages here?

If so, it is noteworthy that the default choice was not to use the
external AGP GART (resulting in Option "UseInternalAGPGART" "yes" in
/etc/X11/XF86Config), thus leveraging the device GART, i.e. what
Christian proposal is all about. Unless I still mix everything.

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

AGP GART clarifications, please!

[Émeric MASCHINO]

2014-06-20 2:06 GMT+02:00 Dave Airlie :
> So to run in AGP mode you need a chipset specific driver to manage the
> chipsets AGP GART and other features, that the GPU drivers can talk
> to.

Do the GPU drivers then talk differently to the graphics card when
there's a GART? I mean, are there different code paths in the GPU
drivers depending on the presence of GART or not? Or is the command
stream built by the DRI module exactly the same with or without GART?
Next, in the kernel DRM, are there different code paths taken
depending on the presence of GART or not? Or is it something
"transparently" (from the DRI module/kernel DRM point of view) managed
at the hardware level: I mean, the exact same data are sent to the
graphics card through the DRI module and kernel DRM, but depending on
the presence of GART or not, the data aren't handled the same at the
hardware level and are "intercepted" and managed differently (e.g.
reorganized) by the GART before being effectively delivered to the
graphics adapter?

> I'm not sure how best to measure a speed difference, it should be noticable 
> with
> games and stuff, maybe not with plain desktop usage, anything that up
> or downloads
> lots of stuff or uses main RAM for textures.

So, my OpenSceneGraph datasets, old Quake II/III demos and
SPECviewperf 7.1.1 benchmark are too limited nowadays ;-) But they
were contemporary to my hardware, so should be representative of this
era.

Thanks Dave for this first batch of explanations,

 ?meric

AGP GART clarifications, please!

[Émeric MASCHINO]

DRI gurus,

If I'm not mistaken, the current Linux graphics stack is as follows
(excluding Wayland protocol and LLVM or GLAMOR-based approaches):

X11/OpenGL app -> libX/Mesa -> DDX driver/Mesa DRI module -> kernel
DRM -> hardware

What's unclear to me is, in the case of an AGP graphics adapter, where
does the AGP GART takes place in this stack (if applicable)?

Say I have an AGP ATI R300-based graphics adapter. In the above stack,
DDX driver is x86-video-ati, Mesa DRI module is r300 (Classic or
Gallium3D) and kernel DRM is radeon. (Am I still right?)

Obviously, this AGP graphics adapter nevertheless works flawlessly
without AGP GART compiled in kernel or as module. This is at least
true for the open source stack, I've tested it. Is my AGP graphics
adapter thus running in what's known as PCI/PCIe mode? I've read all
the AGP scatter/gather, texturing and fast writes things, but I can't
see any difference performance-wise between having AGP GART compiled
in kernel or as a module and no AGP GART. Is it because my usage
doesn't stress the graphics subsystem enough or is it because PCI/PCIe
mode is so amazing that AGP GART doesn't provide any performance
enhancements? AGP GART however provides me nice stability issues ;-)

When compiled in kernel or as a module, is AGP GART only used for 3D
hardware acceleration by the r300 Mesa DRI module (or is it by the
radeon DRM? Or both?) or also by the xf86-video-ati DDX driver for
XAA/EXA acceleration? And what about video acceleration?

What happens when the AGP GART isn't compiled in kernel or as a
module? Is it simply a matter of skipping a participant (the AGP GART)
in the graphics stack or are there different code paths in the DDX
driver, Mesa DRI module and/or kernel DRM depending upon the
availability of AGP GART or not?

Is the code path the same in the following situations:
- no AGP GART at all;
- AGP GART compiled in kernel or as a module but "options radeon
agpmode=-1" set in /etc/modprobe.d/radeon-kms.conf.

Is setting a different AGP mode (1x, 2x, 4x, 8x) in
/etc/modprobe.d/radeon-kms.conf only a hardware thing or are there
different code paths taken in the various components of the graphics
stack depending on the current AGP mode?

What happens if you compile AGP GART in kernel or as a module with a
PCI/PCIe graphics adapter? Is it simply ignored? How? Out of Linux
control at the hardware level or are there simply no code path taking
advantages of the AGP GART in a PCI/PCIe graphics stack?

Finally is this assertion of the "radeon-KMS with AGP gfxcards"
section of the radeonBuildHowTo [1] still true?

"AGP gfxcards have a lot of problems so if you have one it is good
idea to test PCI/PCIE mode using radeon.agpmode=-1."

Thanks,

 ?meric


[1] http://www.x.org/wiki/radeonBuildHowTo/

[PATCH] radeon: Remove useless quirk for zx1/FireGL X1 combo introduced with fdo #7770

[Émeric MASCHINO]

Removes useless quirk a7f465f73363fce409870f62173d518b1bc02ae6 introduced with
fdo #7770 as a failed attempt to minimize stability issues with hp zx1 chipset/
ATI FireGL X1 graphics adapter configuration
(see http://marc.info/?l=linux-ia64&m=140077543819871&w=2 for details/reason)

Signed-off-by: ?meric MASCHINO 
---

diff --git a/drivers/gpu/drm/radeon/radeon_agp.c
b/drivers/gpu/drm/radeon/radeon_agp.c
index 4243334..a9297b2 100644
--- a/drivers/gpu/drm/radeon/radeon_agp.c
+++ b/drivers/gpu/drm/radeon/radeon_agp.c
@@ -117,9 +117,6 @@ static struct radeon_agpmode_quirk
radeon_agpmode_quirk_list[] = {
 /* ATI Host Bridge / RV280 [M9+] Needs AGPMode 1 (phoronix forum) */
 { PCI_VENDOR_ID_ATI, 0xcbb2, PCI_VENDOR_ID_ATI, 0x5c61,
 PCI_VENDOR_ID_SONY, 0x8175, 1},
-/* HP Host Bridge / R300 [FireGL X1] Needs AGPMode 2 (fdo #7770) */
-{ PCI_VENDOR_ID_HP, 0x122e, PCI_VENDOR_ID_ATI, 0x4e47,
-PCI_VENDOR_ID_ATI, 0x0152, 2},
 { 0, 0, 0, 0, 0, 0, 0 },
 };
 #endif

2014-05-22 23:37 GMT+02:00 ?meric MASCHINO :
> Oops,
>
> Sorry for the double-post, but the bounce from the sourceforge address
> let me think that the old list was completely disabled. Well, it seems
> that mailing to the sourceforge address are forwarded to fdo.
>
> Furthermore, it seems that submitting a patch as an attachment to a
> message, as outlined in the "Submitting patches" section of the dri/
> GettingStarted page is not the correct way to do [1]:
>
> "Submit a patch by posting it to the dri-devel mailing list as an
> attachment to a message. Make sure you explain clearly what your patch
> is for."
>
> I'll thus repost my patch as clear text in another message.
>
>  ?meric
>
>
> [1] http://dri.freedesktop.org/wiki/GettingStarted/

[PATCH] radeon: Remove useless quirk for zx1/FireGL X1 combo introduced with fdo #7770

[Émeric MASCHINO]

Oops,

Sorry for the double-post, but the bounce from the sourceforge address
let me think that the old list was completely disabled. Well, it seems
that mailing to the sourceforge address are forwarded to fdo.

Furthermore, it seems that submitting a patch as an attachment to a
message, as outlined in the "Submitting patches" section of the dri/
GettingStarted page is not the correct way to do [1]:

"Submit a patch by posting it to the dri-devel mailing list as an
attachment to a message. Make sure you explain clearly what your patch
is for."

I'll thus repost my patch as clear text in another message.

 ?meric


[1] http://dri.freedesktop.org/wiki/GettingStarted/

[PATCH] radeon: Remove useless quirk for zx1/FireGL X1 combo introduced with fdo #7770

[Émeric MASCHINO]

Hi,

Several years ago, I started a thread about stability issues with hp
zx1 chipset and ATI FireGL X1 graphics adapter on ia64 platform [1].
As an attempt to minimize problems, a quirk was introduced to restrict
AGP mode to 2x [2]. This never solve the stability issues, as the real
cause was in fact incorrect settings of the selectable timer interrupt
frequency [3].

The attached patch thus removes the useless restriction on AGP mode.
Indeed, I'm running at full AGP 4x mode for several weeks now without
a problem.

The attached patch applies cleanly against 3.15-rc5.

Thanks,

 ?meric


[1] http://marc.info/?l=dri-devel&m=126494456828755&w=2
[2] 
http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=a7f465f73363fce409870f62173d518b1bc02ae6
[3] http://marc.info/?l=linux-ia64&m=140077543819871&w=2
-- next part --
A non-text attachment was scrubbed...
Name: radeon_agp.c.patch
Type: text/x-patch
Size: 1011 bytes
Desc: not available
URL: 

[PATCH] radeon: Remove useless quirk for zx1/FireGL X1 combo introduced with fdo #7770

[Émeric MASCHINO]

Hi,

Several years ago, I started a thread about stability issues with hp
zx1 chipset and ATI FireGL X1 graphics adapter on ia64 platform [1].
As an attempt to minimize problems, a quirk was introduced to restrict
AGP mode to 2x [2]. This never solve the stability issues, as the real
cause was in fact incorrect settings of the selectable timer interrupt
frequency [3].

The attached patch thus removes the useless restriction on AGP mode.
Indeed, I'm running at full AGP 4x mode for several weeks now without
a problem.

The attached patch applies cleanly against 3.15-rc5.

Thanks,

 ?meric


[1] http://marc.info/?l=dri-devel&m=126494456828755&w=2
[2] 
http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=a7f465f73363fce409870f62173d518b1bc02ae6
[3] http://marc.info/?l=linux-ia64&m=140077543819871&w=2
-- next part --
A non-text attachment was scrubbed...
Name: radeon_agp.c.patch
Type: text/x-patch
Size: 1011 bytes
Desc: not available
URL: 

-- next part --
--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
-- next part --
--
___
Dri-devel mailing list
Dri-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel