00:07airlied: chrisf: 5751f9e38e7385e926696d967644e7208856d2e5 (commit hygeiene sucks :-P
00:08airlied: lets convert a bunch of types and add support ine one patch
00:08pcercuei: )
00:11airlied:has to find some diffs in the mesa bc7 decoder as it fails vk cts
00:25chrisf: airlied, yeah :(
00:28chrisf: airlied, i try to keep mine pretty clean but can't always win :)
00:31airlied: it looks like llvmpipe might pass GL4.5 without the env vars set, it might just be gles2/vk it fails
00:32airlied: find out in 8-10 hrs :-P
06:25tpalli: some "500 Internal Server Error" happening with Mesa CI jobs
06:38airlied: daniels: ^
06:55mlankhorst: danvet: i thoguht i did, maybe it was resurrected?
06:56danvet: mlankhorst, it's still in git and in nightly.conf
06:56danvet: dim remove-branch $thing
07:02mlankhorst: will retry
07:03mlankhorst: done
07:56MrCooper: tpalli: got specific examples?
08:33mareko: tpalli: that's still better than piglit which doesn't accept any MRs anymore :)
08:41MrCooper: mareko: same question to you
08:43MrCooper: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/4429605 succeeded ~100 minutes ago
08:44danvet: pinchartl, sravn another dw-dsi component from narmstrong, I asked when we're going to fix this for real
09:04MrCooper: mareko: ah, I thought you were talking about piglit jobs in Mesa pipelines; for the piglit project, somebody should create an MR which disables the Windows jobs for now
09:46mareko: MrCooper: not everybody knows how to do that
09:52MrCooper: just prepend a dot to the job names
09:59pepp: MrCooper, mareko : https://gitlab.freedesktop.org/mesa/piglit/-/merge_requests/381
10:00pepp: hmm btw piglit still creates pipeline on each push. Should it switch to post-merge only pipelines?
10:01MrCooper: it's still much lighter than Mesa as is :)
10:02pepp: sure
10:02MrCooper: not even on any top 10 lists for CI resource usage yet
10:32sravn: danvet: would be great if you with a gentle push can have this fixed properly. For the moment I am backlogged and have no time for Linux stuff :-(
11:51rah: airlied: :-(
11:55rah: OpenCL is still not well supported? :-(
12:19rah: I wrote this code about 10 years ago using AMD's proprietary "SDK"
12:45pinchartl: danvet: I don't mind dropping it today :-)
12:45pinchartl: someone has to do the work though
13:17rah: https://www.reddit.com/r/Amd/comments/5jqk54/what_is_the_status_of_opencl_in_amdgpumesa/dbjwoc8/
13:17rah: *facepalm*
13:18rah: "we shifted our focus from clover to opening up our proprietary implementation instead"
13:18rah: argh
13:55danvet: pinchartl, sravn yeah I'm pushing
13:55danvet: this was more fyi for you folks
15:05anholt:
19:54Vanfanel: pq: yesterday you told me: "14:00 pq: Vanfanel, if you don't want to leak a GBM buffer, you could create a dumb buffer, clear it with CPU, and put that up, so you can destroy and not leak anything GBM produced. Then just don't RmFB the dumb buffer when you exit. "
19:54Vanfanel: pq: I am doing so now -> https://github.com/vanfanel/SDL/blob/e3a7516c4cd9ae0c1d60f0512e263d2f6b4eade7/src/video/kmsdrm/SDL_kmsdrmvideo.c#L917
19:55Vanfanel: pq: and there are no errors anywhere, no failed atomic commits, no fails on DMESG.. but when the program totally quits, screen is stuck in solid white
19:56Vanfanel: pq: I believe it happens because, in the end, when the program memory is freed, the dumb buffer gets freed outside my control
19:57Vanfanel: pq: so... maybe it's not the best idea, or am I missing something? I am NOT doing rmFB on it, since you told me not to do it.