All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michel Dänzer" <michel@daenzer.net>
To: "Christian König" <deathsimple@vodafone.de>
Cc: mesa-dev@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 0/5] radeon: Write-combined CPU mappings of BOs in GTT
Date: Fri, 18 Jul 2014 12:07:56 +0900	[thread overview]
Message-ID: <53C88F8C.40907@daenzer.net> (raw)
In-Reply-To: <53C7A0D0.6080202@vodafone.de>

On 17.07.2014 19:09, Christian König wrote:
> Am 17.07.2014 12:01, schrieb Michel Dänzer:
>> In order to try and improve X(Shm)PutImage performance with glamor, I
>> implemented support for write-combined CPU mappings of BOs in GTT.
>>
>> This did provide a nice speedup, but to my surprise, using VRAM instead
>> of write-combined GTT turned out to be even faster in general on my
>> Kaveri machine, both for the internal GPU and for discrete GPUs.
>>
>> However, I've kept the changes from GTT to VRAM separated, in case this
>> turns out to be a loss on other setups.
>>
>> Kernel patches:
>>
>> [PATCH 1/5] drm/radeon: Remove radeon_gart_restore()
>> [PATCH 2/5] drm/radeon: Pass GART page flags to
>> [PATCH 3/5] drm/radeon: Allow write-combined CPU mappings of BOs in
>> [PATCH 4/5] drm/radeon: Use write-combined CPU mappings of rings and
> 
> Those four are Reviewed-by: Christian König <christian.koenig@amd.com>

Thanks!


>> [PATCH 5/5] drm/radeon: Use VRAM for indirect buffers on >= SI
> 
> I'm still not very keen with this change since I still don't understand
> the reason why it's faster than with GTT. Definitely needs more testing
> on a wider range of systems.

Sure. If anyone wants to give this patch a spin and see if they can
measure any performance difference, good or bad, that would be interesting.

> Maybe limit it to APUs for now?

But IIRC, CPU writes to VRAM vs. write-combined GTT are actually an even
bigger win with dedicated GPUs than with the Kaveri built-in GPU on my
system. I suspect it may depend on the bandwidth available for PCIe vs.
system memory though.


-- 
Earthling Michel Dänzer            |                  http://www.amd.com
Libre software enthusiast          |                Mesa and X developer

  reply	other threads:[~2014-07-18  3:07 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-17 10:01 [PATCH 0/5] radeon: Write-combined CPU mappings of BOs in GTT Michel Dänzer
2014-07-17 10:01 ` [PATCH 1/5] drm/radeon: Remove radeon_gart_restore() Michel Dänzer
2014-07-17 10:01 ` [PATCH 2/5] drm/radeon: Pass GART page flags to radeon_gart_set_page() explicitly Michel Dänzer
2014-07-17 10:01 ` [PATCH 3/5] drm/radeon: Allow write-combined CPU mappings of BOs in GTT Michel Dänzer
2014-07-17 10:01 ` [PATCH 4/5] drm/radeon: Use write-combined CPU mappings of rings and IBs on >= SI Michel Dänzer
2014-07-17 10:01 ` [PATCH 5/5] drm/radeon: Use VRAM for indirect buffers " Michel Dänzer
2014-07-17 10:01 ` [PATCH 1/5] winsys/radeon: Use separate caching buffer managers for VRAM and GTT Michel Dänzer
2014-07-17 10:01 ` [PATCH 2/5] r600g/radeonsi: Use write-combined CPU mappings of some BOs in GTT Michel Dänzer
2014-07-17 10:01 ` [PATCH 3/5] r600g/radeonsi: Prefer VRAM for CPU -> GPU streaming buffers Michel Dänzer
2014-07-17 10:01 ` [PATCH 4/5] r600g, radeonsi: Use write-combined persistent GTT mappings Michel Dänzer
2014-07-17 10:56   ` Grigori Goronzy
2014-07-17 12:00   ` Marek Olšák
2014-07-18  3:19     ` [Mesa-dev] " Michel Dänzer
2014-07-18 11:45       ` Marek Olšák
2014-07-18 19:50         ` [Mesa-dev] " Grigori Goronzy
2014-07-18 20:52           ` Marek Olšák
2014-07-23  6:32         ` Michel Dänzer
2014-07-23 11:52           ` Marek Olšák
2014-07-18 20:55       ` Marek Olšák
2014-07-17 10:01 ` [PATCH 5/5] r600g, radeonsi: Prefer VRAM for persistent mappings Michel Dänzer
2014-07-17 12:17   ` Marek Olšák
2014-07-17 10:09 ` [PATCH 0/5] radeon: Write-combined CPU mappings of BOs in GTT Christian König
2014-07-18  3:07   ` Michel Dänzer [this message]
2014-07-18  3:58     ` Dieter Nützel
2014-07-18  9:52       ` Michel Dänzer
2014-07-18 15:47     ` Christian König
2014-07-18 17:47       ` Marek Olšák
2014-07-18 22:03         ` Marek Olšák
2014-07-19  1:15       ` Michel Dänzer
2014-07-21  8:07         ` Christian König
2014-07-23  3:54           ` Michel Dänzer
2014-07-23  6:42             ` Christian König
2014-07-23  7:21               ` Michel Dänzer
2014-07-23  7:32                 ` Christian König
2014-07-23 12:07                 ` Marek Olšák
2014-07-23 13:59             ` Alex Deucher
2014-07-17 12:25 ` Marek Olšák
2014-07-17 13:35 ` Alex Deucher

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=53C88F8C.40907@daenzer.net \
    --to=michel@daenzer.net \
    --cc=deathsimple@vodafone.de \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=mesa-dev@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.