Linux binaries, DRI3 and drm_prime_handle_to_fd_ioctl

[shkhln]

Linux O_CLOEXEC != FreeBSD O_CLOEXEC, so this check usually fails:

https://github.com/FreeBSDDesktop/kms-drm/blob/e0ca9126718c81ab155ddf6cdfae29e2d8fc546e/include/uapi/drm/drm.h#L692

https://github.com/FreeBSDDesktop/kms-drm/blob/e0ca9126718c81ab155ddf6cdfae29e2d8fc546e/drivers/gpu/drm/drm_prime.c#L779-L781

[trasz]

Nice! Do you know if it's already been fixed? I cannot reproduce the problem anymore.

[shkhln]

I don't think it was. Are you sure you did not set LIBGL_DRI3_DISABLE somewhere? Presumably DRI3 can also be disabled automatically depending on the driver choice, so beware of that as well.

[trasz]

I thought it could have been fixed by updated userspace (from Ubuntu), so I've just tested it with glxgears from linux-c7-glx-utils-8.3.0_1, with both drm-current-kmod-5.4.62.g20201003, and drm-devel-kmod (don't remember which version), all under 13.0-CURRENT, and... it all works, for some reason. Is there a way to check whether DRI3 isn't getting disabled by some other means? glxinfo output shows "OpenGL version string: 3.0 Mesa 19.0.8", but setting LIBGL_DRI3_DISABLE doesn't seem to change its output.

[trasz]

FWIW, here's my strace glxgears: https://gist.github.com/trasz/ed3ec17ea445d1d92f05aa87344f359e, from Linux chroot with Bionic userland.

[valpackett]

Yeah, seems like you're not using DRI3. I guess the best way to force DRI3 is to use Xwayland rather than Xorg-on-hardware, but also: do you have a custom xorg.conf? intel or modesetting driver? Anything GL or DRI in the env?

[trasz]

No xorg.conf, the driver is:

[     8.647] (II) intel(0): Allocated new frame buffer 1366x768 stride 5632, tiled
[     8.654] (II) UXA(0): Driver registered support for the following operations:
[     8.654] (II)         solid
[     8.654] (II)         copy
[     8.654] (II)         composite (RENDER acceleration)
[     8.654] (II)         put_image
[     8.654] (II)         get_image
[     8.655] (II) intel(0): [DRI2] Setup complete
[     8.655] (II) intel(0): [DRI2]   DRI driver: i965
[     8.655] (II) intel(0): [DRI2]   VDPAU driver: va_gl
[     8.656] (==) intel(0): Backing store enabled
[     8.656] (==) intel(0): Silken mouse enabled
[     8.656] (II) intel(0): Initializing HW Cursor
[     8.660] (==) intel(0): DPMS enabled
[     8.660] (==) intel(0): Intel XvMC decoder enabled
[     8.660] (II) intel(0): Set up textured video
[     8.661] (II) intel(0): [XvMC] xvmc_vld driver initialized.
[     8.661] (II) intel(0): DRI2: Enabled
[     8.661] (II) intel(0): DRI3: Disabled
[     8.661] (==) intel(0): hotplug detection: "enabled"

The driver package is xf86-video-intel-2.99.917.909,1; I've just noticed it says "legacy" in the description, so I guess I should take a look at what is the not legacy counterpart?

Also: for future reference, how did you tell it's not DRI3 from the strace log? Which part should I pay attention to? Thanks!

[jbeich]

Is there a way to check whether DRI3 isn't getting disabled by some other means?

LIBGL_DEBUG=verbose glxgears should show libGL: Using DRI3 for screen 0

xf86-video-intel-2.99.917.909,1

intel unlike modesetting disables DRI3 by default unless xorg.conf(5) contains Option "DRI" "3".

See also https://gitlab.freedesktop.org/xorg/driver/xf86-video-intel/-/commit/db629a383428

[valpackett]

[ 8.661] (II) intel(0): DRI3: Disabled

I guess the intel driver doesn't default to DRI3 on your hardware, or on FreeBSD (?) ah what @jbeich just linked above - the default is determined by compile time options, defaulting to 2. You could do Option "DRI" 3 or whatever it is.

I guess I should take a look at what is the not legacy counterpart?

Not having xf86-video-anything installed and letting it use the built-in modesetting driver.

for future reference, how did you tell it's not DRI3 from the strace log? Which part should I pay attention to?

Well, the lack of DRM_IOCTL_PRIME_HANDLE_TO_FD ioctls mentioned in this thread title of course — but even before that, lack of accesses to something like /sys/dev/char/226:128/….

"DRI3" means X clients act like reasonable modern applications — opening the render node (which is a /dev entry for the GPU that's open to all applications because it doesn't allow doing anything "bad", only rendering), allocating their own buffers there, using DRM_IOCTL_PRIME_HANDLE_TO_FD to convert them to dma-buf file descriptors, passing them to the windowing server over the socket using the appropriate protocol extension (linux-dmabuf-unstable-v1 on Wayland, whatever DRI3 thing on X11).

[trasz]

Success! As in, successful failure: after removing xf86-video-intel, the Xorg.log still claims it's DRI2 ([ 13.280] (II) modeset(0): [DRI2] Setup complete), but now Linux glxgears binary crashes. Thanks :-)

[valpackett]

still claims it's DRI2 ([ 13.280] (II) modeset(0): [DRI2] Setup complete)

Well it didn't claim it was not DRI3 :) These aren't mutually exclusive.