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

[Christopher Snowhill]

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'd like to consider his attempt again, but I forget if it had any
> >outstanding issues, other than the need to split the patches.