00:02 anholt_: fd.o gitlab deployment issue, just reassign when it happens
00:05 apinheiro: anholt_, ok, thanks for the tip
02:59 scx: Hello
03:02 scx: Using MESA_LOADER_DRIVER_OVERRIDE we can change the default driver (i965, iris, nouveau, virgl, zink, swrast, llvmpipe, etc.). What is the best way to display currently used driver name (e.g. iris, i965) from application?
03:13 HdkR: GL_RENDERER
03:13 HdkR: Query that GL enum and it'll give you that information
03:19 scx: thanks
03:20 scx: How can I be sure that Mesa is use, not e.g. NVIDIA (binary blob)?
03:49 HdkR: scx: Nvidia's proprietary blob will return different results
03:49 HdkR: Even for the same physical card
04:28 scx: GL_RENDERER returns Mesa DRI Intel(R) HD Graphics 630 (Kaby Lake GT2)
04:28 scx: How can I distinguish i965 from iris?
04:32 dcbaker[m]: scx is different between iris and i965 IIRC
04:32 dcbaker[m]: GL_VENDOR*
04:52 jekstrand: dcbaker[m]: We used to put "iris" in some string for iris but I can't find it anymore.
05:01 scx: I see only "Intel Open Source Technology Center"
05:03 scx: The thing is we experienced some problems with Iris driver on some configurations (e.g. using the "intel" driver instead of "modesetting" on Mesa 20).
05:03 scx: We want to fallback to i965 when the error occurs.
05:03 scx: However, we can't just export MESA_LOADER_DRIVER_OVERRIDE=i965
05:04 scx: because it will impact other drivers as well
05:04 scx: for example, if nouveau is in use, it will fallback to llvmpipe
05:33 HdkR: `GL_RENDERER: Mesa Intel(R) Iris(R) Plus Graphics (ICL GT2)` Returns Iris for me
05:33 HdkR: Then with i965 override "GL_RENDERER: Mesa DRI Intel(R) Iris(R) Plus Graphics (ICL GT2)"
05:34 HdkR: oh
05:37 scx: As far as I know, for the vendor string i965 should return "Intel Open Source Technology Center", and iris should return "Intel"
05:37 scx: However, it applies only to the latest version.
05:37 HdkR: Oh right, shows DRI versus not now
05:38 scx: In the past, the string was different. For example, iris used "Mesa Project".
05:38 HdkR: I presume that was before it was enabled by default
05:39 scx: well, probably you are right, but it doesn't change the fact that many distros still use Mesa 18.x or 19.x
05:40 scx: and we want to support even Ubuntu 14.04 LTS, with Mesa
05:40 scx: with even older Mesa*
05:40 HdkR: Don't build iris on those old mesa versions?
05:41 HdkR: There's a reason why it only switched to Iris default in 20.x
05:41 HdkR: Users are playing with fire if they enabled it before
05:42 scx: As I said, we hit an issue with Iris on Mesa 20.
05:42 HdkR: So you're talking about multiple issues. Classic support and also Iris past default enabled :)
05:43 scx: We have no control on Mesa version.
05:43 scx: We just want to fallback to i965 when iris fails.
05:43 HdkR: Correct, but you can also choose to ignore bug reports from users enabling Iris on pre-20.0 versions
05:45 HdkR: They made a choice with pre-20 mesa release to play with buggy software
05:45 HdkR: post-20 release is a different story
05:45 scx: well, we wanted to support every valid configuration, if possible
05:45 HdkR: I wouldn't say switching over to a experimental driver is valid
05:46 scx: and what if the vendor string changes again in Mesa 21?
05:46 HdkR: It could
05:48 scx: As you can see, we are looking for more reliable method to detect iris driver
07:36 scx: I think that I will try getDisplayDriverName from EGL
08:36 linkmauve: scx, have you reported the iris bug, instead of trying to find such a workaround?
08:45 scx: linkmauve: kind of
08:45 scx: https://github.com/flatpak/flatpak/issues/3673#issuecomment-650287489
08:45 scx: https://github.com/widelands/widelands/issues/3937#issuecomment-650288132
08:45 gitbot: flatpak issue 3673 in flatpak "Possible incompatibility between Freedesktop's Mesa libraries and Mesa libraries or kernel driver on the host" [Open]
08:45 gitbot: widelands issue 3937 in widelands "Widelands does not start on EL 7 with Mesa 20 and Intel GPU" [Bug, Building & Packaging, Crashes Or Hangs, Open]
08:46 scx: Howover, it will probably take months before it gets fixed in Freedesktop 19.08 (if at all) and potentially Linux distributions
08:46 linkmauve: scx, I mean, reported it to the iris devs. :)
08:48 scx: Have you checked these links at all?
08:50 linkmauve: Somewhat, why?
08:50 linkmauve: If there is a regression compared to i965, they’ll probably want to know about it.
08:51 scx: Because there is already a similar issue in Ubuntu 20.04, and they confirmed it.
08:52 scx: Since someone has already written about it on the Intel 3D Bugs Mailing List, what's the point to duplicate report?
08:53 HdkR: Oh nice, GCC LTO bug
08:54 scx: Of course, this may be a different bug, but it is up to Freedesktop to check it.
08:54 linkmauve: Ok, so it was already reported, then everything’s fine.
08:56 scx: When I reported a bug about PCI, I had to wait about half a year before it was fixed in FD. This is why I'm looking for workaround.
13:18 pcercuei: It's a stupid question but... What do I have to do to make DRM_DEBUG_ATOMIC() actually print something?
13:20 vsyrjala: drm.debug=0x10 is the atomic bit iirc
13:21 pcercuei: vsyrjala: wow, thanks
15:33 Vanfanel: Hi there. I am trying to debug mouse cursor issues on the KMS/DRM backend of SDL2. I am only seeing those in amdgpu. So, where can I find what cursor sizes and pixel formats is the amdgpu driver really supports? For example: it apparently it supports 16x16, but 16x16 cursors appear garbled, and only 128x128 cursors seem to look good, etc, etc
15:57 imirkin_: Vanfanel: i believe there's a kms info ioctl of some sort which queries the supported and preferred cursor sizes
15:58 imirkin_: Vanfanel: e.g. https://drmdb.emersion.fr/devices/3a5c55e30723
15:58 imirkin_: DRM_CAP_CURSOR_HEIGHT = 128
15:59 imirkin_: in order to figure out what it _really_ supports, you may have to browse code. but in general powers of 2 may be supported, it's rare for a cursor plane to support non-pot sizes.
16:01 imirkin_: here's a summary of max cursor sizes supported by various drivers: https://drmdb.emersion.fr/capabilities
16:03 imirkin_: (but e.g. i915 supports 256x256, but it also has native support for lower sizes. but that's not necessarily guaranteed... so you just have to have some fallback logic in there i guess)
16:04 imirkin_: (and if the driver accepts a particular cursor size, then it certainly shouldn't be garbled -- that's a bug that should be reported to the driver authors -- either it should work, or it should get rejected)
17:06 Vanfanel: imirkin_: thanks a lot. I have found drmGetCap(m_fd, DRM_CAP_CURSOR_WIDTH, &capability), which should be a good option to get a supported cursor width for example, right?
18:10 ickle: .win 26
22:38 nifker: Does mesa not support "VK_EXT_debug_utils"?
23:01 bnieuwenhuizen: nifker: isn't that provided by the validation layers?
23:08 nifker: bnieuwenhuizen: oh indeed but I get an error when calling vkCreateDebugUtilsMessengerEXT that it cant load the function
23:08 nifker: I even looked it up in my vulkaninfo and it supports the extension
23:22 bnieuwenhuizen: nifker: did you enable the extension?
23:26 nifker: oh
23:26 nifker: I forgot about it
23:57 pcercuei: trying to mmap GEM buffers to be fully cached
23:59 pcercuei: I got it to work with PRIME buffers, with a drm_driver.gem_prime_mmap() callback that just calls dma_mmap_attrs() with DMA_ATTR_NON_CONSISTENT flag