13:59any1: HDMI supports YCbCr subsampling and RGB, but there doesn't seem to be any way to select which format to use other than modifying the EDID or patching here kernel. At least I don't see it. Is there any way to do it?
13:59any1: the kernel, rather
14:02any1: Most TVs claim support both RBG and YCbCr for any given mode, but some struggle with RGB at 4K@60, so I'd like to be able to override this to always use YCbCr 4:2:x at 4K@60 when available.
14:09any1: Or the cable might be bad, or signal integrity might suffer for whatever reason. I just want things to be reliable regardless.
14:32emersion: any1: no, no way sadly
14:42any1: emersion: Very sad indeed. I wonder what would be the nicest way to add it. I was thinking of adding a format bitmap to drmModeModeInfo and calling it drmModeModeInfo2 or something.
14:44any1: Or maybe it can be stuffed into "flags"
14:48zmike: this is definitely one of the inbox fightbacks of all time.
14:49any1: inbox fightback?
14:50jenatali: zmike: welcome back
14:51zmike: thx
14:55emersion: any1: probably a CRTC prop or something
15:09jenatali: any1: reading through the pile of unread emails that accumulates on vacation
15:13zmike: yeah that
15:14zmike: jenatali: welcome back to you too
15:14jenatali: zmike: thanks
15:43any1: Perhaps the simplest way would be to add a property called "preferred_color_format" to influence the driver's choice and something called "actual_color_format" for feedback.
16:24any1: Ahh, someone's already been working on it: https://lore.kernel.org/dri-devel/20210630151018.330354-1-wse@tuxedocomputers.com/
16:44any1: pq: It seems you were most active in replying to those patches; do you know why it stalled?
17:29robclark: karolherbst: so in the end I needed this:
17:29robclark: https://www.irccloud.com/pastebin/FhGjXu4V/
17:30robclark: and, well, a couple other things that I need to impl in gallium driver..
18:01karolherbst: robclark: ahh yeah...
18:01karolherbst: maybe I should just link in all drivers, because none are enabled by default anyway
18:02karolherbst: but maybe it's better to enable them one by one
18:02karolherbst: robclark: while at it, can you move panfrost above r600? :D
18:10robclark: karolherbst: I realized that lumag had a draft MR for rusticl support so I just switched to that.. but now I need to do some real work
18:10karolherbst: yeah... it always ends up like that :D
18:10karolherbst: what's missing btw?
18:11karolherbst: most missing callbacks have default impls you could use
18:11karolherbst: the only things which might require real work are: 1. variable_shared_mem and 2. decoupling samplers and textures
18:11karolherbst: ohh.. and vec16 lowering I guess
18:20robclark: I think better 8b support.. a proper impl of get_compute_state_info().. and a proper impl of clear_buffer
18:48karolherbst: I see
18:48karolherbst: well.. you can always lower 8b, I've done it for v3d: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25362/commits just pick what you need
18:49karolherbst: you can always do it quick&dirty first to get something working and then work on proper 8/16 bit support
18:50karolherbst: or extend that quick and dirty depending on what the hardware can do
18:50karolherbst: there is also some 64 bit stuff you'll need for libclc builtins, which use 64 bit ops for 32 bit operations
19:19alyssa: anyone know if KHR-GL42.shader_image_load_store.multiple-uniforms is buggy?
19:19alyssa: specifically, when testing tess eval shaders, it relies on side effects happening once
19:19alyssa: that's... doubly wrong
19:20alyssa: wrong first because there are 6 tessellated vertices out
19:20alyssa: and wrong second because the spec allows repeated invocations of tess eval shaders IIRC
19:20alyssa: (I meant the first wrong. The second wrong is broken all over the CTS)
19:25karolherbst: alyssa: could always open a bug and discuss it there
19:25karolherbst: or maybe somebody already did
19:26karolherbst: but I suspect it never came up, because almost no hardware has to deal with this I think
19:26alyssa: no
19:26alyssa: er
19:26alyssa: no?
19:26zmike: this sounds familiar for some test but I don't remember which one
19:27alyssa: filed https://gitlab.khronos.org/Tracker/vk-gl-cts/-/issues/4864
19:28karolherbst: alyssa: could have filed it on github
19:28karolherbst: I think the bug tracker on gitlab is only really useful for those private tests
19:28zmike: incorrect
19:28karolherbst: but whatever
19:29alyssa: maybe?
19:29alyssa: I get lost in the KHR red tape
19:29alyssa: If I could PR cts fixes I might actually fix the bugs I find :clown:
19:30zmike: you can, you just have to type PR as 'gerrit'
19:30karolherbst: seems like most people file issues/MRs on gitlab, I kinda prefer doing that in the open unless there is a reason not to... oh well 🤷
19:30karolherbst: alyssa: yeah.. I fixed a bunch myself, just file a PR/MR
19:30karolherbst: though it seems that stuff usually happens on github :D
19:30alyssa: karolherbst: no, khr members are supposed to gerrit them instead (-:
19:30karolherbst: they do?
19:30karolherbst: I definetly didn't :D
19:30DavidHeidelberg: Sadly they force it.
19:31karolherbst: not to my knowledge
19:31DavidHeidelberg: and so far no-one explained me where their CI fails on my commit when locally the script passes.
19:32karolherbst: though I only submitted two PRs for the GL stuff, and 4 against the CL CTS
19:32DavidHeidelberg: If you send PR signed with KHR member email then yes :D
19:32karolherbst: but uhh, maybe nobody bothered
19:32karolherbst: DavidHeidelberg: well.. mhhh...
19:32karolherbst: use another email then :D
19:32karolherbst: though I used my RH one it seems
19:32alyssa: karolherbst: I'm registered for khr with my @rzg.io email :clown:
19:33karolherbst: just open a PR anyway and see what happens
19:33karolherbst: anyway, most stupid rule ever
19:33karolherbst: I approve anybody to violate it
19:33mareko: zmike: welcome back
19:33zmike: mareko: I see you've been hard at work 💪
19:34karolherbst: zmike: ohh, I have an annoying bug for you to fix, need it for nvidia on zink :D
19:34karolherbst: zmike: https://gist.github.com/karolherbst/6c49f0ef258983ff46e8c91b48e2f7bb
19:34zmike: I didn't see a ticket so it can't be real
19:34karolherbst: sub allocation is entirely broken in a multi threaded world
19:35karolherbst: tried to use a buffer for cb0 to fix other issues
19:35karolherbst: running into that then
19:35karolherbst: ehhhh wait...
19:35zmike: ticket.
19:35karolherbst: zmike: wrong gist anyway :D
19:35karolherbst: yeah, I'll file a gitlab issue and a branch to trigger it easily from
19:35karolherbst: zmike: https://gist.github.com/karolherbst/d94332f88cc01ff9b5d745e8ec8bae44
19:36karolherbst: the issue is kinda that the sub allocation buffer is still referencing a batch from a destroyed context
19:36zmike: yeah I see
19:37zmike: it's annoying to fix but not hard
19:37mareko: zmike: you might want to check the amdgpu changes here, especially the 2 bullets about BO fence tracking and slabs: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26643
19:38zmike: I glanced over that a bit earlier but I'd already read your other MR and then had to try to sparse
19:38zmike: maybe tomorrow
19:38karolherbst: ohh right, I also need this to land: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25985
19:38karolherbst: but that's trivial
19:39karolherbst: that use-after-free is triggered with this: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25946
19:39alyssa: what s not clear is how this test possibly passes on other hardware
19:39karolherbst: luck?
19:39alyssa: Seemingly
19:40alyssa: I guess if all the tess evals are running exactly in lockstep it won't race
19:40alyssa: (effectively barrier'ing in between the loads and stores)
19:45airlied: zmike: hey welcome back, easy question, was GL CTS passing on zink on master on any driver?
19:45zmike: airlied: afaik yes
19:47airlied: I got a bunch of it passing on nvk, but some of the remaining looked more zinky than nvky
19:47zmike: I think radv and anv both, probably lavapipe
19:48zmike: nvidia proprietary there's like 10 that failed last time I ran it which seemed to all be nvidia bugs
19:50zmike: zink/ci in git has all the fail lists that ci uses, so that's probably a good starting place
19:53airlied: zmike: I just wondered if there was bunch of zmike patches that hadn't been upstreamed :-P
19:55ccr: a secret vault full of delicious patches?
19:55pac85: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16881#note_2193145 I think this is relevant to zink passing CTS
19:56alyssa:has one of those
19:56alyssa: pac85: oh hello :)
19:57pac85: alyssa: hello :)
20:11zmike: airlied: I upstreamed everything of note before I left
20:14alyssa: glcts: /home/alyssa/VK-GL-CTS/external/openglcts/modules/gles31/es31cArrayOfArraysTests.cpp:927: tcu::TestNode::IterateResult glcts::ArraysOfArrays::TestCaseBase<API>::execute_positive_test(const std::string&, const std::string&, bool, bool) [with API = glcts::ArraysOfArrays::Interface::GL; std::string = std::__cxx11::basic_string<char>]: Assertion `0 == program_object_id' failed.
20:14alyssa: ...that's a new one :P
23:20DavidHeidelberg: eric_engestrom: hold a second with backporting https://gitlab.freedesktop.org/mesa/mesa/-/commit/c3b95041dc3299a26359f808fff17adbe0248799
23:21DavidHeidelberg: I have feeling it'll need additional fixes...
23:21DavidHeidelberg:investigates some crashes