> 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. Regards, Jammy -----Original Message----- From: Alex Deucher [mailto:alexdeucher@xxxxxxxxx] Sent: Friday, May 29, 2015 10:09 PM To: Emil Velikov Cc: Zhou, Jammy; Deucher, Alexander; Min, Frank; dri-devel@xxxxxxxxxxxxxxxxxxxxx Subject: Re: [PATCH] Add device enumeration interface (v3) On Thu, May 28, 2015 at 10:22 AM, Emil Velikov <emil.l.velikov@xxxxxxxxx> wrote: > Hi Alex, > > On 28 May 2015 at 14:16, Alex Deucher <alexdeucher@xxxxxxxxx> wrote: >> On Thu, May 28, 2015 at 8:44 AM, Emil Velikov <emil.l.velikov@xxxxxxxxx> wrote: >>> On 25 May 2015 at 12:18, Zhou, Jammy <Jammy.Zhou@xxxxxxx> 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. Alex > > Thanks > Emil _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
