Hi Daniel,
thanks for jumping in here.
And yes, you are absolutely right we need to get this fixed and not yell
at each other that we have a different understanding of things.
Your proposal sounds sane to me, but I wouldn't call it slots. Rather
something like "use cases" since we can have m
Am 18.06.21 um 17:17 schrieb Daniel Vetter:
[SNIP]
Ignoring _all_ fences is officially ok for pinned dma-buf. This is
what v4l does. Aside from it's definitely not just i915 that does this
even on the drm side, we have a few more drivers nowadays.
No it seriously isn't. If drivers are doing thi
Am 18.06.21 um 19:20 schrieb Daniel Vetter:
On Fri, Jun 18, 2021 at 6:43 PM Christian König
wrote:
Am 18.06.21 um 17:17 schrieb Daniel Vetter:
[SNIP]
Ignoring _all_ fences is officially ok for pinned dma-buf. This is
what v4l does. Aside from it's definitely not just i915 that does this
even o
Am 16.06.21 um 20:30 schrieb Jason Ekstrand:
On Tue, Jun 15, 2021 at 3:41 AM Christian König
wrote:
Hi Jason & Daniel,
maybe I should explain once more where the problem with this approach is
and why I think we need to get that fixed before we can do something
like this here.
To summarize wha
Am 17.06.21 um 21:58 schrieb Daniel Vetter:
On Thu, Jun 17, 2021 at 09:37:36AM +0200, Christian König wrote:
[SNIP]
But, to the broader point, maybe? I'm a little fuzzy on exactly where
i915 inserts and/or depends on fences.
When you combine that with complex drivers which use TTM and buffer
Am 18.06.21 um 16:31 schrieb Daniel Vetter:
[SNIP]
And that drivers choose to ignore the exclusive fence is an absolutely
no-go from a memory management and security point of view. Exclusive
access means exclusive access. Ignoring that won't work.
Yeah, this is why I've been going all over the
On Mon, Jun 21, 2021 at 12:16:55PM +0200, Christian König wrote:
> Am 18.06.21 um 20:45 schrieb Daniel Vetter:
> > On Fri, Jun 18, 2021 at 8:02 PM Christian König
> > wrote:
> > > Am 18.06.21 um 19:20 schrieb Daniel Vetter:
> > > [SNIP]
> > > The whole thing was introduced with this commit here:
>
Am 18.06.21 um 20:45 schrieb Daniel Vetter:
On Fri, Jun 18, 2021 at 8:02 PM Christian König
wrote:
Am 18.06.21 um 19:20 schrieb Daniel Vetter:
[SNIP]
The whole thing was introduced with this commit here:
commit f2c24b83ae90292d315aa7ac029c6ce7929e01aa
Author: Maarten Lankhorst
Date: Wed Apr
On Fri, Jun 18, 2021 at 8:02 PM Christian König
wrote:
>
> Am 18.06.21 um 19:20 schrieb Daniel Vetter:
> > On Fri, Jun 18, 2021 at 6:43 PM Christian König
> > wrote:
> >> Am 18.06.21 um 17:17 schrieb Daniel Vetter:
> >>> [SNIP]
> >>> Ignoring _all_ fences is officially ok for pinned dma-buf. This
Sorry for the mobile reply, but V4L2 is absolutely not write-only; there has
never been an intersection of V4L2 supporting dmabuf and not supporting reads.
I see your point about the heritage of dma_resv but it’s a red herring. It
doesn’t matter who’s right, or who was first, or where the code w
On Fri, Jun 18, 2021 at 6:43 PM Christian König
wrote:
>
> Am 18.06.21 um 17:17 schrieb Daniel Vetter:
> > [SNIP]
> > Ignoring _all_ fences is officially ok for pinned dma-buf. This is
> > what v4l does. Aside from it's definitely not just i915 that does this
> > even on the drm side, we have a fe
On Fri, Jun 18, 2021 at 4:42 PM Christian König
wrote:
>
> Am 18.06.21 um 16:31 schrieb Daniel Vetter:
> > [SNIP]
> >> And that drivers choose to ignore the exclusive fence is an absolutely
> >> no-go from a memory management and security point of view. Exclusive
> >> access means exclusive access
On Fri, Jun 18, 2021 at 11:15 AM Christian König
wrote:
>
> Am 17.06.21 um 21:58 schrieb Daniel Vetter:
> > On Thu, Jun 17, 2021 at 09:37:36AM +0200, Christian König wrote:
> >> [SNIP]
> >>> But, to the broader point, maybe? I'm a little fuzzy on exactly where
> >>> i915 inserts and/or depends on
On Fri, Jun 18, 2021 at 4:15 AM Christian König
wrote:
>
> Am 17.06.21 um 21:58 schrieb Daniel Vetter:
> > On Thu, Jun 17, 2021 at 09:37:36AM +0200, Christian König wrote:
> >> [SNIP]
> >>> But, to the broader point, maybe? I'm a little fuzzy on exactly where
> >>> i915 inserts and/or depends on
On Thu, Jun 17, 2021 at 09:37:36AM +0200, Christian König wrote:
> Am 16.06.21 um 20:30 schrieb Jason Ekstrand:
> > On Tue, Jun 15, 2021 at 3:41 AM Christian König
> > wrote:
> > > Hi Jason & Daniel,
> > >
> > > maybe I should explain once more where the problem with this approach is
> > > and wh
On Tue, Jun 15, 2021 at 3:41 AM Christian König
wrote:
>
> Hi Jason & Daniel,
>
> maybe I should explain once more where the problem with this approach is
> and why I think we need to get that fixed before we can do something
> like this here.
>
> To summarize what this patch here does is that it
Hi Jason & Daniel,
maybe I should explain once more where the problem with this approach is
and why I think we need to get that fixed before we can do something
like this here.
To summarize what this patch here does is that it copies the exclusive
fence and/or the shared fences into a sync_f
Modern userspace APIs like Vulkan are built on an explicit
synchronization model. This doesn't always play nicely with the
implicit synchronization used in the kernel and assumed by X11 and
Wayland. The client -> compositor half of the synchronization isn't too
bad, at least on intel, because we
18 matches
Mail list logo
