02:36jenatali: CI flakes really make it frustrating to try to merge changes that touch common code :(
02:46karolherbst: especially when it happens like every time
02:47karolherbst: maybe we should just be more aggressive about disabling flaky CI jobs
02:52zmike:cackles in unlimited windows ci flakes
02:56jenatali: zmike: I hope you're not being serious. I haven't noticed any flakes recently outside of the occasional build job timeout. Which will be fixed by the job I'm complaining about failing to merge...
02:56karolherbst: but until this day comes, we can complain about the occasional build job timeout :P
02:57jenatali: Yep, fair
02:57karolherbst: but yeah, the MS jobs aren't the one being a constant pain generally
02:57jenatali: And if they are please complain loudly. I'm very incentivized to make sure they're not a pain
02:58karolherbst: I think once I had to reassign to marge 5 times because the valve stuff was being silly or something? dunno
02:58karolherbst: I should care more and poke people... or just open an MR to disable it on the first flake 🙃
02:59jenatali: Ugh. And now GitLab 503s on the other job I was hoping to merge today...
02:59karolherbst: "fun"
09:58daniels: jenatali: hm, I think I need to stay up really late one night and stare at the infra
09:58daniels: because these only seem to happen very late at night, and in a way which leaves no useful trace behind
10:13MayeulC: Hi, I've been trying to restore GPU acceleration on an old laptop (samsung n130, using Intel atom n270 and GMA950 -- Part of Intel 945GSE chipset).
10:13MayeulC: It was working at some point in the past, but apparently not on recent Alpine. I would like to know if that chipset is supported or could be supported by crocus? It only supports OpenGL 1.4 according to wiki.
10:14MayeulC: https://en.wikipedia.org/wiki/Intel_GMA#GMA_950
10:18psykose: that may be supported by i915g but i'm not sure
10:18psykose: if it doesn't work with the gallium drivers installed then it doesn't work
10:31emersion: maybe try amber?
10:36psykose: alpine doesn't have amber because alpine doesn't have glvnd to support it
10:40psykose: (sure, one can build it anyway, but then it's a mess to package because all the files conflict and are the same since it's just older mesa technically, ..)
10:41MayeulC: Hmm, thanks for the answers, I was able to dig a bit more. Apparently Alpine still has i915, but doesn't have i915g.
10:41MayeulC: The rest may be more related to sway, though I'm open to try to contribute missing extensions to i915 if that allows sway to run. Was i915 moved to amber?
10:41MayeulC: running with EGL_LOG_LEVEL=debug tells me about native formats not being supported, then errors out with EGL user error 0x3009 (EGL_BAD_MATCH) in eglCreateContext: dri2_create_context
10:42psykose: it has i915g
10:43psykose: old i915 is still in amber, yes
10:43MayeulC: psykose: I was expecting to see a i915g.so there then: https://pkgs.alpinelinux.org/contents?file=&path=%2Fusr%2Flib%2Fxorg%2Fmodules%2Fdri&name=*&branch=v3.17&arch=x86
10:43psykose: i915_dri.so is still from gallium so it's i915g
10:43psykose: unless i don't know how it works and i'm wrong, but that is what you get from gallium-drivers=i915, ..
10:44psykose: i915g.so is probably the glvnd name if it exists?
10:44MayeulC: Ah, thank you for explaining, that was confusing, as I coudln't use MESA_LOADER_DRIVER_OVERRIDE=i915g as it was complaining about the missing so file, so I assumed that was i915-no-g
10:48psykose: https://gitlab.freedesktop.org/mesa/mesa/-/blob/7ead71739371ffc036883b9ee89318f5c368f4d4/src/gallium/targets/dri/meson.build#L107 from here
10:48psykose: but yeah, i don't think you even need an override and it should just be default
10:48psykose: unless it picks crocus_dri for some reason :P
10:54MayeulC: Nah, crocus just fails silently if I try to override it, and I see it correctly picking i915. Sway just fails on startup with that EGL_BAD_MATCH, and falls back to sw rendering.
10:54MayeulC: I wish llvmpipe could still make optional use of *some* GPU acceleration.
10:54MayeulC: It seems there is no amber package on Alpine. I'm going to stop my investigation here for today, thank you for your help!
10:58psykose: don't think EGL_BAD_MATCH is related to wrong driver or something, probably just broken in another way
11:13kchibisov: Am I correct that GLX fakes errors relying on Xlib error setting hooks? So you don't actually need any XSync at all to get the errors.
15:55DPA: I still try to find out how to get some HDR out of my monitor. Does HDR always need more than 8 bits per channel? I see a max of 10 for my monitor, but always 8 for the crtc: https://bpa.st/4OX76
15:55DPA: I tried kmscube with the XR30 format, that should be 10bit per channel, right? But checking while "kmscube --format=XR30 -A" was running, it still says 8. And /sys/kernel/debug/dri/0/i915_display_info says it's 24bpp,
16:03JoshuaAshton: DPA: You need to set the HDR static metadata
16:03JoshuaAshton: kmscube isn't going to cut it
16:03JoshuaAshton: Gamescope can do it
19:55alyssa: 2) Should this pipeline state be dynamic?
19:55alyssa: RESOLVED: Yes. The purpose of this extension is to emulate the OpenGL depth range, which is expected to be globally fixed (in case of OpenGL ES) or very infrequently changed (with glClipControl in OpenGL).
19:55alyssa: this... this seems like a contradiction?
20:07zmike: just read the first word
21:24alyssa: zmike: the extension seems to be (just) a struct you chain into the pipeline state
21:24alyssa: so maybe I should just read the first word and then have it be the opposite of that?
21:24zmike: this is the uh depth clip control one?
21:24alyssa: ye
21:24zmike: it's got a dynamic state
21:24alyssa: wait it does? where? what?
21:25zmike: maybe it was part of ds3 and not the base ext 🤔
21:27alyssa: yeah there it is.
21:27alyssa: ugh
21:28alyssa: zink doesn't use it
21:28alyssa: does anything use it?
21:28alyssa: why the heck is this even dynamic state
21:29zmike: pretty sure zink uses it
21:30alyssa: oh there it is
21:30alyssa: the lack of vk threw me off
21:30alyssa: well, this is annoying
22:50bl4ckb0ne: would it be possible for a gpu to swap its vram on disk?
22:50bl4ckb0ne: i imagine that the bus sperd would be a pretty big bottleneck though
22:53jenatali: We can do that on Windows, yeah
22:53bnieuwenhuizen: on Linux too
22:53bnieuwenhuizen: though it may not be smart about it
22:54bl4ckb0ne: why?
22:56bnieuwenhuizen: because we're still doing this thing of passing a list of buffers on submit
22:56HdkR: Some drivers may also explode when attempting this :)
22:56bnieuwenhuizen: and everything that has to be GPU accessible necessarily isn't swapped
22:56bnieuwenhuizen: so no real demand paging and stuff
22:57bnieuwenhuizen: HdkR: oh? I though TTM provided this
22:59HdkR: Adreno explodes in my setup currently :(
23:00HdkR: Although I do have a device with a new kernel, it might work
23:01kisak: HdkR: you'd expect there to be some hardware safeties to keep it from releasing the magic blue smoke.
23:01HdkR: :D