Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

2021-04-20 Thread Daniel Stone
Hi, On Tue, 20 Apr 2021 at 20:30, Daniel Vetter wrote: > The thing is, you can't do this in drm/scheduler. At least not without > splitting up the dma_fence in the kernel into separate memory fences > and sync fences I'm starting to think this thread needs its own glossary ... I propose we

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

2021-04-20 Thread Daniel Vetter
On Tue, Apr 20, 2021 at 9:14 PM Daniel Stone wrote: > > Hi, > > On Tue, 20 Apr 2021 at 19:54, Daniel Vetter wrote: >> >> So I can mostly get behind this, except it's _not_ going to be >> dma_fence. That thing has horrendous internal ordering constraints >> within the kernel, and the one thing

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

2021-04-20 Thread Daniel Vetter
On Tue, Apr 20, 2021 at 9:17 PM Jason Ekstrand wrote: > > On Tue, Apr 20, 2021 at 1:54 PM Daniel Vetter wrote: > > > > On Tue, Apr 20, 2021 at 7:45 PM Daniel Stone wrote: > > > > > And something more concrete: > > > > > > dma_fence. > > > > > > This already has all of the properties described

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

2021-04-20 Thread Marek Olšák
On Tue, Apr 20, 2021 at 2:39 PM Daniel Vetter wrote: > On Tue, Apr 20, 2021 at 6:25 PM Marek Olšák wrote: > > > > Daniel, imagine hardware that can only do what Windows does: future > fences signalled by userspace whenever userspace wants, and no kernel > queues like we have today. > > > > The

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

2021-04-20 Thread Daniel Stone
Hi, On Tue, 20 Apr 2021 at 20:03, Bas Nieuwenhuizen wrote: > On Tue, Apr 20, 2021 at 8:16 PM Daniel Stone wrote: > >> It's a jarring transition. If you take a very narrow view and say 'it's >> all GPU work in shared buffers so it should all work the same', then >> client<->winsys looks the

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

2021-04-20 Thread Jason Ekstrand
On Tue, Apr 20, 2021 at 1:54 PM Daniel Vetter wrote: > > On Tue, Apr 20, 2021 at 7:45 PM Daniel Stone wrote: > > > And something more concrete: > > > > dma_fence. > > > > This already has all of the properties described above. Kernel-wise, it > > already devolves to CPU-side signaling when it

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

2021-04-20 Thread Daniel Stone
Hi, On Tue, 20 Apr 2021 at 19:54, Daniel Vetter wrote: > So I can mostly get behind this, except it's _not_ going to be > dma_fence. That thing has horrendous internal ordering constraints > within the kernel, and the one thing that doesn't allow you is to make > a dma_fence depend upon a

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

2021-04-20 Thread Bas Nieuwenhuizen
On Tue, Apr 20, 2021 at 8:16 PM Daniel Stone wrote: > On Tue, 20 Apr 2021 at 19:00, Christian König < > ckoenig.leichtzumer...@gmail.com> wrote: > >> Am 20.04.21 um 19:44 schrieb Daniel Stone: >> >> But winsys is something _completely_ different. Yes, you're using the GPU >> to do things with

Re: [Mesa-dev] Viability of Mesa 21.0.2 with Windows 10 ARM - Snapdragon/Adreno

2021-04-20 Thread Rob Clark
+Jesse since he knows something about windows So, there are few different questions here: 1) 8cx/a680 .. the userspace difference compared to a6xx devices that are already supported is pretty small.. but I still need to find some time to do (linux) kernel side bringup 2) mesa on windows .. ie.

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

2021-04-20 Thread Daniel Vetter
On Tue, Apr 20, 2021 at 7:45 PM Daniel Stone wrote: > > Hi, > > On Tue, 20 Apr 2021 at 16:46, Jason Ekstrand wrote: >> >> It's still early in the morning here and I'm not awake yet so sorry if >> this comes out in bits and pieces... > > > No problem, it's helpful. If I weren't on this thread I'd

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

2021-04-20 Thread Daniel Vetter
On Tue, Apr 20, 2021 at 6:25 PM Marek Olšák wrote: > > Daniel, imagine hardware that can only do what Windows does: future fences > signalled by userspace whenever userspace wants, and no kernel queues like we > have today. > > The only reason why current AMD GPUs work is because they have a

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

2021-04-20 Thread Daniel Stone
On Tue, 20 Apr 2021 at 19:00, Christian König < ckoenig.leichtzumer...@gmail.com> wrote: > Am 20.04.21 um 19:44 schrieb Daniel Stone: > > But winsys is something _completely_ different. Yes, you're using the GPU > to do things with buffers A, B, and C to produce buffer Z. Yes, you're > using

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

