09:17dj-death: karolherbst: did you see the comment from cmarcelo on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27640 ?
09:17dj-death: karolherbst: looks like this is generating invalid NIR in some cases
10:43karolherbst: yeah....
10:46karolherbst: dj-death: so... I think we need to make the memcpy optimization smarter, but I don't really have a good idea how. Maybe we check there if we have a cast from/to something we could optimize to copy_deref there. Or like casting a struct to a primitive is kinda "normal" in compute, so we could certainly special case it there. I'm convinced that `opt_replace_struct_wrapper_cast` is only valid for a few corner cases and is only safe "by chance"
11:15dj-death: karolherbst: hmmm
14:32karolherbst: okay... it seems like we _might_ be able to improve nir_opt_copy_prop_vars to resolve this issue here...
14:39karolherbst: dj-death: any thoughts on this pattern? https://gist.github.com/karolherbst/b11be6e89f6d6c753a4ca5ec57cbcdc6
14:40karolherbst: though I think we can only do that with explicit types and _if_ the field offset is 0
14:40karolherbst: but we could probably special case it...
14:40karolherbst: dunno...
14:41karolherbst: gfxstrand: if you are up to taking a look at some deref stuff we need to deal with since llvm-17 or so ^^
14:42karolherbst: we kinda need to do the same opt which is possible in the llvm-16 case also with llvm-17, which gives us weird casts in the middle
14:43karolherbst: and I've tried converting that cast to a deref_struct, but that can mess up all sorts of other things
14:54dj-death: karolherbst: ah wtf llvm
14:54dj-death: karolherbst: using 2 different pointers for the same thing...
14:55dj-death: karolherbst: this looks like a pattern we would to optimize
14:55dj-death: karolherbst: try to unify all the pointer cast to the same location
14:56dj-death: karolherbst: but I could also see llvm trying generating different load/store
14:56dj-death: like store 2 vec2, load 1 vec4
14:57dj-death: maybe our vectorizer can optimize that in which case it's not an issue
15:17MrCooper: is DRM_IOCTL_PRIME_HANDLE_TO_FD officially supposed to work for a dumb BO?
15:18emersion: yes
15:21MrCooper: is DRM_IOCTL_MODE_MAP_DUMB supposed to work for any BO imported with DRM_IOCTL_PRIME_FD_TO_HANDLE, even if the original exported BO wasn't dumb?
15:22emersion: i don't think so
15:22emersion: like, there is "DUMB" in the name?
15:23emersion: have you found out that it happens to work in some cases?
15:25MrCooper: background is https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27686 which uses dumb BOs for dma-buf support in lavapipe
15:29emersion: oh no ;_;
15:30emersion: dumb buffers are for modesetting purposes only!
15:31emersion: is there any chance to use a DMA-heap here instead?
15:31emersion: doesn't vgem has a way to allocate buffers?
15:32emersion: sima, see that MR linked above
15:32emersion: hm sima not here
15:35karolherbst: dj-death: yeah... well.. with llvm-17 there is just "pointer", not "pointer to X", so we kinda have to figure out how to map that to derefs to properly optimize. Like.. in that example, it doesn't really matter what types are involved, just that at the same logical/actual location we have a write and a read
15:41cmarcelo: karolherbst: dj-death: havent looked at details, but wonder how much that relates to *spirv* untyped ptrs. that would be mapped in NIR as adding casts everywhere, so NIR would still be somehow typed. I guess the issues you are facing are at NIR level?
15:41karolherbst: afaik spirv untyped pointer exist only because of llvm dropping typed pointers
15:41cmarcelo: (I have some but not complete work on untyped ptrs, just trying to gauge if it would be helpful to jump it to the front of the stack here)
15:42cmarcelo: karolherbst: on paper there are some benefits to it, but yeah likely makes life easier for people using LLVM stacks at various levels.
15:42cmarcelo: "likely the motivator is..."
15:42karolherbst: this all will probably become obsolete with the spirv LLVM target anyway...
15:42cmarcelo: "main motivator"
15:43karolherbst: but I doubt that's ready before llvm-19
15:43cmarcelo: karolherbst: what part of "this all" you mean
15:44karolherbst: the middle end IR in llvm still has typed pointers, no? So the spirv target shouldn't have the same issue here (and overall give us better code probably)
15:44karolherbst: not sure if they'd emit untyped pointers in spirv?
15:45cmarcelo: AFAIK untyped ptrs even in LLVM means: the types are in the operations, so part of the benefit of having such way to do things in SPIR-V.
15:46karolherbst: sure
15:46karolherbst: but the issue is, you don't even know your function types anymore
15:46karolherbst: like if you only see the decl of a function, on the LLVM IR level you have 0 idea what the actual pointer types are
15:46karolherbst: and that leads to all sorts of annoying issues
15:46cmarcelo: oh I see
15:46karolherbst: like..
15:47karolherbst: linking spirvs is entire busted
15:47karolherbst: *entirely
15:47karolherbst: if llvm calls into memcpy the pointers are also random
15:52karolherbst: but anyway.. kinda need to figure out how to optimize that stuff so we don't end up with pointless scratch memory :D
15:54dj-death: karolherbst: private variables are not part of the function interface right?
15:55karolherbst: they are
15:55karolherbst: well
15:55dj-death: karolherbst: shader_temp ?
15:55karolherbst: depends on what you mean
15:55karolherbst: shader_temp doesn't really exist in CL anyway
15:55dj-death: I mean function_temp should not be something we need to exchange between modules we link togehter
15:56karolherbst: yeah... though you can have function_temp arguments
15:56dj-death: heh yeah
15:56dj-death: let say if you have a function call with local pointer and that function is not part of your current module
15:57dj-death: I think all my cases are not that currently
15:57dj-death: GRL or other internal opencl functions
16:00karolherbst: you can still have things like indirects
16:06daniels: kusma: if you want more BGRA fun, I've just spotted that though EXT_texture_format_BGRA8888 adds GL_BGRA_EXT (unsized) as a color-renderable renderbuffer 'sized internal format', glRenderbufferStorage rejects both BGRA_EXT and BGRA8_EXT ...
16:08daniels: I wonder if that's because the renderbuffer stuff was only added later by Tobias
16:18dj-death: karolherbst: hmmm what's that?
16:21abhinav__: jani vsyrjala hi, another gentle reminder about https://patchwork.freedesktop.org/patch/578601/?series=129748&rev=3 pls
16:31karolherbst: dj-death: indirect arrays and stuff?
16:32dj-death: karolherbst: yeah true
16:32dj-death: karolherbst: that's indeed an issue
16:33dj-death: karolherbst: but then we have no way to represent anything bigger than vec16 in NIR
16:34lumag: mripard, tzimmermann, mlankhorst: gracious ping for https://patchwork.freedesktop.org/patch/578600/?series=129750&rev=3
16:34karolherbst: dj-death: why would that matter? Most of the deref opts just look at the type and see if they can figure it out
16:34lumag: we have a series which depends on this patch.
16:35dj-death: karolherbst: then there is no problem :)
16:35mlankhorst: lumag: seems to have a r-b, or do you mean to apply?
16:35karolherbst: yeah, we just need to make the optimizations a bit smarter
16:35dj-death: karolherbst: I was just talking about the stuff that can be fully inferred
16:35lumag: mlankhorst, doesn't it require an ack from core team?
16:35lumag: If no, I can apply to drm-misc
16:36lumag: (or at least an ack from drm-misc mainainers)
16:42Hazematman: Is there an easy way to check what version of the vulkan validation layers this ci test is using? https://gitlab.freedesktop.org/Hazematman/mesa/-/jobs/55228716
16:42Hazematman: I'm 90% sure this test is failing due to an old version of the validation layers
16:43zmike: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27358/diffs?commit_id=c163a38a8e0e23eb96ab0a98b197464463553f08
16:43zmike: I updated it last week
16:46Hazematman: thanks zmike ! I'll test with that version. the crash only happens with validation layers enabled. I don't know if the exact crash the CI is seeing but I was able to reproduce a crash on debian 11 with older validation layers and it seems it was renaming a handling and then that renamed handled got passed into the driver instead of the original handle.
16:47zmike: check the log
16:47zmike: ci is configured to crash on unrecognized vvl errors
16:48Hazematman: the log is just "segfault" with nothing else printed out for the test running
16:50zmike: could be a vvl bug then
17:12karolherbst: ahhh.. I can't decide how this should optimize :')
18:23zmike: jenatali: followup https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27698
18:24jenatali: zmike: I'm on vacation right now so can't take a close look but definitely a-b
18:25zmike: acks are ok
18:25zmike: and good enough for this case
18:40mlankhorst: lumag: I don't see why it needs an ack, unless you want one to merge through different rtree
18:41lumag: mlankhorst, we didn't indent that, but yes, merging through msm-next would save us a lot of trouble
18:43mlankhorst: can do that with my ack if you want, and no other user depends on it. :)
18:43lumag: mlankhorst, yep, that works for us
18:44lumag: thank you
22:31sarthakbhatt: test