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 to
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 year
hort order.
Again, sorry I was so terse. I was just trying to slow the panic.
> 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 m
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
fai
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
> > > cha
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 per-weeke
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"?
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&
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? Tim
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:
>>
&
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
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 ord
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,
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
On Wed, Jul 12, 2017 at 9:45 AM, Christian König
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.
>>
>
> I don't t
On Wed, Jul 12, 2017 at 1:39 AM, Dave Airlie wrote:
> On 12 July 2017 at 17:39, Christian König wrote:
> > Am 11.07.2017 um 17:43 schrieb Jason Ekstrand:
> >
> > On Tue, Jul 11, 2017 at 12:17 AM, Christian König <
> deathsim...@vodafone.de>
> > wrote:
> &g
On Tue, Jul 11, 2017 at 12:22 AM, Daniel Vetter 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:
> >
> > > Am 10.07.2017 um 17:52 schrieb
On Tue, Jul 11, 2017 at 12:17 AM, Christian König
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
>>> mailto:deathsim...@vodafone.de>>
From:* amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org
> ] *On Behalf Of *Jason Ekstrand
> *Sent:* Monday, July 10, 2017 11:53 AM
> *To:* Christian König
> *Cc:* Dave Airlie ; Maling list -
> DRI developers
> ; amd-gfx mailing list
>
> *Subject:* Re: [PATCH] drm/s
On Mon, Jul 10, 2017 at 9:15 AM, Christian König
wrote:
> Am 10.07.2017 um 17:52 schrieb Jason Ekstrand:
>
> On Mon, Jul 10, 2017 at 8:45 AM, Christian König
> wrote:
>
>> Am 10.07.2017 um 17:28 schrieb Jason Ekstrand:
>>
>> On Wed, Jul 5, 2017 at 6:04 PM, Da
On Mon, Jul 10, 2017 at 8:45 AM, Christian König
wrote:
> Am 10.07.2017 um 17:28 schrieb Jason Ekstrand:
>
> 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
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: accept relative timeout, pass remaining time
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
On Wed, May 24, 2017 at 12:06 AM, Dave Airlie wrote:
> Fr
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
On Wed, May 24, 2017 at 12:06 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> Sync objects are new toplevel drm object, that contain a
On Wed, May 24, 2017 at 10:25 AM, Jason Ekstrand
wrote:
> 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 waiti
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: accept relative timeout, pass remaining tim
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 sun with these a few times, and
pretty much i
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 its own
> > headers?
>
> not sure, if drm_file
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.
29 matches
Mail list logo
