00:04 robclark: karolherbst: hmm, I might have a use-case for excluding specific formats depending on rusticl vs gl.. not sure if you have ideas on how to accomplish that
00:04 karolherbst: robclark: mhh sounds annoying, but could always add a special PIPE_BIND flag for it
00:05 karolherbst: at least it's the only parameter we have for is_format_supported that allows this
00:05 robclark: a bit ugly, but that was the best thing I could think of too
00:05 karolherbst: could also add more parameters depending on the thing
00:05 karolherbst: like what's the use case?
00:05 robclark: 10_10_10_2 w/ alpha channel
00:06 karolherbst: mhh what's the main difference there between gl and cl? MSAAA?
00:06 karolherbst: *MSAA
00:06 robclark: for b01 or b10 (the two intermediate alpha values) it looks like they get returned as f16 and then upconverted to f32 on some gens.. so the values slightly mismatch what cl cts expects
00:07 karolherbst: huh...
00:07 robclark: it's close enough for gl/vk but not precise enough for cl
00:07 karolherbst: what's the vendor driver doing? I expect nothing as this is the extension format, right?
00:07 robclark: right, it never exposed that format
00:08 karolherbst: there is also CL_UNORM_INT_101010_2 but I _think_ you talk about CL_UNORM_INT_2_101010_EXT
00:08 karolherbst: right?
00:08 robclark: there is an RGBx format that is not EXT.. they do support that
00:08 karolherbst: or both kinda
00:08 karolherbst: ahh yeah..
00:08 karolherbst: mhh
00:08 karolherbst: so 10_10_10_x
00:08 robclark: right
00:08 robclark: that works fine
00:09 karolherbst: or CL_UNORM_INT_101010 rather
00:09 karolherbst: mhhh
00:09 robclark: it's just the 2b channel that is a problem
00:09 karolherbst: haven't wired up CL_UNORM_INT_101010 yet...
00:09 karolherbst: the RGBx formats are kinda weird, need to think about those a bit, but I guess supporting the packed one should be easier
00:10 karolherbst: but yeah... if it doesn't meet CLs precision requirement...
00:10 karolherbst: let me see if it's just the test or actually the spec
00:11 robclark: it's close enough to correct to totally confuse the tests code that tries to figure out what the problem is ;-)
00:11 karolherbst: the test code is a mess and I don't like looking at it...
00:11 robclark: same
00:13 karolherbst: okay fun.. the spec doesn't define CL_UNORM_INT_101010_2
00:13 robclark: because it's EXT?
00:13 karolherbst: like for CL_UNORM_INT_101010 it says: normalized float value = (float)c / 1023.0f
00:14 karolherbst: nah, CL_UNORM_INT_101010_2 isn't EXT
00:14 karolherbst: CL_UNORM_INT_2_101010_EXT is the EXT one
00:14 robclark: huh.. ok
00:14 robclark: anyways I guess that formula doesn't work for the alpha channel
00:15 karolherbst: anyway.. CL_UNORM_INT_101010_2 got added with CL 2.1
00:15 karolherbst: yeah.. for alpha it should be.. uhm...
00:15 robclark: hmm, blob doesn't advertise CL_UNORM_INT_101010_2 but claims to be 3.0
00:16 karolherbst: well it's optional with 3.0
00:16 karolherbst: I don't think CL_UNORM_INT_101010_2 was ever required anyway
00:16 karolherbst: ohh the CL spec says a bit
00:16 robclark: ahh, ok
00:16 karolherbst: "3 must convert to 1.0f (for A)"
00:16 robclark: and _that_ is happening
00:16 karolherbst: "The precision of conversions from CL_UNORM_INT8, CL_SNORM_INT8, CL_UNORM_INT16, CL_SNORM_INT16, CL_UNORM_INT_101010, and CL_UNORM_INT_101010_2 to float is ≤ 2 ulp for the embedded profile instead of ≤ 1.5 ulp as defined in the full profile. The exception cases described in the full profile and given below apply to the embedded profile."
00:17 robclark: it's just the 2 and 1 values
00:17 karolherbst: okay so how many ULPs are you off the result?
00:18 robclark: hmm, let me find the exact values.. but it is what you'd get if you f2f32(f2f16(alpha_val))
00:18 karolherbst: mhhh
00:19 karolherbst: so the correct float values would be `0x3eaaaaab` and `3f2aaaab` right?
00:20 robclark: 0.666667 is what we should get for 2, 0.666504 is what we get
00:20 karolherbst: and you probably get `0x3eaaa000` and `0x3f2aa000` instead or something
00:21 karolherbst: huh.. so `0x3f2aa002`
00:21 karolherbst: guess that can happen depending on rounding
00:21 karolherbst: but yeah.. that looks a lot off the actual value
00:22 robclark: in f16, the two values are identical 0x3955
00:22 karolherbst: right
00:23 robclark: if spec only defines that b00 -> 0.0 and b11 -> 1.0 and the others are something in between, then maybe this is a test bug
00:23 karolherbst: well it does define 1.5 or 2 as ULP errors, but not quite sure based on what calculation yet
00:24 karolherbst: https://registry.khronos.org/OpenCL/specs/3.0-unified/html/OpenCL_C.html#converting-normalized-integer-channel-data-types-to-floating-point-values
00:24 karolherbst: sounds like "implementation defined" if you ask me 🙃
00:25 karolherbst: anyway, should probably file a spec bug stating that those 2 bit channels aren't defined at all
00:26 karolherbst: or not really
00:29 karolherbst: but I'd assume that for the 2 bit channel, there is no ULP requirement or at least that this would be the intention
00:30 karolherbst: or maybe not...
00:31 karolherbst: so how I read the spec is that the precision of the values besides MIN, 0 and MAX have to be 1.5 or 2.0 ULP precise, and MIN, 0 and MAX must convert to -1.0, 0.0 and 1.0
00:33 karolherbst: robclark: but anyway, from the gallium API perspective I'm kinda wondering how we want to model it.. or rather how to model it that zink can also use it, because I wouldn't be surprised if the same problem could be seen through vulkan...
00:33 karolherbst: and kinda wondering if vulkan has any reqs there or queries that report back how precise stuff is
00:34 robclark: same problem is seen thru vulkan if you try rusticl on zink
00:35 robclark: but solving that is a vk/zink problem
00:36 karolherbst: yeah.. my point is just, that if we modify "is_format_supported" then we should do it in such a way that makes it usable on vulkan
00:36 karolherbst: but if vulkan doesn't have any queries for it, then whatever really
00:37 robclark: I mean, there are already kernel vs compute shader diffs and various other things w/ cl on vk has.. emm. difficulties.. if someone cares about all those things they're going to have to invent some vk extensions
00:38 robclark: I'll do the gallium changes and leave the vk extensions to someone else ;-)
00:59 zmike: add a new pipe format ?
01:03 robclark: that does sound like a lot more work (ie. touch every driver instead of just one each time this sort of issue comes up)
02:57 karolherbst: robclark: mhhhh.... guess we could add a stage param to is_format_supported
02:59 karolherbst: but yeah.. adding a pipe format kinda feels weird for it, because this is a potential issue for any format, not just that specific one
05:27 soreau: I am getting application crashes with valid data in glTexImage2D() at random it seems, using mesa 1:25.3.5-1 on archlinux with integrated amdgpu "OpenGL renderer string: AMD Ryzen 7 7800X3D 8-Core Processor (radeonsi, raphael_mendocino, LLVM 21.1.6, DRM 3.64, 6.17.9-arch1-1)"
05:28 soreau: Is this a known issue or should I install mesa debug symbols?
05:30 bluetail: soreau I use amdonly-gaming-mesa-git to help with this. it's mesa 26.0
05:31 bluetail: I use WLR_SCENE_DISABLE_DIRECT_SCANOUT=1 and WLR_RENDERER=vulkan additionally and since another bug amdgpu.dcdebugmask=0x10 amdgpu.vm_update_mode=3
05:32 bluetail: https://gitlab.freedesktop.org/drm/amd/-/issues/3067#note_3336845
05:33 soreau: bluetail: what's the problem though, the drivers are broken/buggy?
05:38 bluetail: soreau about that link? Yea, there's a state where you'd run into a reset and your window manager disconnecting then, or worse, entire system freeze. the stuff in the cmdline and the newer mesa version helps with that. But with mesa 25.0* I do have textures not loading in f-zero gx for instance
05:39 soreau: bluetail: yea I do have random gpu resets occasionally but that's been happening for awhile now
05:39 bluetail: Using downgrade too for mesa helps. I forgot which version introduced it. But people are aware which one it was so I don't have to.
05:39 soreau: smh
05:39 bluetail: oh, these you should try to address with amdgpu.dcdebugmask=0x10 amdgpu.vm_update_mode=3
05:40 soreau: hm, ok
15:28 soreau: bluetail: FWIW, I found that some images were loading with what seemed like skewing due to wrong stride or something, with odd size dimensions. I put a call to glPixelStorei(GL_UNPACK_ALIGNMENT, 1); directly before the call to glTexImage2D and now the images of odd sizes are not skewed and there are no more crashes in the dirver
17:52 kisak: tjaalton (or anyone), happen to know where libdisplay-info-dev ties into the mesa build? I ask because Ubuntu/Noble doesn't have it for i386.
17:53 kisak: I'm hoping I can just cut a corner there for 32 bit
17:58 emersion: kisak: vulkan display WSI iirc
17:59 emersion: kisak: why doesn't ubuntu have it?
18:03 kisak: there's a i386 allow list that guts a whole bunch of stuff in general. Ubuntu/Questing has it, Noble doesn't retroactively have it in the allow list. Maybe I can ask for the allow list to be regenerated
18:03 urja: ... vulkan? so why does mesa require it on my 32-bit ARM OpenGL-only build?
18:04 urja: i'm only curious because i just assumed libdisplay-info kept ABI compat and broke the graphical login on my laptop at one point (until i rebuilt some other things...)
18:05 urja: (and the update was because mesa required it..)
18:10 kisak: https://gitlab.freedesktop.org/mesa/mesa/-/issues/13657#note_3039011 says it can be configured off.
18:11 kisak: Oh, we're talking about different things that are coincidentally close to each other.
18:15 urja: okay note to self i'll check that next time i build touch my mesa PKGBUILD
18:54 kisak: tjaalton: I ended up unblocking over here. Whatever I get is no worse than my 25.3.x builds.
20:00 bluetail: soreau interesting. Thanks for letting me know, I appreciate :)
20:00 soreau: np