dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Alex Deucher <alexdeucher@gmail.com>
To: "Christian König" <ckoenig.leichtzumerken@gmail.com>
Cc: Alex Deucher <alexander.deucher@amd.com>,
	nouveau <nouveau@lists.freedesktop.org>,
	debian-powerpc@lists.debian.org,
	amd-gfx list <amd-gfx@lists.freedesktop.org>,
	Maling list - DRI developers <dri-devel@lists.freedesktop.org>
Subject: Re: [RFC] Deprecate AGP GART support for Radeon/Nouveau/TTM
Date: Wed, 20 May 2020 12:18:59 -0400	[thread overview]
Message-ID: <CADnq5_PxUD546E852r918xEc=MddzArLDciBKtJRpuoiC4e-qQ@mail.gmail.com> (raw)
In-Reply-To: <9d784383-905e-59af-b17c-923c92474ece@gmail.com>

On Wed, May 20, 2020 at 10:43 AM Christian König
<ckoenig.leichtzumerken@gmail.com> wrote:
>
> Am 13.05.20 um 13:03 schrieb Christian König:
> > Unfortunately AGP is still to widely used as we could just drop support for using its GART.
> >
> > Not using the AGP GART also doesn't mean a loss in functionality since drivers will just fallback to the driver specific PCI GART.
> >
> > For now just deprecate the code and don't enable the AGP GART in TTM even when general AGP support is available.
>
> So I've used an ancient system (32bit) to setup a test box for this.
>
>
> The first GPU I could test is an RV280 (Radeon 9200 PRO) which is easily
> 15 years old.
>
> What happens in AGP mode is that glxgears shows artifacts during
> rendering on this system.
>
> In PCI mode those rendering artifacts are gone and glxgears seems to
> draw everything correctly now.
>
> Performance is obviously not comparable, cause in AGP we don't render
> all triangles correctly.
>
>
> The second GPU I could test is an RV630 PRO (Radeon HD 2600 PRO AGP)
> which is more than 10 years old.
>
> As far as I can tell this one works in both AGP and PCIe mode perfectly
> fine.
>
> Since this is only a 32bit system I couldn't really test any OpenGL game
> that well.
>
> But for glxgears switching from AGP to PCIe mode seems to result in a
> roughly 5% performance drop.
>
> The surprising reason for this is not the better TLB performance, but
> the lack of USWC support for the PCIe GART in radeon.
>
>
> So if anybody wants to get his hands dirty and squeeze a bit more
> performance out of the old hardware, porting USWC from amdgpu to radeon
> shouldn't be to much of a problem.

We do support USWC on radeon, although I think we had separate flags
for cached and WC.  That said we had a lot of problems with WC on 32
bit (see radeon_bo_create()).  The other problem is that, at least on
the really old radeons, the PCI gart didn't support snooped and
unsnooped.  It was always snooped.  It wasn't until pcie that the gart
hw got support for both.  For AGP, the expectation was that AGP
provided the uncached memory.

>
>
> Summing it up I'm still leaning towards disabling AGP completely by
> default for radeon and deprecate it in TTM as well.
>
> Thoughts? Especially Alex what do you think.

Works for me.

Alex
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  parent reply	other threads:[~2020-05-20 16:19 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-13 11:03 [RFC] Deprecate AGP GART support for Radeon/Nouveau/TTM Christian König
2020-05-13 11:03 ` [PATCH 1/2] drm/radeon: disable AGP by default Christian König
2020-05-13 11:55   ` Mathieu Malaterre
2020-05-13 11:03 ` [PATCH 2/2] drm/ttm: deprecate AGP support Christian König
2020-05-13 12:34   ` Daniel Vetter
2020-05-13 12:49     ` Christian König
2020-05-20 14:43 ` [RFC] Deprecate AGP GART support for Radeon/Nouveau/TTM Christian König
2020-05-20 15:58   ` Rui Salvaterra
2020-05-20 16:18   ` Alex Deucher [this message]
2020-05-22 10:41     ` Christian König
2020-05-22 14:46       ` Alex Deucher
2020-05-20 16:25   ` Michel Dänzer
2020-05-22 10:40     ` Christian König
2020-05-22 10:49       ` Michel Dänzer

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_PxUD546E852r918xEc=MddzArLDciBKtJRpuoiC4e-qQ@mail.gmail.com' \
    --to=alexdeucher@gmail.com \
    --cc=alexander.deucher@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=ckoenig.leichtzumerken@gmail.com \
    --cc=debian-powerpc@lists.debian.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=nouveau@lists.freedesktop.org \
    /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).