All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michel Dänzer" <michel@daenzer.net>
To: "Marek Olšák" <maraeo@gmail.com>
Cc: "mesa-dev@lists.freedesktop.org" <mesa-dev@lists.freedesktop.org>,
	dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: [Mesa-dev] [PATCH 4/5] r600g, radeonsi: Use write-combined persistent GTT mappings
Date: Fri, 18 Jul 2014 12:19:34 +0900	[thread overview]
Message-ID: <53C89246.9070607@daenzer.net> (raw)
In-Reply-To: <CAAxE2A40_R0sRdHmjcxLa1YDvYKOU5LEAFb0T35o_WZAuEPfAA@mail.gmail.com>

On 17.07.2014 21:00, Marek Olšák wrote:
> On Thu, Jul 17, 2014 at 12:01 PM, Michel Dänzer <michel@daenzer.net> wrote:
>> From: Michel Dänzer <michel.daenzer@amd.com>
>>
>> This is hopefully safe: The kernel makes sure writes to these mappings
>> finish before the GPU might start reading from them, and the GPU caches
>> are invalidated at the start of a command stream.
>>
> The resource flags actually tell you what you can do. If the COHERENT
> flag is set, the mapping must be cached.

Why is that required? As I explain above, we should satisfy the
requirements of the ARB_buffer_storage extension AFAICT.


As pointed out by you and Grigori in other posts, I should probably just
drop the special treatment of persistent mappings though, so the
placement and flags are derived from the buffer usage.


-- 
Earthling Michel Dänzer            |                  http://www.amd.com
Libre software enthusiast          |                Mesa and X developer
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2014-07-18  3:19 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     ` Michel Dänzer [this message]
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
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=53C89246.9070607@daenzer.net \
    --to=michel@daenzer.net \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=maraeo@gmail.com \
    --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.