[Intel-xe] [PATCH v2 0/2] Update Xe uAPI in a minimally invasive way

[Christopher Snowhill]

On Thu, May 25, 2023 at 5:23 PM Christopher Snowhill <kode54 at gmail.com> wrote:
>
> On Thu, May 25, 2023 at 3:47 PM Lucas De Marchi
> <lucas.demarchi at intel.com> wrote:
> >
> > On Thu, May 25, 2023 at 03:44:08PM -0700, Christopher Snowhill wrote:
> > >On Thu, May 25, 2023 at 12:44 PM Souza, Jose <jose.souza at intel.com> wrote:
> > >>
> > >> On Thu, 2023-05-25 at 12:12 -0700, Lucas De Marchi wrote:
> > >> > On Thu, May 25, 2023 at 08:48:37AM -0700, kode54 at gmail.com wrote:
> > >> > >
> > >> > >
> > >> > > On Thu, May 25 2023 at 08:13:43 AM -07:00:00, Lucas De Marchi
> > >> > > <lucas.demarchi at intel.com> wrote:
> > >> > > > On Thu, May 25, 2023 at 01:24:55PM +0000, Jose Souza wrote:
> > >> > > > > Hi
> > >> > > > >
> > >> > > > > Planning to push this today,
> > >> > > > > Christopher already have sent the Mesa MR and IGT patch series.
> > >> > > >
> > >> > > > the whole point of this series is being able to fix it without
> > >> > > > having to
> > >> > > > synchronize with the mesa / media / igt / intel-compute updates. There
> > >> > > > are some reordering in the structs that would better be done before
> > >> > > > applying upstream and when that is done, then we need to sync all the
> > >> > > > UMDs. But not for this.
> > >> > >
> > >> > > Unfortunately, all userspace software which is also built for multilib
> > >> > > must synchronize with this change, or else their 32-bit userspace will
> > >> > > simply fail. In my experience, apps consuming Mesa 32-bit without this
> > >> > > change will fail spectacularly, often crashing on startup.
> > >> > >
> > >> > > I suppose only Mesa really matters, since most users won't be
> > >> > > installing proprietary software that consumes 32-bit OpenCL or VA-API,
> > >> > > but there may yet be cases for that. This is usually proprietary
> > >> > > software, often involving use of Wine, such as Steam's Proton
> > >> > > distribution.
> > >> >
> > >> > yes, but 32bit was never properly supported before this patch. So if
> > >> > they don't synchronize, they will continue in the current state of
> > >> > not working at all.
> > >> >
> > >> > And I'd still try to pack the structs properly before having the
> > >> > definite uapi in place, which only happens when this all is merged
> > >> > upstream, which is *THE* most important synchronization point.
> > >> > I also sync'ed with Jose to clarify on that.
> > >> >
> > >> > I'm about to push it, but since it's your patch I'd rather let you
> > >> > confirm you are ok with it first.
> > >>
> > >> Christopher, until Xe is not enabled by default for the first platform uAPI can break.
> > >>
> > >> Was also about to push this to Xe and Mesa but lets wait for you ack then.
> > >
> > >Yeah, sorry. I was considering Maarten Lankhorst's repacked structure,
> > >but that also resizes several fields to uint64_t, which actually
> > >breaks a few downstream packages I tried it in.
> > >
> > >I guess we can stick with this for now, at least unless someone wants
> > >to rearrange these structures in the near future. At least this way,
> > >maybe we'll get some wider testing done to squash some of the bugs
> > >I've experienced, of which I cannot tell whether it's Mesa or the
> > >kernel driver. Mostly just CCS shenanigans with frame blitting of
> > >large windows or video playback, or sometimes compositor animations.
> > >
> > >I'm not sure, do you think we should hold off until the structure is
> > >repacked? Unfortunately, the last person to attempt a restructuring,
> > >mlankhorst, has appeared to have gone AFK for an extended period, or
> > >is at least occasionally responding to other things on FD.O.
> >
> > reordering and repacking as we noticed may be problematic.
> > I'd just commit this now and leave that part for later.
> >
> > Lucas De Marchi
>
> Acked-by: Christopher Snowhill <kode54 at gmail.com>

I sent the other patch anyway, as a request for commentary, and so it
will be available for a future date. Do not apply.

> > >
> > >I'd like to consider his attempt again, but I forget if it had any
> > >outstanding issues, other than the need to split the patches.