Re: [RFC PATCH] drm/xe/uapi: Remove support for persistent exec_queues

[Rodrigo Vivi <rodrigo.vivi@intel.com>]

On Thu, Feb 01, 2024 at 05:41:27AM +1000, Dave Airlie wrote:
> On Tue, 30 Jan 2024 at 22:52, Thomas Hellström
> <thomas.hellstrom@linux.intel.com> wrote:
> >
> > Persistent exec_queues delays explicit destruction of exec_queues
> > until they are done executing, but destruction on process exit
> > is still immediate. It turns out no UMD is relying on this
> > functionality, so remove it. If there turns out to be a use-case
> > in the future, let's re-add.
> >
> > Persistent exec_queues were never used for LR VMs
> >
> > Open: Should we renumber the exec_queue properties, or leave a hole
> > as in this patch.
> 
> 
> So can we have a bit of insight into how this happened? Like we just
> merged xe and it already has uapi that had no userspace?

I'm really sorry about that Dave.
In the past months I personally run an uapi clean-up removing everything
that was not used and this was a miss.

> 
> Like seriously? I'm sorry Intel has all these crazy silos with
> compute, video, graphics and kernel teams, but that should be Intel's
> internal problem, can we stop exposing your org chart outside the
> company?
> 
> If you can't get someone from the compute team to work in the kernel
> driver space when a new uAPI is needed, and instead powerpoint up
> uAPIs without commitments, then xe is going to end up being in the
> same hole as i915.

I guarantee to you that this this time, it was not the case. No uapi that
we have in Xe came from powerpoints. And it shouldn't had come from
internal branches as well.

I'm afraid that Xe stayed for too long out of the tree without a proper
scrutiny on the uapi, favoring fast moves to get it working.

Anyway, in this very specific case, this was a poor copy of the internal-i915.
While it shouldn't.

And it shouldn't be there in i915-internal anyway as well.
The I915_CONTEXT_PARAM_PERSISTENCE shouldn't even be part of the
i915-internal/DII's include/uapi/drm/i915_drm.h to start with.
What ever non-upstream uapi in that internal i915 should be part of a separate
header: i915_drm_prelim.h.

It was a escape there, wrongly ported over Xe
without scrutiny and then my personal escape while cleaning things up
before getting it merged.

Sorry,
Rodrigo.

>
> Dave.