<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Am 11.07.2017 um 17:43 schrieb Jason
Ekstrand:<br>
</div>
<blockquote type="cite"
cite="mid:CAOFGe95cnFJCEAO6k8emWFWaAZdMPrdHjQos02peuWe6Ve1wvw@mail.gmail.com">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">On Tue, Jul 11, 2017 at 12:17 AM,
Christian König <span dir="ltr"><<a
href="mailto:deathsimple@vodafone.de" target="_blank"
moz-do-not-send="true">deathsimple@vodafone.de</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><span
class="">[SNIP]<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
If we ever want to share fences across
processes (which we do),<br>
then this needs to be sorted in the kernel.<br>
</blockquote>
That would clearly get a NAK from my side, even
Microsoft forbids<br>
wait before signal because you can easily end
up in deadlock situations.<br>
<br>
Please don't NAK things that are required by the API
specification and<br>
CTS tests.<br>
</blockquote>
There is no requirement for every aspect of the Vulkan
API specification<br>
to be mirrored 1:1 in the kernel <-> userspace
API. We have to work out<br>
what makes sense at each level.<br>
</blockquote>
<br>
</span>
Exactly, if we have a synchronization problem between two
processes that should be solved in userspace.<br>
<br>
E.g. if process A hasn't submitted it's work to the kernel
it should flush it's commands before sending a flip event
to the compositor.<br>
</blockquote>
</div>
<br>
</div>
<div class="gmail_extra">Ok, I think there is some confusion
here on what is being proposed. Here are some things that are
*not* being proposed:<br>
<br>
</div>
<div class="gmail_extra"> 1. This does *not* allow a client to
block another client's GPU work indefinitely. This is
entirely for a CPU wait API to allow for a "wait for submit"
as well as a "wait for finish".<br>
</div>
</div>
</blockquote>
Yeah, that is a rather good point.<br>
<br>
<blockquote type="cite"
cite="mid:CAOFGe95cnFJCEAO6k8emWFWaAZdMPrdHjQos02peuWe6Ve1wvw@mail.gmail.com">
<div dir="ltr">
<div class="gmail_extra"> 2. This is *not* for system
compositors that need to be robust against malicious clients.<br>
</div>
</div>
</blockquote>
I can see the point, but I think the kernel interface should still
be idiot prove even in the unlikely case the universe suddenly stops
to produce idiots.<br>
<br>
<blockquote type="cite"
cite="mid:CAOFGe95cnFJCEAO6k8emWFWaAZdMPrdHjQos02peuWe6Ve1wvw@mail.gmail.com">
<div dir="ltr">
<div class="gmail_extra">The expected use for the OPAQUE_FD is
two very tightly integrated processes which trust each other
but need to be able to share synchronization primitives.<br>
</div>
</div>
</blockquote>
Well, that raises a really important question: What is the actual
use case for this if not communication between client and
compositor?<br>
<br>
<blockquote type="cite"
cite="mid:CAOFGe95cnFJCEAO6k8emWFWaAZdMPrdHjQos02peuWe6Ve1wvw@mail.gmail.com">
<div dir="ltr">
<div class="gmail_extra">Could we do this "in userspace"? Yes,
with added kernel API. we would need some way of strapping a
second FD onto a syncobj or combining two FDs into one to send
across the wire or something like that, then add a shared
memory segment, and then pile on a bunch of code to do
cross-process condition variables and state tracking. I
really don't see how that's a better solution than adding a
flag to the kernel API to just do what we want.<br>
</div>
</div>
</blockquote>
Way to complicated.<br>
<br>
My thinking was rather to optionally allow a single page to be
mmap()ed into the process address space from the fd and then put a
futex, pthread_cond or X shared memory fence or anything like that
into it.<br>
<br>
Regards,<br>
Christian.<br>
</body>
</html>