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

On Tue, May 4, 2021 at 12:16 PM Marek Olšák wrote: > > I see some mentions of XNACK and recoverable page faults. Note that all > gaming AMD hw that has userspace queues doesn't have XNACK, so there is no > overhead in compute units. My understanding is that recoverable page faults > are still

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

I see some mentions of XNACK and recoverable page faults. Note that all gaming AMD hw that has userspace queues doesn't have XNACK, so there is no overhead in compute units. My understanding is that recoverable page faults are still supported without XNACK, but instead of the compute unit

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

On Tue, May 04, 2021 at 02:48:35PM +0200, Christian König wrote: > Am 04.05.21 um 13:13 schrieb Daniel Vetter: > > On Tue, May 4, 2021 at 12:53 PM Christian König > > wrote: > > > Am 04.05.21 um 11:47 schrieb Daniel Vetter: > > > > [SNIP] > > > > > Yeah, it just takes to long for the preemption

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

Am 04.05.21 um 13:13 schrieb Daniel Vetter: On Tue, May 4, 2021 at 12:53 PM Christian König wrote: Am 04.05.21 um 11:47 schrieb Daniel Vetter: [SNIP] Yeah, it just takes to long for the preemption to complete to be really useful for the feature we are discussing here. As I said when the

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

On Tue, May 4, 2021 at 12:53 PM Christian König wrote: > > Am 04.05.21 um 11:47 schrieb Daniel Vetter: > > [SNIP] > >> Yeah, it just takes to long for the preemption to complete to be really > >> useful for the feature we are discussing here. > >> > >> As I said when the kernel requests to

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

Am 04.05.21 um 11:47 schrieb Daniel Vetter: [SNIP] Yeah, it just takes to long for the preemption to complete to be really useful for the feature we are discussing here. As I said when the kernel requests to preempt a queue we can easily expect a timeout of ~100ms until that comes back. For

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

On Tue, May 04, 2021 at 11:14:06AM +0200, Christian König wrote: > Am 04.05.21 um 10:27 schrieb Daniel Vetter: > > On Tue, May 4, 2021 at 10:09 AM Christian König > > wrote: > > > Am 04.05.21 um 09:32 schrieb Daniel Vetter: > > > > On Tue, May 04, 2021 at 09:01:23AM +0200, Christian König wrote:

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

Am 04.05.21 um 10:27 schrieb Daniel Vetter: On Tue, May 4, 2021 at 10:09 AM Christian König wrote: Am 04.05.21 um 09:32 schrieb Daniel Vetter: On Tue, May 04, 2021 at 09:01:23AM +0200, Christian König wrote: Unfortunately as I pointed out to Daniel as well this won't work 100% reliable

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

On Tue, May 4, 2021 at 10:09 AM Christian König wrote: > > Am 04.05.21 um 09:32 schrieb Daniel Vetter: > > On Tue, May 04, 2021 at 09:01:23AM +0200, Christian König wrote: > >> Unfortunately as I pointed out to Daniel as well this won't work 100% > >> reliable either. > > You're claiming this,

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

Am 04.05.21 um 09:32 schrieb Daniel Vetter: On Tue, May 04, 2021 at 09:01:23AM +0200, Christian König wrote: Unfortunately as I pointed out to Daniel as well this won't work 100% reliable either. You're claiming this, but there's no clear reason why really, and you did't reply to my last mail

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

On Tue, May 04, 2021 at 09:01:23AM +0200, Christian König wrote: > Unfortunately as I pointed out to Daniel as well this won't work 100% > reliable either. You're claiming this, but there's no clear reason why really, and you did't reply to my last mail on that sub-thread, so I really don't get

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

Unfortunately as I pointed out to Daniel as well this won't work 100% reliable either. See the signal on the ring buffer needs to be protected by manipulation from userspace so that we can guarantee that the hardware really has finished executing when it fires. Protecting memory by

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

Proposal for a new CS ioctl, kernel pseudo code: lock(_lock); serial = get_next_serial(dev); add_wait_command(ring, serial - 1); add_exec_cmdbuf(ring, user_cmdbuf); add_signal_command(ring, serial); *ring->doorbell = FIRE; unlock(_lock); See? Just like userspace submit, but in the kernel without

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

What about direct submit from the kernel where the process still has write access to the GPU ring buffer but doesn't use it? I think that solves your preemption example, but leaves a potential backdoor for a process to overwrite the signal commands, which shouldn't be a problem since we are OK

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

