[PATCH] Add device enumeration interface (v3)
Frank.Min at amd.com
Sun May 31 20:06:50 PDT 2015
Here is the pseudo code:
int drmGetPciDevices(drmPciDevicePtr devSet, uint16_t vendorId)
If(devSet == NULL && vendorId == 0)
Probe all the graphic device and return the number of it
Else If(devSet != NULL && vendorId != 0)
Probe the specific vender graphic device and return it in the array devSet
Else If(devSet ==NULL && vendorId != 0)
Probe the specific vendorId graphic device and return the number of it
Should not happen
From: Zhou, Jammy
Sent: Monday, June 01, 2015 10:12 AM
To: Alex Deucher; Emil Velikov
Cc: Deucher, Alexander; Min, Frank; dri-devel at lists.freedesktop.org
Subject: RE: [PATCH] Add device enumeration interface (v3)
> Jammy or Frank might be able to provide some pseudo code in the interim.
I think the requirement here is quite simple. We would like to have some interface to enumerate the GPU devices on the system, and select some specific device for different purposes (i.e, rendering, computing, displaying, etc). Current libdrm interfaces are just for single device, and there is no good consideration for multiple GPUs yet.
From: Alex Deucher [mailto:alexdeucher at gmail.com]
Sent: Friday, May 29, 2015 10:09 PM
To: Emil Velikov
Cc: Zhou, Jammy; Deucher, Alexander; Min, Frank; dri-devel at lists.freedesktop.org
Subject: Re: [PATCH] Add device enumeration interface (v3)
On Thu, May 28, 2015 at 10:22 AM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> Hi Alex,
> On 28 May 2015 at 14:16, Alex Deucher <alexdeucher at gmail.com> wrote:
>> On Thu, May 28, 2015 at 8:44 AM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>>> On 25 May 2015 at 12:18, Zhou, Jammy <Jammy.Zhou at amd.com> wrote:
>>>> Hi Emil,
>>>> Do you have chance to have a look at this new version? Thanks!
>>> Hi guys sorry for the delay.
>>> Looking at my original email response it seems that I wasn't clear
>>> enough about my concerns. They can be looked at as independent
>>> and/or grouped up, depending on your liking:
>>> - Adding a new interface using which it's not obvious how one can
>>> simplify/ease existing related implementations.
>>> As mentioned before, the claiming duplication that already exists is
>>> more complete than this API.
>>> - No open-source software uses the interface.
>>> Do you have any patches in progress that convert project foo to
>>> using the API? Otherwise is seems like an open-source project
>>> catering after a closed source project needs.
>> It's actually in preparation for upcoming open source releases.
> Ack. Fair enough - the commit message did not mention any open source
> users. The follow-up response mentioned xserver and mesa for which
> this API doesn't seem like a good fit.
>>> - Adding new dependencies.
>>> Previously libpciaccess, now libudev. The former is used only by a
>>> single function in libdrm_intel, while the latter was optional. v3
>>> makes the use of libudev a hard requirement.
>>> Using the library in mesa has caused problems with Steam (and
>>> possibly other binary programs/games) which ships their own version
>>> of various libraries.
>> Can you think of a better method for device enumeration? Rolling our
>> own seem like a waste of effort.
> Implementation might be uglier (as do other parts of libdrm), but I
> can envision an API that does not require a new dependency, plus it
> works with platform devices. So I'm not sure if it qualifies as better
> or not.
>>> Now that the patch is merged, the last issue has emerged (in a
>>> particular form). Is there any plan to convert an open-source
>>> project to use this API ?
>> The first users actually will be open source they are just not ready
>> for public release just yet. We are trying to reduce our internal
>> patch queue and get stuff upstream early and thought others might be
>> interested, but if there are concerns we can revert it for now and
>> re-submit it when we are ready to release the relevant code.
> If you can share some pseudo code on what the requirements are/how it
> should be used I can prep an alternative solution. A one that works
> for your usecase and existing ones. In the mean while can we revert
> it, pretty please ?
Sure, go for it. Jammy or Frank might be able to provide some pseudo code in the interim.
More information about the dri-devel