2021-04-20 Thread Daniel Stone
On Tue, 20 Apr 2021 at 17:25, Marek Olšák wrote: > Daniel, imagine hardware that can only do what Windows does: future fences > signalled by userspace whenever userspace wants, and no kernel queues like > we have today. > > The only reason why current AMD GPUs work is because they have a ring >

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

2021-04-20 Thread Christian König
Am 20.04.21 um 19:44 schrieb Daniel Stone: Hi, On Tue, 20 Apr 2021 at 16:46, Jason Ekstrand > wrote: It's still early in the morning here and I'm not awake yet so sorry if this comes out in bits and pieces... No problem, it's helpful. If I weren't on

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

2021-04-20 Thread Daniel Stone
Hi, On Tue, 20 Apr 2021 at 16:46, Jason Ekstrand wrote: > It's still early in the morning here and I'm not awake yet so sorry if > this comes out in bits and pieces... > No problem, it's helpful. If I weren't on this thread I'd be attempting to put together a 73-piece chest of drawers whose

Re: [Mesa-dev] [PATCH v3 4/4] drm/doc/rfc: i915 DG1 uAPI

2021-04-20 Thread Jason Ekstrand
On Tue, Apr 20, 2021 at 11:34 AM Tvrtko Ursulin wrote: > > > On 19/04/2021 16:19, Jason Ekstrand wrote: > > On Mon, Apr 19, 2021 at 7:02 AM Matthew Auld wrote: > >> > >> On 16/04/2021 17:38, Jason Ekstrand wrote: > >>> On Thu, Apr 15, 2021 at 11:04 AM Matthew Auld > >>> wrote: > >

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

2021-04-20 Thread Jacob Lifshay
On Tue, Apr 20, 2021, 09:25 Marek Olšák wrote: > Daniel, imagine hardware that can only do what Windows does: future fences > signalled by userspace whenever userspace wants, and no kernel queues like > we have today. > Hmm, that sounds kinda like what we're trying to do for Libre-SOC's gpu

Re: [Mesa-dev] [PATCH v3 4/4] drm/doc/rfc: i915 DG1 uAPI

2021-04-20 Thread Tvrtko Ursulin
On 19/04/2021 16:19, Jason Ekstrand wrote: On Mon, Apr 19, 2021 at 7:02 AM Matthew Auld wrote: On 16/04/2021 17:38, Jason Ekstrand wrote: On Thu, Apr 15, 2021 at 11:04 AM Matthew Auld wrote: Add an entry for the new uAPI needed for DG1. v2(Daniel): - include the overall upstreaming

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

2021-04-20 Thread Marek Olšák
Daniel, imagine hardware that can only do what Windows does: future fences signalled by userspace whenever userspace wants, and no kernel queues like we have today. The only reason why current AMD GPUs work is because they have a ring buffer per queue with pointers to userspace command buffers

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

2021-04-20 Thread Jason Ekstrand
On Tue, Apr 20, 2021 at 9:10 AM Daniel Vetter wrote: > > On Tue, Apr 20, 2021 at 1:59 PM Christian König > wrote: > > > > > Yeah. If we go with userspace fences, then userspace can hang itself. Not > > > the kernel's problem. > > > > Well, the path of inner peace begins with four words. “Not my

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

2021-04-20 Thread Jason Ekstrand
Sorry for the mega-reply but timezones... On Tue, Apr 20, 2021 at 6:59 AM Christian König wrote: > > > Yeah. If we go with userspace fences, then userspace can hang itself. Not > > the kernel's problem. > > Well, the path of inner peace begins with four words. “Not my fucking > problem.” 律 >

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

