[Intel-xe] [PATCH 1/4] drm/doc/rfc: No STAGING out of drivers/staging.

[Rodrigo Vivi]

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@linux.intel.com
> > Signed-off-by: Rodrigo Vivi <rodrigo.vivi at intel.com>
> 
> On the series:
> 
> Acked-by: Daniel Vetter <daniel.vetter at ffwll.ch>

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