winsys/amdgpu: make amdgpu_winsys_create private
What does this MR do and why?
Is it a supported usecase where radeonsi_dri.so and radeonsi_drv_video.so 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
- live with the increated gpu hangs if the increase is acceptable, or
- disable hw decoding and live with increased power consumption
That's why we are exploring decoupling radeonsi_dri.so and radeonsi_drv_video.so.
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 (radeonsi_dri.so,
radeonsi_drv_video.so, 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.