06:42sravn: pinchartl: Thanks for the review. One of my spelling errors made my day (s/bride/bridge) :-)
06:42sravn: Will re-spin all patches and adress all your good feedback
09:53karolherbst: I thought I saw it all, but this is something.. comparing ints: 0 != memcmp(result, &max_textures, sizeof(max_textures)
13:59pinchartl: sravn: up to you, but for me kernel development is easier than wedding planning services :-)
15:38sravn: pinchartl: right - :-)
15:50MrCooper: dcbaker[m]: that's the thing — according to meson configure, valid values for dri3 are auto/true/false, so trying to set it to "enabled" as suggested fails
15:52dcbaker[m]: MrCooper: enabled and disabled are in meson_options.txt, maybe meson --reconfigure?
15:53dcbaker[m]: Actually, come to think of it, I think this is a bug that suggestions reported recently
15:54dcbaker[m]: New options are picked up on reconfigure, but new values to existing options are not
15:57dcbaker[m]: Wow autocorrect butchered that, there an opened issue about this, you have to use --wipe for the new choices to be picked up
16:03MrCooper: that did the trick, thanks!
16:04MrCooper: might be better to wait for that meson issue to be fixed before completely dropping the old supported values
16:07dcbaker[m]: MrCooper: when we drop the old values we'll change the type to a feature, i wonder if changing the type gets picked up
16:08MrCooper: fingers crossed :)
17:50pcercuei: What's the place to report bugs on libdrm?
17:51pcercuei: Nevermind. It's Mesa's gitlab repo.
17:51pcercuei: I thought it was separate
17:52mattst88: pcercuei: yeah, in https://gitlab.freedesktop.org/mesa/drm/
22:02linkmauve: Hi, current master fails to build in softpipe, it seems to trigger an ICE in gcc.
22:02linkmauve: Do you know if it’s been reported already?
22:03linkmauve: Uh, why does Nine require softpipe? :/
22:04linkmauve: Hmm… “OSMesa gallium requires gallium softpipe or llvmpipe.”
22:05imirkin: i saw robclark report it in #freedreno...
22:05dcbaker[m]: Nine has always required those AFAIK
22:05linkmauve: I guess I didn’t need a software backend anyway, nor d3d9 support or osmesa. :-°
22:06linkmauve: “Net Upgrade Size: -120.27 MiB”, woah!
22:06linkmauve: dcbaker[m], do you know why?
22:06robclark: fwiw, the softpipe build crashing gcc thing, only seems to happen w/ release builds.. debug builds are ok.. (and this is on fedora rawhid, so maybe slightly bleeding edge gcc)
22:07airlied: robclark: also f32
22:07linkmauve: Also ArchLinux (btw I use Arch).
22:07robclark: ahh, ok.. so I'm in good company
22:07dcbaker[m]: linkmauve: no idea, I just ported it from autotools to meson
22:08airlied: someone bisected to a mesa commit
22:08airlied: we should revert that for now of someone can locate
22:08robclark: I didn't try to bisect.. but couldn't have been more than ~1wk window since I last rebase
22:09airlied: gcc fixes can take a week or two
22:09robclark: yeah, revert sgtm
22:09airlied: robclark: pretty sure someone mentioned it in here
22:09airlied: but im not in a spot to find it
22:09airlied: but maybe it was on a gitlab issue
22:10airlied: i was going to deal with it tomorrow when i get to work
22:10robclark: could be.. I tend to read like 10% of #dri-devel scrollback
22:11robclark: anyways, debug build isn't a problem for now, so I'm not blocked
22:11linkmauve: dcbaker[m], I just built nine without swrast gallium, it didn’t fail to build or anything, now I’ll try to run it.
22:12dcbaker[m]: It may well be a legacy restriction that wasn't removed
22:12linkmauve: robclark, how do I know whether I’m using a release or a debug build? (I guess the former if I encountered this bug.)
22:12linkmauve: dcbaker[m], I’ll make a MR if it works fine.
22:12robclark: linkmauve: the --buildtype arg to meson
22:13linkmauve: robclark, hmm, the AUR package is passing plain to it.
22:13airlied: linkmauve: i thunk d3d9 has a swrast path
22:14robclark:finally go all the way through a skia skqp on linux run.. which was more painful than expected when I started a couple days ago
22:15linkmauve: How do I know whether I’m using nine or not? It seems to work.
22:16linkmauve: airlied, that should be fine if it’s optional.
22:23orbea: linkmauve: this might help https://github.com/axeldavy/Xnine
22:24linkmauve: Hmm, it segfaults in 0x00007ffff713577e in iris_bo_map (dbg=dbg@entry=0x0, bo=0x0, flags=flags@entry=2) at ../src/gallium/drivers/iris/iris_bufmgr.c:1209
22:25linkmauve: From NineDevice9_ctor().
22:25orbea: huh, maybe it was never fixed for iris...
22:25orbea: with wine it should print its using nine in stdout with wine-nine-standalone
22:26orbea: the dialog to enable it should also test if it works, but I'm not sure to what level.
22:27linkmauve: Hmm, this codepath in iris can only ever trigger a segfault. oO
22:27linkmauve: pool->bo is initialised to NULL, and never changed before being dereferenced.
22:28linkmauve: orbea, ninewinecfg.exe does tell me that it’s enabled, but I see no change in-game (as expected), and I don’t think I have any d3d9 game that would be CPU-limited here, to really see a change.
22:32orbea: tales of zestiria uses nine and is very slow in some of the mid game field maps, I'm not sure where the bottleneck is though
22:32orbea: but most nine games are older than that.
22:33linkmauve: I tested Touhou and it runs.
22:34linkmauve: Hmm, actually it uses /usr/lib32/wine/d3d8.dll.so and not d3d9.
22:35orbea: you could try d3d8to9...
22:35linkmauve: Touhou 11 does work, and it gets rendered off-canvas. :D
22:35orbea: stdout will print its using gallium nine rather conspicously
22:37linkmauve: Works fine when I disable nine, and it doesn’t print the green message you’re talking about anymore, so I can confirm I was running it, thanks!
22:57orbea: this may help with the debugging https://github.com/iXit/wine-nine-standalone/wiki/apitrace
22:58linkmauve: Oh, Xnine’s triangle_c and triangle_cpp examples segfault just after “nine:drm_create_adapter Couldn't wrap drm screen to swrast screen. Software devices will be unavailable.”
22:58linkmauve: It *might* be related. :)
22:59ccr: the plot thickens.
22:59linkmauve: alloc_fresh_bo() is where the allocation fails.
23:00bnieuwenhuizen: robclark: how did you get skqp to compile and run on linux?
23:02linkmauve: gen_ioctl(bufmgr->fd, DRM_IOCTL_I915_GEM_CREATE, &create) != 0 is what fails.
23:03linkmauve: bufmgr->fd is 0 at this point, but that’s stdin according to lsof. :/
23:04linkmauve: Its refcount is 0 too.
23:06robclark: bnieuwenhuizen: by hitting it with a hammer repeatedly.. I put some notes in https://gitlab.freedesktop.org/mesa/mesa/-/issues/3262
23:07robclark: I'm a bit skeptical about some of the things it claims are 'Pass'.. so I might have hit it too hard with the hammer