00:29tarceri: To trigger the issue we need get si_set_sampler_views to free the view twice ... the fix stops us accidentally reusing a sampler view but even if we reused the view it should get referenced twice by the backend so its wrong but it should cause the double free crash?
00:30tarceri: Seems like there must be something else freeing the view before we call the update?
00:31tarceri: *we need to get si_set_sampler_views to free already freed view
00:33zmike: the view doesn't hit the backend before the call to create views completes
00:34zmike: so it only has one ref and then it gets released and deletes
00:35tarceri: yesh but my point it the list we send to the backend just ends up with 2 entries pointing to the same view right?
00:36zmike: no
00:36zmike: in this case one is srgb and one is not srgb
00:36zmike: I assume one is txf and the other is not
00:39zmike: st_get_sampler_views() creates multiple views, and two of them are for the same texobj
00:40zmike: so inside the st_get_sampler_views() loop, creating the second view releases the first one
00:48tarceri: Right I see, diffcult to follow as there is multple litst going on here. the text obj sampler_views list gets the view overridden and one in get_sampler_view ends up with a freed pointer as your saying
01:03zmike: yes
01:55tarceri: zmike: I managed to recreate the bug but patch 4 of your series changes mesa behavior
01:55zmike: 🤔
02:10tarceri: Looks like nothing in piglit will hit it and nether does the cts test that the param was originally added for
02:15zmike: I don't see how it could change behavior when all that patch does is calculate the format earlier to allow potentially reusing the view
02:17tarceri: https://paste.centos.org/view/b3cdb870 02:19zmike: sure, but the formats for those should still be different
02:19zmike: so it should produce different views
02:20tarceri: After patch 4 it just returns a match
02:20zmike: hmm I think I'm too tired to see it now
02:20zmike: maybe make a piglit MR and I'll check tomorrow
02:21tarceri: will do :)
02:21zmike: 🤝
05:23tarceri: zmike: I think its ok my piglit test was using an RGB format not a sRGB previously it would create a new view for this case even though its not really necessary
05:24tarceri: *previously mesa would
11:40zmike: tarceri: yeah that's the idea...now it can reuse the views in some cases
12:01tarceri: yeah makes perfect sensed now that I understand the code :P
12:03zmike: I'm not gonna say it's good code
12:03zmike: but it is code
12:04tarceri: Well at least its got test coverage now...if only piglit ci wasn't busted
12:07mahkoh: Re https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40382, I was under the impression that amdgpu always used implicit sync except for vulkan-internal buffers that are not shared. But it doesn't seem to be that way. Could this be another bug?
12:07zmike: piglit ci seems broken a lot
12:07zmike: which is strange because piglit isn't that active
12:09tarceri: seems its having python numpy issues, maybe pulls in updates automatically?? Anyway bed time maybe a magic elf will have fixed it by the time I wake
12:10zmike: valentine sergi mupuf ^
12:11mupuf: hmm, do you have an example job that failed?
12:12tarceri: https://gitlab.freedesktop.org/mesa/piglit/-/jobs/95161530 12:14mupuf: tarceri: thanks!
12:15mupuf: So.... numpy changed its interface... or has a different interface depending on the python version?
12:15mupuf: should be easy to reproduce locally
12:15tarceri: mupuf: This is code from main not mine
12:16mupuf: lovely
12:17mupuf: so, unpinned dependency, quite likely
12:17mupuf:is taking a look
12:18mupuf: numpy2: numpy>2.0
12:19mupuf: https://github.com/numpy/numpy/pull/29994 <-- this is what broke it
12:21tarceri: Use the ``shape`` parameter instead
12:28mupuf: yes, and there is already code in piglit to do that
12:32mupuf: Meh, please contact the original author of the code: https://gitlab.freedesktop.org/mesa/piglit/-/merge_requests/1063 12:34mupuf: maybe dropping support for older versions of numpy would be less messy
12:42tarceri: ok, that was my bad I didn't have that pulled in
12:44tarceri: Thank you for helping me with my stupid
12:44mupuf: hehe, you're welcome
14:01lynxeye: zmike: Suppose one would like to port ARB_texture_swizzle to GLES2. Would that be a MESA_ extension or is there still anyone around at Khronos to give this the OES_ stamp of approval?
14:02zmike: I think you could make a PR in the registry, make a CTS PR to enable the tests for ES2, and roll the dice
14:29zamundaaa[m]: Umm, do I see correctly, that Mesa caches the result of
14:29zamundaaa[m]: vkEnumeratePhysicalDevices per VkInstance?
14:30zamundaaa[m]: It's a pretty annoying problem when working on a compositor that deals with GPU
14:30zamundaaa[m]: hotplugs...
17:00Lilla: agd5f: Is BACO or mode1 reset needed for hot unbind/bind?