dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Gerhard Pircher <gerhard_pircher@gmx.net>
To: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
	christian.koenig@amd.com
Cc: "debian-powerpc@lists.debian.org"
	<debian-powerpc@lists.debian.org>,
	Maling list - DRI developers <dri-devel@lists.freedesktop.org>
Subject: Re: [RFC] Remove AGP support from Radeon/Nouveau/TTM
Date: Mon, 11 May 2020 22:48:43 +0200	[thread overview]
Message-ID: <b0e4e9eb-77f1-fcca-2bf1-96fda8aca803@gmx.net> (raw)
In-Reply-To: <3b8bfa86-73c0-0eb1-1723-a4f725aec327@physik.fu-berlin.de>

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

  reply	other threads:[~2020-05-11 22:52 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-11 19:55 [RFC] Remove AGP support from Radeon/Nouveau/TTM John Paul Adrian Glaubitz
2020-05-11 20:05 ` Alex Deucher
2020-05-11 20:25   ` Rui Salvaterra
2020-05-11 20:51     ` Alex Deucher
2020-05-12  7:57       ` Michel Dänzer
2020-05-12  9:21         ` Rui Salvaterra
2020-05-12  9:40           ` Karoly Balogh (Charlie/SGR)
2020-05-12 13:22             ` Alex Deucher
2020-05-12 16:37               ` Daniel Vetter
2020-05-12 17:02                 ` Rui Salvaterra
2020-05-12 18:21                   ` Alex Deucher
2020-05-12 20:12                     ` Dave Airlie
2020-05-13  7:26                       ` Christian König
2020-05-12 18:22                 ` Alex Deucher
2020-05-13  7:19                   ` Daniel Vetter
2020-05-13  7:55                     ` Christian König
2020-05-13 10:25                       ` Daniel Vetter
2020-05-13  9:28                     ` Rui Salvaterra
2020-05-13 10:26                       ` Michel Dänzer
2020-05-13 10:29                         ` Daniel Vetter
2020-05-13 10:32                           ` Michel Dänzer
2020-05-13 10:39                         ` Rui Salvaterra
2020-05-13 10:57                           ` Michel Dänzer
2020-05-13 11:07                             ` Rui Salvaterra
2020-05-13 13:44                               ` Christian Zigotzky
2020-05-13 14:01                                 ` John Paul Adrian Glaubitz
2020-05-13 14:01                                 ` Rui Salvaterra
2020-05-13 20:19                                   ` Bertrand Dekoninck
2020-05-13 20:36                                     ` Rui Salvaterra
2020-05-11 20:41   ` John Paul Adrian Glaubitz
2020-05-11 20:46     ` Alex Deucher
2020-05-11 21:50       ` John Paul Adrian Glaubitz
2020-05-12  7:43       ` Christian König
2020-05-11 20:12 ` Christian König
2020-05-11 20:24   ` John Paul Adrian Glaubitz
2020-05-11 20:48     ` Gerhard Pircher [this message]
2020-05-12  5:04 ` David VANTYGHEM
2020-05-12  9:20   ` John Paul Adrian Glaubitz
  -- strict thread matches above, loose matches on Subject: below --
2020-05-11 17:17 Christian König
2020-05-11 20:14 ` Al Dunsmuir
2020-05-11 20:27   ` Alex Deucher
2020-05-11 20:43     ` Dave Airlie
2020-05-11 20:56       ` Al Dunsmuir
2020-05-12  8:11         ` Christian König
2020-05-11 20:59       ` Emil Velikov
2020-05-11 20:46     ` Al Dunsmuir

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b0e4e9eb-77f1-fcca-2bf1-96fda8aca803@gmx.net \
    --to=gerhard_pircher@gmx.net \
    --cc=christian.koenig@amd.com \
    --cc=debian-powerpc@lists.debian.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=glaubitz@physik.fu-berlin.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).