On Mon, May 3, 2021 at 10:16 AM Bas Nieuwenhuizen wrote: > > On Mon, May 3, 2021 at 5:00 PM Jason Ekstrand wrote: > > > > Sorry for the top-post but there's no good thing to reply to here... > > > > One of the things pointed out to me recently by Daniel Vetter that I > > didn't fully understand

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

On Mon, May 3, 2021 at 5:00 PM Jason Ekstrand wrote: > > Sorry for the top-post but there's no good thing to reply to here... > > One of the things pointed out to me recently by Daniel Vetter that I > didn't fully understand before is that dma_buf has a very subtle > second requirement beyond

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

On Mon, May 3, 2021 at 10:03 AM Christian König wrote: > > Am 03.05.21 um 16:59 schrieb Jason Ekstrand: > > Sorry for the top-post but there's no good thing to reply to here... > > > > One of the things pointed out to me recently by Daniel Vetter that I > > didn't fully understand before is that

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

Am 03.05.21 um 16:59 schrieb Jason Ekstrand: Sorry for the top-post but there's no good thing to reply to here... One of the things pointed out to me recently by Daniel Vetter that I didn't fully understand before is that dma_buf has a very subtle second requirement beyond finite time

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

Sorry for the top-post but there's no good thing to reply to here... One of the things pointed out to me recently by Daniel Vetter that I didn't fully understand before is that dma_buf has a very subtle second requirement beyond finite time completion: Nothing required for signaling a dma-fence

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

On Sat, May 1, 2021 at 6:27 PM Marek Olšák wrote: > > On Wed, Apr 28, 2021 at 5:07 AM Michel Dänzer wrote: >> >> On 2021-04-28 8:59 a.m., Christian König wrote: >> > Hi Dave, >> > >> > Am 27.04.21 um 21:23 schrieb Marek Olšák: >> >> Supporting interop with any device is always possible. It

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

On Wed, Apr 28, 2021 at 5:07 AM Michel Dänzer wrote: > On 2021-04-28 8:59 a.m., Christian König wrote: > > Hi Dave, > > > > Am 27.04.21 um 21:23 schrieb Marek Olšák: > >> Supporting interop with any device is always possible. It depends on > which drivers we need to interoperate with and update

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

Hi, On Fri, 30 Apr 2021 at 10:35, Daniel Vetter wrote: > On Fri, Apr 30, 2021 at 11:08 AM Christian König > wrote: > > This doesn't work in hardware. We at least need to setup a few registers > > and memory locations from inside the VM which userspace shouldn't have > > access to when we want

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

On Fri, Apr 30, 2021 at 11:08 AM Christian König wrote: > > Am 30.04.21 um 10:58 schrieb Daniel Vetter: > > [SNIP] > >>> When the user allocates usermode queues, the kernel driver sets up a > >>> queue descriptor in the kernel which defines the location of the queue > >>> in memory, what priority

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

Am 30.04.21 um 10:58 schrieb Daniel Vetter: [SNIP] When the user allocates usermode queues, the kernel driver sets up a queue descriptor in the kernel which defines the location of the queue in memory, what priority it has, what page tables it should use, etc. User mode can then start writing

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

On Thu, Apr 29, 2021 at 1:12 PM Daniel Vetter wrote: > > On Wed, Apr 28, 2021 at 04:39:24PM -0400, Alex Deucher wrote: > > On Wed, Apr 28, 2021 at 10:35 AM Daniel Vetter wrote: > > > > > > On Wed, Apr 28, 2021 at 03:37:49PM +0200, Christian König wrote: > > > > Am 28.04.21 um 15:34 schrieb

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

On Wed, Apr 28, 2021 at 04:39:24PM -0400, Alex Deucher wrote: > On Wed, Apr 28, 2021 at 10:35 AM Daniel Vetter wrote: > > > > On Wed, Apr 28, 2021 at 03:37:49PM +0200, Christian König wrote: > > > Am 28.04.21 um 15:34 schrieb Daniel Vetter: > > > > On Wed, Apr 28, 2021 at 03:11:27PM +0200,

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

On Wed, Apr 28, 2021 at 04:45:01PM +0200, Christian König wrote: > Am 28.04.21 um 16:34 schrieb Daniel Vetter: > > On Wed, Apr 28, 2021 at 03:37:49PM +0200, Christian König wrote: > > > Am 28.04.21 um 15:34 schrieb Daniel Vetter: > > > > On Wed, Apr 28, 2021 at 03:11:27PM +0200, Christian König

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

