> > >
> > > On 20/04/2022 20:13, Matthew Auld wrote:
> > > > Add an entry for the new uapi needed for small BAR on DG2+.
> > > >
> > > > v2:
> > > > - Some spelling fixes and other small tweaks. (Akeem & Thomas)
> > > >
H. Kristensen
Cc: Michel Dänzer
Cc: Daniel Stone
Cc: Sumit Semwal
Cc: "Christian König"
Cc: Alex Deucher
Cc: Daniel Vetter
Cc: Deepak R Varma
Cc: Chen Li
Cc: Kevin Wang
Cc: Dennis Li
Cc: Luben Tuikov
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Daniel Vetter
---
include
H. Kristensen
Cc: Michel Dänzer
Cc: Daniel Stone
Cc: Sumit Semwal
Cc: "Christian König"
Cc: Alex Deucher
Cc: Daniel Vetter
Cc: Deepak R Varma
Cc: Chen Li
Cc: Kevin Wang
Cc: Dennis Li
Cc: Luben Tuikov
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Daniel Vetter
---
include
On Thu, Jun 24, 2021 at 1:08 PM Daniel Stone wrote:
>
> Hi,
>
> On Wed, 23 Jun 2021 at 17:20, Daniel Vetter wrote:
> > +*
> > +* IMPLICIT SYNCHRONIZATION RULES:
> > +*
> > +* Drivers which support impli
aniel Stone
Cc: Sumit Semwal
Cc: "Christian König"
Cc: Alex Deucher
Cc: Daniel Vetter
Cc: Deepak R Varma
Cc: Chen Li
Cc: Kevin Wang
Cc: Dennis Li
Cc: Luben Tuikov
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Daniel Vetter
---
include/linux/dma-buf.h | 39 +++
On Wed, Jun 23, 2021 at 05:07:17PM +0200, Christian König wrote:
> Am 23.06.21 um 17:03 schrieb Daniel Vetter:
> > On Wed, Jun 23, 2021 at 04:58:27PM +0200, Bas Nieuwenhuizen wrote:
> > > On Wed, Jun 23, 2021 at 4:50 PM Daniel Vetter
> > > wrote:
> > > > On
On Wed, Jun 23, 2021 at 04:58:27PM +0200, Bas Nieuwenhuizen wrote:
> On Wed, Jun 23, 2021 at 4:50 PM Daniel Vetter wrote:
> >
> > On Wed, Jun 23, 2021 at 4:02 PM Christian König
> > wrote:
> > >
> > > Am 23.06.21 um 15:49 schrieb Daniel Vetter:
> >
On Wed, Jun 23, 2021 at 4:02 PM Christian König
wrote:
>
> Am 23.06.21 um 15:49 schrieb Daniel Vetter:
> > On Wed, Jun 23, 2021 at 3:44 PM Christian König
> > wrote:
> >> Am 23.06.21 um 15:38 schrieb Bas Nieuwenhuizen:
> >>> On Wed, Jun 23, 2021 at 2:59 PM
On Wed, Jun 23, 2021 at 3:44 PM Christian König
wrote:
>
> Am 23.06.21 um 15:38 schrieb Bas Nieuwenhuizen:
> > On Wed, Jun 23, 2021 at 2:59 PM Christian König
> > wrote:
> >> Am 23.06.21 um 14:18 schrieb Daniel Vetter:
> >>> On Wed, Jun 23, 2021 at
On Wed, Jun 23, 2021 at 11:45 AM Bas Nieuwenhuizen
wrote:
>
> On Tue, Jun 22, 2021 at 6:55 PM Daniel Vetter wrote:
> >
> > WARNING: Absolutely untested beyond "gcc isn't dying in agony".
> >
> > Implicit fencing done properly needs to treat the implicit fe
tian König"
Cc: Alex Deucher
Cc: Daniel Vetter
Cc: Deepak R Varma
Cc: Chen Li
Cc: Kevin Wang
Cc: Dennis Li
Cc: Luben Tuikov
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 7 +--
drivers/gpu/drm/amd/amdg
as Nieuwenhuizen
Cc: Dave Airlie
Cc: Rob Clark
Cc: Kristian H. Kristensen
Cc: Michel Dänzer
Cc: Daniel Stone
Cc: Sumit Semwal
Cc: "Christian König"
Cc: Alex Deucher
Cc: Daniel Vetter
Cc: Deepak R Varma
Cc: Chen Li
Cc: Kevin Wang
Cc: Dennis Li
Cc: Luben Tuikov
Cc: linaro-mm-.
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
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]
> >>> Ignori
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
> >
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. Exclusi
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
> > > however,
> > > > has a lot of debate around it so it's intended to be RFC-only for now.
> > > >
> > > > Mesa MR:
> > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fmesa%2Fmesa%2F-%2Fmerge_requests%2F4037data=04%7C01%7Cchristian.koenig%40amd.com
up
> > > > > to the conclusion that the hardware needs to understand sync
> > > > > object handles and have high-level wait and signal operations in
> > > > > the command stream. Sync objects will be backed by memory, but
> > > >
s(+)
> create mode 100644 Documentation/gpu/rfc/i915_parallel_execbuf.h
> create mode 100644 Documentation/gpu/rfc/i915_scheduler.rst
>
> --
> 2.28.0
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.f
y. The kernel will identify
> > > malicious behavior.
> > >
> > > Example of a hardware command stream:
> > > ...
> > > ImplicitSyncWait(syncObjHandle, sequenceNumber); // the sequence
> > > number is assigned by t
Sorry I'm behind on mails ...
On Fri, Jun 11, 2021 at 12:50:29PM -0700, Matthew Brost wrote:
> On Fri, Jun 04, 2021 at 07:59:05PM +0200, Daniel Vetter wrote:
> > On Wed, May 26, 2021 at 04:33:57PM -0700, Matthew Brost wrote:
> > > Add entry for i915 new parallel su
On Wed, Jun 09, 2021 at 03:58:26PM +0200, Christian König wrote:
> Am 09.06.21 um 15:19 schrieb Daniel Vetter:
> > [SNIP]
> > > Yeah, we call this the lightweight and the heavyweight tlb flush.
> > >
> > > The lighweight can be used when
On Fri, Jun 04, 2021 at 01:27:15PM +0200, Christian König wrote:
> Am 04.06.21 um 10:57 schrieb Daniel Vetter:
> > On Fri, Jun 04, 2021 at 09:00:31AM +0200, Christian König wrote:
> > > Am 02.06.21 um 21:19 schrieb Daniel Vetter:
> > > > On Wed, Jun 02, 2021 at 08:
On Wed, May 26, 2021 at 04:33:57PM -0700, Matthew Brost wrote:
> Add entry for i915 new parallel submission uAPI plan.
>
> v2:
> (Daniel Vetter):
> - Expand logical order explaination
> - Add dummy header
> - Only allow N BBs in execbuf IOCTL
> - Configure para
On Wed, May 26, 2021 at 04:33:56PM -0700, Matthew Brost wrote:
> Add entry for i915 GuC submission / DRM scheduler integration plan.
> Follow up patch with details of new parallel submission uAPI to come.
>
> v2:
> (Daniel Vetter)
> - Expand explaination of why bonding isn't
On Fri, Jun 04, 2021 at 09:00:31AM +0200, Christian König wrote:
> Am 02.06.21 um 21:19 schrieb Daniel Vetter:
> > On Wed, Jun 02, 2021 at 08:52:38PM +0200, Christian König wrote:
> > >
> > > Am 02.06.21 um 20:48 schrieb Daniel Vetter:
> > > > On Wed, Jun 02
ming i915
hw model, maybe works differently on amd. Iirc we have some of that
already in the i915 scheduler, but I'd need to recheck how much it
really uses the hw semaphores.
-Daniel
> Thanks,
> Marek
>
> On Thu, Jun 3, 2021 at 7:22 AM Daniel Vetter wrote:
>>
>> On Thu,
On Thu, Jun 3, 2021 at 12:55 PM Marek Olšák wrote:
>
> On Thu., Jun. 3, 2021, 06:03 Daniel Vetter, wrote:
>>
>> On Thu, Jun 03, 2021 at 04:20:18AM -0400, Marek Olšák wrote:
>> > On Thu, Jun 3, 2021 at 3:47 AM Daniel Vetter wrote:
>> >
>> > > On We
On Thu, Jun 03, 2021 at 04:20:18AM -0400, Marek Olšák wrote:
> On Thu, Jun 3, 2021 at 3:47 AM Daniel Vetter wrote:
>
> > On Wed, Jun 02, 2021 at 11:16:39PM -0400, Marek Olšák wrote:
> > > On Wed, Jun 2, 2021 at 2:48 PM Daniel Vetter wrote:
> > >
> > > >
On Wed, Jun 02, 2021 at 11:16:39PM -0400, Marek Olšák wrote:
> On Wed, Jun 2, 2021 at 2:48 PM Daniel Vetter wrote:
>
> > On Wed, Jun 02, 2021 at 05:38:51AM -0400, Marek Olšák wrote:
> > > On Wed, Jun 2, 2021 at 5:34 AM Marek Olšák wrote:
> > >
> > > &g
to tell your GL stack to _not_ do
implicit sync. Would need a new extension. vk afaiui does this
automatically already.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Wed, Jun 02, 2021 at 08:52:38PM +0200, Christian König wrote:
>
>
> Am 02.06.21 um 20:48 schrieb Daniel Vetter:
> > On Wed, Jun 02, 2021 at 05:38:51AM -0400, Marek Olšák wrote:
> > > On Wed, Jun 2, 2021 at 5:34 AM Marek Olšák wrote:
> > >
> > >
sting to know what doesn't work there instead of amd folks going of
into internal again and then coming back with another rfc from out of
nowhere :-)
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
mesa-dev mailing l
vement of the compositor. At least without
adding eglstreams fd to the kernel and wiring up all the relevant
extensions.
-Daniel
> >> Another question is if that is sufficient as security for the display
> >> server or if we need further handling down the road? I mean essentia
On Thu, May 27, 2021 at 11:06:38AM +0100, Tvrtko Ursulin wrote:
>
> On 27/05/2021 00:33, Matthew Brost wrote:
> > Add entry for i915 GuC submission / DRM scheduler integration plan.
> > Follow up patch with details of new parallel submission uAPI to come.
> >
>
On Wed, May 26, 2021 at 3:32 PM Christian König
wrote:
>
> Am 25.05.21 um 17:23 schrieb Daniel Vetter:
> > On Tue, May 25, 2021 at 5:05 PM Christian König
> > wrote:
> >> Hi Daniel,
> >>
> >> Am 25.05.21 um 15:05 schrieb Daniel Vetter:
> >>
On Tue, May 25, 2021 at 5:05 PM Christian König
wrote:
>
> Hi Daniel,
>
> Am 25.05.21 um 15:05 schrieb Daniel Vetter:
> > Hi Christian,
> >
> > On Sat, May 22, 2021 at 10:30:19AM +0200, Christian König wrote:
> >> Am 21.05.21 um 20:31 schrieb Daniel Vett
Hi Christian,
On Sat, May 22, 2021 at 10:30:19AM +0200, Christian König wrote:
> Am 21.05.21 um 20:31 schrieb Daniel Vetter:
> > [SNIP]
> > > We could provide an IOCTL for the BO to change the flag.
> > That's not the semantics we need.
> >
> > > But cou
On Fri, May 21, 2021 at 8:08 PM Christian König
wrote:
>
> Am 21.05.21 um 17:16 schrieb Daniel Vetter:
> > On Fri, May 21, 2021 at 05:00:46PM +0200, Bas Nieuwenhuizen wrote:
> >> On Fri, May 21, 2021 at 4:37 PM Daniel Vetter wrote:
> >>> On Fri, May
On Fri, May 21, 2021 at 05:00:46PM +0200, Bas Nieuwenhuizen wrote:
> On Fri, May 21, 2021 at 4:37 PM Daniel Vetter wrote:
> >
> > On Fri, May 21, 2021 at 11:46:23AM +0200, Bas Nieuwenhuizen wrote:
> > > On Fri, May 21, 2021 at 11:10 AM Daniel Vetter
> > > wrote:
On Fri, May 21, 2021 at 07:58:57AM -0700, Rob Clark wrote:
> On Fri, May 21, 2021 at 2:10 AM Daniel Vetter wrote:
> >
> > - msm is mildly entertaining. It also supports MSM_SUBMIT_NO_IMPLICIT,
> > but because it doesn't use the drm/scheduler it handles fences from
&g
On Fri, May 21, 2021 at 11:46:23AM +0200, Bas Nieuwenhuizen wrote:
> On Fri, May 21, 2021 at 11:10 AM Daniel Vetter wrote:
> >
> > Docs for struct dma_resv are fairly clear:
> >
> > "A reservation object can have attached one exclusive fence (normally
> >
l Stone
Cc: Sumit Semwal
Cc: "Christian König"
Cc: Alex Deucher
Cc: Daniel Vetter
Cc: Deepak R Varma
Cc: Chen Li
Cc: Kevin Wang
Cc: Dennis Li
Cc: Luben Tuikov
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 4 ++-
On Thu, May 20, 2021 at 08:10:59AM -0700, Matthew Brost wrote:
> On Thu, May 20, 2021 at 11:54:25AM +0200, Daniel Vetter wrote:
> > On Wed, May 19, 2021 at 7:19 PM Matthew Brost
> > wrote:
> > >
> > > On Wed, May 19, 2021 at 01:10:04PM +0200, Daniel Vetter wr
On Thu, May 20, 2021 at 11:57:44AM +0100, Tvrtko Ursulin wrote:
>
> On 20/05/2021 10:54, Daniel Vetter wrote:
> > On Wed, May 19, 2021 at 7:19 PM Matthew Brost
> > wrote:
> > >
> > > On Wed, May 19, 2021 at 01:10:04PM +0200, Daniel Vetter wrote:
> > &g
On Wed, May 19, 2021 at 7:19 PM Matthew Brost wrote:
>
> On Wed, May 19, 2021 at 01:10:04PM +0200, Daniel Vetter wrote:
> > On Tue, May 18, 2021 at 04:58:30PM -0700, Matthew Brost wrote:
> > > Add entry fpr i915 new parallel submission uAPI plan.
> > >
&
On Tue, May 18, 2021 at 04:58:30PM -0700, Matthew Brost wrote:
> Add entry fpr i915 new parallel submission uAPI plan.
>
> v2:
> (Daniel Vetter):
> - Expand logical order explaination
> - Add dummy header
> - Only allow N BBs in execbuf IOCTL
> - Configure para
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]
> > > >
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.
> >>
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:
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%
> >> reliab
it, it tells the hw scheduler that there are new
> > GPU commands in the ring buffer. Userspace inserts all the
> > wait, draw, and signal commands into the ring buffer and then
> > "rings" the doorbell. It's my understanding that
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
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:
> &
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 W
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:
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 0
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
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
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
ion
properly with drm_syncobj timeline explicit sync and protocol reving.
At least I think you'd have to work extra hard to create a gpu which
cannot possibly be intercepted by the kernel, even when it's designed to
support userspace direct submit only.
Or are your hw engineers more creativ
NDROID_native_fence_sync + EGL_KHR_wait_sync in EGL)
If you have hw which really _only_ supports userspace direct submission
(i.e. the ringbuffer has to be in the same gpu vm as everything else by
design, and can't be protected at all with e.g. read-only pte entries)
then all that stuff would be
awaiting enlightenment. :)
Yeah in all this discussion what's unclear to me is, is this a hard amdgpu
requirement going forward, in which case you need a time machine and lots
of people to retroactively fix this because this aint fast to get fixed.
Or is this just mu
correctness issue, since you have to stall for
future/indefinite fences at the beginning of the CS ioctl. Or at the
beginning of the atomic modeset ioctl, which kinda defeats the point of
nonblocking.
- You still have to touch all kmd drivers.
- For performance, you still have to glue a submit t
> The only case when the kernel will wait on a future fence is before a page
>> flip. Everything today already depends on userspace not hanging the gpu,
>> which makes everything a future fence.
>>
>> Marek
>>
>> On Tue., Apr. 27, 2021, 04:02 Daniel Vetter,
in.
-Daniel
>
> Marek
>
> On Tue., Apr. 27, 2021, 04:02 Daniel Vetter, wrote:
>>
>> 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.
&
a context flag or similar to render nodes for gl/vk. Of
course that means you can only use this mode in headless, without
glx/wayland winsys support, but it's a start.
-Daniel
>
> Marek
>
> On Tue, Apr 20, 2021 at 4:34 PM Daniel Stone wrote:
>
> > Hi,
> >
> &g
for ttm conversion
> > >>- bunch of other stuff
> > >> (Jason)
> > >>- uAPI change(!):
> > >> - drop all the extra rsvd members for the region_query and
> > >>region_info, just keep the bare minimum needed for padd
y hard to be source compatible, but we have screwed up in the
past and shrugged it off. The one example that comes to mind is
extended structures at the bottom with new field, which the kernel
automatically zero-extends for old userspace. But when you recompile,
your new-old userspace migh
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
>>
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.
> >
s roughly it.
The fancy version would allow you to access the underlying memory
fence from the cmd streamer and do fancy conditional rendering and fun
stuff like that (pick old/new frame depending which one is ready), but
that's the fancy advanced compositor on top here. The "give me
-display-on-KMS case? Do we need to do the equivalent of
>> glFinish() in userspace and only submit the KMS atomic request when the GPU
>> work has fully retired?
>>
>> Clarifying those points would be really helpful so this is less of a
>> strawman. I have some further opi
plicit.
> >
> >> Do you have any concern with the deprecation/removal of BO fences in the
> >> kernel assuming userspace is only using explicit fences? Any concern with
> >> the submit and return fences for modesetting and other producer<->consumer
> >>
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
space has all the changes for explicit synchronization. This could
> potentially create an isolated part of the kernel DRM where all drivers
> only support explicit synchronization.
10-20 years I'd say before that's even an option.
-Daniel
>
> Marek
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
roducer<->consumer
> scenarios?
Let me work on the full replay for your rfc first, because there's a lot
of details here and nuance.
-Daniel
>
> Thanks,
> Marek
>
> On Tue, Apr 20, 2021 at 6:34 AM Daniel Vetter wrote:
>
> > On Tue, Apr 20, 2021 at 12:15 PM Christian
destroy them. Mitigation of malicious behavior:
> >> - If userspace destroys a busy buffer, it will get a GPU page fault.
> >> - If userspace sends fences that never signal, the kernel will have a
> >> timeout period and then will proceed to deallocate the buf
nsion be responsible for one thing
> > only
> >
> > Signed-off-by: Matthew Auld
> > Cc: Joonas Lahtinen
> > Cc: Jordan Justen
> > Cc: Daniel Vetter
> > Cc: Kenneth Graunke
> > Cc: Jason Ekstrand
> > Cc: Dave Airlie
> > Cc:
On Fri, Apr 16, 2021 at 12:37 PM Matthew Auld wrote:
>
> Add section for drm/i915 uAPI and pull in i915_drm.h.
>
> Suggested-by: Daniel Vetter
> Signed-off-by: Matthew Auld
> Cc: Joonas Lahtinen
> Cc: Jordan Justen
> Cc: Daniel Vetter
> Cc: Kenneth Graunke
>
simpler design with the placements extension
> - rather than have a generic setparam which can cover multiple
> use cases, have each extension be responsible for one thing
> only
>
> Signed-off-by: Matthew Auld
> Cc: Joonas Lahtinen
> Cc: Jordan Justen
> Cc: D
On Fri, Apr 16, 2021 at 12:25 AM Ian Romanick wrote:
> On 4/15/21 8:59 AM, Matthew Auld wrote:
> > Add a note about the two-step process.
> >
> > Suggested-by: Daniel Vetter
> > Signed-off-by: Matthew Auld
> > Cc: Joonas Lahtinen
> > Cc: Jordan Justen
On Fri, Apr 16, 2021 at 10:44:28AM +0200, Daniel Vetter wrote:
> On Thu, Apr 15, 2021 at 04:59:55PM +0100, Matthew Auld wrote:
> > It's not properly formatted kernel doc, just nerf the warnings for now.
> >
> > Signed-off-by: Matthew Auld
> > Cc: Joonas Lahtinen
&g
On Thu, Apr 15, 2021 at 04:59:57PM +0100, Matthew Auld wrote:
> Add a note about the two-step process.
>
> Suggested-by: Daniel Vetter
> Signed-off-by: Matthew Auld
> Cc: Joonas Lahtinen
> Cc: Jordan Justen
> Cc: Daniel Vetter
> Cc: Kenneth Graunke
> Cc: Jason
On Thu, Apr 15, 2021 at 04:59:56PM +0100, Matthew Auld wrote:
> Add some example usage for the extension chaining also, which is quite
> nifty.
>
> Suggested-by: Daniel Vetter
> Signed-off-by: Matthew Auld
> Cc: Joonas Lahtinen
> Cc: Jordan Justen
> Cc: Daniel Vette
On Thu, Apr 15, 2021 at 04:59:55PM +0100, Matthew Auld wrote:
> It's not properly formatted kernel doc, just nerf the warnings for now.
>
> Signed-off-by: Matthew Auld
> Cc: Joonas Lahtinen
> Cc: Jordan Justen
> Cc: Daniel Vetter
> Cc: Kenneth Graunke
> Cc: Jason Eks
Another reminder that we're in the election process, and the next
deadline is approaching:
- Send board nominations to elections AT x DOT org
- Got to https://members.x.org/ to renew your membership (or become
one to begin with!)
On Tue, Mar 17, 2020 at 7:21 AM Daniel Vetter wrote:
>
>
, no idea. We might need to revamp all that. But for a
userspace client that does nothing fancy (no multiple render buffer
targets in one bo, or vk style "I write to everything all the time,
perhaps" stuff) there should be 0 perf difference between implicit sync
through dma_resv and explicit sync through sync_file/syncobj/dma_fence
directly.
If there is I'd consider that a bit a driver bug.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
video experts. (I just do 3D)
dma_fence has an error state which you can set when things went south. The
fence still completes (to guarantee forward progress).
Currently that error code isn't really propagated anywhere (well i915 iirc
does something like that since it tracks the depedencies internally
hristian gets to fix up amdgpu more,
at least for anything that has a dma-buf attached even if it's not shared
with anything !amdgpu.ko).
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
mesa-dev mail
rendering
with a quick reset. Iirc someone (from cros google team maybe) was even
looking into making llvmpipe run on top of vgem as a real dri/drm mesa
driver.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
mesa-dev
ctors who received two year terms starting in 2019 wereSamuel
> Iglesias Gonsálvez, Manasi D Navare, Lyude Paul and Daniel Vetter.
> They will continue to serve until their term ends in 2021. Current
> directors whose term expires in 2020 are Eric Anholt, Bryce
> Harrington, Keith
, Manasi D Navare, Lyude Paul and Daniel Vetter.
They will continue to serve until their term ends in 2021. Current
directors whose term expires in 2020 are Eric Anholt, Bryce
Harrington, Keith Packard and Harry Wentland.
A director is expected to participate in the fortnightly IRC meeting
are messy. In the old
> system the feedback loop was simple, we don't have admin time or money
> for servers we don't get the features, cloud allows us to get the
> features and enjoy them and at some point in the future the bill gets
> paid by someone else. Credit cards lifesty
On Fri, Feb 28, 2020 at 10:29 AM Erik Faye-Lund
wrote:
>
> On Fri, 2020-02-28 at 13:37 +1000, Dave Airlie wrote:
> > On Fri, 28 Feb 2020 at 07:27, Daniel Vetter
> > wrote:
> > > Hi all,
> > >
> > > You might have read the short take in the X.org boar
On Fri, Feb 28, 2020 at 4:38 AM Dave Airlie wrote:
>
> On Fri, 28 Feb 2020 at 07:27, Daniel Vetter wrote:
> >
> > Hi all,
> >
> > You might have read the short take in the X.org board meeting minutes
> > already, here's the long version.
> >
> > Th
sponsors, but
filling a shortfall of this magnitude is neither easy nor quick work,
and we therefore decided to give an early warning as soon as possible.
Any help in finding sponsors for fd.o is very much appreciated.
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365
a bunch more submissions in the future now!
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman
ibe to get all the spam.
> > I presume something similar would be available to subscribe to every
> > issue across a range of categories.
>
> You (individually) can subscribe to a label (per-project-or-group),
> yes. Subscribing a mailing list to a label is somewhat awkward since
>
1 - 100 of 325 matches
Mail list logo
