02:19 alyssa: jannau: might be fallout of mareko's changes
02:20 alyssa: 2f6b4803abe6d2d76b474d46670d68849cbfd21f
02:20 alyssa: those are causing trouble for Intel too
07:17 tzimmermann: vsyrjala, as you asked for, the vblank timeout has been increased and it resolves the spurious timeouts. if you have no further comments, i'd like to merge the patch https://lore.kernel.org/dri-devel/20251028034337.6341-1-chintanlike@gmail.com/
08:02 glehmann: Lynne: depends on your access pattern
08:03 glehmann: a 2D storage image would likely be better than using a dumb buffer in a linear way if your access is a typical 2D kernel
08:04 jannau: alyssa: bingo. is this an existing issue in asahi exposed by the change or an issue in the chnage itself? I'll open an issue in any case
08:41 jannau: Mary: I see more flakes and potentially crashes (I haven't rerun the affected cases non-concurrent yet) than recorded in commit fb4010e64123 ("asahi: Update CI expectations") using mesa's debian arm64 containers for building and testing
08:43 jannau: in which environment did you test?
08:46 jannau: if anyone is interested I have a small script and environment files to build and test using the CI scripts and containers locally
09:06 Mary: jannau: Tested with VKCTS 1.4.4.0 on Fedora 42 with 6.15.10-402.asahi.fc42.aarch64+16k for the kernel
09:07 Lynne: glehmann: I'll be doing one pixel access per invocation
09:07 Lynne: I think that's pretty random
09:08 Mary: jannau: my script to run the CTS https://gist.github.com/marysaka/e5f0cf5356fb693b7d78f03cdb233e83
09:27 glehmann: Lynne: well one pixel access might still prefer 2D if you dipatch e.g. 8x8 workgroup and use the invocation id as the coordinate
10:06 Lynne: can I workaround the <octet buffer full of expletives> limitation of push data not being addressable directly via gl_LocalInvocationID?
10:13 Lynne: like, how can this limitation even exist or be considered workable? its probably the number one thing you'd want to use
10:17 glehmann: because push constants are meant for uniform data
10:18 glehmann: just like e.g. gl uniforms or d3d12 root constant
10:19 glehmann: if you want to use fully dynamic indexing, use a ssbo descriptor, or put a buffer device address to the data in a push constant
11:28 karolherbst: mhhh.. having a bit of a weird situation with nir_lower_mem_access_bit_sizes. store_global storing a 16x2 value with align_mul=4 and align_offset=0. Driver returns bit_size=32, num_components=1, align=1. nir_lower_mem_access_bit_sizes splits it into two stores of 16 bit each... is this expected behavior?
11:29 karolherbst: like should drivers use nir_opt_load_store_vectorize after nir_lower_mem_access_bit_sizes?
11:34 karolherbst: ohh wait nevermind.. I've done something bad :)
14:15 Lynne: why are R10X6 and R12X4 formats defined as MSB-padded, which is annoying but okay, but in shaders, you need to shift your results up by 4 or 6 bits?
14:16 Lynne: surely, this is the imageview's job to do, since you know, it does this for every single other format ever, such as float views of int images having a range of 0-1?
14:19 Lynne: ...except of course for bgr, which is a can of worms I won't get into now, but at least the TSG had a pseudo-excuse for that one
17:14 ophilia: Hello, Is this the channel for the Linux Mesa drivers for AMD GPUs??
17:14 K900: One of them, at least
17:15 ophilia: ahh, i was sent here to report something going on with my pc by the app developer and my distro manager
17:15 ophilia: they both said it was linked to mesa
17:17 ophilia: I use Second Life Viewers on linux and any viewer i use for it all crash within a few minutes even if they are linux compatible.
17:17 K900: Do you have a stack trace or anything?
17:18 ophilia: Ophilia I've been told the stack trace contains no usable information sadly - this might be because the version of the libraries you have installed contain no debugging symbols.
17:18 ophilia: Suggested next steps – Seek guidance for installing a version of the libraries with debugging symbols included in them, then trigger the crash again, and submit the bugsplat report again.
17:19 ophilia: Actually at this point, I'd be involving either your distro maintainers support and/or the mesa folks in debugging this further. It's at the point where the problems are external to the viewer. We've at least identified where the issues are and you have some direction now to pursue it if you want to debug further.
17:19 ophilia: they sent me this on the forums
17:19 ophilia: i do have crash logs though
17:19 ophilia: but if you can help me find out how to give a usable stack trace, i would do it
17:20 K900: What distro are you on?
17:20 ophilia: this message is from the app dev
17:20 K900: Most distros provide debug symbols in some way
17:20 ophilia: i use CachyOS
17:20 ophilia: which is Arch based i know
17:21 K900: Yeah I don't know if they provide debug symbols
17:21 K900: Because the debug symbols need to exactly match the package sources
17:21 K900: And I know they patch Mesa
17:21 ophilia: patch mesa?
17:21 K900: So the Arch debug symbols will not be applicable
17:22 K900: Apply additional changes to the source code that are not shipped by the official upstream releases of Mesa
17:22 K900: (or the Arch packaging of Mesa)
17:22 ophilia: ahh i see.
17:23 ophilia: so does that mean i was sent to the wrong place?
17:23 llyyr: is there a place where I could read your bug report to cachyos?
17:23 ophilia: like the ones i all sent?
17:23 llyyr: not necessarily, it's just that your bug report won't be actionable for mesa either without debug symbols
17:23 llyyr: yeah
17:23 llyyr: better to read those than you ask you for informatin you've already provided
17:24 K900: Supposedly they have https://debuginfod.cachyos.org but it is currently down
17:24 ophilia: https://paste.cachyos.org/p/4142dcf.log
17:24 K900: I would maybe try seeing if it still reproduces on a distro that does have debug symbols
17:24 K900: Like vanilla Arch or Fedora or something
17:24 ophilia: https://paste.cachyos.org/p/4142dcf.log
17:24 ophilia: wait thats the same one
17:25 ophilia: uh darn, i could try, i just dont have a second pc to install it on
17:25 K900: The only crash in that log is "megasync"
17:25 ophilia: at least not one able to run the apps
17:25 K900: Which is probably not the thing
17:25 ophilia: oh
17:25 K900: Boot a live CD
17:25 ophilia: darn it
17:25 ophilia: live USB lets me install things?
17:26 ophilia: i can do that easy!
17:26 K900: Yes, they generally do
17:26 llyyr: what is this second life viewers?
17:27 ophilia: Second life is a thing similar to VRChat from the early 2000s, however it has Viewers which are used to access it.
17:28 ophilia: rather than just 1 app, anyone can make a Viewer to fit whatever needs they have
17:28 ophilia: from photo taking and looks, to advanced features and stability
17:29 K900: So a videogame
17:29 K900: Understood
17:29 K900: It would be very nice to confirm this reproduces outside of CachyOS then
17:29 K900: Because the CachyOS folks generally tend to ship things that may not be fully stable, as long as they're also fsat
17:29 K900: And sometimes it works and sometimes, well, it doesn't
17:30 ophilia: yea
17:30 ophilia: it just weird since it was working and now it isnt
17:30 llyyr: would I need to login to trigger a crash?
17:30 ophilia: and for me, cachy was the most stable and mix of os i have tried
17:31 ophilia: yes
17:32 ophilia: the crash for me happened between 2 and 25 minutes after login
17:32 ophilia: this also included even when i was just standing still doing nothing
17:32 K900: Yeah I doubt this is something that's going to be easily reproducible then
17:32 K900: It would be very helpful to get a stack trace
17:33 ophilia: and it happened with Firestorm Viewer linux compatible version in beta and stable, The windows version of firestorm, and Black Dragon Viewer which is windows only
17:33 ophilia: so right now i am downloading the iso for Fedora
17:34 K900: Hold on, do you mean Windows things running on Wine?
17:34 K900: Or do you mean Windows things running on actual Windows?
17:34 ophilia: both windows running through lutris and linux compatible
17:34 K900: OK, so Wine
17:35 ophilia: i had assumed it was jhust the linux version but it happened with the windows version also
17:35 ophilia: the reason i use them on linux is cause the frame rate is HUGE
17:35 K900: The reason I'm asking about Windows is because Windows does not use Mes
17:35 K900: *Mesa
17:36 ophilia: how do i make a Live USB on linux again? Balena ether isnt in the repo, is it AUR?
17:36 K900: So if it crashes on native Windows, it's likely an application bug or possibly (but unlikely) a hardware issue
17:36 ophilia: it didnt crash on windows at least
17:36 ophilia: i did test that
17:36 K900: "dd if=path/to/your.iso of=/dev/sdX bs=1M status=progress"
17:36 K900: (where /dev/sdX is your USB stick)
17:37 ophilia: okok
17:37 K900: It's not the fastest way probably but at least you should have dd already installed
17:39 ophilia: sorry for the delay though
17:43 ophilia: actually it might take awhile for the app dev to respond with the stack trace, ill miss you all darn it
17:44 K900: Why do you need the app dev?
17:44 K900: You can get a stack trace by yourself
17:45 llyyr: can you at least provide the stack trace without symbols so we can verify that it is indeed crashing in mesa?
17:46 ophilia: i can?
17:46 ophilia: how would i get the stack trace
17:46 orbea: ophilia: gdb
17:47 llyyr: coredumpctl should list all recent stack trace from previous crashes
17:47 K900: Start the application, let it crash, then run "coredumpctl info"
17:47 K900: And pastebin the output
17:47 ophilia: thank you
17:47 ophilia: i will try that!
17:57 ophilia: i swear if it starts working after a month of being dead
18:15 ophilia: would stack traces for a app running through lutris show also? or no ? just wondering
18:16 K900: A native Linux version would be a better test
18:16 K900: A Wine version should show _something_ but it will be easier with a native Linux one
18:20 ophilia: is it really not gonna crash now?
18:21 K900: I mean
18:21 K900: If it doesn't
18:21 K900: We might know what your problem is
18:21 llyyr: if it's not crashing on fedora that means the issue is with cachyos patches/compiler flags
18:21 ophilia: well no, i am still doing the cachy test trying to crash it on cachy first
18:21 ophilia: but it isnt crashing now
18:22 ophilia: but it did yesterday
18:22 K900: Are you sure this is not just like, an actual game bug?
18:22 K900: That was fixed?
18:23 ophilia: well there hasn't been any updates lately which is why i was confused. Viewers have to be manually updated
18:23 ophilia: let me see if black dragon works now?
18:41 ophilia: i have not changed anything
18:41 ophilia: and now it works
18:41 ophilia: at least for now
18:41 ophilia: but
18:41 ophilia: i will send any stack trace i get when the dev send me the other ones i had sent from older crashes
18:49 jannau: Mary: still seeing unexpected fails and flakes: https://paste.debian.net/1404676/ fails from 3 runs: 6.16.8 fedora 42, 6.16.8 mesa's debian and 6.17.7 mesa debian. I wonder if I regressed something in the kernel
18:51 Mary: jannau: Hmmm let me redo a full run on 6.15 maybe I forgot those somehow...
18:55 alyssa: all GS fails is bizarre
18:56 alyssa: jannau: dEQP-VK.spirv_assembly.type.vec4.u64.clamp_vert fails too
18:57 alyssa: timeout
18:57 alyssa: see dmesg
18:58 alyssa: explains the flake
18:58 alyssa: & why only VS/GS affected
18:58 alyssa: we never figured out how to increase the VS timeout
19:01 alyssa: Possibly I didn't notice this because I ran on m2 max
19:11 Mary: hmmm yeah it timeout here too (tested the clamp_geom one)
19:11 Mary: so it seems I forgot to add things to the list somehow...
19:13 jannau: alyssa: dEQP-VK.spirv_assembly.type.vec4.u64.clamp_vert is as Pass in all results.csv
19:14 jannau: yes, there are timeouts in the log, tests are still flaky/failing with 1 job though
19:28 alyssa: on g13g clamp_vert flakes due to timeout
19:29 alyssa: run in isolation 1 job
23:04 Venemo: hey guys
23:05 Venemo: does anyone here know about the drm scheduler? does drm_sched_wqueue_stop just stops accepting submissions from user space, or will it also stop stuff from the kernel?