diff mbox series

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

Message ID 20230829163005.54067-1-rodrigo.vivi@intel.com (mailing list archive)
State New, archived
Headers show
Series [1/4] drm/doc/rfc: No STAGING out of drivers/staging. | expand

Commit Message

Rodrigo Vivi Aug. 29, 2023, 4:30 p.m. UTC
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@intel.com>
---
 Documentation/gpu/rfc/xe.rst | 6 ------
 1 file changed, 6 deletions(-)

Comments

Lucas De Marchi Aug. 29, 2023, 5:35 p.m. UTC | #1
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@intel.com>

Agreed. The STAGING config is something specifically for drivers/staging
as noted in the previous discussion. If other subsystems want to re-use
it, then there would be more to do to cause a taint.  It could also be
confusing to cause that taint for drivers outside drivers/staging.

Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>

Lucas De Marchi

>---
> 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 Aug. 31, 2023, 8:31 a.m. UTC | #2
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@intel.com>

On the series:

Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>

But also, I really don't want to be the gatekeeper for "is xe ready for
merging", 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.

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.

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
>
Rodrigo Vivi Aug. 31, 2023, 7:08 p.m. UTC | #3
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@intel.com>
> 
> On the series:
> 
> Acked-by: Daniel Vetter <daniel.vetter@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
diff mbox series

Patch

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
 ====================