08:42 karolherbst: has anybody worked on a pass to convert 16x2 phis to 32 ones (or 16x4 to 32x2)?
09:51 lucaceresoli: mripard: you was offline, so you might have missed my ping about https://patchwork.freedesktop.org/series/149581/
09:51 lucaceresoli: mripard: that one patch is blocking a pile of others from being sent, so I'f greatly appreeciate if you could have a look
09:52 lucaceresoli: s/I'f/I'd/
11:12 mripard: lucaceresoli: it looks like lumag has reviewed it, so is there anything you wanted to ask in particular?
11:22 mlankhorst: jfalempe_: are you going to send one more version for VRAM?
12:29 mlankhorst: jani: can I also get an ack on https://patchwork.freedesktop.org/series/141937/ to get the series merged through drm-misc?
12:29 lucaceresoli: mripard: no particular question, I was not sure lumag's R-by is enough for applying. Is it?
12:35 mripard: lucaceresoli: it is
12:49 lucaceresoli: mripard: awesome, thanks!
12:51 jani: mlankhorst: I realize I just pushed a series that's bound to conflict with that series. I didn't really think anything of it at the time. but if you merge that to drm-misc now, the conflict might be pretty bad at drm-tip rebuild.
12:52 jani: mlankhorst: ISTR vsyrjala had some comments about disabling tiling, I haven't really followed the whole thing, so might be good to get an ack from vsyrjala as well
12:53 mlankhorst: It only disables tiling for pre-DPT platforms now
12:53 jani: mlankhorst: other than that, once the above are sorted out, ack for merging via whichever tree makes most sense
12:54 mlankhorst: I think that was the main issue with tiling
12:58 jani: like I said, I haven't followed the discussion, I'm pretty clueless here :/
13:25 sima: hm MrCooper on vacations?
13:31 sima: just stumbled over it, but os_same_file_description() in mesa should use the F_DUPFD_QUERY fcntl() added in 6.10 with c62b758bae6af as the first thing since the kcmp syscall might not be available, the fcntl always is
13:31 sima: on new enough kernels at least
13:33 pepp: sima: oh interesting. Might be a better fallback than epoll
13:34 pepp: see https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34447
13:35 sima: oh good link, I'll drop a comment there
13:39 sima: pepp, done
13:40 pepp: sima: thanks!
13:43 sima: pepp, btw EPOLL is also a Kconfig knob, just I guess enabled a lot more often than KCMP
13:44 emersion: is this for DMA-BUF FDs, or for DRM FDs?
13:44 sima: dma-buf can fall back to ino comparison
13:44 emersion: yeah
13:44 sima: for drm fd we have only this
13:44 emersion: just wanted to make sure this was known :P
13:44 sima: might also be used for other stuff
13:48 sima: pepp, if you want an r-b on a respin probably best you ping here, I tend to ignore everything else a bit much sometimes :-/
13:49 sima: emersion, this entire wild goose chase on my side actually started with some questions about that
13:49 sima: because on 32bit the ino isn't unique enough and you could overflow
13:49 sima: so would be really good to first use the fcntl even for dma-buf
13:49 pepp: sima: ok
13:49 sima: we allocate them with atomic64_inc_return
13:49 sima: "allocate"
13:50 sima: emersion, so maybe sway patch too
13:50 emersion: hm
13:50 sima: well wlroots
13:50 emersion: the nice thing about ino is that it doesn't use linux-specific APIs
13:51 sima: well dma-buf is fairly linux specific ...
13:51 emersion: it's on BSDs as well
13:51 sima: hm
13:51 sima: well you need an #ifdef F_DUPFD_QUERY anyway since this is very new
13:53 sima: or I guess we should fix the fun with dma-buf ino on 32bit
13:54 emersion: what's the issue exactly?
13:54 emersion: that after an overflow, we might land on an already-used ino again?
13:54 emersion: or something else?
13:55 emersion: ah, also
13:55 emersion: i _think_ F_DUPFD_QUERY wouldn't work if you use the magic re-open thing?
13:55 emersion: open("/dev/fd/n")
13:56 sima: the magic reopen should be like a dup()
13:56 sima: or it would horrible break dma-buf on linux because we don't care about the inode, it's all attached to struct file
13:56 emersion: hm, i have a recollection that it's somehow different, but i may be misremembering
13:59 zmike: karolherbst mareko: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35612
14:13 sima: emersion, I got entirely lost trying to understand how that magic works
14:14 sima: but if you do that on a dma-buf, and you get a working dma-buf back, then it's definitely like dup
14:15 emersion: if you do it on a regular file, then it's not a dup
14:16 emersion: but yeah, no idea how that works w/ dmabufs
14:18 sima: emersion, do you do that somewhere and it works?
14:18 emersion: i haven't tried, no
14:18 emersion: i hope it just doesn't work
14:19 sima: like from a quick reading it really just is a symlink
14:19 sima: and for special files it's a symlink to nowhere
14:19 sima: I'm not even sure what happens with namespaces
14:19 emersion: the symlink is a lie :^)
14:19 emersion: when you open() it doesn't go through the regular logic
14:20 sima: yeah I tried to find that and couldn't
14:21 emersion: https://blog.gnoack.org/post/proc-fd-is-not-dup/
14:27 sima: ok I got it now, I got lost in how link lookup works
14:28 sima: so yeah it's magic insofar it can jump through special files and get at their kernel-internal dentry and vfs_mount through file->f_path
14:28 sima: but crucially, it then re-opens that file through the dentry->d_inode->i_fop->fop_open implementation
14:28 sima: roughly
14:29 sima: and dma_buf doesn't have that
14:29 emersion: yeah, makes sense
14:29 sima: so yeah that one isn't dup, but it's also not a thing for all the special fd in the gpu world like dma_buf, sync_file, drm_syncobj
14:29 emersion: indeed
14:30 sima: but otoh pidfd_getfd does work like dup()
14:30 sima: also apparently really old linux did handle it like a dup
14:31 sima: the magic procfs open I mean
14:49 sima: emersion, ok wild goose chase finished, unless you take special action you get the default no_open inode->i_fop implementation, which stops the magic proc open
14:49 sima: that happens in inode_init_always_gfp()
14:49 sima: reading vfs code is wild
14:51 emersion: ha
14:51 emersion: thanks for tracking this down :P
15:00 sima: emersion, anyway I think the F_DUPFD_QUERY thing is good and I'd say preferred on linux
15:00 emersion: ack
15:00 sima: ofc guaranteed that I'll regret this statement in 10 years :-)
15:09 karolherbst: zmike: ship it
15:12 zmike: cool just waiting on Intel then
15:13 tnt: Did anything change in the way mesa links or uses LLVM in the last few months ? Or in the way it does when using llvm19 vs 20 ?
15:50 karolherbst: tnt: not specifically, why?
15:51 tnt: karolherbst: In the past intel-compute-runtime could work just fine in a GL application and the LLVM used by mesa wouldn't clash with the one used by the intel CL stack.
15:51 tnt: But now they seem to clash ...
15:52 karolherbst: mesa reworked how gallium drivers are loaded, maybe that caused something to get messed up?
15:52 karolherbst: But anyway.. having multiple llvm versions in one applications is kinda a known disaster
15:55 tnt: Yeah, I know. AFAIR mesa wouldn't even load LLVM at all but my memory might be fuzzy on that.
15:55 tnt: If I could, I'd have everything using the same LLVM but the intel CL stack is using LLVM15 -_- ...
16:01 tnt: Now libGLX_mesa.so links to libLLVM.so.20.1 and I don't remember that being the case before.
16:24 karolherbst: mhhh
16:24 karolherbst: right.. because libgallium-25.2.0-devel.so does
16:25 karolherbst: I think the only difference is, that instead of it getting pulled in via dlopen it's now directly?
16:28 tnt: Yeah, that's very possible.
16:28 mareko: libLLVM should be loaded indirectly via libgallium, not via libGLX_mesa
16:29 karolherbst: I'm wondering... can we leave LLVM symbols unresolved and dlopen llvm at runtime in drivers needing it?
16:29 karolherbst: mareko: libGLX_mesa links to libgallium now
16:29 mareko: yes but it doesn't have to link to libLLVM
16:29 karolherbst: libgallium contains the gallium drivers
16:30 mareko: and libgallium links with LLVM
16:30 karolherbst: yeah, so libGLX_mesa needs to load llvm
16:30 mareko: so why do loaders link to LLVM too
16:31 mareko: there is a bunch of libraries that loaders link to that they probably shouldn't, like libelf
16:31 karolherbst: I think it might make sense to make the loader not link against libgallium and do dlopen instead or something...
16:31 karolherbst: though could be quite a bit of work
16:32 karolherbst: we kinda want our own symbol namespace tho...
16:32 mareko: it's possible that ldd prints dependencies of all loaded libraries, and in fact, loaders don't link with those libraries, but are printed by ldd to show a complete list
16:32 karolherbst: they do with 25.1
16:33 mareko: we have our own private symbol namespace since the removal of dlopen(RTLD_GLOBAL)
16:34 karolherbst: anyway.. libegl links to libgallium_dri which contains all the drivers, and that's kinda a new thing
16:34 mareko: and that's fine
16:35 karolherbst: yeah I'd thought so as well
16:35 karolherbst: maybe it's something that intel is doing that makes this annoying, or maybe something in glvnd causing issues...
16:35 mareko: something in libGLX_mesa is using LLVM that's independent of libgallium
16:36 karolherbst: I don't think it does
16:36 karolherbst: at least not seeing anything obvious
16:40 mareko: yeah, libGLX doesn't seem to use LLVM at all, so nm probably shows LLVM functions because of libgallium, which gives the misleading impression that libGLX uses LLVM
16:41 karolherbst: yeah, it's an indirect dependency, but LLVM does things on init time
16:42 karolherbst: and that sometimes causes weird issues if you have multiple LLVMs
16:42 karolherbst: it would be kinda nice to postpone loading LLVM though, because today every GL application ends up loading LLVM because of llvmpipe even if it's not usre
16:43 mareko: I think it shouldn't cause weird issues if the symbol namespace is truly private
16:43 karolherbst: soo.. maybe we should just dlopen LLVM and just solve it for real
16:43 karolherbst: yeah...
16:43 karolherbst: I think glvnd might do something weird...
16:44 karolherbst: "dlopen(dlopenName, RTLD_LAZY);" mhhh
16:44 karolherbst: that implies RTLD_LOCAL
16:45 karolherbst: tnt: the intel runtime doesn't link to libEGL or so, correct?
16:46 karolherbst: though I can't see how that would even matter...
16:46 karolherbst: where is the crash anyway?
16:52 zmike: it's not just llvmpipe that loads it
16:52 zmike: the draw module is used by core mesa
16:53 jenatali: Sometimes
16:53 jenatali: Or rather, it's there all the time but actually used rarely
16:54 zmike: yes
16:54 zmike: very rarely
16:58 mareko: the TGSI interpreter might not be the worst option for draw if you have GS support and enable the GS path for the GL_SELECT mode
16:59 jenatali: TGSI interpreter being the alternative to the llvm version of the draw module?
16:59 mareko: yes
16:59 jenatali: That's what we ship, since Windows LLVM dynamic linking doesn't really work
16:59 jenatali: And static linking is just too much bloat
17:00 mareko: there are a few old drivers that need draw to use LLVM because the hw lacks hw vertex processing
17:00 jenatali: I should look at the GS path, I think that's new since we started shipping Mesa and we probably didn't flip it on, but should
17:02 mareko: hardware_gl_select is enabled automatically if you have a few other other caps
17:03 daniels: genuinely quite alarmed to discover that i915g has actually had a double-digit number of fixes since amber branched
17:10 tnt: karolherbst: No, it doesn't link to libEGL directly. The issue is when I make an application that does both GL and CL ( no interop, just using both ) then you get errors like "Attribute list does not match Module context" and a bunch of other runtimg LLVM failure/errors.
17:44 karolherbst: right.. the usual LLVM conflict thing
17:45 karolherbst: tnt: khronos ICD loader or ocl-icd?
17:45 karolherbst: if the former, try ocl-icd instead
17:46 karolherbst: the khronos loader does "dlopen (libraryName, RTLD_NOW)" where ocl-ocd is doing RTLD_LAZY|RTLD_LOCAL
17:46 karolherbst: though the official one is RTLD_NOW|RTLD_LOCAL as local is implicit
17:52 mareko: we could link LLVM statically into libgallium
17:52 mareko: it's only inconvenient to developers because of long link times
17:54 tnt: karolherbst: Doesn't change anything.
17:54 karolherbst: I'm doing static llvm locally already, meson doesn't like it and always relinks or something
17:54 karolherbst: quite the pain
17:54 karolherbst: but yeah...
17:54 tnt: ATM I can actually work around the problem by disabling llvm all together ...
17:55 karolherbst: maybe we should just go full static on LLVM...
17:55 karolherbst: tnt: .... yeah well...
17:55 karolherbst: going full static solves a couple of other problems as well
17:55 karolherbst: like the opencl-c-base.h header issue is then also solved, because we'd just ship that file also included (for OpenCL support)
17:56 karolherbst: it's just...
17:56 karolherbst: my rusticl build is like 500MB :)
17:57 karolherbst: libgallium-25.2.0-devel.so is 350MB
17:57 karolherbst: maybe should check with a release build
18:01 karolherbst: libgallium-25.2.0-devel.so is 144MB
18:02 karolherbst: libRusticlOpenCL.so.1.0.0 is 205MB
18:02 karolherbst: libvulkan_lvp.so is 110MB
18:02 karolherbst: ehh 95MB
18:02 karolherbst: forgot to strip that one
18:03 karolherbst: currently libgallium on fedora is 44MB
18:04 karolherbst: rusticl is 36MB
18:04 karolherbst: lavapipe is 10MB
18:04 karolherbst: soo.. we are talking about ~350MB more space used
18:05 jenatali: karolherbst: That's why I ship GL without LLVM
18:05 karolherbst: yeah....
18:21 tnt: Just to confirm, issue did appear going from 25.0.7 to 25.1.3 so I guess that's where those changes were made.
18:24 mareko: ACO is 7% slower than LLVM in Furmark and we don't know why
18:29 anholt: mareko: do you have it drilled down to specific shaders? I've been working on a tool that's doing that with trace replays for me on tu.
18:30 anholt: though furmark probably doesn't have that much going on
18:36 mareko: yes I have the exact shader, but I also have a hw trace telling me what happens in the SIMD every clock cycle, and I haven't been able to see why it's slower
18:38 mareko: I made sure the command buffers between LLVM and ACO are completely identical
20:01 karolherbst: tnt: mind checking with LD_DEBUG=libs if the order of loaded libs changes significantly?
20:13 olivial: what's the point of all the 'assert(desc); if (!desc) { ... }' in u_format.h?
20:13 olivial: is the if block not unreachable?
20:15 tnt: karolherbst: I'm not so sure about 25.0.7 -> 25.1.3 is actually the trigger, it seems random wether it works. And I think that yeah, lib load order matters. Doing LD_PRELOAD of the OpenCL lib makes it work.
20:15 karolherbst: mhhh
20:15 karolherbst: that's annoying...
20:22 tnt: karolherbst: And now it seems to work without it ... I swear it's almost like once I started an application once with the LD_PRELOAD, then it will work for that application without it in subsequent attempts.
20:23 karolherbst: ...
20:26 tnt: Well if someone else complains, then maybe it's worth looking into but for me now it seem to have magically fixed itself and if it re-appears, I know how to work around it for now ... Who knows maybe they'll finally update to newer LLVM before it appears again.
20:26 tnt: Sorry for the noise :/
20:29 zmike: olivial: release builds
20:30 olivial: ah, didn't realize mesa was dropping asserts on release builds. Thanks!
20:42 anholt: olivial: it's a general thing in C build systems.
21:46 tnt: karolherbst: Ah ... ~/.cache/neo_compiler_cache/ ... so yeah I'm not crazy ... after starting an app once with LD_PRELOAD the programs are compiled so LLVM isn't used and so it works without LD_PRELOAD. But if I wipe the cache, it bugs again.
21:47 karolherbst: mhhh
21:50 tnt: I'm headed to bed now, but at least I'm glad I got an explanation for the inconsistent behavior I was seeing.