On 2020-03-19 8:54 p.m., Marek Olšák wrote:
> On Thu., Mar. 19, 2020, 06:51 Daniel Vetter,
> wrote:
>>
>> Yeah, this is entirely about the programming model visible to
>> userspace. There shouldn't be any impact on the driver's choice of
>> a top vs. bottom of the gpu pipeline used for
On Thu., Mar. 19, 2020, 06:51 Daniel Vetter, wrote:
> On Tue, Mar 17, 2020 at 11:01:57AM +0100, Michel Dänzer wrote:
> > On 2020-03-16 7:33 p.m., Marek Olšák wrote:
> > > On Mon, Mar 16, 2020 at 5:57 AM Michel Dänzer
> wrote:
> > >> On 2020-03-16 4:50 a.m., Marek Olšák wrote:
> > >>> The
On Tue, Mar 17, 2020 at 11:01:57AM +0100, Michel Dänzer wrote:
> On 2020-03-16 7:33 p.m., Marek Olšák wrote:
> > On Mon, Mar 16, 2020 at 5:57 AM Michel Dänzer wrote:
> >> On 2020-03-16 4:50 a.m., Marek Olšák wrote:
> >>> The synchronization works because the Mesa driver waits for idle (drains
>
On Tue, Mar 17, 2020 at 11:27:28AM -0500, Jason Ekstrand wrote:
> On Tue, Mar 17, 2020 at 10:33 AM Nicolas Dufresne
> wrote:
> >
> > Le lundi 16 mars 2020 à 23:15 +0200, Laurent Pinchart a écrit :
> > > Hi Jason,
> > >
> > > On Mon, Mar 16, 2020 at 10:06:07AM -0500, Jason Ekstrand wrote:
> > > >
Le lundi 16 mars 2020 à 23:15 +0200, Laurent Pinchart a écrit :
> Hi Jason,
>
> On Mon, Mar 16, 2020 at 10:06:07AM -0500, Jason Ekstrand wrote:
> > On Mon, Mar 16, 2020 at 5:20 AM Laurent Pinchart wrote:
> > > On Wed, Mar 11, 2020 at 04:18:55PM -0400, Nicolas Dufresne wrote:
> > > > (I know I'm
On Mon, Mar 16, 2020 at 4:15 PM Laurent Pinchart
wrote:
>
> Hi Jason,
>
> On Mon, Mar 16, 2020 at 10:06:07AM -0500, Jason Ekstrand wrote:
> > On Mon, Mar 16, 2020 at 5:20 AM Laurent Pinchart wrote:
> > > On Wed, Mar 11, 2020 at 04:18:55PM -0400, Nicolas Dufresne wrote:
> > >> (I know I'm going to
On Wed, Mar 11, 2020 at 8:21 PM Jason Ekstrand wrote:
>
> On Wed, Mar 11, 2020 at 12:31 PM Jason Ekstrand wrote:
> >
> > All,
> >
> > Sorry for casting such a broad net with this one. I'm sure most people
> > who reply will get at least one mailing list rejection. However, this
> > is an issue
On Monday, March 16, 2020 5:04 PM, Jason Ekstrand wrote:
> Hopefully, that will provide some motivation for other compositors
> (kwin, gnome-shell, etc.) because they now have a real user of it in
> an upstream driver for a major desktop platform and not just a few
> weston examples. However,
On Tue, Mar 17, 2020 at 10:33 AM Nicolas Dufresne wrote:
>
> Le lundi 16 mars 2020 à 23:15 +0200, Laurent Pinchart a écrit :
> > Hi Jason,
> >
> > On Mon, Mar 16, 2020 at 10:06:07AM -0500, Jason Ekstrand wrote:
> > > On Mon, Mar 16, 2020 at 5:20 AM Laurent Pinchart wrote:
> > > > On Wed, Mar 11,
On Tue, Mar 17, 2020 at 3:01 AM Simon Ser wrote:
>
> On Monday, March 16, 2020 5:04 PM, Jason Ekstrand
> wrote:
>
> > Hopefully, that will provide some motivation for other compositors
> > (kwin, gnome-shell, etc.) because they now have a real user of it in
> > an upstream driver for a major
Le mardi 17 mars 2020 à 11:27 -0500, Jason Ekstrand a écrit :
> On Tue, Mar 17, 2020 at 10:33 AM Nicolas Dufresne
> wrote:
> > Le lundi 16 mars 2020 à 23:15 +0200, Laurent Pinchart a écrit :
> > > Hi Jason,
> > >
> > > On Mon, Mar 16, 2020 at 10:06:07AM -0500, Jason Ekstrand wrote:
> > > > On
On Mon, Mar 16, 2020 at 6:39 PM Roman Gilg wrote:
>
> On Wed, Mar 11, 2020 at 8:21 PM Jason Ekstrand wrote:
> >
> > On Wed, Mar 11, 2020 at 12:31 PM Jason Ekstrand
> > wrote:
> > >
> > > All,
> > >
> > > Sorry for casting such a broad net with this one. I'm sure most people
> > > who reply
On Tue., Mar. 17, 2020, 06:02 Michel Dänzer, wrote:
> On 2020-03-16 7:33 p.m., Marek Olšák wrote:
> > On Mon, Mar 16, 2020 at 5:57 AM Michel Dänzer
> wrote:
> >> On 2020-03-16 4:50 a.m., Marek Olšák wrote:
> >>> The synchronization works because the Mesa driver waits for idle
> (drains
> >>>
On 2020-03-16 7:33 p.m., Marek Olšák wrote:
> On Mon, Mar 16, 2020 at 5:57 AM Michel Dänzer wrote:
>> On 2020-03-16 4:50 a.m., Marek Olšák wrote:
>>> The synchronization works because the Mesa driver waits for idle (drains
>>> the GFX pipeline) at the end of command buffers and there is only 1
On Mon, Mar 16, 2020 at 10:37:04PM -0500, Jason Ekstrand wrote:
> On Mon, Mar 16, 2020 at 6:39 PM Roman Gilg wrote:
> >
> > On Wed, Mar 11, 2020 at 8:21 PM Jason Ekstrand wrote:
> > >
> > > On Wed, Mar 11, 2020 at 12:31 PM Jason Ekstrand
> > > wrote:
> > > >
> > > > All,
> > > >
> > > > Sorry
> That's not true; you can post back a sync token every time the client
> buffer is used by the compositor.
Technically, yes but it's very cumbersome and invasive to the point
where it becomes impractical. Explicit sync is much cleaner solution.
> For instance, Mesa adds the `wl_drm` extension,
On Wed, Mar 11, 2020 at 04:18:55PM -0400, Nicolas Dufresne wrote:
> (I know I'm going to be spammed by so many mailing list ...)
>
> Le mercredi 11 mars 2020 à 14:21 -0500, Jason Ekstrand a écrit :
> > On Wed, Mar 11, 2020 at 12:31 PM Jason Ekstrand
> > wrote:
> > > All,
> > >
> > > Sorry for
On Mon, Mar 16, 2020 at 10:33 AM Tomek Bury wrote:
>
> > GL and GLES are not relevant. What is relevant is EGL, which defines
> > interfaces to make things work on the native platform.
> Yes and no. This is what EGL spec says about sharing a texture between
> contexts:
>
> "OpenGL and OpenGL ES
Hi Tomek,
On Mon, 16 Mar 2020 at 12:55, Tomek Bury wrote:
> I've been wrestling with the sync problems in Wayland some time ago, but only
> with regards to 3D drivers.
>
> The guarantee given by the GL/GLES spec is limited to a single graphics
> context. If the same buffer is accessed by 2
Hi,
On Mon, 16 Mar 2020 at 15:33, Tomek Bury wrote:
> > GL and GLES are not relevant. What is relevant is EGL, which defines
> > interfaces to make things work on the native platform.
> Yes and no. This is what EGL spec says about sharing a texture between
> contexts:
Contexts are different
Hi Jason,
I've been wrestling with the sync problems in Wayland some time ago, but
only with regards to 3D drivers.
The guarantee given by the GL/GLES spec is limited to a single graphics
context. If the same buffer is accessed by 2 contexts the outcome is
unspecified. The cross-context and
> GL and GLES are not relevant. What is relevant is EGL, which defines
> interfaces to make things work on the native platform.
Yes and no. This is what EGL spec says about sharing a texture between contexts:
"OpenGL and OpenGL ES makes no attempt to synchronize access to
texture objects. If a
Hi Jason,
On Mon, Mar 16, 2020 at 10:06:07AM -0500, Jason Ekstrand wrote:
> On Mon, Mar 16, 2020 at 5:20 AM Laurent Pinchart wrote:
> > On Wed, Mar 11, 2020 at 04:18:55PM -0400, Nicolas Dufresne wrote:
> >> (I know I'm going to be spammed by so many mailing list ...)
> >>
> >> Le mercredi 11 mars
On Mon, Mar 16, 2020 at 5:20 AM Laurent Pinchart
wrote:
>
> On Wed, Mar 11, 2020 at 04:18:55PM -0400, Nicolas Dufresne wrote:
> > (I know I'm going to be spammed by so many mailing list ...)
> >
> > Le mercredi 11 mars 2020 à 14:21 -0500, Jason Ekstrand a écrit :
> > > On Wed, Mar 11, 2020 at
Hi Tomek,
On Mon, Mar 16, 2020 at 12:55:27PM +, Tomek Bury wrote:
> Hi Jason,
>
> I've been wrestling with the sync problems in Wayland some time ago, but only
> with regards to 3D drivers.
>
> The guarantee given by the GL/GLES spec is limited to a single graphics
> context. If the same
> As long as we can fall back to not using fences then we should be fine.
Buffers written by the camera are trivial because you control what
happens - just don't attach fence, so that the capture can be used
immediately. For recycled buffers there's an extra bit of work to do
because won't be up
> vkAcquireNextImageKHR() [...] it's the application's decision whether it
> wants a fence, a semaphore, both or none
Correction: "or none" is not allowed
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
On Thu, Mar 12, 2020 at 6:36 PM Jason Ekstrand wrote:
> From the perspective of a Wayland compositor (I used to play in this
> space), they'd love to implement the new explicit sync extension but
> can't. Sure, they could wire up the extension, but the moment they go
> to flip a client buffer to
It seems I may have not set the tone I intended with this e-mail... My
intention was never to stomp on anyone's favorite window system (Adam,
isn't the only one who's seemed a bit miffed). My intention was to
try and solve some very real problems that we have with Vulkan and I
had the hope that a
(I know I'm going to be spammed by so many mailing list ...)
Le mercredi 11 mars 2020 à 14:21 -0500, Jason Ekstrand a écrit :
> On Wed, Mar 11, 2020 at 12:31 PM Jason Ekstrand wrote:
> > All,
> >
> > Sorry for casting such a broad net with this one. I'm sure most people
> > who reply will get
On Wed, 2020-03-11 at 12:31 -0500, Jason Ekstrand wrote:
> - X11: With present, it has these "explicit" fence objects but
> they're always a shmfence which lets the X server and client do a
> userspace CPU-side hand-off without going over the socket (and
> round-tripping through the kernel).
On Wed, Mar 11, 2020 at 12:31 PM Jason Ekstrand wrote:
>
> All,
>
> Sorry for casting such a broad net with this one. I'm sure most people
> who reply will get at least one mailing list rejection. However, this
> is an issue that affects a LOT of components and that's why it's
> thorny to begin
32 matches
Mail list logo
