Re: [repost] drm sync objects cleaned up

A few thoughts (from the anv perspective) that I put on IRC but may be better in a mail. In no particular order: 1. Having the fd exported from a syncobj be a valid sync_file seems like a fairly pointless feature to me. If we can make things more sane by throwing that out, I'm all for it. 2.

Re: [PATCH] drm/syncobj: add sync obj wait interface. (v6)

On Tue, Jul 11, 2017 at 12:17 AM, Christian König <deathsim...@vodafone.de> wrote: > Am 11.07.2017 um 04:36 schrieb Michel Dänzer: > >> On 11/07/17 06:09 AM, Jason Ekstrand wrote: >> >>> On Mon, Jul 10, 2017 at 9:15 AM, Christian König >>> <deathsim..

Re: [PATCH] drm/syncobj: add sync obj wait interface. (v6)

On Tue, Jul 11, 2017 at 12:22 AM, Daniel Vetter <dan...@ffwll.ch> wrote: > On Mon, Jul 10, 2017 at 02:09:42PM -0700, Jason Ekstrand wrote: > > On Mon, Jul 10, 2017 at 9:15 AM, Christian König < > deathsim...@vodafone.de> > > wrote: > > > > >

Re: [PATCH] drm/syncobj: add sync obj wait interface. (v6)

> > Alex Bin Xie > > *From:* amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org > <amd-gfx-boun...@lists.freedesktop.org>] *On Behalf Of *Jason Ekstrand > *Sent:* Monday, July 10, 2017 11:53 AM > *To:* Christian König <deathsim...@vodafone.de> <deathsim...@vodafone.de

Re: [PATCH] drm/syncobj: add sync obj wait interface. (v6)

On Wed, Jul 5, 2017 at 6:04 PM, Dave Airlie wrote: > From: Dave Airlie > > This interface will allow sync object to be used to back > Vulkan fences. This API is pretty much the vulkan fence waiting > API, and I've ported the code from amdgpu. > > v2:

Re: [PATCH] drm/syncobj: add sync obj wait interface. (v6)

On Mon, Jul 10, 2017 at 9:15 AM, Christian König <deathsim...@vodafone.de> wrote: > Am 10.07.2017 um 17:52 schrieb Jason Ekstrand: > > On Mon, Jul 10, 2017 at 8:45 AM, Christian König <deathsim...@vodafone.de> > wrote: > >> Am 10.07.2017 um 17:28 schrieb Jason Ek

Re: [PATCH] drm/syncobj: add sync obj wait interface. (v6)

On Wed, Jul 12, 2017 at 1:39 AM, Dave Airlie <airl...@gmail.com> wrote: > On 12 July 2017 at 17:39, Christian König <deathsim...@vodafone.de> wrote: > > Am 11.07.2017 um 17:43 schrieb Jason Ekstrand: > > > > On Tue, Jul 11, 2017 at 12:17 AM, Christian König <

Re: [PATCH] drm/syncobj: add sync obj wait interface. (v6)

On Wed, Jul 12, 2017 at 9:45 AM, Christian König <deathsim...@vodafone.de> wrote: > Am 12.07.2017 um 17:53 schrieb Jason Ekstrand: > > [SNIP] > > >> Is that easier than just waiting in the kernel, I'm not sure how >> optimised we need this path to be. >> &

Re: [PATCH 1/5] drm: introduce sync objects

On Mon, May 8, 2017 at 7:26 PM, Dave Airlie wrote: > On 4 May 2017 at 18:16, Chris Wilson wrote: > > On Wed, Apr 26, 2017 at 01:28:29PM +1000, Dave Airlie wrote: > >> +#include > > > > I wonder if Daniel has already split everything used here into

Re: [rfc] drm sync objects (search for spock)

On Wed, Apr 26, 2017 at 7:57 AM, Christian König wrote: > Am 26.04.2017 um 11:57 schrieb Dave Airlie: > >> On 26 April 2017 at 18:45, Christian König >> wrote: >> >>> Am 26.04.2017 um 05:28 schrieb Dave Airlie: >>> Okay I've gone around the

Re: [PATCH 2/5] drm/syncobj: add sync obj wait interface. (v3)

On Wed, May 24, 2017 at 10:25 AM, Jason Ekstrand <ja...@jlekstrand.net> wrote: > On Wed, May 24, 2017 at 12:06 AM, Dave Airlie <airl...@gmail.com> wrote: > >> From: Dave Airlie <airl...@redhat.com> >> >> This interface will allow sync object to be used to

Re: [PATCH 2/5] drm/syncobj: add sync obj wait interface. (v3)

On Wed, May 24, 2017 at 12:06 AM, Dave Airlie wrote: > From: Dave Airlie > > This interface will allow sync object to be used to back > Vulkan fences. This API is pretty much the vulkan fence waiting > API, and I've ported the code from amdgpu. > > v2:

Re: [PATCH 1/5] drm: introduce sync objects (v3)

I can't really review for all of the kernel details (though the seem ok to me) so this mostly applies to the API: Reviewed-by: Jason Ekstrand <ja...@jlekstrand.net> On Wed, May 24, 2017 at 12:06 AM, Dave Airlie <airl...@gmail.com> wrote: > From: Dave Airlie <airl...@redhat.com

Re: [PATCH 3/5] drm/syncobj: add sync_file interaction.

Yes, I believe this is the proper way for sync_file and syncobj to interact. Again, I can't really review for all of the kernel details (though the seem ok to me) so this mostly applies to the API: Reviewed-by: Jason Ekstrand <ja...@jlekstrand.net> On Wed, May 24, 2017 at 12:06 AM, Dave

