12:40karolherbst: zmike: no idea if I asked you before, but are you planning to de-pointerize pipe_sampler_view?
13:03zmike: I am not
13:12karolherbst: mhhh..
14:43zmike: surfaces were in a weird spot where they were kinda single-context but also they could be shared between contexts but they weren't actually supposed to be, and it was super confusing
14:43zmike: also they're only used in framebuffer state with a small fixed number
14:44zmike: vs samplerviews, which are now exclusively single-context for sure and can be passed around in gigantic arrays
14:45karolherbst: right... it would help me if I could share sampler views between contexts
14:45karolherbst: but I suspect that's kinda hard to achieve and not only because of the destruction callback
14:46zmike: I explicitly did the huge refactor months ago to prevent that
14:46zmike: so don't
14:47zmike: some drivers (e.g., zink) deduplicate them internally anyway
14:47karolherbst: right, it would just be easier for me to allocate sampler views when the CL memory object gets allocated and I'd just use that one forever, but I can make it work per context... it's not hard to be better than "create sampler views when a kernel gets launched"
14:47karolherbst: I can just cache them per context
14:48karolherbst: it's just a bit annoying because of object lifetimes
14:48zmike: suck it up buttercup
15:05karolherbst: yeah...
15:06karolherbst: same for samplers
17:17karolherbst: okay.. I already figured out sampler caching :D
17:17karolherbst: but those are also way simpler to deal with
17:18karolherbst: "Crashes 202" okay.. I'm doing something wrong..
17:36Lynne: is there a dissassembler/decompiler for old GCN1/HD 8000-era IR (if_logicalnz r42.x, div_zeroop(infinity) r42.x___, r45.x, r42.x and so on)?
17:46glehmann: Lynne: AMD IL? grvk probably has something like that as part of their translator to spir-v
17:47Lynne: oh, right, amdilc
17:49glehmann: there is also a public spec for it
17:50Lynne: I need something that can parse the string-based IR variant and output something more readable
17:51Lynne: alternatively, I also have 64-bit addressing nvidia PTX IR
20:53karolherbst: zmike: I'm running into a heap-use-after-free in zink inside zink_update_barriers, where "ctx->update_barriers" references pipe_resources already destroyed from e.g. inside "zink_set_sampler_views" (zink_sampler_view_destroy triggers also destroying the pipe_resource). Now I'm wondering if there is a hidden usage pattern I need to follow, or if
20:53karolherbst: zink simply should reference any resource going into the ctx->update_barriers set as well
20:54karolherbst: ehh "ctx->need_barriers"
20:55karolherbst: or maybe it's easier to simply remove the resources from the sets, because doing anything with them also feels super pointless :)
20:56karolherbst: though uhm.. don't have references to the context when destroying resources...
20:57karolherbst: ohh it's the tex2d_from_buf imported resources... *sigh*
20:59karolherbst: in which case this should be easy to fix..
21:14karolherbst: mhh something odd is going on there.. the imported resource has a bind_count of 0, where the main one has 1...
21:25zmike: ETOOCOMPLEX
21:25zmike: will think Monday
21:25karolherbst: ohhh I wonder if it's zink_context_replace_buffer_storage...
21:25karolherbst: it doesn't fix the bind for the imported one
21:26karolherbst: nope...
21:40karolherbst: okay... on unbind time the import2d one changes?
21:40karolherbst: or rather it tries to unbind a different one the main was bound with earlier...
21:50karolherbst: okay.. at bind and unbind a different sampler view is used.. curious... maybe I'm messing something up big times?
22:00karolherbst: ohhhhhh
22:00karolherbst: I got it
22:02karolherbst: nice fixed
22:07karolherbst: zmike: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36243/diffs?commit_id=c96a969c98866c1b1ba59e5b618cd54e16fec5cf
22:09karolherbst: I should implement sampler view caching next...