10:35karolherbst: do we have any drivers that can write to sRGB images?
10:37emersion: i think most of them can
10:37emersion: it depends on the format modifier
10:38karolherbst: ohh, I mean like inside shaders
10:38karolherbst: or rather inside mesa
10:39karolherbst: don't really see them advertised as shader images in any driver
10:39emersion: ah, i was talking about being able to output linear colors from a shader, and offload the sRGB encoding to the driver, with vulkan
10:39karolherbst: for writing I mean
10:39karolherbst: right... I was looking into cl_khr_srgb_image_writes which means you can write to them from shaders with that, but yeah.. reading seems to work just fine so far
10:39emersion: basically, _SRGB variants with VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT
10:40karolherbst: VK_IMAGE_USAGE_STORAGE_BIT I think
10:40emersion: (as opposed to SAMPLED, which would be for reading)
10:41karolherbst: right
10:41karolherbst: it's for the compute pipeline
10:41emersion: makes sense (i don't know then)
10:41karolherbst: so uhm.. like using imageStore in GLSL on them
10:41emersion: hm
10:41emersion: maybe gamescope is using that?
10:42karolherbst: no idea.. anv doesn't seem to advertize, nor iris/lp/zink
10:42karolherbst: should check the vulkaninfo site
10:42emersion: yeah, it does
10:43emersion: uses _SRGB with STORAGE
10:44karolherbst: opencl only has RGBA and BGRA, soo R8G8B8A8_SRGB and B8G8R8A8_SRGB, and some drivers indeed seems to support it..
10:44karolherbst: asahi does
10:45karolherbst: nice, so I can try that out
10:45karolherbst: llvmpipe used to support it
10:45karolherbst: but yeah.. seems like only asahi supports it inside mesa
10:46emersion: that's surprising, i would've expected amd to support it too at least
10:46emersion: maybe with only some format modifiers?
10:46karolherbst: maybe? I only checked optimal tiling
10:47karolherbst: seems like those queries kinda dos the gpuinfo webpage :'(
10:48karolherbst: yeah, maybe I just need to check myself
11:04glehmann: no desktop hardware supports storage srgb images
11:06glehmann: emersion: gamescope does the color conversion at the end of the shader for storage, SRGB formats are only used for input sampled images
11:06emersion: eh
11:18karolherbst: anyway.. seems to work just fine on asahi and zink+hk
13:41pac85: Color space conversion is supported for rendering though on amd isn't it?
15:09imeguras: has anyone developed stuff for libdrm? im a newbie and i figured that i should start contributing to projects i use instead of complaining
15:20glehmann: pac85: yes, that's required by basically every graphics api under the sun
15:21pac85: Fair yeah
15:29imeguras: I just wanted to contribute although i only ever contributed to very small projects which i tipically knew that if i implemented i wouldnt be stepping over another person
15:31imeguras: how do you guys organize what is "todo" without having a patch being rejected since no one asked for it or worse implementing something but being to late to the party
16:02imeguras: also i have a 7600X and aparently the PCI-ID+version(guess mine was older i bought it in second hand) is not on the list the others show up as AMD Radeon 610M which corresponds to laptop cpu's should i also label mine as 610M?
16:11robclark: karolherbst: why is pipe_tex2d_from_buf->offset hard coded to zero? Shouldn't this be non-zero when the img is created from a cl subbuffer?
16:12robclark: https://www.irccloud.com/pastebin/vyJEh8QH/
16:12robclark: I'd expect that to have offset 917504/bpp
16:25robclark: karolherbst: is there an implicit dependency on svm here?
16:26karolherbst: mhhh, let me check
16:27robclark: (I am planning on implementing resource_assign_vma at some point but until now it is lower prio because tflite doesn't use svm directly
16:27robclark: )
16:27karolherbst: nah those interfaces are only used for SVM
16:29robclark: I'm pretty sure the cl_khr_image2d_from_buffer issue I'm debugging is because of non-zero offset subbuffers vs offset=0 passed when creating sampler/image views
16:29karolherbst: robclark: yeah.. I think a proper offset needs to be encoded there
16:30robclark: hmm, ok.. but I think this failure isn't seen w/ llvmpipe, so still not sure if I'm missing something in driver (or some combination of caps causes rusticl to do something differently)
16:32karolherbst: robclark: completely untested: https://gist.github.com/karolherbst/f457e65c1ef4ebbff15025d02f453a50
16:32karolherbst: robclark: I don't think llvmpipe supports that extension
16:32karolherbst: mhh maybe it does...
16:33karolherbst: forgot "offset: offset," in the patch 🙃
16:33robclark: one sec.. I'll try to trace it with llvmpipe to see if it is doing something differently (but have to hack things up because tflite asks for GPU device)
16:34karolherbst: RUSTICL_DEVICE_TYPE=gpu
16:35karolherbst: maybe I should properly set the offset...
16:35karolherbst: ehh and it's also not set for sampler views
16:36robclark: ok, with llvmpipe, for whatever reason it is creating subbuffers but not creating image2d's from them
16:37robclark: ok.. if setting the offset properly isn't going to break someone else then I'll implement that
16:37robclark: I just wanted to make sure I wasn't missing something else
16:38karolherbst: https://gist.github.com/karolherbst/f457e65c1ef4ebbff15025d02f453a50
16:38karolherbst: I think that's correct...
16:38karolherbst: kinda need to clean the area up, because the parent memory stuff is kinda a mess
16:39robclark: karolherbst: yup, that does the trick, t-b
16:40karolherbst: just need to spend 4 hours to think about how I want the code to look better :D
16:41robclark: hmm, it lgtm but maybe `pub fn pixel_offset()` to avoid converting bytes to pixels in two places?
16:44karolherbst: I should get rid of all the Option with the format info stuff, because that's just dead code...
16:44karolherbst: should probably use `unreachable!` instead
16:47robclark: well I pushed your suggestion as a WIP patch to my MR so at least people can test the MR
17:08karolherbst: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35537/diffs?commit_id=d3f6d41d867dc0f65c6e40c94b6e56886ba122ed
17:10karolherbst: robclark: oh also, if you want to test srgb support: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35535
17:11karolherbst: just run all the image tests, some support passing in the format with "CL_sRGBA CL_sBGRA"
17:13robclark: give me a sec, I'm rebasing on your first MR
17:13robclark: works.. t-b
17:14karolherbst: nice.. I had to drop my refactoring, because I think API validation depends on some of the Options there :'(
17:15karolherbst: kinda annoying that the CL CTS doesn't catch those issues
17:15robclark: you can add Reported-by if you want
17:15robclark: yeah
17:15robclark: I spent much more time than I'd care to admit digging thru tflite code trying to figure out wtf was going on.. a cts test would have been easier ;-0
17:15robclark: ;-)
17:17karolherbst: yeah..
17:17karolherbst: I wonder if debugging tflite is worse or not compared to debugging davinci resolve 🙃
17:20robclark: I'd have to think similar but haven't had to look at davinci resolve (yet?)
17:20karolherbst: it's x86 only anyway
17:21karolherbst: seems like there is a windows arm beta
17:21karolherbst: however
17:21karolherbst: for davinci resolve you'll also need gl_sharing
17:21karolherbst: and that's a little fun
17:21karolherbst: basically will have to teach your driver to import and export arbitrary pipe_resources, not just 2D
17:22karolherbst: anyway.. that application is brutal
17:22karolherbst: creates a couple of queues and a couple of threads
17:23karolherbst: so in my debugging sessions I usually have like ~100 active threads around 🙃
17:23karolherbst: triggered a couple of weirdo dead-locks in my queue/event handling code
20:30airlied: imeguras: libdrm isn't really where much development happens, it's mostly kernel or mesa projects
21:12karolherbst: seems like radeonsi indeed advertises sRGB storage images
21:13karolherbst: but it doesn't really work...