00:59 karolherbst: jenatali: never actually checked what you are doing to select a good workgroup size, but I've been toying around with some ideas and I think I found something I'm happy with: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/42288 but I'm also kinda wondering about your approach there
01:04 jenatali: karolherbst: https://github.com/microsoft/OpenCLOn12/commit/5141b78f784083499e3e164cf729ff88ec24f976
01:04 jenatali: Seems not too far off?
01:05 karolherbst: mhhhh
01:05 karolherbst: yeah... doing something prime based is kinda the more or less obvious choise
01:05 karolherbst: *choice
01:05 karolherbst: but I also have to take arbitrary thread limits into account and it kinda sucks if the driver tells you: 724 threads max :)
01:06 karolherbst: maybe I copy yours and see if that helps with anything
01:07 karolherbst: though my "suggest_local_size_impl_run_down" algo shows great results...
01:08 karolherbst: I also tried to optimize against "make sure subgroups are as full as possible on average" and "pick workgroups as huge as possible"
01:08 karolherbst: _but_
01:08 karolherbst: I also have a non-uniform workgroup that works on every hardware without having to emulate anything inside the kernel :D
01:09 karolherbst: but I still need a properly efficient workgroup size selection even with that
01:26 elibrokeit: karolherbst: on the Gentoo side I suspect we'd be rather unhappy at vendoring a fork even just compared to being able to package the fork as "libclc". building from source is common and adding more compile time would be un-ideal
01:27 elibrokeit: maybe if it can be installed and used in our mesa_clc package (that builds mesa just to produce /usr/bin/mesa_clc/vtn_bindgen2 etc) that would be fine?
01:30 elibrokeit: I'm curious if this is just a matter of a blessed commit or if upstream is never really in proper shape and it requires fixes anyway. rolling all the fixes into our llvm-project patchset may be viable (llvm is absolutely terrible about maintaining older versions so there is lots to patch...)
01:39 karolherbst: elibrokeit: many changes atm and almost no validation across implementations using it
01:40 karolherbst: but building libclc takes like... 10 seconds?
01:41 karolherbst: the other potential benefit of picked the libclc impl at compile time is that we could pre-cache the entire thing, which atm causes huge delays in initial start-up times
01:43 karolherbst: but also "having distributions pick patches" sounds like an awful model
01:45 karolherbst: but in the end it's really a correctness thing, and if there are any bugs due to having a bad libclc impl, those are awful and almost impossible to track down
01:45 elibrokeit: hmm, it took 2 minutes on my machine to merge the libclc package. it builds 2150 ninja targets
01:46 elibrokeit: I asked the llvm maintainer in gentoo
01:47 elibrokeit: > you mean after all the time it was maintained independently, then merged to llvm-project for no good reason?
01:47 elibrokeit: > and then llvm folks started messing it up, linking it more tightly to llvm?
01:47 elibrokeit: seems like I stepped in a hornet's nest :P
02:22 karolherbst: elibrokeit: ohh right.. the 10 seconds here is just for the 64 bit spirv version
02:22 karolherbst: so I guess maybe 30 seconds if you also built 32 bit
02:22 karolherbst: on slower machines
06:22 tzimmermann: javierm, hi. can we deprecate CONFIG_SYSFB_SIMPLEFB and eventually remove it ?
07:35 javierm: tzimmermann: I think so. I was planning to disable it in Fedora and instead enable efidrm and vesadrm, did you already disable it in opensuse ?
07:35 tzimmermann: javierm, yes i did
07:36 tzimmermann: works nicely
07:36 javierm: tzimmermann: cool, it seems I missed Fedora 44 but I'll do a change request for Fedor 45
07:36 tzimmermann: great
07:37 javierm: but yeah, I agree with deprecating it and eventually removing it. Will simplify things a lot
07:44 tzimmermann: then i'll send out a patch to update the kconfig text accordingly
07:49 javierm: tzimmermann: perfect, thanks!
07:54 jannau: debian is still using it (https://salsa.debian.org/kernel-team/linux/-/merge_requests/1453)
07:59 javierm: jannau: actually, it seems that is not using it (yet) ?
08:02 javierm: IMO they might move to CONFIG_DRM_{SIMPLE,VESADRM,EFI}DRM=y directly
08:04 mlankhorst: tzimmermann: is it my turn now or are you doing a final drm-misc-fixes pull?
08:05 tzimmermann: mlankhorst, hi. i can do another -fixes PR
08:06 tzimmermann: jannau, javierm, is that MR still open?
08:08 mlankhorst: tzimmermann: can stop if you want, drm-misc-next-fixes is empty. :)
08:09 tzimmermann: mlankhorst, in that case i'll happily hand over -fixes to you and do some vacation from PRs :D
08:09 mlankhorst: Enjoy!
08:10 javierm: tzimmermann: yeah, it seems is still open because they had some bugs in grub that needed to be fixed first
08:10 javierm: but the grub changes seems to be merged already which was the blocker
08:10 tzimmermann: ok, i see.
08:10 javierm: I'm not a debian developer though so I might not be looking at the correct places :)
08:11 javierm: tzimmermann: but hence my point that given is still open, they could just update the MR to enable the per platform DRM drivers instead
08:11 tzimmermann: indeed
08:12 tzimmermann: and in any case, we're no going to remove the option from release kernels. what ever they have will continue to work. and switching to efidrm is easy
08:12 javierm: tzimmermann: agreed
08:25 jannau: javierm: as usual I mixed it up with FB_SIMPLE
08:32 tzimmermann: if only i could remove this as well
08:34 javierm: tzimmermann: yeah, I didn't want to touch fbdev drivers
08:34 javierm: jannau: it's all very confusing :)
08:35 javierm: tzimmermann: but I think there's a ton of fbdev drivers that could be removed now that we have DRM drivers for these
08:35 tzimmermann: javierm, i'd assume it's ~90%
08:36 tzimmermann: i'm sure no one is useing these old drivers any longer. the only exception might be the drivers for atari and amiga. AFAIK there's still a community around those systems
08:37 javierm: tzimmermann: yeah, maybe we should try to remove them and see if anyone complains ?
08:37 tzimmermann: helge, the fbdev maintainer will complain. although i don't think he has a use case either :)
08:37 javierm: I know that the net maintainers have been doing more agressive old drivers removal now that people are using LLMs to find CVEs all over the place
08:39 javierm: tzimmermann: https://lwn.net/Articles/1068928/
08:39 javierm: I think the same logic applies to fbdev, likely those old drivers are full of vulnerabilities
08:40 tzimmermann: i'd think so
08:41 javierm: tzimmermann: but yeah, if the maintainer itself of the subsystem is happy to keep the drivers and deal with the LLM-created patch load, it's on him I guess
08:50 mlankhorst: tzimmermann: Looks like airlied already created a drm-next tag, only 3 patches in fixes, so I think I'm skipping this weeks pull request too and send a normal one next week. :)
08:58 tzimmermann: mlankhorst, ok
11:46 akien: airlied: Hi! I have a question regarding https://gitlab.freedesktop.org/mesa/mesa/-/work_items/14341 and the linked MR. I had this warning in Fedora 43's Mesa 25.3, and thought your MR would silence it. But now on F44 with Mesa 26.0.8, I still get the warning, just with error -9 instead of -3.
11:48 akien: Shouldn't the load avoid warning for VK_ERROR_INCOMPATIBLE_DRIVER when checking available ICDs? Or should we special case it and silence this application side? (seeing this in Godot)
11:55 mripard: lumag_: tzimmermann: could you review the first patches of https://lore.kernel.org/r/20260608-drm-no-more-bridge-reset-v2-0-0a91018bf886@kernel.org ?
13:25 alyssa: elibrokeit: in general anything matching the regex /LL.*M/ is a hornet's nest ;P
13:26 elibrokeit: yes....
13:27 alyssa: elibrokeit: beware of beryllium
13:27 alyssa: and gallium for that matter
13:40 tzimmermann: mripard, this looks all good to me. unless i'm mistaken, the whole series has my r-b already
13:43 mripard: tzimmermann: you had a reviewed-by on all the drivers one (but the cadence ones) but not the early ones I think?
13:43 mripard: but I take it I can add it everywhere then?
13:49 tzimmermann: mripard, right! i looked over it again now, but it looks all good to me. feel free to add the r-bs
13:55 karolherbst: alyssa: I just noticed that the most fun part of moving libclc into mesa would be dealing with all those clang builtin functions :')
13:55 alyssa: which?
13:59 karolherbst: they use builtins for opcodes quite a bit, not sure how stable they are across clang versions: https://gist.githubusercontent.com/karolherbst/21907af0d20cfb1e16d521c3d1d1130a/raw/37a977240c4de7fdd3f11881b492fc8a8c5eb3fb/gistfile1.txt
13:59 karolherbst: but maybe they are all fine
14:45 enginmanap: Hello everyone. I reported the following bug a month ago, but it didn't get auto-labeled, and seems like lost in the ocean without labels. I can't add labels either, and the how to create a bug report page doesn't have any more information. Can someone give me some hints? https://gitlab.freedesktop.org/mesa/mesa/-/work_items/15330
14:46 karolherbst: enginmanap: added the appropriate label
14:47 enginmanap: karolHerbst: thank you very much
14:47 karolherbst: enginmanap: though your mesa version is EoL and won't get updates from us
14:47 karolherbst: so probably better to report it against Debian. Unless you also hit the issue with an upstream supported version
14:47 karolherbst: which is.. 26.1 or newer
14:57 enginmanap: karolherbst: thanks for the info. I will look into which project would be better suited. It might be debian, or it might be some raspberry pi owned thing, as I am using RPI OS
17:18 Company: I have a question - the long form of that question is in https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/10049
17:18 Company: GTK has been using push constants for some generic state - scale factor, clip region, things like that
17:19 Company: now we've put enough data into those constant that we've run out of the 128 bytes limit - Mesa does 256, so that was fine, but Android doesn't
17:20 Company: and someone has ported it to use an UBO instead - one large buffer for all the constants we need and then we essentially BindBufferRange() the constants we want
17:21 Company: and then I wrote a benchmark specifically to test that
17:21 Company: and it works basically without performance difference on Intel or AMD
17:21 Company: but lavapipe is about 60% slower
17:22 Company: a quick comparison with sysprof points at is spending that time in llvmpipe_map_memory() called from the descriptor set binding code
17:23 Company: so is GTK doing things wrong? Is lavapipe? Is this likely to happen with other drivers? What's going on?
17:23 karolherbst: feels like a perf issue of lavapipe
17:24 Company: https://i.imgur.com/emog3eQ.png is the sysprof flamegraph of the relevant parts
17:26 Company: I just don't want to cause slowdowns on uncommon hardware - like any of the mobile chips
17:58 alyssa: Company: whether push constants are "real" or not is firmly hw dependent, yeah.
17:58 alyssa: although it usually saves an indirection
17:58 karolherbst: *sobs in nvidia*
17:59 Company: I'm more wondering if the UBO idea is bad
17:59 Company: and we should avoid it
17:59 Company: either by using something else entirely or by only using it if maxPushConstantSize < size_gtk_needs
17:59 alyssa: Company: it's probably fine, but trust your benchmark
18:00 karolherbst: it kinda feels like that lavapipe could be improved there... not really sure why push constants would be any faster than UBOs, unless the way those are allocated is different...
18:00 karolherbst: ohh yeah.. push_constants are just stack memory
18:00 karolherbst: or preallocated mhh
18:01 Company: it feels like it's constantly remapping the buffer
18:01 Company: or copying it or something
18:01 karolherbst: well..
18:02 karolherbst: lavapipe converts push constants to an UBO :)
18:02 karolherbst: but I guess the "uploading" path is just more efficient
18:02 Company: it should be something like a 100MB buffer and use 256 byte chunks per shader invocation
18:03 karolherbst: Company: are you using multiple chunks in a single shader?
18:04 Company: no
18:04 karolherbst: but it seems the descriptor set thing isn't very optimal in lavapipe
18:04 Company: it's literally replacing vkCmdPushConstants() with vkCmdEquivalentOfBindBufferRange()
18:05 karolherbst: yeah the issue isn't really uploading, but the indirection that lavapipe adds with UBOs and it's allocating and mapping new memory on each desc set creation
18:06 karolherbst: so it kinda feels like you are recreating descriptor sets constnatly?
18:06 karolherbst: using UpdateDescriptorSets might be better
18:07 karolherbst: but also feels like that lavapipe could allocate memory a bit more efficient here
18:08 karolherbst: memset running into pagefaults.. maybe want some madvise(MADV_POPULATE_WRITE) here and there mhhh
18:09 Company: shouldn't it just index into the existing big buffer that I spent all that time creating for it?
18:09 Company: the big beautiful buffer?
18:09 karolherbst: it's not the UBO that's a problem
18:09 karolherbst: but the descriptor set
18:10 karolherbst: that's where the address+size of the UBO goes into
18:10 Company: the descriptor set is constant, too
18:10 Company: it's just lots of vkCmdBindDescriptorSets() with different offsets
18:11 Company: we update the descriptor set at the start of the frame to the big beautiful buffer
18:11 Company: and then we index into it via vkCmdBindDescriptorSets()
18:13 karolherbst: ohh looks like lvp recreates them mhh...
18:57 karolherbst: in case I'm wrong: we don't have any "official" process for fixing confidential issues, right? We all just do public MRs and fix it publicly, or is there something I'm missing here?
18:57 karolherbst: for Mesa that is
19:29 Kayden: we do not. people can file confidential issues, but I believe the MRs are all public
19:30 karolherbst: yeah.. it's not like there is a great workflow in gitlab for it. Would require a private fork and then we'd have to merge it in on release or something annoying like that...
19:35 alyssa: I really don't want to be in the position of being Security Relevant given *gestures at curl*
19:35 alyssa: I guess browsers don't give us the choice
19:35 alyssa:has been hating WebGL since 2019
19:38 karolherbst: alyssa: well the "security" issues I'm getting are more related to use-after-frees and stuff
19:43 alyssa: sure
20:57 Company: <karolherbst> ohh looks like lvp recreates them mhh...
20:57 Company: should I file an issue about that btw?
21:01 airlied: not sure how fixable it it, dynamic offsets seem to suck on lvp, maybe konstantin has some ideas
21:03 zmike: it's probably a bit more tractable now than it used to be
23:26 sghuge: any idea why https://gitlab.freedesktop.org/mesa/mesa/-/jobs/102641378 is failing?
23:26 sghuge: or anyone know how to get this fixed?
23:33 airlied: sghuge: if it's happening consistently we just turn off the vmware tests
23:34 airlied: mv .ci-farms/vmware to .ci-farms-disabled/vmware or something ike that