Hi Emil,
With our previous RFC patches to add interfaces to support GPU device enumeration support in libdrm, the udev mechanism was used. But we found that if we introduce the libudev dependency for libdrm, there will be some problem to run steam application on recent distributions (for example, Ubuntu 14.04 LTS) because of the conflict between the system libudev.so.1 (loaded by libdrm) and the libudev.so.0 (bundled in steam-runtime and loaded by steam application). There are some similar issues as mentioned in the links below. Although we can argue that it is application's problem, can we get rid of libudev for the device enumeration before Valve can make steam-runtime use system libraries by default? It is much appreciated if you can give some suggestions about how we can support device enumeration with libdrm.
https://wiki.debian.org/Steam https://github.com/ValveSoftware/steam-runtime/issues/13
Regards, Jammy
Hello Jammy,
On 8 July 2015 at 06:53, Zhou, Jammy Jammy.Zhou@amd.com wrote:
Hi Emil,
With our previous RFC patches to add interfaces to support GPU device enumeration support in libdrm, the udev mechanism was used. But we found that if we introduce the libudev dependency for libdrm, there will be some problem to run steam application on recent distributions (for example, Ubuntu 14.04 LTS) because of the conflict between the system libudev.so.1 (loaded by libdrm) and the libudev.so.0 (bundled in steam-runtime and loaded by steam application). There are some similar issues as mentioned in the links below. Although we can argue that it is application’s problem, can we get rid of libudev for the device enumeration before Valve can make steam-runtime use system libraries by default? It is much appreciated if you can give some suggestions about how we can support device enumeration with libdrm.
I believe I mentioned it before, perhaps I wasn't clear enough. Rather than using libudev, manually iterate through sysfs. I agree it's not a not pretty solution yet the libdrm code already has much weirder stuff.
Cheers Emil
Although I don't like the method of manually iterating sysfs, it seems the last resort if we want to avoid introducing libudev dependency.
Besides, you mentioned that you would spend some time on the device enumeration interface, do you have some chance to look at it?
Regards, Jammy
-----Original Message----- From: Emil Velikov [mailto:emil.l.velikov@gmail.com] Sent: Thursday, July 09, 2015 12:25 AM To: Zhou, Jammy Cc: dri-devel@lists.freedesktop.org Subject: Re: Device enumeration support in libdrm
Hello Jammy,
On 8 July 2015 at 06:53, Zhou, Jammy Jammy.Zhou@amd.com wrote:
Hi Emil,
With our previous RFC patches to add interfaces to support GPU device enumeration support in libdrm, the udev mechanism was used. But we found that if we introduce the libudev dependency for libdrm, there will be some problem to run steam application on recent distributions (for example, Ubuntu 14.04 LTS) because of the conflict between the system libudev.so.1 (loaded by libdrm) and the libudev.so.0 (bundled in steam-runtime and loaded by steam application). There are some similar issues as mentioned in the links below. Although we can argue that it is application’s problem, can we get rid of libudev for the device enumeration before Valve can make steam-runtime use system libraries by default? It is much appreciated if you can give some suggestions about how we can support device enumeration with libdrm.
I believe I mentioned it before, perhaps I wasn't clear enough. Rather than using libudev, manually iterate through sysfs. I agree it's not a not pretty solution yet the libdrm code already has much weirder stuff.
Cheers Emil
On 9 July 2015 at 03:26, Zhou, Jammy Jammy.Zhou@amd.com wrote:
Although I don't like the method of manually iterating sysfs, it seems the last resort if we want to avoid introducing libudev dependency.
I have the same feeling, so if anyone can come with an better solution I'm all ears.
Besides, you mentioned that you would spend some time on the device enumeration interface, do you have some chance to look at it?
Not really bth. Waiting for a month someone to ack the revert inspired me to push this at the bottom on my list. Now that there is some interest I'll bring it back up.
-Emil
Dropping dri-devel for a second.
Hi Jammy,
On 10 July 2015 at 18:56, Emil Velikov emil.l.velikov@gmail.com wrote:
On 9 July 2015 at 03:26, Zhou, Jammy Jammy.Zhou@amd.com wrote:
Although I don't like the method of manually iterating sysfs, it seems the last resort if we want to avoid introducing libudev dependency.
I have the same feeling, so if anyone can come with an better solution I'm all ears.
Besides, you mentioned that you would spend some time on the device enumeration interface, do you have some chance to look at it?
Not really bth. Waiting for a month someone to ack the revert inspired me to push this at the bottom on my list. Now that there is some interest I'll bring it back up.
I've been looking at this over the last few days, aiming for a compatible solution and it has been proving a bit annoying. Mostly due to the way any platform devices interact with the UNIQUE ioctls.
Namely the goal is to have drmGetDevices() provide bus information that can be used with conjunction with drmOpen and (optionally) drmGetBusid.
Can you help me out, understand how you're going to be using this, such that I don't butcher things. In what formal should the bus information be - are your intentions solely on feeding that to drmOpen() or is the user going to do something with it ?
Would providing the vendor/device id (via drmGetDevices) suffice or you guys need the sub{vendor,device} rev as well ?
Thanks Emil
dri-devel@lists.freedesktop.org
-
Emil Velikov -
Zhou, Jammy