lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPj87rPJj0E_WvKCfGbANoXT9w6ns2k3mnNWvo5LZFfqtN1RGQ@mail.gmail.com>
Date:	Mon, 28 Mar 2016 14:26:32 +0100
From:	Daniel Stone <daniel@...ishbar.org>
To:	Inki Dae <inki.dae@...sung.com>
Cc:	Rob Clark <robdclark@...il.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
	Arve Hjønnevåg <arve@...roid.com>,
	Daniel Vetter <daniel.vetter@...ll.ch>,
	Riley Andrews <riandrews@...roid.com>,
	Gustavo Padovan <gustavo.padovan@...labora.co.uk>,
	John Harrison <John.C.Harrison@...el.com>
Subject: Re: [RFC 0/6] drm/fences: add in-fences to DRM

Hi Inki,

On 28 March 2016 at 02:26, Inki Dae <inki.dae@...sung.com> wrote:
> 2016년 03월 25일 21:10에 Daniel Stone 이(가) 쓴 글:
>> Second, really. Vulkan avoids implicit sync entirely, and exposes
>> fence-like primitives throughout its whole API. These include being
>> able to pass prerequisite fences for display (what Gustavo is adding
>> here: something to block on before display), and also when the user
>> acquires a buffer as a render target, it is given another prerequisite
>> fence (the other side of what Gustavo is suggesting, i.e. the fence
>> triggers when the buffer is no longer displayed and becomes available
>> for rendering).
>>
>> In order to implement this correctly, and avoid performance bubbles,
>> we need a primitive like this exposed through the KMS API, from both
>> sides. This is especially important when you take the case of
>> userspace suballocation, where userspace allocates larger blocks and
>> divides the allocation internally for different uses. Implicit sync
>> does not work at all for that case.
>
> Can you give me more details why implicit sync cannot take care of the case of userspace suballocation?

Implicit sync does not know about suballocation, so implicit will
operate for every range in the buffer, not just the one you want.

Say you have one kernel buffer, which userspace subdivides into four
independent buffers. It can perform operations on these buffers which
are completely independent of each other, and an explicit sync model
allows this independence to be kept. Implicit sync ties them together,
so that you cannot do any operations on buffer 1 until all operations
on buffer 2 have completed.

> And is there any reason that fence fd shouldn't dependent of DMABUF - now fence fd is a new file, not DMABUF fd?

Because dmabuf is for buffer sharing, and fences aren't buffers (they
will never export page ranges). Is there any particular benefit you
think you would get from doing this?

>> good thing. This is also the model that ChromeOS is moving towards, so
>> it becomes more important from that point of view as well.
>
> I think Gustavo should had explaned this path series enough to other people when posting them - ie, what relationship explict and implicit fences have, and why implicit fence - which is independent of DMABUF - is required, and what use cases there are in real users, and etc.

Fair enough, the summary could perhaps contain something like this.

Cheers,
Daniel

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