00:08bl4ckb0ne: could eglSwapBuffers fail?
00:15HdkR: `EGL_FALSE is returned if swapping of the surface buffers fails, EGL_TRUE otherwise.`
00:15HdkR: So sure
00:16HdkR: EGL_CONTEXT_LOST probably ending up being the reason if it did fail
00:38pinchartl:is unhappy about the new final_kfree warning in drm-misc
00:38pinchartl: clearly half-baked :-(
00:42bl4ckb0ne: so it fails if either the surface or the context has been destroyed?
01:11HdkR: bl4ckb0ne: https://www.khronos.org/registry/EGL/sdk/docs/man/html/eglSwapBuffers.xhtml It has a couple of other failure options, but that is most likely yes
01:12bl4ckb0ne: so ill have to handle the case, thanks
04:11anholt: jekstrand: theoretically? I mean, we're running traces under apitrace or renderdoc, you've already impacted the runtime environment a bunch. the question is whether this tool can still find useful information (by testing more workloads than you ever would otherwise)
04:11anholt: I'm trying to build a replacement for shader-db because that's such a bad tool for any choice involving tradeoffs
04:12anholt: (FWIW, apitrace and apitrace --pgpu on an arbitrary trace I picked, seemed to be basically the same range of fps)
08:09tomeu: btw, there will be a round table about free GPU drivers on Arm devices in about 7 hours from now: https://connect.linaro.org/resources/ltd20/ltd20-401/
08:09MrCooper: daniels: I saw meson-windows-vs2019 take 30 minutes once yesterday (around when you were giving your talk, that's why I didn't report it immediately)
08:11MrCooper: anholt: not seeing many s390x timeouts since the job is limited to packet runners (in fact, I only remember one yesterday), are you?
09:46daniels: MrCooper: oh, I know why it is, it's because the GSt Windows runner isn't back yet, so its jobs are using the one runner we have
09:46MrCooper: I suspected something like that
10:24swick: does some hardware support scanout from fp16?
10:32emersion: swick: https://drmdb.emersion.fr/formats
10:32emersion: grep for "16161616F"
10:54swick: emersion: thanks
10:55swick: are the components just getting clamped between 0 and 1 or is that configurable somehow?
12:15imirkin: emersion: what does the percentage indicate?
12:15emersion: imirkin: number of devices supporting the format/modifier pair
12:15emersion: you can filter these devices by clicking on the column headers
12:16imirkin: so like what is the 62% for C8 under nouveau?
12:16emersion: and you get a per-plane-type percentage too
12:16imirkin: 62% of what?
12:16emersion: of all recorder devices
12:17imirkin: is there a list?
12:17emersion: of devices?
12:17imirkin: aha, thanks
12:17emersion: i should add a driver filter to this page
12:18imirkin: oh right. we don't support C8 pre-nv50. probably should... o well.
12:18pq: How does C8 work, what does it mean?
12:19imirkin: emersion: oh that is just a cheap shot -- https://drmdb.emersion.fr/devices/60ed09688930
12:19imirkin: that brings down the percentages just coz there are no connectors (and thus no planes)
12:19emersion: imirkin: i think it's a render-only device?
12:19imirkin: pq: indexed
12:19emersion: yeah, that's right, should probably filter those out
12:19pq: imirkin, yes, but how? Where is the palette? How is it used?
12:20imirkin: pq: it's used by fbcon (fbdev?) optionally, the palette is in gamma
12:20pq: so, you take the C8 value, and use it as an index on all three channels of the gamma table?
12:21pq: ok, thanks
12:21imirkin: there is support in modetest too (i added it)
12:21emersion: would be nice to document that :P
12:24imirkin: emersion: btw, where do you get the data from?
12:24emersion: imirkin: nice people !
12:26imirkin: depending on the kindness of strangers, eh
12:26emersion: the alternative would be to buy a whole lot of devices
12:26imirkin: anyways, ftr all nv50+ support FP16 scanout. but not in that kernel apparently.
12:27imirkin: yeah :)
13:43kisak: jekstrand: morning, quick question about https://gitlab.freedesktop.org/mesa/mesa/-/commit/68f325b256d96dca923f6c7d84bc6faf43911245 , is this something that should be fast-tracked out to a 20.0.3 build or wait until 20.0.4?
13:49hakzsam: it should be applied asap, it breaks a bunch of things
13:49kisak: okay, will do
14:15jcristau: i filed https://gitlab.freedesktop.org/mesa/mesa/-/issues/2727 earlier, and i'd like jrmuizel to have access. is that possible somehow?
14:21jcristau: daniels: ^ do you know?
14:32daniels: jcristau: i'm not aware of anything, sorry
14:34jcristau: thanks :( that's sort of inconvenient..
14:34jekstrand: kisak: Yeah... that was very much my bad. :-(
14:34jekstrand: I was sure I'd run it in CI multiple times.
14:35ajax: jcristau: i've added him to the mesa group as a Reporter, he should be able to see it now
14:36jcristau: thanks ajax!
14:36ajax: well, specifically to the mesa/mesa project
14:37ajax: apparently Guests (the default) can only see confidential issues they've created, Reporters can see them all.
14:39ajax: nothing like bugzilla's "add this specific person to the cc list for this specific bug", afaict
16:29nroberts: does this build error mean anything to anybody? it looks like it’s trying to parse my commit message for some reason https://gitlab.freedesktop.org/nroberts/mesa/-/jobs/2160682
17:20daniels: nroberts: it's trying to put it into an environment variable, and failing ... https://gitlab.com/gitlab-org/gitlab-runner/issues/10123
17:20gitbot: GitLab.org issue 10123 in gitlab-runner "powershell runner is confused by Unicode curly quote marks" [Category:Runner, Devops::Verify, Group::Runner, Opened]
17:21nroberts: urg, ok, that’s pretty annoying. I guess I can just change it to straight quotes then
17:41ldiamond: I opened an issue on mesa's gitlab a few days ago. Is it realistic to run a profiler against a locally compiled version to figure out where the performance issue may be? https://gitlab.freedesktop.org/mesa/mesa/-/issues/2702
19:16airlied: oh man do I really want in on this mux discussion
19:33vsyrjala: run away!
22:08karolherbst: anybody want to take a look at the clover build fix before people complain they really need this fix? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4417
22:09karolherbst: I don't see why it's clang-10 related or did they get rid of the multi lib build option?
22:18mattst88: karolherbst: I'm not sure. in gentoo we've finally switched away from using the split shared libraries
22:19mattst88: I've gotten ~3 bug reports about mesa failing to build against clang-10 in gentoo, but I'm not sure if that is entirely the cause or if there were upstream changes as well
23:03airlied: karolherbst: fedora just changed the packaging
23:03airlied: but yeah please push it already
23:18karolherbst: mattst88: mind testing it with this patch and report back (or trigger the merge or so)
23:18mattst88: karolherbst: sure, will do