2021-04-20 Thread Daniel Stone
Hi, On Tue, 20 Apr 2021 at 16:16, Christian König < ckoenig.leichtzumer...@gmail.com> wrote: > Am 20.04.21 um 17:07 schrieb Daniel Stone: > > If the compositor no longer has a guarantee that the buffer will be ready > for composition in a reasonable amount of time (which dma_fence gives us, >

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

2021-04-20 Thread Jason Ekstrand
It's still early in the morning here and I'm not awake yet so sorry if this comes out in bits and pieces... On Tue, Apr 20, 2021 at 7:43 AM Daniel Stone wrote: > > Hi Marek, > > On Mon, 19 Apr 2021 at 11:48, Marek Olšák wrote: >> >> 2. Explicit synchronization for window systems and modesetting

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

2021-04-20 Thread Christian König
Am 20.04.21 um 17:07 schrieb Daniel Stone: On Tue, 20 Apr 2021 at 15:58, Christian König > wrote: Am 20.04.21 um 16:53 schrieb Daniel Stone: On Mon, 19 Apr 2021 at 11:48, Marek Olšák mailto:mar...@gmail.com>> wrote: Deadlock

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

2021-04-20 Thread Christian König
Am 20.04.21 um 16:53 schrieb Daniel Stone: Hi, On Mon, 19 Apr 2021 at 11:48, Marek Olšák > wrote: Deadlock mitigation to recover from segfaults: - The kernel knows which process is obliged to signal which fence. This information is part of the Present

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

2021-04-20 Thread Daniel Stone
On Tue, 20 Apr 2021 at 15:58, Christian König < ckoenig.leichtzumer...@gmail.com> wrote: > Am 20.04.21 um 16:53 schrieb Daniel Stone: > > On Mon, 19 Apr 2021 at 11:48, Marek Olšák wrote: > >> Deadlock mitigation to recover from segfaults: >> - The kernel knows which process is obliged to signal

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

2021-04-20 Thread Daniel Stone
Hi, On Mon, 19 Apr 2021 at 11:48, Marek Olšák wrote: > Deadlock mitigation to recover from segfaults: > - The kernel knows which process is obliged to signal which fence. This > information is part of the Present request and supplied by userspace. > - If the producer crashes, the kernel signals

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

2021-04-20 Thread Daniel Vetter
On Tue, Apr 20, 2021 at 1:59 PM Christian König wrote: > > > Yeah. If we go with userspace fences, then userspace can hang itself. Not > > the kernel's problem. > > Well, the path of inner peace begins with four words. “Not my fucking > problem.” > > But I'm not that much concerned about the

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

2021-04-20 Thread Daniel Vetter
On Tue, Apr 20, 2021 at 3:04 PM Daniel Stone wrote: > > Hi, > > On Tue, 20 Apr 2021 at 13:01, Daniel Vetter wrote: >> >> - We live in a post xf86-video-$vendor world, and all these other >> compositors rely on implicit sync. You're not going to be able to get >> rid of them anytime soon.

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

2021-04-20 Thread Daniel Stone
Hi, On Tue, 20 Apr 2021 at 13:01, Daniel Vetter wrote: > - We live in a post xf86-video-$vendor world, and all these other > compositors rely on implicit sync. You're not going to be able to get > rid of them anytime soon. What's worse, all the various EGL/vk buffer > sharing things also

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

2021-04-20 Thread Daniel Stone
Hi Marek, On Mon, 19 Apr 2021 at 11:48, Marek Olšák wrote: > *2. Explicit synchronization for window systems and modesetting* > > The producer is an application and the consumer is a compositor or a > modesetting driver. > > *2.1. The Present request* > So the 'present request' is an ioctl,

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

2021-04-20 Thread Christian König
Hi Daniel, Am 20.04.21 um 14:01 schrieb Daniel Vetter: On Mon, Apr 19, 2021 at 06:47:48AM -0400, Marek Olšák wrote: Hi, This is our initial proposal for explicit fences everywhere and new memory management that doesn't use BO fences. It's a redesign of how Linux graphics drivers work, and it

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

2021-04-20 Thread Daniel Vetter
On Mon, Apr 19, 2021 at 06:47:48AM -0400, Marek Olšák wrote: > Hi, > > This is our initial proposal for explicit fences everywhere and new memory > management that doesn't use BO fences. It's a redesign of how Linux > graphics drivers work, and it can coexist with what we have now. > > > *1.

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

2021-04-20 Thread Christian König
Yeah. If we go with userspace fences, then userspace can hang itself. Not the kernel's problem. Well, the path of inner peace begins with four words. “Not my fucking problem.” But I'm not that much concerned about the kernel, but rather about important userspace processes like X, Wayland,

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

2021-04-20 Thread Daniel Vetter
On Tue, Apr 20, 2021 at 07:03:19AM -0400, Marek Olšák wrote: > Daniel, are you suggesting that we should skip any deadlock prevention in > the kernel, and just let userspace wait for and signal any fence it has > access to? Yeah. If we go with userspace fences, then userspace can hang itself. Not

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

2021-04-20 Thread Marek Olšák
Daniel, are you suggesting that we should skip any deadlock prevention in the kernel, and just let userspace wait for and signal any fence it has access to? Do you have any concern with the deprecation/removal of BO fences in the kernel assuming userspace is only using explicit fences? Any

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

2021-04-20 Thread Daniel Vetter
On Tue, Apr 20, 2021 at 12:15 PM Christian König wrote: > > Am 19.04.21 um 17:48 schrieb Jason Ekstrand: > > Not going to comment on everything on the first pass... > > > > On Mon, Apr 19, 2021 at 5:48 AM Marek Olšák wrote: > >> Hi, > >> > >> This is our initial proposal for explicit fences

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

2021-04-20 Thread Christian König
Am 19.04.21 um 17:48 schrieb Jason Ekstrand: Not going to comment on everything on the first pass... On Mon, Apr 19, 2021 at 5:48 AM Marek Olšák wrote: Hi, This is our initial proposal for explicit fences everywhere and new memory management that doesn't use BO fences. It's a redesign of