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

[Lucas De Marchi]

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

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