[PATCH 1/2] Add device enumeration interface (v2)

Emil Velikov emil.l.velikov at gmail.com
Tue Apr 28 09:17:34 PDT 2015


On 28 April 2015 at 04:26, Zhou, Jammy <Jammy.Zhou at amd.com> wrote:
> Hi Emil,
>
> This interface is intended for multiple GPU support. For example, we need to know how many GPU devices are available on the system (and for some specific vendor) in the client drivers, and then we can select proper devices for rendering/compute/etc. For current mesa and Xserver implementations, the device enumeration is done separately. I think it will be helpful if we can have such kind of function in libdrm core, which can also be leveraged by other new APIs requiring multi GPU support.
>
Hmm I'm not sure how the proposed interface will ease either mesa or
xserver's implementation. The former is used only for clover(opencl)
and already handles platform devices. While for the server I believe
(haven't checked) that it just "throws" the PCI device information to
the ddx and lets the latter do its thing.

>> Any particular reason why "3D controller" (0x32000) is omitted ?
> No. For AMD cards, we currently have 0x30000 and 0x38000. Is 0x32000 used by Nvidia cards? If so, I think we should add it as well.
>
What I am thinking is that using heuristics such as these will either
1) work for vendor A but not for B or 2) will be OK for B but will
produce false positives for A.

>> Using libpciaccess, will give you the number of PCI devices available on the system rather than the ones accessible - think about platform devices and/or devices without a drm driver.
> This interface is just to enumerate the PCIE GPU devices on the system. With regard to which ones are accessible, we can use drmOpen/drmOpenWithType to check, and I don't want to have duplicated functionalities for these interfaces. And for those non-PCIE platform devices (mostly on ARM platforms), this interface shouldn't be used, and instead the client drivers should handle it by themselves.
>
I am against duplication, to the point that I may have alienated a
person or two :-\ Although this function as-is won't bring much
benefit to mesa/xserver afaict. Plus it would be nice to keep an open
mind for platform world, so that things will just work when AMD
decides to go that road. Not to mention that iterating through all the
devices in drmOpen* just to find that the device at pci:X:Y provides
only a primary/render node seems a bit wasteful.


A trivial lookup in sysfs will be able to provide all the required
information, won't you agree ?


Cheers,
Emil


More information about the dri-devel mailing list