08:28karolherbst: Soo.. I might want to do something about resource_from_user_memory. Atm I think most drivers only accept page aligned pointers, iris does internal offset magic to support any. I'm wondering if it's better to move that into the frontends instead. On the OpenGL side it's used through GL_AMD_pinned_memory and GL_EXTERNAL_VIRTUAL_MEMORY_BUFFER_AMD. The
08:28karolherbst: GL extension doesn't specify any alignment requirements, just advises to use system page size in the FAQ. The OpenCL side of things can create cl_mem buffers from host memory and doesn't specify an alignment req either, however the request is not allowed to fail in OpenCL, so atm if the driver rejects it, I simply create a shadow buffer and handle
08:28karolherbst: it in the frontend.
08:29karolherbst: I wonder if we should add a cap where each driver specifies the required alignment of resource_from_user_memory
08:29karolherbst: and then make it a frontend problem to make the call reliable
09:52kode54: is geekbench6 known to do bad behavior?
13:45eric_engestrom: hakzsam: sorry the for ~48h late reply, I've been very sporadically on my laptop these last couple of days (and I'm about to be mostly offline for a week)
13:45eric_engestrom: hakzsam: I'll make a release right now, although I only have a few minutes before I have to go; if I don't manage now I'll find some time tomorrow
13:46eric_engestrom: the release will have no other commit and I'll skip the normal ci round to verify it otherwise I don't have time to wait
14:08robclark: karolherbst: any idea about this (from cts test_conversions):
14:08robclark: https://www.irccloud.com/pastebin/rurQwfmt/
14:09eric_engestrom: hakzsam: release is out :)
14:09karolherbst: robclark: LLVM Translator bug
14:09robclark: ok so "not our bug"(TM)
14:09karolherbst: robclark: https://github.com/KhronosGroup/SPIRV-LLVM-Translator/pull/3120
14:09robclark: and yeah, I would appreciate frontend doing page alignment ;-)
14:10karolherbst: already merged and backported, might just need to update your deps or so
14:10robclark: (there might be extra fun for asahi with different host vs guest pg size)
14:10karolherbst: yeah...
14:10karolherbst: I really want the driver to tell me the alignment it expets
14:10karolherbst: but
14:10robclark: hmm, I just cloned SPIRV-LLVM-Translator yesterday
14:10karolherbst: asahi doesn't support resource_from_user_memory yet
14:11karolherbst: soo..
14:11karolherbst: robclark: ohh.. which llvm branch?
14:11karolherbst: maybe it wasn't backported...
14:11robclark: (nether does freedreno.. yet.. kernel supports it but not wired up yet)
14:11robclark: but yeah, required alignment cap would be a good idea
14:11karolherbst: I'm more interested in it in terms of fine-grained buffer SVM support
14:11robclark: I think main?
14:12karolherbst: which will require from_user_memory to be reliable
14:12karolherbst: mhhh
14:12karolherbst: mesa doesn't build on llvm main
14:12karolherbst: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35399
14:12robclark: oh, hmm
14:12robclark: I guess I'm using distro version?
14:13karolherbst: possibly
14:13robclark: yeah, /lib/aarch64-linux-gnu/libLLVMSPIRVLib.so.19.1
14:14karolherbst: ahh
14:14karolherbst: let's see
14:14karolherbst: https://github.com/KhronosGroup/SPIRV-LLVM-Translator/commit/83052effe3ac1f015b9009ca84e7286254c62754
14:15karolherbst: but the translator doesn't do releases in the classical sense
14:15karolherbst: ohh it does actually...
14:15karolherbst: since when I wonder
14:15karolherbst: robclark: anyway.. looks like you'll need 19.1.8 of the translator then
14:16karolherbst: I think they just tag whenever llvm tags
14:16robclark: this is debian (trixie/13) for $reasons.. looks like it is still on 19.1.6
14:16karolherbst: rough
14:16karolherbst: wanna have my llvm build script?
14:17robclark: no!
14:17karolherbst: :D
14:17robclark: this thing is slow (basically a watch SoC).. it would take half a century to build llvm ;-)
14:17robclark: I'll just note what version it is fixed in and move on
14:17karolherbst: okay
14:21karolherbst: mhhh
14:21karolherbst: the from_user_memory alignment problem could become _interesting_ to support
14:22karolherbst: e.g. what if your host has 4k pages, the device needs 16k
14:22karolherbst: and now you get a 0x...3100 pointer
14:22karolherbst: do you try to map 0x...0000 + (internal offset 0x3100) and hope the driver manages if a page is mapped at 0x...3000 but not before?
14:23karolherbst: that's gonna get interesting to support properly...
14:23robclark: I assume the same offset tricks as sub-page.. if guest has smaller page size, the guest mapping can still be page aligned.. I think
14:24karolherbst: yeah but if the driver says "16k alignment" I can't just try to map 0x...3000 even if it's the start of the page on the host
14:24karolherbst: _however_
14:25karolherbst: for SVM it doesn't matter, because I do the allocation :)
14:25karolherbst: and for non SVM I can still do shadow buffers
14:25karolherbst: so guess this is a corner case I'll just ignore
14:25robclark: so guest VA doesn't need the same alignment as host VA
14:25karolherbst: right, but I map into the GPU's VM space
14:25robclark: but buffer size and gpu mapping would need 16k alignment
14:26karolherbst: mhhhhhh
14:26karolherbst: I _think_ there was an issue with that on asahi... but I can't remember
14:26robclark: I guess if you want gpu va to equal guest va then it is 16k alignment
14:26karolherbst: I think the physical memory needs alignment
14:27karolherbst: but not sure...
14:27karolherbst: anyway.. can try to solve this when it becomes necessary 🙃
21:57DemiMarie: karolherbst: confirming that per-GPU-context is (required to be) the security boundary