ROCm Media - Dependency: amd-mesa

[kiritigowda]

Motivation

Add rocDecode/rocJPEG dependency - AMD MESA - into system deps

Technical Details

Infrastructure required to build ROCm media projects - rocDecode and rocJPEG

Test Plan

Current tests

Test Result

All current tests should pass and mesa libraries generated

Submission Checklist

• [x ] Look over the contributing guidelines at https://github.com/ROCm/ROCm/blob/develop/CONTRIBUTING.md#pull-requests.

[kiritigowda]

@jayhawk-commits - This PR requires libva-dev package to build. Can you help install this into the CI

[jayhawk-commits]

@jayhawk-commits - This PR requires libva-dev package to build. Can you help install this into the CI

I would like @stellaraccident to comment on the prospect of inclusion of libva-dev, if adding to the docker image would suffice.

[stellaraccident]

Looks like a good start. I'll review in detail in a bit. Regarding libva-dev, my suspicion is that we need to add that to sysdeps too. But there is a gray area here that depends on the abi stability of libva backend plugins. Basically: if we tell users to separately install libva and the plug-in we deliver can work across all libva versions (not just the one we compiled for), then it may be viable to add it to the docker image vs building it in sysdeps. But there would still be a product call in that.

[jayhawk-commits]

So to add libva-dev into the docker image, you can create a branch name prefixed with stage/docker/** that updates this manylinux dockerfile with the appropriate yum package. This workflow will automatically create a new docker image on pushes to that branch. Then you can use that docker image for your work.

For the building in sysdeps approach that @stellaraccident cites, please take a look at the examples in the source tree here.

[stellaraccident]

To be clear - I won't approve -devel packages added to the base docker image without understanding that it is the right thing technically to be doing. And it is often not.

But feel free to experiment.

[thaithong]

This just got merged into the upstream Mesa: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38271

Not sure if it will help? It allows for the libva source code to be downloaded at compile time, and then installed when Mesa is installed.

To use it, specify -Dallow-fallback-for=libva -Dforce_fallback_for=libva when using meson setup/meson configure.

---

It's already in mesa-fork by the way: ROCm/mesa-fork@2ab4ac8

[stellaraccident]

This just got merged into the upstream Mesa: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38271

Not sure if it will help? It allows for the libva source code to be downloaded at compile time, and then installed when Mesa is installed.

To use it, specify -Dallow-fallback-for=libva -Dforce_fallback_for=libva when using meson setup/meson configure.

It's already in mesa-fork by the way: ROCm/mesa-fork@2ab4ac8

Redistributing system libraries on Linux (which is what this would be) as part of a shared library ecosystem like rocm is a tricky endeavor. We evaluate and implement each one individually to ensure that our customers don't need to link to something that will conflict. It may not look like it, but every library in third-party has been evaluated (and sometimes retrofitted) with respect to integration approach that is expected to meet this goal.

If the resulting libradeonsi.so is just using libva to produce a plug-in that works with any version of libva, then this mechanism would be fine. If the libva it is downloading needs to be distributed (because there is a dt_needed to it) then it would not.

Then the bigger question is whether we want users of the rocm SDK rocdecode/jpeg to have to install a libva system package to access the functionality. That would currently be a change of requirements for rocm overall. We may choose to go that way, but it would be the first time we've chosen that, and we have strong feedback from key customers that this stance causes problems.

If the first thing is true and we would like time to redistribute libva properly, then we can temporarily add it to the build docker image, but we then have to do the work to properly build it for redistribution before the next release.