On Thursday, 13 October 2016, Emil Velikov <emil.l.veli...@gmail.com> wrote:
> On 12 October 2016 at 18:59, Axel Davy <axel.d...@ens.fr <javascript:;>>
> wrote:
> > On 12/10/2016 19:15, Emil Velikov wrote:
> >>
> >> On 11 October 2016 at 19:54, Axel Davy <axel.d...@ens.fr <javascript:;>>
> 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.
>
> Or it's likely just me being weird in expect IMG different components of
mesa to behave identically when DRI_PRIME is set ;-)
Either way I'll drop the lovely comments.
Emil
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