On Wed, Apr 28, 2021 at 10:35 AM Daniel Vetter wrote: > > On Wed, Apr 28, 2021 at 03:37:49PM +0200, Christian König wrote: > > Am 28.04.21 um 15:34 schrieb Daniel Vetter: > > > On Wed, Apr 28, 2021 at 03:11:27PM +0200, Christian König wrote: > > > > Am 28.04.21 um 14:26 schrieb Daniel Vetter: > >

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

Am 28.04.21 um 16:34 schrieb Daniel Vetter: On Wed, Apr 28, 2021 at 03:37:49PM +0200, Christian König wrote: Am 28.04.21 um 15:34 schrieb Daniel Vetter: On Wed, Apr 28, 2021 at 03:11:27PM +0200, Christian König wrote: Am 28.04.21 um 14:26 schrieb Daniel Vetter: On Wed, Apr 28, 2021 at

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

On Wed, Apr 28, 2021 at 03:37:49PM +0200, Christian König wrote: > Am 28.04.21 um 15:34 schrieb Daniel Vetter: > > On Wed, Apr 28, 2021 at 03:11:27PM +0200, Christian König wrote: > > > Am 28.04.21 um 14:26 schrieb Daniel Vetter: > > > > On Wed, Apr 28, 2021 at 02:21:54PM +0200, Daniel Vetter

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

Am 28.04.21 um 15:34 schrieb Daniel Vetter: On Wed, Apr 28, 2021 at 03:11:27PM +0200, Christian König wrote: Am 28.04.21 um 14:26 schrieb Daniel Vetter: On Wed, Apr 28, 2021 at 02:21:54PM +0200, Daniel Vetter wrote: On Wed, Apr 28, 2021 at 12:31:09PM +0200, Christian König wrote: Am 28.04.21

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

On Wed, Apr 28, 2021 at 03:11:27PM +0200, Christian König wrote: > Am 28.04.21 um 14:26 schrieb Daniel Vetter: > > On Wed, Apr 28, 2021 at 02:21:54PM +0200, Daniel Vetter wrote: > > > On Wed, Apr 28, 2021 at 12:31:09PM +0200, Christian König wrote: > > > > Am 28.04.21 um 12:05 schrieb Daniel

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

Am 28.04.21 um 14:26 schrieb Daniel Vetter: On Wed, Apr 28, 2021 at 02:21:54PM +0200, Daniel Vetter wrote: On Wed, Apr 28, 2021 at 12:31:09PM +0200, Christian König wrote: Am 28.04.21 um 12:05 schrieb Daniel Vetter: On Tue, Apr 27, 2021 at 02:01:20PM -0400, Alex Deucher wrote: On Tue, Apr

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

On Wed, Apr 28, 2021 at 6:31 AM Christian König wrote: > > Am 28.04.21 um 12:05 schrieb Daniel Vetter: > > On Tue, Apr 27, 2021 at 02:01:20PM -0400, Alex Deucher wrote: > >> On Tue, Apr 27, 2021 at 1:35 PM Simon Ser wrote: > >>> On Tuesday, April 27th, 2021 at 7:31 PM, Lucas Stach > >>> wrote:

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

On Wednesday, April 28th, 2021 at 2:21 PM, Daniel Vetter wrote: > Yeah I think we have pretty clear consensus on that goal, just no one yet > volunteered to get going with the winsys/wayland work to plumb drm_syncobj > through, and the kernel/mesa work to make that optionally a userspace >

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

On Wed, Apr 28, 2021 at 02:21:54PM +0200, Daniel Vetter wrote: > On Wed, Apr 28, 2021 at 12:31:09PM +0200, Christian König wrote: > > Am 28.04.21 um 12:05 schrieb Daniel Vetter: > > > On Tue, Apr 27, 2021 at 02:01:20PM -0400, Alex Deucher wrote: > > > > On Tue, Apr 27, 2021 at 1:35 PM Simon Ser

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

On Wed, Apr 28, 2021 at 12:31:09PM +0200, Christian König wrote: > Am 28.04.21 um 12:05 schrieb Daniel Vetter: > > On Tue, Apr 27, 2021 at 02:01:20PM -0400, Alex Deucher wrote: > > > On Tue, Apr 27, 2021 at 1:35 PM Simon Ser wrote: > > > > On Tuesday, April 27th, 2021 at 7:31 PM, Lucas Stach > >

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

