From: "Michel Dänzer" <michel@daenzer.net>
To: christian.koenig@amd.com, Alex Deucher <alexander.deucher@amd.com>
Cc: nouveau@lists.freedesktop.org, debian-powerpc@lists.debian.org,
dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org
Subject: Re: [RFC] Deprecate AGP GART support for Radeon/Nouveau/TTM
Date: Fri, 22 May 2020 12:49:09 +0200 [thread overview]
Message-ID: <b08c9f7d-ffa2-c9f9-6ccb-3ce40708cc84@daenzer.net> (raw)
In-Reply-To: <39241451-b25e-759f-6d52-455d806add09@gmail.com>
On 2020-05-22 12:40 p.m., Christian König wrote:
> Am 20.05.20 um 18:25 schrieb Michel Dänzer:
>> On 2020-05-20 4:43 p.m., Christian König 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.
>> I suspect the main reason it's only 5% is that PCIe GART page tables are
>> stored in VRAM, so they don't need to be fetched across the PCIe link
>> (and presumably it has more than one TLB entry as well). The difference
>> is much bigger with native AGP ASICs with PCI GART.
>
> Do you have some hardware you could give that a try on?
As I mentioned before, I tested this many times on my AGP PowerBooks
back in the day. The result was always a similar, big hit with PCI GART
vs AGP (even just 1x). I haven't seen any reason to believe this has
changed.
> While I agree that it means a performance regression, this is a rather
> high motivation to go ahead with at least the first patch.
I totally agree with the benefits, I just want everyone to be honest and
clear about the performance hit with native AGP Radeons, which already
have very weak performance by today's standards even with AGP.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
prev parent reply other threads:[~2020-05-22 10:49 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
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 [this message]
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=b08c9f7d-ffa2-c9f9-6ccb-3ce40708cc84@daenzer.net \
--to=michel@daenzer.net \
--cc=alexander.deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=christian.koenig@amd.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).