On Thursday, 13 October 2016, Emil Velikov <<a href="mailto:emil.l.velikov@gmail.com">emil.l.velikov@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 12 October 2016 at 18:59, Axel Davy <<a href="javascript:;" onclick="_e(event, 'cvml', 'axel.davy@ens.fr')">axel.davy@ens.fr</a>> wrote: > On 12/10/2016 19:15, Emil Velikov wrote: >> >> On 11 October 2016 at 19:54, Axel Davy <<a href="javascript:;" onclick="_e(event, 'cvml', 'axel.davy@ens.fr')">axel.davy@ens.fr</a>> wrote: >>> >>> On 11/10/2016 20:31, Emil Velikov wrote: >>>> >>>> - udev = udev_new(); >>>> - if (!udev) >>>> - goto prime_clean; >>>> + if (drmGetDevice(default_fd, &device) != 0) >>>> + goto err; >>>> - default_device_id_path_tag = get_id_path_tag_from_fd(udev, >>>> default_fd); >>>> - if (!default_device_id_path_tag) >>>> - goto udev_clean; >>>> - >>>> - is_different_device = 1; >>>> /* two format are supported: >>>> * "1": choose any other card than the card used by default. >>>> * id_path_tag: (for example "pci-0000_02_00_0") choose the card >>>> * with this id_path_tag. >>>> */ >>>> if (!strcmp(prime,"1")) { >>>> - free(prime); >>>> - prime = strdup(default_device_id_path_tag); >>>> - /* request a card with a different card than the default card */ >>>> - another_tag = 1; >>>> - } else if (!strcmp(default_device_id_path_tag, prime)) >>>> - /* we are to get a new fd (render-node) of the same device */ >>>> - is_different_device = 0; >>>> + /* Hmm... detection for 2-7 seems to be broken. Nicely done. */ >>> >>> For DRI2, DRI_PRIME takes a number corresponding to the device number as >>> configured in xorg (and you have xrandr commands to configure the >>> behaviour). This doesn't work with the DRI3 scheme. However for >>> retrocompatibility, after several discussions, we decided to let DRI2's >>> most >>> used command 'DRI_PRIME=1' to still sorta work on DRI3, but the meaning >>> changed: DRI_PRIME=1 => 'give me any device that is not the >>> compositor/xorg >>> device' >> >> No argument/objection against DRI_PRIME with DRI3, yet the current >> hard coded DRI_PRIME=1 _only_ check is iffy. As per the spec there can >> be 8 devices (0-8) with 0 always being the xorg/compositor one and 1-7 >> as 'other' devices. Yet here we only consider 1 and ignore everything >> else :-\ > > Do you suggest to have DRI_PRIME=2 (up to 8) be the same than DRI_PRIME=1 ? > Where/how did you read that ? It sounds like you've not read through the spec, have you ? I'm saying that the DRI2(DriverPrime) spec allows for 8 devices in total. The 0 one is always the xserver one and you have 7 "others". Atm things are completely bonkers, since you have this half a**ed broken heuristics which ignores anything but 1. Admittedly there aren't many users with 3 or more GPUs but if they were things just won't work :-\ Furthermore atm you get a walk over the renderD* (missing D in the libudev pattern ;-) devices which does not relate to what you get as the 1 device in any other DRI_PRIME use case. Or in other words, if you use DRI_PRIME=1 with libGL/EGL/gbm you can get different result than when doing the same with the vdpau/xvmc/omx/vaapi drivers. Even within libGL (DRI2) things are quite magical , fortunately you get the same device if the loader fails. </blockquote><div>Or it's likely just me being weird in expect IMG different components of mesa to behave identically when DRI_PRIME is set ;-)</div><div> </div><div>Either way I'll drop the lovely comments.</div><div> </div><div>Emil</div>