Re: [PATCH 3/6] drm: add support of syncobj timeline point wait v2

IT_COMPLETED > > DRM_SYNCOBJ_WAIT_FLAGS_WAIT_AVAILABLE > Those seem like fine names to me. We should require that one of the two flags be present when the sync object is a timeline. --Jason > Thanks, > > David > > > > *From:* Christian König > *Sent:* Tuesday,

Re: [PATCH 3/6] drm: add support of syncobj timeline point wait v2

On Thu, Sep 20, 2018 at 6:04 AM Chunming Zhou wrote: > points array is one-to-one match with syncobjs array. > v2: > add seperate ioctl for timeline point wait, otherwise break uapi. > I think ioctl structs can be extended as long as fields aren't re-ordered. I'm not sure on the details of this

Re: [PATCH 02/11] dma-buf: add new dma_fence_chain container v4

On Fri, Feb 15, 2019 at 9:52 AM Lionel Landwerlin via dri-devel < dri-de...@lists.freedesktop.org> wrote: > On 15/02/2019 14:32, Koenig, Christian wrote: > > Am 15.02.19 um 15:23 schrieb Lionel Landwerlin: > >> Hi Christian, David, > >> > >> For timeline semaphore we need points to signaled in

Re: [PATCH 02/11] dma-buf: add new dma_fence_chain container v4

On Fri, Feb 15, 2019 at 12:33 PM Koenig, Christian wrote: > Am 15.02.19 um 19:16 schrieb Jason Ekstrand: > > On Fri, Feb 15, 2019 at 11:51 AM Christian König < > ckoenig.leichtzumer...@gmail.com> wrote: > >> Am 15.02.19 um 17:49 schrieb Jason Ekstrand: >> &

Re: [PATCH 02/11] dma-buf: add new dma_fence_chain container v4

On Fri, Feb 15, 2019 at 11:51 AM Christian König < ckoenig.leichtzumer...@gmail.com> wrote: > Am 15.02.19 um 17:49 schrieb Jason Ekstrand: > > On Fri, Feb 15, 2019 at 9:52 AM Lionel Landwerlin via dri-devel < > dri-de...@lists.freedesktop.org> wrote: > >> On 15

Re: [Intel-gfx] [Mesa-dev] gitlab.fd.o financial situation and impact on services

On Fri, Feb 28, 2020 at 11:00 AM Rob Clark wrote: > > On Fri, Feb 28, 2020 at 3:43 AM Michel Dänzer wrote: > > > > On 2020-02-28 10:28 a.m., Erik Faye-Lund wrote: > > > > > > We could also do stuff like reducing the amount of tests we run on each > > > commit, and punt some testing to a

Re: [Mesa-dev] [Intel-gfx] gitlab.fd.o financial situation and impact on services

On Sat, Feb 29, 2020 at 3:47 PM Timur Kristóf wrote: > > On Sat, 2020-02-29 at 14:46 -0500, Nicolas Dufresne wrote: > > > > > > 1. I think we should completely disable running the CI on MRs which > > > are > > > marked WIP. Speaking from personal experience, I usually make a lot > > > of > > >

Re: [Intel-gfx] [Mesa-dev] gitlab.fd.o financial situation and impact on services

I don't think we need to worry so much about the cost of CI that we need to micro-optimize to to get the minimal number of CI runs. We especially shouldn't if it begins to impact coffee quality, people's ability to merge patches in a timely manner, or visibility into what went wrong when CI

Re: [Intel-gfx] [Mesa-dev] gitlab.fd.o financial situation and impact on services

> Le dimanche 01 mars 2020 à 14:18 -0600, Jason Ekstrand a écrit : > > I've seen a number of suggestions which will do one or both of those things > > including: > > > > - Batching merge requests > > Agreed. Or at least I foresee quite complicated code to handl

Re: [PATCH 09/11] drm, cgroup: Introduce lgpu as DRM cgroup resource

On Fri, Feb 14, 2020 at 11:08 AM Kenny Ho wrote: > > Hi Jason, > > Thanks for the review. > > On Fri, Feb 14, 2020 at 11:44 AM Jason Ekstrand wrote: > > > > Pardon my ignorance but I'm a bit confused by this. What is a "logical > > GPU"? What

Re: [PATCH 09/11] drm, cgroup: Introduce lgpu as DRM cgroup resource

Pardon my ignorance but I'm a bit confused by this. What is a "logical GPU"? What are we subdividing? Are we carving up memory? Compute power? Both? If it's carving up memory, why aren't we just measuring it in megabytes? If it's carving up compute power, what's actually being carved up?

Re: [PATCH 09/11] drm, cgroup: Introduce lgpu as DRM cgroup resource

On Fri, Feb 14, 2020 at 10:44 AM Jason Ekstrand wrote: > > Pardon my ignorance but I'm a bit confused by this. What is a "logical GPU"? > What are we subdividing? Are we carving up memory? Compute power? Both? > > If it's carving up memory, why aren't we just

Re: [Mesa-dev] XDC 2020 feedback and comments

First off, I think you all did a fantastic job. I felt that things ran very smoothly and, as far as the talks themselves go, I think it went almost as smoothly as an in-person XDC. I'm really quite impressed. I do have a couple pieces of more nuanced feedback: 1. I think we were maybe a bit

Re: [PATCH 1/2] dma-buf.rst: Document why indefinite fences are a bad idea

This matches my understanding for what it's worth. In my little bit of synchronization work in drm, I've gone out of my way to ensure we can maintain this constraint. Acked-by: Jason Ekstrand On Thu, Jul 9, 2020 at 7:33 AM Daniel Vetter wrote: > > Comes up every few years, gets so