Modern userspace APIs like Vulkan are built on an explicit
synchronization model. This doesn't always play nicely with the
implicit synchronization used in the kernel and assumed by X11 and
Wayland. The client -> compositor half of the synchronization isn't too
bad, at least on intel, because we
On Thu, Jun 10, 2021 at 3:11 PM Chia-I Wu wrote:
>
> On Tue, May 25, 2021 at 2:18 PM Jason Ekstrand wrote:
> > Modern userspace APIs like Vulkan are built on an explicit
> > synchronization model. This doesn't always play nicely with the
> > implicit synchronization used in the kernel and assume
On Tue, May 25, 2021 at 2:18 PM Jason Ekstrand wrote:
> Modern userspace APIs like Vulkan are built on an explicit
> synchronization model. This doesn't always play nicely with the
> implicit synchronization used in the kernel and assumed by X11 and
> Wayland. The client -> compositor half of th
Hi guys,
maybe soften that a bit. Reading from the shared memory of the user
fence is ok for everybody. What we need to take more care of is the
writing side.
So my current thinking is that we allow read only access, but writing a
new sequence value needs to go through the scheduler/kernel.
Hi Daniel,
We just talked about this whole topic internally and we came up to the
conclusion that the hardware needs to understand sync object handles and
have high-level wait and signal operations in the command stream. Sync
objects will be backed by memory, but they won't be readable or writable
On Wed, Jun 9, 2021 at 2:19 PM Jason Ekstrand wrote:
>
> +Nanley
>
> We've not defined those yet. We had some internal talks a couple
> years ago. The rough idea we had at the time was to define a modifier
> for those cases which put the CCS after each main surface at some
> fixed calculation of
