01:53Fya: If I may be some bold to make a joke; https://files.catbox.moe/esvuyu.png But in all seriousness, is there something wrong with ANV's acceleration structures?
01:54Fya: s/some bold/bold enough
02:07HdkR: That's some good stuff right there.
09:13Ermine: are there libdrm env variables for debug output?
09:15tzimmermann: sima, thanks again for dealing with that regression on Fri. what's the current status? AFAICS the reverts didn't make it, but the original fix went into upstream
09:43pq: Ermine, 'git grep -p getenv' says LIBGL_DEBUG=verbose might do something.
10:05karolherbst: Anybody want to review my basic Initializer support for CrossWorkgroup Variables MR? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24515/diffs
10:55sima: tzimmermann, yeah see my reply to linus' mails on dri-devel, I figured not rushing the reverts is the prudent choice
10:55sima: plus turned out it was an epoll regression which was responsible for the delays
10:55sima: tzimmermann, I do think switching back to ->import_attach.dmabuf is prudent, I'll type up a mail with justification for that
10:55tzimmermann: sima, but the patches are still supposed to be reverted?
10:56sima: and also what I think the options for the handle_count patches are
10:56pinchartl: sima: it was nice reading Linus apologizing. that feels good
10:56tzimmermann: ah, i see
10:56tzimmermann: :D
10:57sima: tzimmermann, yeah since it was pretty clear that your fix was good enough for now for linus and his regressions something else, I didn't want to rush anything
10:57sima: given our track record at not understanding this part of the code base
10:57tzimmermann: makes sense
10:57sima: gives us another week at scratching our heads :-)
10:58tzimmermann: i think we should already revert the patches outside of drm-misc (amd + tegra IIRC). otherwise things will get chaotic in he next release cycle
10:59tzimmermann: with the most recent fix in place, we can also undo the import_attach->dmabuf changes without touching the framebuffer-handle changes
11:00tzimmermann: so that problem with handles would remain fixed for now (until we have a better solution there)
11:01sima: yeah that's what I'm leaning towards, too
11:01sima: at least for v6.16
11:14Ermine: pq: didn't help, but thank you nonetheless
11:15Ermine: is ARM_AFBC a modifier?
11:17Ermine: drm_info groups plane's IN_FORMATS, and several groups are labelled by "ARM_AFBC(...)"
12:48sima: tzimmermann, typed some text with my thoughts
12:48tzimmermann: thanks
12:49sima: maybe one thing to add that I forgot: I wouldn't rush the handle_count reverts into 6.16, even if you decide to go with them
12:50sima: this is all a bit too scary stuff
12:54pq: Ermine, AFBC is a set of modifiers, yes.
15:39robclark: karolherbst: is this even legal (ie. local size 0x0x64):
15:39robclark: https://www.irccloud.com/pastebin/bNEEdZly/
15:39robclark: (rusticl doesn't seem to throw an error.. but the grid seems to get dropped)
15:41karolherbst: well.. I don't think it's illegal, but I think it's legal that it runs 0 threads
15:41karolherbst: "The total number of work-items in a work-group is computed as local_work_size[0] × … × local_work_size[work_dim - 1]"
15:42karolherbst: well..
15:42karolherbst: maybe undefined if you go by this: "Otherwise, when non-uniform work-groups are not supported, the size of each work-group must be uniform. If local_work_size is specified, the values specified in global_work_size[0], …, global_work_size[work_dim - 1] must be evenly divisible by the corresponding values specified in local_work_size[0], …,
15:42karolherbst: local_work_size[work_dim - 1]. If local_work_size is NULL, the OpenCL runtime must choose a uniform work-group size."
15:43karolherbst: that _should_ run in a division by 0 thing...
15:44robclark: ok.. so UB
15:45karolherbst: rusticl seems to try to make it work regardless
15:45karolherbst: but... I'm sure it might ask for nonsense values
15:45karolherbst: let me see what intel would be doing...
15:46karolherbst: it runs..
15:46karolherbst: ehh wait
15:46karolherbst: I messed up
15:47karolherbst: intel fails to launch :)
15:48karolherbst: mhh
15:48karolherbst: rusticl seems to throw an error for me...
15:48karolherbst: robclark: is it 0x0x64 or 64x0x0?
15:48karolherbst: and what's the dimension?
15:49robclark: no, it really is 0x0x64
15:49karolherbst: like if work_dim == 1 then this is perfectly legal
15:49karolherbst: probably
15:49karolherbst: depending if [0] or [2] being 64
15:49robclark: somehow clintercept isn't printing workdim
15:50karolherbst: rusticl does pipe work_dim through to the driver
15:50karolherbst: so it should show up in pipe_grid_info
15:50robclark: correct.. just not logged here
15:50karolherbst: so maybe your driver just sees 0 and launches 0 threads
15:51robclark: anyways, I can debug more, I just wanted to see what the correct/expected behavior is
15:51karolherbst: and should sanitize the values to 1? could also make it the frontends responsibility
15:51karolherbst: could also hard code 3 and make it's the frontends problem
15:51robclark: from looking at cmdstream trace, I think the grid gets dropped
15:51karolherbst: yeah.. but can you configure a 1 dimensional grid?
15:51karolherbst: or do you assume it's always 3D
15:52robclark: yup, we pass workdim down to the hw
15:52karolherbst: ahh..
15:52robclark: (gl and zink always assume 3d due to api limitations)
15:52karolherbst: does it work forcing 3D and replacing 0s with 1s?
15:52karolherbst: probably I guess..
15:53robclark: I don't _think_ it is getting as far as gallium but maybe I'm lining up the CP_EXEC_CS in cmdstream incorrectly
15:54karolherbst: mhh
15:54karolherbst: well launching a 8, 0, 0 with dim 1 seems to work on iris
15:55karolherbst: GALLIUM_TRACE=/dev/stdout
15:55karolherbst: I think I've fixed it enough that it shouldn't crash anymore
15:56karolherbst: impossible to read but: <arg name='info'><struct name='pipe_grid_info'><member name='variable_shared_mem'><uint>0</uint></member><member name='block'><array><elem><uint>8</uint></elem><elem><uint>1</uint></elem><elem><uint>1</uint></elem></array></member><member
15:56karolherbst: name='grid'><array><elem><uint>16</uint></elem><elem><uint>1</uint></elem><elem><uint>1</uint></elem></array></member><member name='indirect'><null/></member><member name='indirect_offset'><uint>0</uint></member><member
15:56karolherbst: name='globals'><array><elem><ptr>0x02b13750</ptr></elem><elem><ptr>0x02b13cb0</ptr></elem><elem><ptr>0x02b0b390</ptr></elem><elem><ptr>0x02b13990</ptr></elem></array></member></struct></arg>
15:58karolherbst: maybe rusticl should sanitize those 0s with 1s, maybe we should just stop pretending it's a thing on hardware 🙃
15:58karolherbst: like dunno
15:59robclark: I mean, this could be an app bug.. not sure why on a x1-85 I get sane(ish) looking 1x1x64 but on this smaller thing I get 0x0x64 ;-)
16:01karolherbst: mhhh
16:01karolherbst: I see
16:01karolherbst: maybe some math going wrong
16:02karolherbst: I've hit CTS bugs where the math was broken and it sent nonsense values because it couldn't cope with limits being too high/low
16:05robclark: so I see in the driver the launch_grid before and after the "bogus" one, but the "bogus" on is skipped.. adding some assert!()
16:05karolherbst: but maybe rusticl should also error when it hits a 0, just not sure it's _explicitly_ stated that it's an error
16:05karolherbst: mhhh
16:07robclark:wonders why rust assert!() generates 96 levels of assert related stack frames :-P
16:07karolherbst: :D
16:08karolherbst: it uhm.. shouldn't, but sometimes...
16:08robclark: fwiw:
16:08robclark: https://www.irccloud.com/pastebin/dE3uKERN/
16:08robclark: work_dim=3
16:09karolherbst: fun
16:09karolherbst: anyway, brb
16:09karolherbst: well might take a while actually
16:09robclark: np, I can debug more.. I was just wanted to get your spec opinion on what should happen ;-)
16:10robclark: https://www.irccloud.com/pastebin/BiGBWRaX/
16:14robclark: yup, we are hitting that case.. so at least that mystery is solved
16:37xeyler: does anyone happen to know if Neil Armstrong has been on vacation? i sent out a patch which will likely make its way upstream through him
16:41gfxstrand: mareko, ajax: Does one of you know what's up with setBackgroundContext? It's looking like maybe it's only releveant for DRI2 and since we burned that, maybe we can burn this, too?
16:46MrCooper: gfxstrand: doubtful, since it's used in src/glx/dri3_glx.c
16:51alyssa: xeyler: last I heard he was somewhere in space
16:53vsyrjala: agd5f: hwentlan_: can i get some acks for merging the amd parts of https://patchwork.freedesktop.org/series/147541/ via drm-misc?
17:01karolherbst: robclark: ohh.. I couldn't find that part :) thanks for finding it
17:01karolherbst: robclark: though I think that's only valid for the _global_ size
17:02robclark: oh, well global size also had zero's
17:02robclark: anyways, fixed it.. https://github.com/robclark/tensorflow/commit/2613dd1b638b7272b1c764e54909fbb019712060
17:03karolherbst: hah
17:04robclark: 32/64 => 0
17:04karolherbst: ahh.. yeah...
17:04karolherbst: classic
17:05karolherbst: but I like that rusticl is at the state that most issues are actually application side bugs 🙃
17:06robclark: running tflite on a _tiny_ gpu exposes a lot of bad assumptions ;-)
17:06karolherbst: heh
17:06robclark: I guess no one ever tried running tensorflow on a watch before :-P
17:06karolherbst: :D
17:08xeyler: alyssa: got it. thanks.
17:17alyssa: xeyler: (I'm just being silly)
17:25gfxstrand: MrCooper: I see that. But I can't figure out what it actually does.
18:52xeyler: alyssa: oh.
18:53xeyler: well if that means he’s _not_ somewhere in space, does that mean the kernel needs a new maintainer for drm/panels? i wonder who i should forward this patch to..
19:41mareko: tarceri: FYI, I'm going to merge this soon: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36091
19:43mareko: gfxstrand: good question, it sets ctx as the current context in the consumer thread of glthread
19:43gfxstrand: Yes but what does that actually do?
19:44gfxstrand: Does the threaded context stuff call back into EGL/GLX?
19:44gfxstrand: I guess maybe for things like binding drawables to textures?
19:45gfxstrand: I guess I could delete it and see what explodes
19:45mareko: that's also a good approach
19:47mareko: it allso st/mesa and st/dri to call glX/EGL in the consumer thread, though I hope that never happens
19:47mareko: *allows
19:47gfxstrand: Yeah, that's what I was thinking
19:47gfxstrand: I could kind of see it for DRI2 but not DRI3
19:47gfxstrand: And it's only ever used for X11 and not Wayland so I'm having trouble coming up with use cases
19:48mareko: if st/dri calls back into GLX/EGL via callbacks, those callbacks could have beeen implemented by getting the current context from TLS instead of from parameters
19:49zmike: I deleted a lot of those callbacks
19:55mareko: fun idea: glX implemented on top of libEGL
19:55Sachiel: strange concept of fun
19:56mareko: it could be more fun than zink on lavapipe on softpipe
20:06mareko: karolherbst: maybe you know how to fix the rust compile failure here: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36094/diffs?commit_id=37c365e9662b5075a8b8511e916f8cbf0218d26e#64fdb9722099fe40b33c373a81dc89ae5e7b4797
20:11alyssa: mareko: can we get a virtual machine boundary in there somewhere to make it extra fun? :P
20:13karolherbst: mareko: "self.screen().nir_options[shader as usize]"
20:14karolherbst: just need to explicitly cast
20:18mareko: glX -> EGL -> zink -> venus -> glX -> EGL -> zink -> lavapipe -> softpipe
20:19mareko: zmike: ^^ your next new CI job
20:20karolherbst: if you run that on xwayland, do you get an EGL -> glX in front?
20:21mareko: that's just X I think
20:21karolherbst: mhhh could be
20:22karolherbst: so it's wayland -> glX
20:22karolherbst: no idea honestly
20:25karolherbst: mareko: ohh and also drop the unsafe around that, it's not needed anymore after your change
20:33zmike: mareko: surely d3d12 in there somehow with dozen
20:35alyssa: take 1 down, pass it around, 98 layers of graphics on the stack
21:26gfxstrand: Every day you can delete something from dri_interface.h is a good day. :D
21:27alyssa: =D
21:27gfxstrand: I'm going to run ALL OF CI on this, though. :joy:
21:30gfxstrand: Ugh... This might not work...
21:31gfxstrand: I might need to do actual work.
21:35gfxstrand: Actually, it might be okay. None of this should come from the thread
21:38gfxstrand: Okay, I'm gonna walk home while that CIs
22:29karolherbst: eric_engestrom: you want to branch mesa tomorrow?