On Thu, Aug 31, 2023 at 10:31:07AM +0200, Daniel Vetter wrote: > On Tue, Aug 29, 2023 at 12:30:01PM -0400, Rodrigo Vivi wrote: > > Also the uapi should be reviewed and scrutinized before xe > > is accepted upstream and we shouldn't cause regression. > > > > Link: https://lore.kernel.org/all/20230630100059.122881-1-thomas.hellstrom@xxxxxxxxxxxxxxx > > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@xxxxxxxxx> > > On the series: > > Acked-by: Daniel Vetter <daniel.vetter@xxxxxxxx> Thank you > > But also, I really don't want to be the gatekeeper for "is xe ready for > merging", It makes sense. I'm also cc'ing the folks you mentioned here so they are aware on why I would be pinging them asking for acks on the follow-up patches. Also I'd like to mention that we have already addressed almost all of the critical items found by Oded, and we will soon open gitlab issues for the items he agreed that will be nice to have. Another front of getting Xe really ready is the uAPI review. We have identified the items that we need to change before we are ready for our first pull-request: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues?label_name=Fix-for-upstream now back to this xe.rst updates: > so at least for the last two patches I think an ack from Danilo > that there's indeed a rough consensus/plan is much more important than my > own. The first two don't need that, because there was no "build dri-devel > consensus" aspect to those. Agreed. > > And for the sched side I guess an ack from Christian or maybe some of the > other in-flight drivers (Lina or Boris?), with maybe an ack from Danilo > for the long running compute stuff (or whoever cares about that, I don't > think amd is working on extracting the amdkfd trickery, but maybe they > need the sched support when they add real compute to the render driver > too) is again much more important than me dropping an ack from the > sidelines. Yeap, that long-running patch is out of this series for now. Let's first get these ones in so we start to mark little by little what is completed. On that long-running one, I have chatted with Alex and the goal for the amd compute is to really use the userspace queue for any kind of compute and long-running. And the only thing that I could spot on their code that could be similar is the their eviction_fences vs our preempt_fences. But I don't see much value on having another layer for that instead of using the dma_fences directly. But as I told, let's first get these 4 updates in and next I will send only the long-running one cc'ing all the mentioned folks so we can agree on a consensus around the long-running. Thanks, Rodrigo > > Cheers, Sima > > > --- > > Documentation/gpu/rfc/xe.rst | 6 ------ > > 1 file changed, 6 deletions(-) > > > > diff --git a/Documentation/gpu/rfc/xe.rst b/Documentation/gpu/rfc/xe.rst > > index 2516fe141db6..3d2181bf3dad 100644 > > --- a/Documentation/gpu/rfc/xe.rst > > +++ b/Documentation/gpu/rfc/xe.rst > > @@ -67,12 +67,6 @@ platforms. > > > > When the time comes for Xe, the protection will be lifted on Xe and kept in i915. > > > > -Xe driver will be protected with both STAGING Kconfig and force_probe. Changes in > > -the uAPI are expected while the driver is behind these protections. STAGING will > > -be removed when the driver uAPI gets to a mature state where we can guarantee the > > -‘no regression’ rule. Then force_probe will be lifted only for future platforms > > -that will be productized with Xe driver, but not with i915. > > - > > Xe – Pre-Merge Goals > > ==================== > > > > -- > > 2.41.0 > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch
