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
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
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
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
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.
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
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
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
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
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 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
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
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
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
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
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
