09:14tzimmermann: javierm, i intend to post the final patches for the fbdev ops. after that, each driver sets its fb_ops. the I/O helpers will be in a module and all helpers test if the FBINFO_VIRTFB flag has been set correctly. ok?
09:17javierm: tzimmermann: makes sense. I assume it's a patch bomb :)
09:18tzimmermann: ~30 patches
09:18tzimmermann: i do expect some fallout though
09:18tzimmermann: as i cannot test all drivers.
09:18javierm: tzimmermann: yeah. That's OK
09:18tzimmermann: it's all the rest plus some fixes
09:19tzimmermann: some drivers are inconsistent and mix I/O and sysmem code. IDK how to fix that
09:20tzimmermann: so there'd then be a warning. if anyone complains, we'll have to take a closer look
09:21javierm: tzimmermann: yes, that's the best that can be done. Can't guess whether should be I/O or sysmem to make it consistent
09:23tzimmermann: in other cases, drivers use shadow buffering for read/write like for deferred I/O, but don't actually implement deferred I/O for mmap. tha tmakes me wonder if the dirver even works correctly
09:23tzimmermann: anyway, i'll post it once ready
09:24javierm: tzimmermann: Ok
09:38emersion: enunes: aha i really like how this MR is +3 -367 :P
09:48javierm: that's an amazing diffstat :)
10:08mripard: sgruszka: I just pushed the 6.7-rc1 merge into drm-misc-next, and there was a conflict in ivpu_job_done_thread_fini(). I think I got the resolution right, but you might want to double-check
10:49tjaalton: what's happening with mesa-23.2.x?
12:47enunes: emersion: that was the plan all along :) but looks like I have to put at least some of it back
12:49emersion: yeah, a few lines
12:55thellstrom: bbrezillon, dakr: Any chance you could provide an / ack / rb on the VM bind locking document patch? It's been updated to match the latest drm_gpuvm development.
14:59MrCooper: anholt_: hmm, LIBGL_DEBUG=verbose produces a lot of "WARNING: unknown fbconfig attribute from server: tag 0x8060 value 0x8063" (0x8060 is GLX_SWAP_METHOD_OML) now
15:33mripard: sima: how do we deal with series that should be merged through other trees but affecting some DRM drivers ?
15:34mripard: we ask for a stable branch and merge it?
15:42dj-death: jenatali: I put together a simple example : https://gitlab.freedesktop.org/llandwerlin/mesa/-/commit/105513763c17a2c1d003c6c0798d0d6a037f4f7c
15:43dj-death: jenatali: what I would like is to avoid that the struct is temporarly stored in scratch
15:43dj-death: jenatali: I'm wondering how to avoid that
15:44airlied: mripard: sometimes we can just ack the drm drivers
15:44airlied: and they can all go in via another tree
15:44airlied: or we get a stable topic branch from them with the base + drm patches and pull that into drm-misc-next
15:44jenatali: dj-death: I'll try to repro
15:46dj-death: jenatali: thanks a lot
15:46jenatali: dj-death: Does intel-clc build on Windows?
15:47dj-death: jenatali: I'm still wondering if that's how things are or people have some magic that gets rid of all temporaries to variables
15:47dj-death: s/variables/ssa/
15:47dj-death: jenatali: hmm I've never tried :)
15:47dj-death: jenatali: likely no
15:47jenatali: Yeah that makes it a lot harder for me to repro. Not impossible, just harder
15:47mripard: airlied: thanks :)
15:48dj-death: jenatali: I think asashi-clc would exhibit the same behavior
15:48mripard: it's for a "convenience" patch for kunit that would be useful for other drivers too going forward (and possibly conflict with some of the work happening at the moment), so I'll ask for a topic branch and put you in Cc
15:48sima: mripard, if it's not too conflict-y just an ack from airlied or me is enough
15:48sima: and then merge it all through the other tree
15:48dj-death: jenatali: I mean if you have the linux container thing, it probably just compiles out of the box
15:49sima: topic branch imo only when needed, i.e. additional patches in both trees or some serious conflicts you can see will happen
15:49sima: serious = functional ones where Linus will balk at resolving them
15:49dj-death: jenatali: wsl :)
15:49dj-death: jenatali: forgot the name :)
15:49jenatali: dj-death: let me try it on the CLOn12 compiler first
15:49mripard: sima: ok then, I'll ack it
15:50sima: mripard, yeah if it's just in your driver then your ack is good enough too
15:51mripard: it's in the DRM and vc4 kunit tests
15:51mripard: guess it should be good enough either way :)
15:52sima: mripard, if you want I can whack some ack on top too, if you give me some pointers
15:53sima: in general I'm very much in favor of "least amount of paperwork" for anything cross-tree
15:53mripard: https://lore.kernel.org/dri-devel/20231110200830.1832556-1-davidgow@google.com/
15:59sima: yeah a-b: me for merging through kunit or whatever
15:59sima: I guess I need to reply on-list ..
16:04jenatali: dj-death: CLOn12 is getting rid of the variables before lowering to scratch
16:06jenatali: dj-death: Ah right, I remember now. You have to lower function_temp to explicit types before opt_memcpy can remove the memcpy
16:07jenatali: dj-death: https://gitlab.freedesktop.org/mesa/mesa/-/commit/e9b2bb244bab82c4638ead8cee57c9507d793239
16:13jenatali: dj-death: The relevant two nir dumps: https://gitlab.freedesktop.org/-/snippets/7759
16:57dj-death: jenatali: thanks a lot!
16:57dj-death: jenatali: I'll try that
17:06dj-death: jenatali: I'm a bit confused, your dump still shows the variable
17:08alyssa: jenatali: fire
17:09jenatali: dj-death: yeah, then the var copies get split and then they can get lowered to SSA to make the var dead
17:10dj-death: ah okay
17:15alyssa: dj-death: "
17:15alyssa: anv: rewrite internal shaders using OpenCL
17:15alyssa: " uwu
17:17alyssa:is curious for your feedback coming from glsl
17:17alyssa:is hoping she made the right call betting the farm on clc
17:26dj-death: alyssa: hmm I think it's a requirement for what I want to do
17:26dj-death: alyssa: like pointers of pointers
17:27dj-death: alyssa: but my current lowering appears broken so I can't use any struct
17:27dj-death: alyssa: which is a shame, hopefully I can fix that
17:28dj-death: jenatali: I just copied your lowering code
17:28dj-death: jenatali: amazing :)
17:28dj-death: down to maybe 2 loads + 2 stores
17:28dj-death: direct to global memory
17:29dj-death: I wonder how much the GRL kernels will be optimized with the same lowering
17:32karolherbst: for everybody still on ikiwiki: skelly was working on a complete redesign of the nouveau wiki (which I migrated to gitlab pages a while ago), preview can be seen here: https://theevilskeleton.pages.freedesktop.org/-/wiki/-/jobs/51615598/artifacts/public/index.html
17:32karolherbst: MR: https://gitlab.freedesktop.org/nouveau/wiki/-/merge_requests/29
17:32karolherbst: in case any here still has a ikiwiki thing going for their project and want to have the same
17:33karolherbst: any feedback welcomed
17:38dj-death: alyssa: it's starting to look amazing
17:42jenatali: dj-death: 👍 glad I could help
17:43jenatali: There's probably more that could be moved to common pass lists or something so everyone doesn't have to copy a bunch of passes
17:44jenatali: alyssa: was that about the CL topic or the GL MR I posted?
17:50dj-death: jenatali: agreed, I have no idea why you stuff works
18:12alyssa: dj-death: :-D
18:13alyssa: is there a particular new kernel/library routine you have in mind for this/
18:13alyssa: jenatali: GL MR
18:14dj-death: alyssa: generated commands
18:22alyssa: ahhhhhhhhh
18:22alyssa: nice :-)
18:22alyssa: with gpu genxml?
18:28dj-death: well no
18:28dj-death: hand coded I think
18:29dj-death: it's all and nice genxml
18:29dj-death: until you have 6 different variants of GPUs
18:29dj-death: not sure how much that's workable
18:32alyssa: ah..
18:32alyssa: why not?
18:33alyssa: do the exact same per-gen recompile+suffixing as on the cpu, it's just C code
18:34alyssa: if the -D thing is unhappy with libraries, then define in an auxiliary .cl and have your entry .cl do a `#define arch 1, #include foo.cl, #define arch 2, #include foo.cl` pattern?
18:35dj-death: hmm maybe
18:35dj-death: so far for generated indirect draws the instructions didn't change between gens
18:36dj-death: so it was somewhat simpler to debug
18:36dj-death: also verify my shader does not have too many send messages
18:40bwidawsk: melissawen: curious if you or someone you know is interested in adding modifier support for VKMS
18:40bwidawsk: I could use it for a project, and I really don't want to write anymore kernel patches
18:52melissawen: bwidawsk, it isn't in my radar at the moment. I may be missing something, but I didn't get what would be the point for vkms... emulating each vendor-specific modifier there?
18:53bwidawsk: actually, I just want/need linear support. Currently if you allocate a buffer with modifiers via GBM, you get back an Invalid
18:53bwidawsk: so it should be fairly trivial (I think)
19:00bwidawsk: melissawen: I'd like to have this pass for VKSM, in short: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/gbm/backends/dri/gbm_dri.c?ref_type=heads#L1066
19:15melissawen: bwidawsk, oh, I see, makes sense. I'll take a look (hope this week) and get back to you.
19:16bwidawsk: melissawen: thanks!
20:26airlied: zzoon[m]: I haven't fixed it yet, but take a look at my branch h264enc_anv_4, might be some other fixes in there you might find useful
20:26airlied: also my irc connection isn't great, so might not see msgs at all, back to my desk next week