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
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
>
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 ->
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
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
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,
Maybe, maybe not I mean, normally I'd be all for it but
https://rosenzweig.io/blog/asahi-gpu-part-3.html
--Jason
On Tue, Apr 27, 2021 at 12:32 PM Ian Romanick wrote:
>
> If we're going to cut all the classic drivers and a handful of older
> Gallium drivers... can we also cut Apple
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
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
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"
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
If we're going to cut all the classic drivers and a handful of older
Gallium drivers... can we also cut Apple GLX? Apple comes around every
couple years to fix breakages that have crept in, and we periodically
have compile breaks that need fixing (see
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
On Tue, Apr 27, 2021 at 7:50 AM Luke A. Guest wrote:
>
>
> On 27/04/2021 08:00, Pierre Moreau wrote:
> > Hello Luke,
> >
> > If you set `PKG_CONFIG_PATH=$PATH_TO_LIBCLC_INSTALL/share/pkgconfig` when
> > running meson, it should pick that version instead of the system one.
> >
> > I run it as
On 27/04/2021 08:00, Pierre Moreau wrote:
Hello Luke,
If you set `PKG_CONFIG_PATH=$PATH_TO_LIBCLC_INSTALL/share/pkgconfig` when
running meson, it should pick that version instead of the system one.
I run it as `PKG_CONFIG_PATH=[…] meson setup […]`; it might also be possible to
pass it as an
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
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
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
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"
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
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
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
>
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
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,
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
Hello Luke,
If you set `PKG_CONFIG_PATH=$PATH_TO_LIBCLC_INSTALL/share/pkgconfig` when
running meson, it should pick that version instead of the system one.
I run it as `PKG_CONFIG_PATH=[…] meson setup […]`; it might also be possible to
pass it as an argument instead, I do not know.
Best,
Pierre
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
27 matches
Mail list logo
