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