Am 28.04.21 um 12:05 schrieb Daniel Vetter: On Tue, Apr 27, 2021 at 02:01:20PM -0400, Alex Deucher wrote: On Tue, Apr 27, 2021 at 1:35 PM Simon Ser wrote: On Tuesday, April 27th, 2021 at 7:31 PM, Lucas Stach wrote: Ok. So that would only make the following use cases broken for now: - amd

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

On Tue, Apr 27, 2021 at 02:01:20PM -0400, Alex Deucher wrote: > On Tue, Apr 27, 2021 at 1:35 PM Simon Ser wrote: > > > > On Tuesday, April 27th, 2021 at 7:31 PM, Lucas Stach > > wrote: > > > > > > Ok. So that would only make the following use cases broken for now: > > > > > > > > - amd render

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

On Tue, Apr 27, 2021 at 06:27:27PM +, Simon Ser wrote: > On Tuesday, April 27th, 2021 at 8:01 PM, Alex Deucher > wrote: > > > It's an upcoming requirement for windows[1], so you are likely to > > start seeing this across all GPU vendors that support windows. I > > think the timing depends

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

On Wed, Apr 28, 2021 at 11:07:09AM +0200, Michel Dänzer wrote: > On 2021-04-28 8:59 a.m., Christian König wrote: > > Hi Dave, > > > > Am 27.04.21 um 21:23 schrieb Marek Olšák: > >> Supporting interop with any device is always possible. It depends on which > >> drivers we need to interoperate

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

On Wed, Apr 28, 2021 at 08:59:47AM +0200, Christian König wrote: > Hi Dave, > > Am 27.04.21 um 21:23 schrieb Marek Olšák: > > Supporting interop with any device is always possible. It depends on > > which drivers we need to interoperate with and update them. We've > > already found the path

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

On 2021-04-28 8:59 a.m., Christian König wrote: > Hi Dave, > > Am 27.04.21 um 21:23 schrieb Marek Olšák: >> Supporting interop with any device is always possible. It depends on which >> drivers we need to interoperate with and update them. We've already found >> the path forward for amdgpu. We

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

Hi Dave, Am 27.04.21 um 21:23 schrieb Marek Olšák: Supporting interop with any device is always possible. It depends on which drivers we need to interoperate with and update them. We've already found the path forward for amdgpu. We just need to find out how many other drivers need to be

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

On Wed., Apr. 28, 2021, 00:01 Jason Ekstrand, wrote: > On Tue, Apr 27, 2021 at 4:59 PM Marek Olšák wrote: > > > > Jason, both memory-based signalling as well as interrupt-based > signalling to the CPU would be supported by amdgpu. External devices don't > need to support memory-based sync

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

On Tue, Apr 27, 2021 at 4:59 PM Marek Olšák wrote: > > Jason, both memory-based signalling as well as interrupt-based signalling to > the CPU would be supported by amdgpu. External devices don't need to support > memory-based sync objects. The only limitation is that they can't convert >

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

Jason, both memory-based signalling as well as interrupt-based signalling to the CPU would be supported by amdgpu. External devices don't need to support memory-based sync objects. The only limitation is that they can't convert amdgpu sync objects to dma_fence. The sad thing is that "external ->

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

On Tue, Apr 27, 2021 at 1:38 PM Dave Airlie wrote: > > On Tue, 27 Apr 2021 at 22:06, Christian König > wrote: > > > > Correct, we wouldn't have synchronization between device with and without > > user queues any more. > > > > That could only be a problem for A+I Laptops. > > Since I think you

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

Trying to figure out which e-mail in this mess is the right one to reply to On Tue, Apr 27, 2021 at 12:31 PM Lucas Stach wrote: > > Hi, > > Am Dienstag, dem 27.04.2021 um 09:26 -0400 schrieb Marek Olšák: > > Ok. So that would only make the following use cases broken for now: > > - amd render

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

Supporting interop with any device is always possible. It depends on which drivers we need to interoperate with and update them. We've already found the path forward for amdgpu. We just need to find out how many other drivers need to be updated and evaluate the cost/benefit aspect. Marek On Tue,

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

On Tue, 27 Apr 2021 at 22:06, Christian König wrote: > > Correct, we wouldn't have synchronization between device with and without > user queues any more. > > That could only be a problem for A+I Laptops. Since I think you mentioned you'd only be enabling this on newer chipsets, won't it be a

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

