Dynamic loading of libdrm and libdrm_amdgpu

[Umio-Yasuno]

libdrm_amdgpu_sys 0.8.0 supports dynamic loading.
Now LACT supports GPUs from multiple vendors, so dynamic loading would be better.

[ilya-zlobintsev]

Dynamic loading would make sense, though it is not a requirement as libdrm is something that is usually present on every system, even when using nvidia proprietary drivers.

However, I have one concern with this: what are the backwards compatibility guarantees of the libdrm API? Could the symbols change or be removed in an update? Currently this would lead to a link-time error, which is easier to catch than a runtime one when a function symbol fails to load (or even worse, have the wrong signature).

[ilya-zlobintsev]

I don't believe this needs to be wrapped in an Rc, as LibDrmAmdgpu is a cloneable struct with Arcs internally: https://github.com/Umio-Yasuno/libdrm-amdgpu-sys-rs/blob/main/lib.rs#L75

[Umio-Yasuno]

Done.

af7aecc

[Umio-Yasuno]

Dynamic loading would make sense, though it is not a requirement as libdrm is something that is usually present on every system, even when using nvidia proprietary drivers.

For users who only use NVIDIA GPUs, there is less need to be concerned about libdrm_amdgpu by dynamic loading.

However, I have one concern with this: what are the backwards compatibility guarantees of the libdrm API? Could the symbols change or be removed in an update? Currently this would lead to a link-time error, which is easier to catch than a runtime one when a function symbol fails to load (or even worse, have the wrong signature).

Runtime errors can probably occur with dynamic linking, even if not dynamic loading.
Umio-Yasuno/amdgpu_top#17

[ilya-zlobintsev]

I'll merge this as is since it turns out the mismatched header problem is already a possibility before this PR, but I would like to continue the discussion in Umio-Yasuno/libdrm-amdgpu-sys-rs#9