11:36HdkR: Who owns the FDO runners? robclark, anholt?
11:36HdkR: oh, I can update the CI jobs directly...
11:46HdkR: Oh meson-arm64-build-test is actually bugged
11:46HdkR: It extends meson-arm which builds vulkan drivers freedreno, broadcom, but overwrites it to only build amd
11:48HdkR: Or just separation between build testing and running?
11:49HdkR: meson-arm64 versus meson-arm64-build-test
11:49MrCooper: the latter
11:49MrCooper: meson-arm64 builds only what's needed for test jobs
11:49MrCooper: to minimize the duration of the pipeline
11:51MrCooper: and meson-arm64-build-test is for build-testing other components
11:52HdkR: and since there isn't an r300,r600, or radeonsi connected arm64 runner it should only be in the build-test runner
11:53HdkR: since it's also build testing radv there
12:13HdkR: oof, Werror
12:17HdkR: Let's see if I can reproduce those here...
12:19HdkR: It's even a spurious Werror which is great
12:59HdkR: Reproduced, hope that was the only one...
12:59HdkR: Only two even
13:17HdkR: Awesome, looks like only those two spurious uninitialized warnings because of the super old GCC version
14:46clever: i'm working on a util using drm/kms, to test for tearing problems in the drivers
14:47clever: 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:47clever: 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:47clever: what am i doing wrong?
14:48clever:notices the pitch variable...
14:48clever:pats the rubber duck, lol
19:34jekstrand: 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:39robclark: 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:41dj-death: jekstrand: there is that gtk thing if you care : https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/2540
19:41robclark: jekstrand: https://github.com/robclark/shadertoy-render .. ignore the stuff about ffmpeg, I hacked it to render to screen
21:24jekstrand: robclark: cool
21:25robclark: I do wish there was a generic soln to running webgl stuff outside of context of browser
21:28HdkR: robclark: Does https://shadered.org/ count since it has an independent application?
21:29HdkR: Nearly shadertoy
21:29robclark: idk, haven't played with it before
21:30HdkR: I'm guessing it's just a chromium instance in the self-hosted application
21:30HdkR: But haven't actually tried
21:30robclark: hmm, that probably doesnt make things easier
21:32ccr: not sure how a generic webgl would work without a (almost) full browser implementation anyway
21:39HdkR: 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:39HdkR: rather than "webgl" freestanding
21:39HdkR: As long as it can repro the bugs ;)
21:40robclark: yeah, https://github.com/robclark/shadertoy-render is basically that.. modulo potentially falling being wrt to changes in shadertoy api