02:05bl4ckb0ne: If anybody is still awake, I have a tiny egl ext implementation that is looking for a r-b https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25996
02:05bl4ckb0ne: can also exchange for a novice eyes r-b
11:34jani: so the vesa e-ddc spec says we should try to read displayid from address 0xa4 before reading edid from 0xa0. we currently don't. I've been curious if displays commonly populate the displayid ddc address. we never probe it, so we have no idea
11:35jani: I wrote some patches to do just that, and sent them to the intel ci trybot
11:35jani: looks like very few of the displays in our ci respond to the displayid ddc address
11:37jani: I found three that do. two of them have the regular edid header 00 ff ff ff ff ff ff 00 which is wrong for data in the displayid ddc address. *sigh*. one of them responds with all 00, all 66, or all 22. *facepalm*
11:39ccr: not knowing much about the topic, but what I've heard about EDID etc conformance, that somehow does not surprise me at all
11:39jani: in conclusion, if you had any hopes that a dedicated displayid at a dedicated ddc address would make things better, and reduce legacy, forget it. same shit, new ddc address
11:40jani: ccr: yeah
11:41ccr: with such things, it seems like it's often the case of https://xkcd.com/927/ but with the addition that it's another standard nobody complies with
11:41jani: so far all the displays will populate the edid at its address, with displayid data in edid extension blocks, because that's backwards compatible with old source devices
11:43jani: this is where I say I think Postel was wrong :p
11:45jani: basically "be liberal in what you accept" in this context means no matter what garbage a display has for an EDID, we try very hard to interpret it as if it was meaningful, and get a picture on screen
11:46jani: if windows outright rejected EDIDs that don't follow the spec, we'd only have standards compliant EDIDs out there
11:46jani: /rant
14:47bl4ckb0ne: there's no entry in doc/features.txt for EGL exts?
15:04karolherbst: jenatali: `get_global_size` is broken :')
15:04jenatali: karolherbst: elaborate
15:04karolherbst: it doesn't account for lowered huge workgroups
15:04karolherbst: ehh huge grids
15:05jenatali: Oh, we don't actually have a sysval for that so I have to pass it through a side channel anyway
15:05karolherbst: yeah...
15:05karolherbst: well.. we have num_workgroups
15:06karolherbst: guess the frontend could kinda handle that, but...
15:06jenatali: Right, you'll need to disable whatever sysval is reporting that and pass it through a ubo like the offsets themselves
15:07karolherbst: I was actually wondering to clean up all that sysval mess properly
15:07karolherbst: like
15:07karolherbst: rename/split them properly between "driver" and "api" versions, and drivers never should have to implement the API ones
15:07karolherbst: atm it's kinda a mess
15:08karolherbst: maybe keep the names...
15:08karolherbst: but then uhh.. the frontend doesn't really know what the hardware supports anyway
15:08karolherbst: but yeah...
15:08karolherbst: I guess lowering the num_workgroups to a constant ubo pull is probably the cheapest solution here...
15:09jenatali: Yeah having a clean split is hard, there's a lot of details that only the driver knows
15:09karolherbst: no point in doing the math in the kernel
16:00karolherbst: okay done.. 🙃 that wasn't too hard actually
16:08karolherbst: nice.. seems to work on my rpi4 :3
16:13karolherbst: now half of math_bruteforce isn't crashing anymore :D
16:14jenatali: Nice
16:15karolherbst: but there is a second benefit: I've added an env variable so users can reduce the grid size drivers support in order to work around the kernel nuking long running jobs
16:16karolherbst: need to test if it actually helps or if I also have to flush more often
16:16karolherbst: I have some bug reports on iris where this should help
16:22karolherbst: now the only big item left are splitting textures and samplers inside v3d :'(
16:23jenatali: karolherbst: Pretty sure I have a pass that helps with that
16:23karolherbst: it's wrong in the gallium driver
16:23jenatali: Right
16:23karolherbst: v3d kinda only works with gl atm as they simply assume they appear in pairs
16:24karolherbst: shouldn't be hard to fix, just.. uhh.. work
16:52karolherbst: oh no.. regressions :(
16:58karolherbst: unrelated problem.. I've added an assert drive-by and it triggers :')
16:59karolherbst: might actually fix other issues
17:14abhinav__: pq Hi, I had a question about https://patchwork.freedesktop.org/patch/572343/. So this series is not actually using the UAPI's struct drm_mode_solid_fill but actually just a local IGT struct equal in size to the UAPI one. For demonstrating IGT usage for UAPI changes, is the usual flow that we first make libdrm change for the UAPI, wait for it to
17:14abhinav__: merge and then uprev IGT's libdrm version and use that UAPI?
18:06kchibisov: Is EGLSurface thread safe (like can you send it between threads)? I see that EGL spec says that the API is thread safe. I just remember that wayland platform creates queues, and I'm not sure you can send them?
18:54daniels: kchibisov: queues are totally fine; the rule is just that you can only dispatch a queue from one thread at a time, and it represents one context of execution
18:54daniels: that's ok with EGL, because you can only have one context current on one thread at a time
18:55kchibisov: So sending EGLSurface around is fine? I just know that you sort of need to handle callbacks, etc?
18:56kchibisov: I'd assume that I need to make surface not-current and then send, so it'll be _safe_?
18:57kchibisov: From what I understand there's a current context and current surface concepts, and they are not tied to each other. Since you can make context current without any surface just fine, but you can't send it unless you make it non-current.
19:15steev: lumag: what's the status of https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26277 ? without those changes, i get a crash on a minecraft on the thinkpad
19:17robclark: lumag: split out the stuff after the first commit into a different MR to unblock the patch that steev needs
19:40DavidHeidelberg: robclark: this commit enables the tests which are failing by default, do u see anything suspicious: https://github.com/KhronosGroup/VK-GL-CTS/commit/79b25659bcbced0cfc2c3fe318951c585f682abe ?
19:41DavidHeidelberg: btw. he didn't exactly catch what is affected in the commit messages (except the .*other part)
19:41DavidHeidelberg: previously all these tests has been skipped
19:43robclark: that is... weird.. without looking closely at the test, a quick look at the commit looks like it is making things _more_ restrictive
19:44robclark: looking at the result .xml, the failure looks like maybe a color precision issue or maybe srgb confusion or something like that
19:44robclark: the rendered vs reference is close, just slightly off in color
19:59daniels: kchibisov: a surface is only current with respect to a context - so just make sure that you don't have the context active in more than one thread (eglMakeCurrent will fail if you try) and you'll be totally fine. there are no callbacks in EGL so no concerns there
21:20karolherbst: jenatali: review needed for (it's a small change) https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26764/diffs?commit_id=d06f02ca9a4cca39ba4d30fd63302caa6c6b0f6c
21:25karolherbst: ohh.. and I've also added a mr label maker rule for clc -> OpenCL https://gitlab.freedesktop.org/freedesktop/mr-label-maker/-/merge_requests/20
21:27karolherbst: thanks
22:07lumag: steev, robclark ack
22:15emersion: any takers for an easy libdrm review? https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/337
22:42airlied: rodrigovivi: if you rebased the xe tree you need to add signoffs for yourself
22:42airlied: getting a lot of missing committer signoffs, so please go add them and resend
22:42rodrigovivi: ouch! forgot that, sorry
22:43rodrigovivi: I'm going to prepare another one right now... will take a moment because I will need to fix the hashes on the fixes and commit mentions