11:36 HdkR: Who owns the FDO runners? robclark, anholt?
11:36 HdkR: oh, I can update the CI jobs directly...
11:38 MrCooper: yep
11:46 HdkR: Oh meson-arm64-build-test is actually bugged
11:46 HdkR: It extends meson-arm which builds vulkan drivers freedreno, broadcom, but overwrites it to only build amd
11:47 HdkR: Oops?
11:48 HdkR: Or just separation between build testing and running?
11:49 HdkR: meson-arm64 versus meson-arm64-build-test
11:49 MrCooper: the latter
11:49 HdkR: alright
11:49 MrCooper: meson-arm64 builds only what's needed for test jobs
11:49 MrCooper: to minimize the duration of the pipeline
11:50 HdkR: perfect
11:51 MrCooper: and meson-arm64-build-test is for build-testing other components
11:52 HdkR: and since there isn't an r300,r600, or radeonsi connected arm64 runner it should only be in the build-test runner
11:53 HdkR: since it's also build testing radv there
12:13 HdkR: oof, Werror
12:17 HdkR: Let's see if I can reproduce those here...
12:19 HdkR: It's even a spurious Werror which is great
12:59 HdkR: Reproduced, hope that was the only one...
12:59 HdkR: Only two even
13:17 HdkR: Awesome, looks like only those two spurious uninitialized warnings because of the super old GCC version
14:46 clever: https://github.com/librerpi/rpi-tools/blob/master/utils/tearing-test.cpp#L60
14:46 clever: i'm working on a util using drm/kms, to test for tearing problems in the drivers
14:47 clever: if i use DRM_IOCTL_MODE_CREATE_DUMB+drmModeAddFB+DRM_IOCTL_MODE_MAP_DUMB+drmModeSetCrtc (via setupFrameBuffer), then i can get a frame covering the full screen, but that doesnt have page-flip capabilites
14:47 clever: so i re-arranged the code to be able to create 2 framebuffers, and then call drmModePageFlip to switch between them, but now only the 1st scanline of the the buffer is visible
14:47 clever: what am i doing wrong?
14:48 clever:notices the pitch variable...
14:48 clever:pats the rubber duck, lol
19:34 jekstrand: anholt, robclark: I know both of youhave played around with shader-toy a bit. Do either of you have a stand-alone shader-toy runner? I hate running Chrome on a custom mesa build. :-/
19:39 robclark: jekstrand: yeah, give me a few min to dig it up.. although last time I used it was a while back, and the shadertop API seems to change every now and then..
19:41 dj-death: jekstrand: there is that gtk thing if you care : https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/2540
19:41 robclark: jekstrand: https://github.com/robclark/shadertoy-render .. ignore the stuff about ffmpeg, I hacked it to render to screen
21:24 jekstrand: robclark: cool
21:25 robclark: I do wish there was a generic soln to running webgl stuff outside of context of browser
21:28 HdkR: robclark: Does https://shadered.org/ count since it has an independent application?
21:29 HdkR: Nearly shadertoy
21:29 robclark: idk, haven't played with it before
21:30 HdkR: I'm guessing it's just a chromium instance in the self-hosted application
21:30 HdkR: But haven't actually tried
21:30 robclark: hmm, that probably doesnt make things easier
21:32 ccr: not sure how a generic webgl would work without a (almost) full browser implementation anyway
21:32 ccr: +thing
21:35 ccr: plain javascript runner + webgl canvas would still have to somehow intelligently strip out or ignore things related to whatever fluff there is for everything else
21:37 robclark: true.. javascript makes things non-easy
21:39 HdkR: Seems like you would just want shadertoy freestanding. So do all the base uniform handling to get the basic fragment shaders running with mostly copy and paste
21:39 HdkR: rather than "webgl" freestanding
21:39 HdkR: As long as it can repro the bugs ;)
21:40 robclark: yeah, https://github.com/robclark/shadertoy-render is basically that.. modulo potentially falling being wrt to changes in shadertoy api