00:27 janesma: thank you for the insight. If udev has changed to start with card1 instead of card0, then a kernel update (with no change to userspace) should not affect the device numbering. I will check that experiment on a debian-testing system that is currently reporting card0.
00:56 sghuge: Is there a option to dump the spirv as text from glslang or does it just allow to dump in binary form?
01:45 Sachiel: sghuge: you can use spirv-dis on the binary
01:48 sghuge: Sachiel: Yeah, that's working fine for me, but I was looking for option to dump the output directly from glslang to file (glslang has -H option to dump things)
01:49 Sachiel: I read through all the options and managed to skip that one
01:50 sghuge: I thought if we combine -H and -o would work but then it doesn't
08:24 DavidHeidelberg: is there anything arm7 based having VK support?
08:26 linkmauve: DavidHeidelberg, anything running lavapipe?
08:27 linkmauve: Also most ARMv8 CPUs still support AArch32 mode.
08:27 DavidHeidelberg: sure, but I'm asking for our CI devices..
08:28 HdkR: Snapdragon 8 Gen 2 can run 32-bit applications
08:29 DavidHeidelberg: aaah, ARM T760 is "" vulkan capable.. but it'll never Mesa have support...
08:32 DavidHeidelberg: Jetson TK1 has nice spec, but I guess no coverage for now. So nothing 32bit in our CI uses VK
09:08 MrCooper: janesma: isn't it because card0 was simpledrm?
09:20 ncopa: hi!
09:21 emersion: hi
09:21 emersion: fancy seeing you here
09:22 ncopa: I'm looking at this now: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10988#note_2425832
09:23 ncopa: i am not familiar with ralloc_*, but it seems like it is a way to do chained allocations? and when freeing the "top" level allocation/context, you free them all?
09:24 javierm: janesma: probably simpledrm is card0 and the real DRM driver is card1
09:24 ncopa: I also notice that there are currently no error handling, in case nir_opt_varyings run sout of memory
09:24 ncopa: if that happens it will simply segfault
09:25 alice: there's no malloc checking in mesa i don't think is there
09:25 alice: nor does that even generally work on linux due to default overcommit heuristic (the malloc will succeed and just crash later even when oom)
09:26 alice: well, sometimes it works, sometimes not
09:26 alice: vm.overcommit_memory=2 enables strict checking
09:29 ncopa: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/compiler/nir/nir_opt_varyings.c#L4182
09:30 MrCooper: javierm: beat you by 15 minutes :P great minds think alike, as they say
09:31 javierm: MrCooper: haha, sorry I missed your comment
15:43 janesma: javierm: I didn't know about simpledrm, but it looks older than the change that changed /dev/dri/card0 to card1. There is no card0 anywhere in /dev. I guess the sound cards are still counted starting at 0, because I have /sys/class/sound/card0
15:52 gumstixforreal: hello, is obnoxious tomato here? Michigans fecalist anal ponytail please be reasonable, none has to see your volkovs brainpain jabbering, it's your deluded dreams of networking admin powers has no ending, but a fecalist who was born by dog ejaculating on brainless worm embryo, where part of brain area was eaten by gecko who also shitted on the remains, can't succeed in networking
15:52 gumstixforreal: tasks. Give up fecalist.
15:54 MrCooper: janesma: the sequence of events we have in mind goes something like: 1) simpledrm inits as card0 2) HW driver inits as card1 3) simpledrm gets deinited in favour of the HW driver, so card0 disappears
15:55 MrCooper: there should be something about simpledrm in dmesg if so
16:01 janesma: ah, yes, I see it in dmesg. it did not show in lsmod, which made me think it was not being used
16:12 janesma: is there a way to disable simpledrm? I tried `modprobe.blacklist=xe,simpledrm` on the kernel command line, but it is still in my dmesg
16:15 mattst88: dschuermann: FYI we found that 3a2226be47751272c3ce4b7bbf39e2e2470a1f29 improved some AI workload on Intel by about 5%. thanks!
16:17 MrCooper: janesma: module_blacklist=simpledrm maybe
16:18 MrCooper: presumably modprobe.blacklist doesn't work because it's built into the kernel, not a module
16:28 janesma: bah, ok. I will confirm the theory. Relying on card numbers is a brittle aspect of some automation that our development process relies upon. I understand that the process needs to be stronger. I do wonder if stability in the card numbering is something that end-users with customized display configurations rely on.
16:29 sima: MrCooper, so the deinit should happen before the hw driver really loads, but the issue is that the chardev numbers are reserved for longer
16:29 sima: so if we're maybe trying to be really clever and limit that to drm_dev_register/unregister instead of drm_dev_init/free a lot of these issues would be less ugly?
16:29 sima: (I haven't tried, just an idea that crossed my mind rn)
16:30 MrCooper: it's really just cosmetic though, user space can't rely on card0 existing anyway
16:30 zamundaaa[m]: janesma: in KWin we just allow using the identifiers in /dev/dri/by-path, which are (more) stable
16:30 sima: MrCooper, yeah ...
16:31 sima: zamundaaa[m], yeah would be only really for userspace that tries the cardX names
16:31 janesma: some people still have /dev/sdc in their fstab...
16:33 emersion: yeah, and sometimes it breaks, just like card0…
16:33 janesma: exactly, yes
16:33 janesma: My own use case requires access to /sys/class/drm/cardX for whatever the default rendering device is. We have a lab of machines, and we configure bios at install time to select the discrete card if that is the test target.
16:34 zamundaaa[m]: janesma: there's a boot-vga tag that you can use for getting the bios-selected device
16:35 janesma: oh, that sounds much better than keeping configuring pci addresses per machine.
16:35 zamundaaa[m]: https://invent.kde.org/plasma/kwin/-/blob/master/src/utils/udev.cpp?ref_type=heads#L225
16:36 emersion: probably you can convince udevadm to filter based on this or something
16:40 janesma: Just to be clear on how I used boot_vga: I would have to iterate through the pci devices in /sys/devices looking for boot_vga, and either use the contents of the file to identify cardX, or the path to the file to identify the correct /dev/dri/by-path entry?
16:41 janesma: we try to avoid customizing the distro configuration, so we have less to maintain and also so our deployment looks more like the platforms that end users will encounter.
16:46 emersion: doesn't seem like udevadm lets you filter on a sysattr sadly
16:46 emersion: you can iterate on dirs in /sys/class/drm/
16:46 emersion: then check if /sys/class/drm/card*/device/boot_vga is "1"
16:48 janesma: ah, so the contents of the file '1' is not indicating 'card1', but the path to file in /dev or sysfs will give me the info I need.
16:48 janesma: I really appreciate the information thank you.
16:49 emersion: np!
17:04 daniels: janesma: fwiw userspace is generally immune to ordering as Arm systems typically have separate DRM devices for render and display anyway, plus vgem also mixes it up
17:33 javierm: daniels: yeah, in general the Linux device model doesn't guarantee a deterministic device node numbering
18:09 mareko: the r300_should_vectorize_io callback has incorrect parameters
19:27 zmike: for all you glcts enthusiasts who know and hate KHR-GL46.texture_swizzle.smoke
19:28 zmike: did you know that this one test case actually contains over 70,000 unit tests?
19:47 daniels: so 0.00001% of an eds/so test?
19:48 zmike: yes
19:48 zmike: if by "test" in that case you mean CL
22:27 mareko: 70,000 tests? DELETE!
22:50 zmike: if only
22:50 zmike: but they'll be 70,000 from now on instead of 1, which means they can be run in parallel to complete in fewer than 10 minutes
23:16 alyssa: zmike: isn't swizzle.functional even slower than .smoke?
23:16 alyssa: (-:
23:17 zmike: we're getting there
23:48 DavidHeidelberg: for people who would love watch their scheduled nightly runs of pipelines and it's too annoying, please look at https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29392
23:49 DavidHeidelberg: I see "infinite" numbers of idea for improvement, but I believe this could provide a good value for people who get to the work and want to run one command which tell them how their pipelines doing :P
23:49 DavidHeidelberg: s/pipelines/jobs/
23:55 DavidHeidelberg: zmike: ^ :P you may like it