01:00 karolherbst: uhh.. we have to handle deref_struct inside nir_deref_instr_array_stride
01:01 karolherbst: currently a ptr_as_array(struct(...)) returns 0
01:01 karolherbst: and this will upset nir_explicit_io_address_from_deref:)
01:04 jenatali: karolherbst: Why do you have to handle that?
01:05 karolherbst: because I have code running into it
01:05 jenatali: Are you just missing an explicit sizing step?
01:05 karolherbst: vec1 64 ssa_27 = deref_struct &ssa_26->field0 (global uint) /* &(*(struct.FLACCLSubframeTask *)ssa_1)[ssa_24].field0.field0 */
01:05 karolherbst: vec1 64 ssa_28 = deref_ptr_as_array &(*ssa_27)[ssa_18] (global uint) /* &(*(struct.FLACCLSubframeTask *)ssa_1)[ssa_24].field0.field0[ssa_18] */
01:05 karolherbst: vec1 32 ssa_122 = intrinsic load_global (ssa_28) (access=0, align_mul=4, align_offset=0)
01:05 karolherbst: well.. I _als) miss an explicit sizing step I think
01:05 karolherbst: *_also_
01:06 jenatali: It should be load_deref if it's loading from a deref...
01:06 karolherbst: huh...
01:06 jenatali: Lower_explicit_io should change the derefs to math and the access to load_global
01:06 karolherbst: why didn't I see that :D
01:06 karolherbst: yeah.. you are right..
01:06 karolherbst: ohh
01:07 karolherbst: wait
01:07 karolherbst: it's printing while doing the lowering
01:07 karolherbst: so it asserts on handling the ssa_28 thing
01:07 karolherbst: and that's the state the shader was
01:07 karolherbst: anyway
01:07 karolherbst: as nir_deref_instr_array_stride is today, it clearly returns 0 for this deref chain
01:09 karolherbst: the painful part is, this happens under wine :')
01:14 zmike: I think if you drink enough of it things will start working
01:14 karolherbst: probably
01:22 jenatali: karolherbst: What app is it?
01:22 karolherbst: https://gitlab.freedesktop.org/mesa/mesa/-/issues/8289
01:23 karolherbst: yeah.. I think no explicit_stride gets assigned here for whatever reason
01:23 karolherbst: well... to that field at least
01:24 karolherbst: but also being allowed to use gdb is too much to ask for I guess...
01:29 jenatali: Just use WinDbg :ap
01:29 jenatali: :P *
01:29 karolherbst: uhhh
01:29 zmike: why can't you use gdb
01:30 karolherbst: because wine is stupid
01:30 zmike: ?
01:30 zmike: use winereload.py
01:30 zmike: like a normal human
01:30 Sachiel: a normal human would not be working on any of this stuff
01:30 karolherbst: that's not even the problam
01:30 karolherbst: *problem
01:31 karolherbst: yo, rude
01:31 zmike: we're already in #dri-devel so it's a given that none of us are normal
01:31 karolherbst: wine doesn't allow me to even catch that crash :')
01:31 jenatali: It's probably the app, not wine
01:32 karolherbst: it's wine
01:33 karolherbst: wine thinks that it's a smart idea to use its own debugger
01:34 karolherbst: but if I use winedbg --gdb or something
01:34 karolherbst: then it does stupid shit anyway
01:34 zmike: is it an app or a game or what
01:34 karolherbst: I honestly doubt that anybody uses it even
01:34 karolherbst: well.. an app using OpenCL
01:34 zmike: does it happen on startup
01:35 karolherbst: what do you mean by startup?
01:35 zmike: if no, manually gdb attach and use winereload.py like a normal human
01:35 zmike: if yes, add a sleep(5) and see above
01:35 karolherbst: it doesn't change the problem
01:36 zmike: you were complaining about gdb not working
01:36 karolherbst: because wine just handles the fault on its own
01:36 zmike: 🤔
01:36 zmike: so you're saying this having tried what I'm proposing
01:36 jenatali: You're sure it's not the app? I've seen lots of Windows apps try to use their own crash handler
01:37 karolherbst: it's wines crash handler
01:38 karolherbst: it does some weirdo thing if the crash happens on the linux side for whatever reason
01:39 karolherbst: and wine-reload obviously doesn't help with any of that
01:39 karolherbst: it's doing a "handle SIGUSR1 nostop" thing, but that's not helping
01:41 karolherbst: anyway.. debugging linux libs with wine is broken and always has been
01:41 zmike: I've never had an issue with it
01:42 karolherbst: I don't even know why it doesn't trigger my breakpoints..
01:43 zmike: because your libs aren't loaded by gdb?
01:44 jenatali: Reminds me of trying to debug Android... Any time the debugger attached, the process would instantly crash. Fun times
01:44 Kayden: huh, what's winereload.py? it sounds useful, but I haven't tried to debug wine apps
01:45 karolherbst: it's all stupid anyway, because once the application finishes, gdb isn't able to restart ...
01:45 karolherbst: it's like nobody is doing this kind of stuff
01:45 Kayden: I think most of us just don't have a lot of practice with it
01:45 karolherbst: no, it's just wine being silly
01:45 zmike: https://gist.github.com/zmike/4a8059403ce1e330a9fcdff79d214fbd
01:46 zmike: right off google
01:46 zmike: gdb attach, source WineReload.py, wr, now you can use gdb
01:46 karolherbst: it doesn't work
01:46 zmike: Kayden: ^
01:46 zmike: karolherbst: you're on your own
01:46 zmike: 🙏
01:47 Kayden: huh, neat
01:49 DemiMarie: Anyone here familiar with AMD GPU command processing?
01:49 karolherbst: zmike: yeah apparently. All I can tell is that even with that, nothing gets resolved and the restarting the process within gdb issue isn't fixed by it either.
01:50 zmike: the script is for debugging steam games, so probably you have to tweak it for general use
01:50 zmike: assuming you don't already have symbols loaded
01:51 karolherbst: yeah well... I don't understand why wine can't just provide a debugging thing which works instead
01:51 DemiMarie: File a bug in Wine
01:52 karolherbst: that's going to be a fun one
01:52 zmike: eh it does work, just not for your purpose
01:53 karolherbst: debugging linux libs? I guess not
01:53 zmike: that's what regular gdb attach is for
01:55 HdkR: Restarting the process under gdb doesn't usually work because it's usually a child process spinning off some temporary thing anyway
01:55 karolherbst: ehh apparently winedbg isn't able to parse my debug info anyway.. *sigh*
01:55 karolherbst: yeah.. it's all very cursed
01:55 HdkR: Was debugging an application a few days ago and I could only gdb attach the very final process once I saw it had crashed and spinning in a crash loop
01:56 karolherbst: heh
01:56 HdkR: no amount of child execve and fork option setting would give it to me directly
01:56 karolherbst: what process did you attach to? the exe one?
01:57 HdkR: It did end up eventually being an exe process. The parent one basically did nothing while waiting for the child one to get done
01:58 HdkR: But it also did some wacky reparenting which is why gdb couldn't track it
02:14 DemiMarie: Can gdb be set to track all child processes?
02:14 karolherbst: well.. define "all"
02:15 karolherbst: it can follow children
02:15 karolherbst: but then it detaches from the old parent
02:15 karolherbst: so if the parent spawns multiple children you end up with the first one
02:15 DemiMarie: That’s just a gdb limitation then. A debugger that could trace multiple children at once would not have that problem.
02:15 karolherbst: well, true
02:16 karolherbst: do you know such a debugger?
02:16 DemiMarie: You can also break on return from clone() and attach manually.
02:16 karolherbst: mhh.. fair point actually
02:16 jenatali: WinDbg
02:16 jenatali: :P
02:16 karolherbst: heh
02:16 karolherbst: I think I'll just use printf to debug this...
02:16 DemiMarie: I don’t know such a debugger, but one can be emulated.
02:17 DemiMarie: Might be something worth implementing and upstreaming to GDB or LLDB.
02:17 karolherbst: yeah... though I suspect this might require rewriting most of the core bits
02:17 jenatali: Not that it's useful for you, but yeah WinDbg can trace multiple child processes and switch between them, and set breaks in any of them
02:17 jenatali: Comes in handy
02:18 karolherbst: power feature for power users
02:18 DemiMarie: karolherbst: LLDB might be easier to implement this in.
02:18 karolherbst: probably
02:19 DemiMarie: For one LLDB is actually a library.
02:28 karolherbst: okay.. getting close
02:28 karolherbst: I do have some types around with explicit_stride set to 0 indeed.. and that messes up array types
02:33 jenatali: karolherbst: Do you have a valid sizing callback passed when setting up explicit types?
02:33 karolherbst: yeah
02:33 karolherbst: using glsl_get_cl_type_size_align
02:34 karolherbst: uhhhh
02:34 karolherbst: I'm reading the CL code
02:34 karolherbst: and it's...
02:34 karolherbst: uhhhh
02:35 karolherbst: I think mesa is wrong here anyway
02:35 karolherbst: or maybe the spir-v...
02:35 karolherbst: would have to double check
02:36 karolherbst: ((__local int*)&task)[tid] = ((__global int*)(&tasks[get_group_id(0) * tasksPerChannel].data))[tid]; is the code
02:36 karolherbst: but the chains is /* &(*(struct.FLACCLSubframeTask *)ssa_1)[ssa_24].field0.field0[ssa_18] */
02:36 karolherbst: why is there .field0.field0?
02:38 karolherbst: why is compute code always looking so weirdly cursed
02:39 karolherbst: jenatali: it's this code https://github.com/gchudov/cuetools.net/blob/7d66a5d2d9f05478fc179d0dda4ee605e376586a/CUETools.Codecs.FLACCL/flac.cl#L269
02:39 karolherbst: and somehow none of this makes any sense if you apply sane programming logic?
02:40 jenatali: Wow
02:42 karolherbst: okay...
02:42 karolherbst: mhhh
02:42 jenatali: Yeah I dunno what's going on with that field0 stuff. I would've expected to see a cast to uint*
02:42 karolherbst: not necessarily
02:42 jenatali: We int* I guess
02:42 jenatali: Well*
02:42 karolherbst: soo... huh
02:43 karolherbst: tasks[get_group_id(0) * tasksPerChannel] this makes sense
02:43 karolherbst: so it just offsets into a global array by group id, whatever
02:43 karolherbst: but then it does &item.data?
02:43 jenatali: So that it can cast it to int
02:43 karolherbst: ehh well
02:43 karolherbst: that's a global* FLACCLSubframeData
02:44 karolherbst: yeah.. the case is totally weird
02:44 karolherbst: *cast
02:44 karolherbst: so FLACCLSubframeData is a struct with 16 ints
02:44 karolherbst: sure
02:44 karolherbst: but...
02:44 jenatali: Why is it weird? It's using thread id to pick which one to read
02:44 karolherbst: noooo
02:44 karolherbst: it's pointless
02:45 karolherbst: I think I'm close to getting it
02:45 karolherbst: the left side is also cursed
02:45 karolherbst: "((__local int*)&task)[tid]"?
02:45 karolherbst: but why?
02:45 jenatali: It just seems like it's doing a strided copy
02:46 karolherbst: yeah
02:46 jenatali: Each thread copies one int instead of copying the whole structure on a single thread
02:46 karolherbst: so it's just copying the .data struct
02:46 jenatali: Yep
02:47 karolherbst: that's some kind of optimization I tell you
02:47 karolherbst: in any case, the nir is wrong
02:47 karolherbst: I think
02:48 karolherbst: vec1 64 ssa_25 = deref_ptr_as_array &(*ssa_13)[ssa_24] (global struct.FLACCLSubframeTask) /* &(*(struct.FLACCLSubframeTask *)ssa_1)[ssa_24] */
02:48 karolherbst: vec1 64 ssa_26 = deref_struct &ssa_25->field0 (global struct.FLACCLSubframeData) /* &(*(struct.FLACCLSubframeTask *)ssa_1)[ssa_24].field0 */
02:48 karolherbst: vec1 64 ssa_27 = deref_struct &ssa_26->field0 (global uint) /* &(*(struct.FLACCLSubframeTask *)ssa_1)[ssa_24].field0.field0 */
02:48 karolherbst: vec1 64 ssa_28 = deref_ptr_as_array &(*ssa_27)[ssa_18] (global uint) /* &(*(struct.FLACCLSubframeTask *)ssa_1)[ssa_24].field0.field0[ssa_18] */
02:48 karolherbst: the second deref_struct should be a deref_cast instead, no?
02:49 jenatali: Yeah
02:50 karolherbst: I should check out the spir-v tomorrow and figure out if that's our or llvm's bug
02:50 jenatali: Weird
02:50 jenatali: Yeah or the translator
02:50 jenatali: Ping me on the MR when you solve it?
02:50 karolherbst: would be interesting to know if you run into the same issue on windows
02:50 karolherbst: which I'd assume you do
02:50 jenatali: Yeah I should try it
02:51 karolherbst: would also explain why there is no stride, because .field0.field0 is neither a pointer nor an array :)
02:52 jenatali: Right
02:52 jenatali: Seems like some missing nir validation
02:52 karolherbst: yeah
02:52 karolherbst: I'll probably figure out if we can validate this case somewhere
02:53 karolherbst: well assuming it's our bug
02:54 jenatali: There's definitely a missing nir validation, trying to array-address a non-array type
02:54 karolherbst: well
02:55 karolherbst: that reminds me, I still don't call nir_validate in rusticl :)
02:55 jenatali: Oh that'd do it
02:59 karolherbst: :3 https://gist.githubusercontent.com/karolherbst/c6006eb509a9e9717d1af631984e5025/raw/66edc449c88d0835a1a879e47bd7ed63cd141768/gistfile1.txt
02:59 karolherbst: guess I should figure this out next
02:59 karolherbst: kind of have to mimic the C side of NIR
03:00 karolherbst: at least add support for the validation bits
03:00 karolherbst: the painful part is, that nir_validate_shader is a static inline in non debug builds
03:00 karolherbst: so I can't really rely on it being there...
03:01 karolherbst: I guess I'll just wrap it then :'(
03:01 karolherbst: or something
03:03 jenatali: karolherbst: Do you know what pass that's after?
03:04 karolherbst: mhh let me try something
03:10 karolherbst: I have to create a proper macro for that stuff :)
03:10 karolherbst: or something
03:16 karolherbst: jenatali: opt_deref
03:16 karolherbst: https://gist.githubusercontent.com/karolherbst/84149024ae14d178e56b408eb6c64323/raw/d960518da5bb489b16659671f384140bf1570fa3/gistfile1.txt
03:16 karolherbst: so the one is before opt_deref
03:16 karolherbst: and I'd say it looks correct
03:17 jenatali: Yeah
03:17 karolherbst: oh well.. it's 4 am now :) I'll figure out the rest tomorrow
03:17 jenatali: Seems it's being too aggressive at removing the cast where the casted-to type is the same as the casted-from type
03:17 jenatali: But the from type doesn't have stride
03:17 karolherbst: yeah
03:17 karolherbst: something soemthing
03:18 karolherbst: I'm sure I'll find the spot tomorrow
03:18 karolherbst: and I probably also add support for this kind of debugging to rusticl, because it's getting annoying :D
03:19 jenatali: Seems like something gfxstrand would want to look at. I hit similar loss-of-info problems with cast deref opts
03:19 jenatali: Mine was alignment rather than stride though
03:22 karolherbst: I think I'll do dark magic macro stuff for the passes: pass!(nir.nir_opt_deref()); and pass!(nir.nir_shader_gather_info(nir.entrypoint());...or something.. could be fun once I figure out how I want it to look like
03:42 DavidHeidelberg[m]: robclark: Hey! Any chance we could get CI `http://10.42.0.1:8888/` as `caching-proxy` on default port 80? I'm trying to combine our LAVA cache (using default) with the google a630 and if this change would be easily doable on your side it would simplify setup a bit
05:05 robclark: anholt_: ^^^
10:08 eric_engestrom: Mesa 23.1 Release Blockers milestone -> https://gitlab.freedesktop.org/mesa/mesa/-/milestones/42
12:22 karolherbst: oh wow.. I have this test where 33% of the runtime is spent at nir_cf_node_get_function
12:24 karolherbst: ahh, it's the assert inside nir_block_dominates mhhh
12:24 karolherbst: wow
12:31 karolherbst: but I think I can cut down the runtime a little by being tricky :)
12:35 tzimmermann: javierm, may i ask you for a review of https://lore.kernel.org/dri-devel/20230216140620.17699-1-tzimmermann@suse.de/ ?
12:51 karolherbst: nir_compare_deref_paths is 22% in a debug build... huh
12:51 karolherbst: and that one doesn't have expensive asserts
12:51 karolherbst: let's dig into that with a debugoptimized build...
13:01 karolherbst: nir_compare_deref_paths is 23% in a optimized build :')
13:04 karolherbst: but not sure I can do much about it
15:09 eric_engestrom: karolherbst: you can remove just the asserts with `-D b_ndebug=true`
18:21 karolherbst: sure, but that won't help with CI
18:21 karolherbst: anyway.. I incresed the timeout for the job a little, so I hope it's less of an annoyence for everybody: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20161/diffs?commit_id=5c01747b9718d4f1d66028584d193c3b6f5abf04
18:39 karolherbst: *increased
18:39 karolherbst: and anyway, if somebody minds acking/reviewing the llvmpipe ci patch I can probably land it
18:50 swisstackle: Whatsup guys. I am Alain, a recent CS graduate and former student athlete. I am currently making an effort to learn OS (Unix) dev and possibly contribute to the Linux Kernel soon (Currently selfstudying with this course: https://ocw.mit.edu/courses/6-828-operating-system-engineering-fall-2012/pages/syllabus/). I am also try to get my skills up to the point where I'll be able to participate in an X.org EVoC.
19:40 javierm: tzimmermann: sorry, I was on PTO today. Sure, I'll do it tomorrow morning
19:40 tzimmermann: thanks a lot
20:12 karolherbst: how would people feel about backporting a series like https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10752 ?
20:13 karolherbst: I'm quite confident from a "does it cause regression" pov I think, but I'm wondering if the series is simply "too big" for backporting... dunno
20:13 karolherbst: ohh wait.. 22.2 is EoL. right?
20:14 karolherbst: nvm then
20:20 karolherbst: and I think I'll be starting to mess with "rustc --cfg"
20:56 bl4ckb0ne: exchanging r-b for a gl ext imp https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18847
20:59 zmike: still on my list for during wg calls tomorrow
21:04 bl4ckb0ne: got merged today o/
21:05 bl4ckb0ne: ill put a reminder to bug you again in 3 days then :p
21:07 zmike: 👍