From mboxrd@z Thu Jan  1 00:00:00 1970
From: =?windows-1252?Q?Christian_K=F6nig?= <deathsimple@vodafone.de>
Subject: Re: [PATCH 6/7] drm/radeon: allow asynchronous waiting on foreign
 fences
Date: Thu, 04 Sep 2014 14:25:43 +0200
Message-ID: <54085A47.1050106@vodafone.de>
References: <54084F0E.9020500@canonical.com> <54085031.1080600@canonical.com>
 <540852F6.9040006@vodafone.de> <5408563D.8010108@canonical.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
Content-Transfer-Encoding: quoted-printable
Return-path: <dri-devel-bounces@lists.freedesktop.org>
Received: from pegasos-out.vodafone.de (pegasos-out.vodafone.de [80.84.1.38])
 by gabe.freedesktop.org (Postfix) with ESMTP id D8D3D6E331
 for <dri-devel@lists.freedesktop.org>; Thu,  4 Sep 2014 05:26:19 -0700 (PDT)
In-Reply-To: <5408563D.8010108@canonical.com>
List-Unsubscribe: <http://lists.freedesktop.org/mailman/options/dri-devel>,
 <mailto:dri-devel-request@lists.freedesktop.org?subject=unsubscribe>
List-Archive: <http://lists.freedesktop.org/archives/dri-devel>
List-Post: <mailto:dri-devel@lists.freedesktop.org>
List-Help: <mailto:dri-devel-request@lists.freedesktop.org?subject=help>
List-Subscribe: <http://lists.freedesktop.org/mailman/listinfo/dri-devel>,
 <mailto:dri-devel-request@lists.freedesktop.org?subject=subscribe>
Errors-To: dri-devel-bounces@lists.freedesktop.org
Sender: "dri-devel" <dri-devel-bounces@lists.freedesktop.org>
To: Maarten Lankhorst <maarten.lankhorst@canonical.com>, "dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org>
List-Id: dri-devel@lists.freedesktop.org

Am 04.09.2014 um 14:08 schrieb Maarten Lankhorst:
> Hey,
>
> Op 04-09-14 om 13:54 schreef Christian K=F6nig:
>> Am 04.09.2014 um 13:42 schrieb Maarten Lankhorst:
>>> Use the semaphore mechanism to make this happen, this uses signaling
>>> from the cpu instead of signaling by the gpu.
>> I'm not sure if this will work reliable when the semaphores are in syste=
m memory. We might need to reserve some VRAM for them instead.
>>
>> Regards,
>> Christian.
> Why would it be unreliable? I mostly kept it in semaphore for simplicity.

The semaphore block tries to avoid memory accesses whenever possible.

For example when a signal for address A arrives the block doesn't =

necessary writes that to memory but instead tries to match it =

immediately with a wait for address A. Similar is true if a wait for =

address A arrives and the semaphore block thinks it knows the memory =

value at address A.

Also I'm not sure if the semaphore block really polls the memory address =

for changes, instead it might just snoop the MC for writes to this =

address. Since CPU writes to system memory aren't seen by the GPU MC the =

semaphore block would never know something changed.

I need to check the docs how to do this correctly,
Christian.

>
> ~Maarten
>