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, 2020-03-17 at 10:12 -0700, Jacob Lifshay wrote:
> One related issue with explicit sync using sync_file is that combined
> CPUs/GPUs (the CPU cores *are* the GPU cores) that do all the
> rendering in userspace (like llvmpipe but for Vulkan and with extra
> instructions for GPU tasks) but
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:
> > > >
On Wed, Mar 18, 2020 at 11:05:48AM +0100, Michel Dänzer wrote:
> On 2020-03-17 6:21 p.m., Lucas Stach wrote:
> > That's one of the issues with implicit sync that explicit may solve:
> > a single client taking way too much time to render something can
> > block the whole pipeline up until the
On Tue, Mar 17, 2020 at 12:18:47PM -0500, Jason Ekstrand wrote:
> On Tue, Mar 17, 2020 at 12:13 PM Jacob Lifshay
> wrote:
> >
> > One related issue with explicit sync using sync_file is that combined
> > CPUs/GPUs (the CPU cores *are* the GPU cores) that do all the
> > rendering in userspace
Le mercredi 18 mars 2020 à 11:05 +0100, Michel Dänzer a écrit :
> On 2020-03-17 6:21 p.m., Lucas Stach wrote:
> > That's one of the issues with implicit sync that explicit may solve:
> > a single client taking way too much time to render something can
> > block the whole pipeline up until the
On 2020-03-17 6:21 p.m., Lucas Stach wrote:
> That's one of the issues with implicit sync that explicit may solve:
> a single client taking way too much time to render something can
> block the whole pipeline up until the display flip. With explicit
> sync the compositor can just decide to use
> 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
> vkAcquireNextImageKHR() [...] it's the application's decision whether it
> wants a fence, a semaphore, both or none
Correction: "or none" is not allowed
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
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
> 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,
> 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
On Tue, Mar 17, 2020 at 11:35 PM Jason Ekstrand wrote:
>
> On Wed, Mar 18, 2020 at 12:20 AM Jacob Lifshay
> wrote:
> >
> > The main issue with doing everything immediately is that a lot of the
> > function calls that games expect to take a very short time (e.g.
> > vkQueueSubmit) would instead
On Wed, Mar 18, 2020 at 12:20 AM Jacob Lifshay wrote:
>
> On Tue, Mar 17, 2020 at 7:08 PM Jason Ekstrand wrote:
> >
> > On Tue, Mar 17, 2020 at 7:16 PM Jacob Lifshay
> > wrote:
> > >
> > > On Tue, Mar 17, 2020 at 11:14 AM Lucas Stach wrote:
> > > >
> > > > Am Dienstag, den 17.03.2020, 10:59
On Tue, Mar 17, 2020 at 7:08 PM Jason Ekstrand wrote:
>
> On Tue, Mar 17, 2020 at 7:16 PM Jacob Lifshay
> wrote:
> >
> > On Tue, Mar 17, 2020 at 11:14 AM Lucas Stach wrote:
> > >
> > > Am Dienstag, den 17.03.2020, 10:59 -0700 schrieb Jacob Lifshay:
> > > > I think I found a
On Tue, Mar 17, 2020 at 7:16 PM Jacob Lifshay wrote:
>
> On Tue, Mar 17, 2020 at 11:14 AM Lucas Stach wrote:
> >
> > Am Dienstag, den 17.03.2020, 10:59 -0700 schrieb Jacob Lifshay:
> > > I think I found a userspace-accessible way to create sync_files and
> > > dma_fences that would fulfill the
On Tue, Mar 17, 2020 at 11:14 AM Lucas Stach wrote:
>
> Am Dienstag, den 17.03.2020, 10:59 -0700 schrieb Jacob Lifshay:
> > I think I found a userspace-accessible way to create sync_files and
> > dma_fences that would fulfill the requirements:
> >
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
Am Dienstag, den 17.03.2020, 10:59 -0700 schrieb Jacob Lifshay:
> On Tue, Mar 17, 2020 at 10:21 AM Lucas Stach wrote:
> > Am Dienstag, den 17.03.2020, 10:12 -0700 schrieb Jacob Lifshay:
> > > One related issue with explicit sync using sync_file is that combined
> > > CPUs/GPUs (the CPU cores
On Tue, Mar 17, 2020 at 10:21 AM Lucas Stach wrote:
>
> Am Dienstag, den 17.03.2020, 10:12 -0700 schrieb Jacob Lifshay:
> > One related issue with explicit sync using sync_file is that combined
> > CPUs/GPUs (the CPU cores *are* the GPU cores) that do all the
> > rendering in userspace (like
Am Dienstag, den 17.03.2020, 11:33 -0400 schrieb Nicolas Dufresne:
> 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,
Am Dienstag, den 17.03.2020, 10:12 -0700 schrieb Jacob Lifshay:
> One related issue with explicit sync using sync_file is that combined
> CPUs/GPUs (the CPU cores *are* the GPU cores) that do all the
> rendering in userspace (like llvmpipe but for Vulkan and with extra
> instructions for GPU
On Tue, Mar 17, 2020 at 12:13 PM Jacob Lifshay wrote:
>
> One related issue with explicit sync using sync_file is that combined
> CPUs/GPUs (the CPU cores *are* the GPU cores) that do all the
> rendering in userspace (like llvmpipe but for Vulkan and with extra
> instructions for GPU tasks) but
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
> >>>
One related issue with explicit sync using sync_file is that combined
CPUs/GPUs (the CPU cores *are* the GPU cores) that do all the
rendering in userspace (like llvmpipe but for Vulkan and with extra
instructions for GPU tasks) but need to synchronize with other
drivers/processes is that there
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,
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 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
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 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 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
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 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 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
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: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
> > graphics queue, so everything is ordered.
>
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
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
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, 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 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
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 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
> graphics queue, so everything is ordered.
>
> The GFX pipeline runs asynchronously to the command buffer,
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
graphics queue, so everything is ordered.
The GFX pipeline runs asynchronously to the command buffer, meaning the
command buffer only starts draws and
Could you elaborate. If there's something missing from my mental model of
how implicit sync works, I'd like to have it corrected. People continue
claiming that AMD is somehow special but I have yet to grasp what makes it
so. (Not that anyone has bothered to try all that hard to explain it.)
There is no synchronization between processes (e.g. 3D app and compositor)
within X on AMD hw. It works because of some hacks in Mesa.
Marek
On Wed, Mar 11, 2020 at 1:31 PM Jason Ekstrand wrote:
> All,
>
> Sorry for casting such a broad net with this one. I'm sure most people
> who reply will
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
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).
(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, 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
53 matches
Mail list logo
