Skip to content

winsys/amdgpu: make amdgpu_winsys_create private

Chia-I Wu requested to merge olv/mesa:radeonsi-dri-vaapi into main

What does this MR do and why?

Is it a supported usecase where and are built from different Mesa versions? We (Chrome OS) were told yes, and from a quick test, it seems that can work after making amdgpu_winsys_create private. Thanks to commit 50d20dc0 and commit 923758a5, it seems amdgpu_winsys_create can be safely made private again.

From our experiences, we often see increased video-related gpu hangs in the field after updating the Mesa drivers. Sometimes, we don't have a repro and are forced to

  1. live with the increated gpu hangs if the increase is acceptable, or
  2. disable hw decoding and live with increased power consumption

That's why we are exploring decoupling and

From the commit message,

winsys/amdgpu: make amdgpu_winsys_create private

Because amdgpu_winsys_create is public, it becomes a part of the ABI
between different driver binaries (,, etc.).  A process loading more than one driver
binaries can run into ABI compat issues if the binaries are built from
different Mesa versions.  Hiding amdgpu_winsys_create solves the issues.

Historically, amdgpu_winsys_create was made public in commit 18b12bf5335
("targets: export radeon winsys_create functions to silence LLVM
warning").  That became insufficient over time and commit 50d20dc055d
("ac/llvm: export ac_init_llvm_once in targets") solved the same issue
again in a nicer way.

A public amdgpu_winsys_create actually solved another issue which was
better solved by commit 923758a5c22 ("winsys/amdgpu: use
amdgpu_device_get_fd").  Now that we have both commits, we can hide
amdgpu_winsys_create again.

Note that this hides amdgpu_winsys_create but keeps
ac_init_shared_llvm_once (and radeon_drm_winsys_create) public.  As
such, ac_init_shared_llvm_once is still a part of the ABI unless
-Dllvm=disabled or -Dshared-llvm=disabled is specified.

Merge request reports