Hi Jason,
I use it in Broadcom EGL and Vulkan WSI implementations and "It Just Works
(TM)". I've asked to include the opaque EGL buffers as a valid type of
buffer that can be explicitly synchronised and this change was merged too,
quite some time ago. Weston 6.0.0 definitely has it, not sure
On 4/02/20 10:16 pm, Pekka Paalanen wrote:
On Mon, 3 Feb 2020 23:26:55 -0600
Jason Ekstrand wrote:
Sorry to drag up ancient threads, but what's the status of this? I see
rumors that it's in Weston. Is it stable? Is it implemented anywhere
else? It'd be great, for the sake of Vulkan, if we
On Mon, 3 Feb 2020 23:26:55 -0600
Jason Ekstrand wrote:
> Sorry to drag up ancient threads, but what's the status of this? I see
> rumors that it's in Weston. Is it stable? Is it implemented anywhere
> else? It'd be great, for the sake of Vulkan, if we could get this stable
> and everywhere.
Sorry to drag up ancient threads, but what's the status of this? I see
rumors that it's in Weston. Is it stable? Is it implemented anywhere
else? It'd be great, for the sake of Vulkan, if we could get this stable
and everywhere.
--Jason
On Mon, Dec 17, 2018 at 11:25 AM Tomek Bury wrote:
>
Thanks! That looks better than my patch.
On Mon, 17 Dec 2018 at 15:37, Alexandros Frantzis <
alexandros.frant...@collabora.com> wrote:
> On Monday, December 17, 2018 12:44 GMT, Tomek Bury
> wrote:
> > On Wed, 28 Nov 2018 at 14:35, Tomek Bury wrote:
> > > Hi Pekka,
> > >
> > > > I suppose the
On Monday, December 17, 2018 12:44 GMT, Tomek Bury
wrote:
> On Wed, 28 Nov 2018 at 14:35, Tomek Bury wrote:
> > Hi Pekka,
> >
> > > I suppose the compositor-side copy of buffers you mentioned is for the
> > > lack of release fences, not acquire fences?
> > Yes, the lack of release fences is
Hi Pekka, Alexandros,
Here's a patch containing all I had to do in order to test the explicit
sync support Alexandros has implemented in Weston.
Thanks,
Tomek
On Wed, 28 Nov 2018 at 14:35, Tomek Bury wrote:
> Hi Pekka,
>
> > I suppose the compositor-side copy of buffers you mentioned is for
Hi Pekka,
> I suppose the compositor-side copy of buffers you mentioned is for the
> lack of release fences, not acquire fences?
Yes, the lack of release fences is the very reason for the copy. I could
cook something up for the acquire fence, but that wouldn't synchronise the
buffer access
On Tue, 27 Nov 2018 18:25:04 +0200
Alexandros Frantzis wrote:
> On Tue, Nov 27, 2018 at 05:17:40PM +0200, Alexandros Frantzis wrote:
> > On Tue, Nov 27, 2018 at 10:53:45AM +0200, Pekka Paalanen wrote:
> > > Yes, we probably should have some wording that if a client is letting
> > > something
On Tue, 27 Nov 2018 14:57:07 +
Tomek Bury wrote:
> Hi Pekka,
>
> I'm just trying to figure out how to use this extension in a driver.
> Without this extension the only option I have is to take a copy if each
> wl_buffer on the compositor-side. I can't really do implicit sync so I'm
> really
On Tue, Nov 27, 2018 at 05:17:40PM +0200, Alexandros Frantzis wrote:
> On Tue, Nov 27, 2018 at 10:53:45AM +0200, Pekka Paalanen wrote:
> > Yes, we probably should have some wording that if a client is letting
> > something like EGL to commit the buffers, it must not attempt to use
> > the fence
On Tue, Nov 27, 2018 at 10:53:45AM +0200, Pekka Paalanen wrote:
> Yes, we probably should have some wording that if a client is letting
> something like EGL to commit the buffers, it must not attempt to use
> the fence extension on that wl_surface itself because EGL will probably
> be using the
Hi Pekka,
> I suppose that applies to the opaque EGL buffers only?
Sort of. As far as I understand it, the divide is between wl_surface
managed by EGL/WSI vs. wl_surface managed directly by the client
application. For EGL case the wl_surface managed by EGL would be set-up
more or less like this:
On Mon, 26 Nov 2018 15:14:45 +
Tomek Bury wrote:
> Hi Pekka,
>
> Yes, sorry, I was writing specifically about Weston implementation. In the
> merge request from Alexandros the actual compatibility check is in the main
> compositor, while compositor doesn't have enough information to decide
Hi Pekka,
Yes, sorry, I was writing specifically about Weston implementation. In the
merge request from Alexandros the actual compatibility check is in the main
compositor, while compositor doesn't have enough information to decide
whether the selected renderer can handle buffer+fence combination
On Fri, 23 Nov 2018 16:26:19 +
Tomek Bury wrote:
> Hi Pekka,
>
> > I presume you have a driver stack that relies on the opaque EGL buffers
> and not zwp_linux_dmabuf any time soon?
> Yes, exactly. I've added a protocol extension for sharing those buffers and
> our eglCreateImage()
Hi Pekka,
> I presume you have a driver stack that relies on the opaque EGL buffers
and not zwp_linux_dmabuf any time soon?
Yes, exactly. I've added a protocol extension for sharing those buffers and
our eglCreateImage() implementation can import such buffers into the driver
on the compositor
On Fri, 23 Nov 2018 13:07:37 +
Tomek Bury wrote:
> Hi Alexandros,
>
> Sorry for a delay. I've finally got an end-to-end system to test it out. It
> took some time because Weston backend I wrote a while back needed serious
> rework to catch up with latest changes.
>
> There's one thing that
Hi Alexandros,
Sorry for a delay. I've finally got an end-to-end system to test it out. It
took some time because Weston backend I wrote a while back needed serious
rework to catch up with latest changes.
There's one thing that didn't work for me. In compositor you reject
anything that isn't a
Thanks!
On Tue, Nov 13, 2018 at 9:08 AM Alexandros Frantzis <
alexandros.frant...@collabora.com> wrote:
> On Mon, Nov 12, 2018 at 12:39:58PM +, Tomek Bury wrote:
> > On Mon, Nov 12, 2018 at 11:15 AM Daniel Stone
> wrote:
> >
> > > On Fri, 9 Nov 2018 at 10:48, Pekka Paalanen
> wrote:
> > >
On Mon, Nov 12, 2018 at 12:39:58PM +, Tomek Bury wrote:
> On Mon, Nov 12, 2018 at 11:15 AM Daniel Stone wrote:
>
> > On Fri, 9 Nov 2018 at 10:48, Pekka Paalanen wrote:
> > > I can add that while pushing upstream, if there are no other changes
> > > coming.
> > >
> > > Reviewed-by: Pekka
On Mon, 12 Nov 2018 11:15:25 +
Daniel Stone wrote:
> On Fri, 9 Nov 2018 at 10:48, Pekka Paalanen wrote:
> > I can add that while pushing upstream, if there are no other changes
> > coming.
> >
> > Reviewed-by: Pekka Paalanen
> >
> > You have ensured that the C files generated from this
HI Daniel,
Where can I find the work-in-progress implementation? I'd like to try it
out with Broadcom driver which doesn't have implicit cross-process sync. I
can add the explicit sync protocol implementation on the driver side but
I'd need a reference to test it against.
Cheers,
Tomek
On Mon,
On Fri, Nov 09, 2018 at 04:24:56PM +0200, Alexandros Frantzis wrote:
> On Fri, Nov 09, 2018 at 12:48:09PM +0200, Pekka Paalanen wrote:
> > On Fri, 9 Nov 2018 09:46:36 +0200
> > Alexandros Frantzis wrote:
> >
> > > Signed-off-by: Alexandros Frantzis
> >
> > Hi Alf,
>
> Hi Pekka,
>
> thanks
On Fri, 9 Nov 2018 at 10:48, Pekka Paalanen wrote:
> I can add that while pushing upstream, if there are no other changes
> coming.
>
> Reviewed-by: Pekka Paalanen
>
> You have ensured that the C files generated from this revision build
> fine in Weston, right?
>
> David, Daniel, since your name
On Fri, Nov 09, 2018 at 12:48:09PM +0200, Pekka Paalanen wrote:
> On Fri, 9 Nov 2018 09:46:36 +0200
> Alexandros Frantzis wrote:
>
> > Signed-off-by: Alexandros Frantzis
>
> Hi Alf,
Hi Pekka,
thanks for the review!
> could you come up with some rationale to put in the commit message on
>
On Fri, 9 Nov 2018 09:46:36 +0200
Alexandros Frantzis wrote:
> Signed-off-by: Alexandros Frantzis
Hi Alf,
could you come up with some rationale to put in the commit message on
why this extension is being added?
I can add that while pushing upstream, if there are no other changes
coming.
Reviewed-by: Simon Ser
Thanks!
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
28 matches
Mail list logo
