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

[Lucas De Marchi]

On Thu, May 25, 2023 at 05:33:41PM -0700, Christopher Snowhill wrote:
>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.

applied this one for now so we can get the 32bit support.

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