All of lore.kernel.org
 help / color / mirror / Atom feed
From: kode54@gmail.com
To: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: "Hazubski, Filip" <filip.hazubski@intel.com>,
	"Yu, Effie" <effie.yu@intel.com>,
	intel-xe@lists.freedesktop.org, "Vivi,
	Rodrigo" <rodrigo.vivi@intel.com>
Subject: Re: [Intel-xe] [PATCH v2 0/2] Update Xe uAPI in a minimally invasive way
Date: Thu, 25 May 2023 08:48:37 -0700	[thread overview]
Message-ID: <1918VR.US05UYXGP19H3@gmail.com> (raw)
In-Reply-To: <can3buqui3msmblc7bkxo7mb5nfwpdlmsg7abo4sit2hqgpc33@rukg2yblkk67>

[-- Attachment #1: Type: text/plain, Size: 3320 bytes --]



On Thu, May 25 2023 at 08:13:43 AM -07:00:00, Lucas De Marchi 
<lucas.demarchi@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.

> 
> Lucas De Marchi
> 
>> It should not break 64 bits ABI but would be good to update 
>> intel-compute and media as well.
>> 
>> On Wed, 2023-05-24 at 18:56 -0700, Christopher Snowhill wrote:
>>> This series takes off from mlankhorst's attempt to do the same, 
>>> except
>>> instead, it tries to be as minimally invasive to the original uAPI 
>>> as
>>> possible, by only inserting padding where appropriate to ensure all
>>> 32-bit members are 32-bit aligned, and all 64-bit members are 64-bit
>>> aligned. This should have zero effect on 64-bit hosts versus 64-bit
>>> userspace, so existing native software will operate the same with or
>>> without the update. The only real change is 32-bit compat support 
>>> for
>>> multilib userspace, which was previously broken.
>>> 
>>> Also introduces field validation against all of the padding and
>>> reserved fields, which must be zero, in a separate commit.
>>> 
>>> v2:
>>>   Removed extensions checks where there were none originally. 
>>> (José)
>>>   Moved extraneous parentheses to the correct places. (Lucas)
>>> 
>>> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com 
>>> <mailto:maarten.lankhorst@linux.intel.com>>
>>> Signed-off-by: Christopher Snowhill <kode54@gmail.com 
>>> <mailto:kode54@gmail.com>>
>>> 
>>> Christopher Snowhill (2):
>>>   drm/xe: Add explicit padding to uAPI definition
>>>   drm/xe: Validate uAPI padding and reserved fields
>>> 
>>>  drivers/gpu/drm/xe/xe_bo.c              |  6 +++--
>>>  drivers/gpu/drm/xe/xe_engine.c          | 18 ++++++++++---
>>>  drivers/gpu/drm/xe/xe_exec.c            |  4 ++-
>>>  drivers/gpu/drm/xe/xe_mmio.c            |  3 ++-
>>>  drivers/gpu/drm/xe/xe_query.c           |  3 ++-
>>>  drivers/gpu/drm/xe/xe_sync.c            |  4 ++-
>>>  drivers/gpu/drm/xe/xe_vm.c              | 22 +++++++++++++---
>>>  drivers/gpu/drm/xe/xe_vm_madvise.c      |  4 ++-
>>>  drivers/gpu/drm/xe/xe_wait_user_fence.c |  3 ++-
>>>  include/uapi/drm/xe_drm.h               | 34 
>>> ++++++++++++++++++++++++-
>>>  10 files changed, 85 insertions(+), 16 deletions(-)
>>> 
>> 


[-- Attachment #2: Type: text/html, Size: 3764 bytes --]

  reply	other threads:[~2023-05-25 15:48 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-25  1:56 [Intel-xe] [PATCH v2 0/2] Update Xe uAPI in a minimally invasive way Christopher Snowhill
2023-05-25  1:56 ` [Intel-xe] [PATCH v2 1/2] drm/xe: Add explicit padding to uAPI definition Christopher Snowhill
2023-05-25  1:56 ` [Intel-xe] [PATCH v2 2/2] drm/xe: Validate uAPI padding and reserved fields Christopher Snowhill
2023-05-25 13:18   ` Souza, Jose
2023-05-25 13:52     ` Christopher Snowhill
2023-05-25 14:16       ` Souza, Jose
2023-05-25  1:59 ` [Intel-xe] ✓ CI.Patch_applied: success for Update Xe uAPI in a minimally invasive way (rev2) Patchwork
2023-05-25  2:00 ` [Intel-xe] ✓ CI.KUnit: " Patchwork
2023-05-25  2:04 ` [Intel-xe] ✓ CI.Build: " Patchwork
2023-05-25  2:32 ` [Intel-xe] ○ CI.BAT: info " Patchwork
2023-05-25 13:24 ` [Intel-xe] [PATCH v2 0/2] Update Xe uAPI in a minimally invasive way Souza, Jose
2023-05-25 13:28   ` Souza, Jose
2023-05-25 14:27     ` Francois Dugast
2023-05-25 13:39   ` Christopher Snowhill
2023-05-25 15:13   ` Lucas De Marchi
2023-05-25 15:48     ` kode54 [this message]
2023-05-25 19:12       ` Lucas De Marchi
2023-05-25 19:43         ` Souza, Jose
2023-05-25 22:44           ` Christopher Snowhill
2023-05-25 22:46             ` Lucas De Marchi
2023-05-26  0:23               ` Christopher Snowhill
2023-05-26  0:33                 ` Christopher Snowhill
2023-05-26  6:02                   ` Lucas De Marchi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1918VR.US05UYXGP19H3@gmail.com \
    --to=kode54@gmail.com \
    --cc=effie.yu@intel.com \
    --cc=filip.hazubski@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=lucas.demarchi@intel.com \
    --cc=rodrigo.vivi@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.