dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Alex Deucher <alexdeucher@gmail.com>
To: "Karoly Balogh (Charlie/SGR)" <charlie@scenergy.dfmk.hu>
Cc: "Christian König" <ckoenig.leichtzumerken@gmail.com>,
	"Michel Dänzer" <michel@daenzer.net>,
	"Maling list - DRI developers" <dri-devel@lists.freedesktop.org>,
	"Rui Salvaterra" <rsalvaterra@gmail.com>,
	"debian-powerpc@lists.debian.org"
	<debian-powerpc@lists.debian.org>,
	"John Paul Adrian Glaubitz" <glaubitz@physik.fu-berlin.de>
Subject: Re: [RFC] Remove AGP support from Radeon/Nouveau/TTM
Date: Tue, 12 May 2020 09:22:05 -0400	[thread overview]
Message-ID: <CADnq5_PwY5czTPepDwzc5qoMJ3cKc4Mui=uN=k1EOtmOD42Log@mail.gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.02.2005121124110.28199@scenergy.dfmk.hu>

On Tue, May 12, 2020 at 5:40 AM Karoly Balogh (Charlie/SGR)
<charlie@scenergy.dfmk.hu> 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

  reply	other threads:[~2020-05-12 13:22 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 [this message]
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
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='CADnq5_PwY5czTPepDwzc5qoMJ3cKc4Mui=uN=k1EOtmOD42Log@mail.gmail.com' \
    --to=alexdeucher@gmail.com \
    --cc=charlie@scenergy.dfmk.hu \
    --cc=ckoenig.leichtzumerken@gmail.com \
    --cc=debian-powerpc@lists.debian.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=glaubitz@physik.fu-berlin.de \
    --cc=michel@daenzer.net \
    --cc=rsalvaterra@gmail.com \
    /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).