[Mesa-dev] GBM backend dynamic dispatch method

[Axel Davy]

Hi,

I'm not sure if that answers your need, but to me it looks like
it would be simpler if gbm was trying different backends for the given
device, until it succeeds. You'd pass several backends to GBM_BACKEND 
(perhaps
rename to GBM_BACKENDS), and in your example it would put amdgpu pro first.
Then when using the amd card, amdgpu pro would be used, else since the 
loading
would fail, it would use the second backend, which would be mesa.

That's just a suggestion, and you'd better wait for gbm maintainers to 
voice theirs.

Axel

On 12/05/2016 04:45, Yu, Qiang wrote:
>
> Hi guys,
>
>
> Let me introduce myself. My name is Qiang Yu, I'm a developer 
> of amdgpu-pro driver.
>
> As you know the amdgpu-pro adopts some open source part like GBM but 
> due to its
>
> close source OGL part, we implement our own GBM backend.
>
>
> Currently libgbm only support static selection of GBM backend by 
> GBM_BACKEND,
>
> so for the hybrid GPU case like Intel iGPU + AMD dGPU and AMD dGPU is 
> drived
>
> by amdgpu-pro, it's not convenient for client to switch backend all 
> the time and even
>
> impossible for applications that need to deal with both GPUs like the 
> XServer.
>
>
> So I'm wondering a dynamic dispatch method and hope it can go upstream 
> to the libgbm:
>
> 1. create a /etc/gbm/xxx.conf for libgbm to read when none default 
> backend needed
>
> 2. the content should be like: <kernel driver name>:<gbm backend name>
>
>     In the amdgpu-pro case, the content is: amdgpu:gbm_amdgpu.so
>
>
> This method need libgbm use libdrm to determine the FD kernel driver 
> first.
>
> Any feedback on this method and the hope to go upstream?
>
>
> Thanks,
>
> Qiang
>
>
>
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20160512/920822fa/attachment.html>