On Tuesday, April 27th, 2021 at 8:01 PM, Alex Deucher wrote: > It's an upcoming requirement for windows[1], so you are likely to > start seeing this across all GPU vendors that support windows. I > think the timing depends on how quickly the legacy hardware support > sticks around for each

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

On Tue, Apr 27, 2021 at 1:35 PM Simon Ser wrote: > > On Tuesday, April 27th, 2021 at 7:31 PM, Lucas Stach > wrote: > > > > Ok. So that would only make the following use cases broken for now: > > > > > > - amd render -> external gpu > > > - amd video encode -> network device > > > > FWIW, "only"

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

On Tuesday, April 27th, 2021 at 7:31 PM, Lucas Stach wrote: > > Ok. So that would only make the following use cases broken for now: > > > > - amd render -> external gpu > > - amd video encode -> network device > > FWIW, "only" breaking amd render -> external gpu will make us pretty > unhappy I

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

Hi, Am Dienstag, dem 27.04.2021 um 09:26 -0400 schrieb Marek Olšák: > Ok. So that would only make the following use cases broken for now: > - amd render -> external gpu > - amd video encode -> network device FWIW, "only" breaking amd render -> external gpu will make us pretty unhappy, as we have

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

Uff good question. DMA-buf certainly supports that use case, but I have no idea if that is actually used somewhere. Daniel do you know any case? Christian. Am 27.04.21 um 15:26 schrieb Marek Olšák: Ok. So that would only make the following use cases broken for now: - amd render -> external

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

Ok. So that would only make the following use cases broken for now: - amd render -> external gpu - amd video encode -> network device What about the case when we get a buffer from an external device and we're supposed to make it "busy" when we are using it, and the external device wants to wait

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

Only amd -> external. We can easily install something in an user queue which waits for a dma_fence in the kernel. But we can't easily wait for an user queue as dependency of a dma_fence. The good thing is we have this wait before signal case on Vulkan timeline semaphores which have the same

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

I'll defer to Christian and Alex to decide whether dropping sync with non-amd devices (GPUs, cameras etc.) is acceptable. Rewriting those drivers to this new sync model could be done on a case by case basis. For now, would we only lose the "amd -> external" dependency? Or the "external -> amd"

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

Am 27.04.21 um 14:15 schrieb Daniel Vetter: On Tue, Apr 27, 2021 at 2:11 PM Marek Olšák wrote: Ok. I'll interpret this as "yes, it will work, let's do it". It works if all you care about is drm/amdgpu. I'm not sure that's a reasonable approach for upstream, but it definitely is an approach

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

On Tue, Apr 27, 2021 at 2:11 PM Marek Olšák wrote: > Ok. I'll interpret this as "yes, it will work, let's do it". It works if all you care about is drm/amdgpu. I'm not sure that's a reasonable approach for upstream, but it definitely is an approach :-) We've already gone somewhat through the

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

On Tue, Apr 27, 2021 at 1:49 PM Marek Olšák wrote: > > If we don't use future fences for DMA fences at all, e.g. we don't use them > for memory management, it can work, right? Memory management can suspend user > queues anytime. It doesn't need to use DMA fences. There might be something >

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

Ok. I'll interpret this as "yes, it will work, let's do it". Marek On Tue., Apr. 27, 2021, 08:06 Christian König, < ckoenig.leichtzumer...@gmail.com> wrote: > Correct, we wouldn't have synchronization between device with and without > user queues any more. > > That could only be a problem for

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

Correct, we wouldn't have synchronization between device with and without user queues any more. That could only be a problem for A+I Laptops. Memory management will just work with preemption fences which pause the user queues of a process before evicting something. That will be a dma_fence,

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

If we don't use future fences for DMA fences at all, e.g. we don't use them for memory management, it can work, right? Memory management can suspend user queues anytime. It doesn't need to use DMA fences. There might be something that I'm missing here. What would we lose without DMA fences? Just

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

On Mon, Apr 26, 2021 at 04:59:28PM -0400, Marek Olšák wrote: > Thanks everybody. The initial proposal is dead. Here are some thoughts on > how to do it differently. > > I think we can have direct command submission from userspace via > memory-mapped queues ("user queues") without changing window

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

Thanks everybody. The initial proposal is dead. Here are some thoughts on how to do it differently. I think we can have direct command submission from userspace via memory-mapped queues ("user queues") without changing window systems. The memory management doesn't have to use GPU page faults

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

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

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

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

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

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

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

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

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] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

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

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

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

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

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

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] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

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] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1   2   >