00:08 alyssa: anholt: deqp-runner feature request -- if prerequisites.read_pixels fails, abort the run earlier, and possibly { reboot the machine, print motivational messages about accepting failure, rickroll the user } to ensure it doesn't happen again ;P
00:56 alyssa: Also, service announcement for clueless denizens like me who only RTFM after two years: shader-db run.c needs to be compiled with -fopenmp, not just -lgomp
00:57 alyssa: -------Or just `make run`.... I'm good at computers...
00:58 alyssa: (`make` alone tries to build intel_stub which fails on arm)
01:00 Lyude: sounds like it should just use meson and enforce those checks so no one ever has to read the manual :)
01:01 HdkR: meson yes. ship it
01:01 alyssa: Lyude: Thanks for volunteering to write a meson.build for shader-db :)
01:01 alyssa: ;P
01:02 Lyude: alyssa: i mean - no :P, but it's super easy usually.
01:03 alyssa:is discovering that not doing everything in a single thread can make her development life better *gasp* :p
01:03 alyssa: first deqp, now shader-db ;P
01:04 HdkR: Soon alyssa will get an 80 core ARM device and never want to go back
01:05 Lyude: I still need to build myself a new machine, hopefully with a threadripper
01:05 Lyude: i'm still rocking a 6 core sandybridge desktop
01:05 HdkR: Zen3 Threadripper just around the corner. I'm looking forward to it :)
01:09 alyssa:hugs last-gen chromebook
01:13 HdkR: I'm sure you'll eventually find a new-gen chromebook to love as well :P
01:17 imirkin: just remember ... every last-gen device used to be a new-gen device ;)
01:17 imirkin: except the i740
01:18 HdkR: poor i740, getting beat up
01:20 imirkin: it's ok ... it was like 25y ago. i think people have gotten over it.
01:25 HdkR: It's okay, we have DG1 now as a replacement
01:25 HdkR: :>
01:26 imirkin: hopefully its an upgrade :}
01:26 HdkR: Only once you get that custom bios installed to be able to use it
01:27 imirkin: i'm _really_ curious what will happen if you don't have the custom bios
01:27 imirkin: does it just report a funny pci class?
01:27 bnieuwenhuizen: HdkR: shouldn't be a problem with laptops that come with one :)
01:28 bnieuwenhuizen: though the weird part is I wonder if in such cases the dGPU or IGPU is faster
01:29 HdkR: DG1 with 80EU and clocked faster than a 96EU part in iGPU? Probably quite close. Until we get DDR5 machines I guess
01:30 bnieuwenhuizen: I guess it is very power management dependent which part actually achieves which clocks :)
01:32 bnieuwenhuizen: like at a guess given the same power budget the 96 EU GPU might be faster than the 80 EU one assuming they're powerlimited (and not looking at VRAM bandwidth)
01:32 HdkR: Right
02:51 jenatali: Anybody offhand know how much test coverage is available for 3.3 compatibility contexts? We're at 3.3 core and 3.1 compat at the moment and I'd love to get a quick idea of how far off we would be from 3.3 compat as well
02:54 bnieuwenhuizen: I thought there was zero coverage for the compat parts above core versions?
02:54 jenatali: Zero in piglit even?
02:54 bnieuwenhuizen: though maybe some stuff got added to piglit
02:59 zmike: there are some tests which will fail if you start enabling higher versions of compat
03:01 alyssa: jenatali: compat what's that? 😉
03:01 HdkR: Those things you want to support if you want triple-A games on your platform :>
03:01 jenatali: zmike: Piglit or CTS? I'm guessing piglit?
03:02 zmike: piglit
03:02 zmike: it's why zink has been clamped to 3.0 compat forever
03:03 jenatali: HdkR: Yeah we see a bunch of random apps that are non-AAA games that use compat contexts too
03:03 jenatali: There's also a bug currently when using the standalone OpenGL32.dll build where some apps don't see that the driver can even create core contexts... haven't finished debugging that one though
03:03 bnieuwenhuizen: yeah I think on windows almost nobody really started using core contexts
03:04 HdkR: Windows must be a mess of compat contexts
03:04 HdkR: with everyone supporting them over there
03:04 jenatali: Yeah...
03:38 anholt: alyssa: never had that fail.
03:39 anholt: not sure how I would do that -- prepend every parallel run with a single-threaded run of that test?
03:39 anholt: I've thought about that for collecting renderer info
03:58 mareko: jenatali: screen.rst describes what you need for compat
03:59 mareko: there's not much
04:00 jenatali: mareko: Thanks for that pointer. Looks like "The only legacy features that Gallium drivers must implement are the legacy shader inputs and outputs (colors, texcoords, fog, clipvertex, edgeflag)."
04:03 mareko: yes
04:03 jenatali: Sweet, hopefully that's not too bad
08:23 MrCooper: danvet: heh, not sure I'd consider Xwayland a king though, more like Santa's little helper :)
10:19 mripard: j4ni: it's weird, it breaks here in amdgpu and i915 when merging drm-next, not drm-misc-next?
10:20 j4ni: mripard: it worked for me again earlier today, I thought you'd fixed it :)
10:21 mripard: I didn't :)
10:30 mripard: it's weird, really, even dim rebuild-tip fails for me here
10:30 mripard: but I'm confused if it works for you :)
10:35 dolphin: mripard: updated maintainer-tools?
10:35 dolphin: I updated nightly.conf yesterday to remove the deprecated drm-intel-next-queued and moved drm-intel-gt-next
10:35 dolphin: but dim rebuild-tip finished without complaints
10:40 dolphin: duh, looks like dim automatically added two .patch files, too...
10:40 mripard: dolphin: yeah, it looks like maintainer-tools is up to date too :/
10:40 dolphin: mripard: dim rebuild-tip works fine here too
10:41 dolphin: just removed the two patch files and rebuilt tip
10:41 dolphin: git version 2.29.2
10:45 mripard: same git version here
10:45 mripard: and git clean'd drm-rerere and drm-tip, same story
10:46 dolphin: how does drm-tip conflict look like after you attempt rebuild?
10:47 mripard: it looks like it's the same conflict every time, a dozen or so files in conflict in i915 and amdgpu
10:48 dolphin: corruption in filesystem? I've had to resort starting DIM from scratch occasionally
10:48 mripard: is rebuild-tip doing a new branch all over again every time (like next), or is it based on the previous merges?
10:49 dolphin: it starts from scratch
10:49 mripard: ok, so that explains why it starts by checking out 5.11-rc7 then
10:50 dolphin: yeah, I think whatever is in origin/master
11:02 mripard: even with a new run of dim setup, dim rebuild-tip fails is the exact same way
11:33 j4ni: mripard: what's your git version?
12:20 mripard: j4ni: 2.29.2
12:43 alyssa: anholt: It fails if you completely break absolutely everything and not a single test passes except for negative coverage. Like I did last night 🙃
13:16 danvet: mlankhorst_, Subject: linux-next: build failure after merge of the drm-misc tree
13:17 danvet: you really should have looked for fixes to cherry-pick over :-)
13:17 danvet: pls sort out and reply to that
13:17 mlankhorst_: Yeah I will
13:21 mlankhorst_: drm-misc-next-fixes compiles, so possibly a merge failure?
13:22 mlankhorst_: Oh nm, not sure what I was trying to compile
13:24 mlankhorst_: Ah yeah I see it, will fix. Missed compiling on arm. :)
13:24 mlankhorst_: I wonder how that happened, shouldn't have been picked.
13:25 danvet: könig doesn't compile test consistently before pushing
13:25 danvet: airlied maybe neither
13:25 danvet: or is there a pull pending that's not merged into drm-next yet?
13:28 imirkin: i don't test often, but when i do, it's in production!
13:30 imirkin: jenatali: and there are piglit tests that cover those features for compat
13:30 imirkin: jenatali: but there's not a lot of just "general" compat tests for higher GL features
13:30 imirkin: (i.e. there are piglits for clip vertex in tess/gs, etc)
13:38 alyssa: jenatali: GL4.0 on d3d12 when :p
13:48 kevintang: danvet i saw your comments in patch v3 mentioned drmm_universal_plane_alloc, it seems that this api is still on drm-misc. i think is need to update my patch on drm-misc(no mainline) and then upstream for review, right?
13:59 zmike: these i965 asm timeouts on ci are super annoying
14:08 dj-death: zmike: agreed
14:09 dj-death: not quite sure why it started failing, I don't think we've touched those tests in a whole
14:09 dj-death: while
14:12 pepp: dj-death: something is wrong *somewhere*. The glcpp were failing, and when they got disabled the i965-asm tests started to fail (see https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8738#note_781940)
14:12 zmike: I'm at 4 in a row now...
14:12 zmike: although I think now I need to be manually running the pipeline
14:17 jenatali: alyssa: Eventually? :)
14:32 ajax: hmph
14:32 ajax: seems like the issue causing the timeouts might be in the hypervisor we're using then
15:06 MrCooper: dj-death zmike pepp ajax: see https://gitlab.freedesktop.org/mesa/mesa/-/issues/4256#note_795351
15:09 dj-death: MrCooper: I saw that, I didn't know what to make of it though
15:10 MrCooper: somebody needs to find out why these tests are getting so heavily blocked on file writes (or on what else)
15:18 MrCooper: i.e. likely, what causes what kind of overload on the runners
15:18 MrCooper: (has anyone seen these timeouts on a gst-htz-* runner?)
15:45 MrCooper: if not, a possible workaround would be restricting the affected jobs to those runners
15:55 alyssa: jenatali: \o/
16:04 MrCooper: I can only find timeouts on packet runners, going back to https://gitlab.freedesktop.org/mesa/mesa/pipelines?page=9&scope=all&status=failed (about a month ago)
17:36 daniels: ajax: no hypervisor, it's bare metal
17:36 daniels: MrCooper: I can give you SSH access to one of them if you want to bash at it for a while
17:36 daniels: I'm currently working on some monitoring things first
17:36 daniels: but like, has anyone tried running it under strace to see what it's actually doing?
17:42 MrCooper: I wouldn't really know what to look for with strace; since you do... :)
18:03 ajax: i was hoping for something like a meson feature where if a test times out it gets whacked with pstack(1) before being killed
18:04 ajax: alternatively, if disk is why they're stalling, possibly we can write the tests in terms of pipelines or tmpfs or...
18:06 ajax: as in, unix pipeline, not gitlab ci pipeline
18:07 anholt: pstack sounds like a nice tool
18:08 MrCooper: ajax: currently meson only waits for 0.5 between SIGTERM and SIGKILL to timed out tests, which isn't enough to get the output from time
18:08 MrCooper: 0.5s
23:26 jenatali: Has anyone thought about what it'd look like to add debug info into NIR so a compiler backend can provide source line info?