00:08 bl4ckb0ne: could eglSwapBuffers fail?
00:15 HdkR: `EGL_FALSE is returned if swapping of the surface buffers fails, EGL_TRUE otherwise.`
00:15 HdkR: So sure
00:16 HdkR: EGL_CONTEXT_LOST probably ending up being the reason if it did fail
00:38 pinchartl:is unhappy about the new final_kfree warning in drm-misc
00:38 pinchartl: clearly half-baked :-(
00:42 bl4ckb0ne: so it fails if either the surface or the context has been destroyed?
01:11 HdkR: 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:12 bl4ckb0ne: so ill have to handle the case, thanks
04:11 anholt: 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:11 anholt: I'm trying to build a replacement for shader-db because that's such a bad tool for any choice involving tradeoffs
04:12 anholt: (FWIW, apitrace and apitrace --pgpu on an arbitrary trace I picked, seemed to be basically the same range of fps)
08:09 tomeu: 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:09 MrCooper: 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:11 MrCooper: anholt: not seeing many s390x timeouts since the job is limited to packet runners (in fact, I only remember one yesterday), are you?
09:46 daniels: 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:46 MrCooper: I suspected something like that
10:24 swick: does some hardware support scanout from fp16?
10:32 emersion: swick: https://drmdb.emersion.fr/formats
10:32 emersion: grep for "16161616F"
10:54 swick: emersion: thanks
10:55 swick: are the components just getting clamped between 0 and 1 or is that configurable somehow?
12:15 imirkin: emersion: what does the percentage indicate?
12:15 emersion: imirkin: number of devices supporting the format/modifier pair
12:15 emersion: you can filter these devices by clicking on the column headers
12:15 imirkin: https://drmdb.emersion.fr/formats?driver=nouveau
12:16 imirkin: so like what is the 62% for C8 under nouveau?
12:16 emersion: aye
12:16 emersion: and you get a per-plane-type percentage too
12:16 imirkin: 62% of what?
12:16 emersion: of all recorder devices
12:17 emersion: recorded*
12:17 imirkin: is there a list?
12:17 emersion: of devices?
12:17 imirkin: yes
12:17 emersion: https://drmdb.emersion.fr/devices
12:17 imirkin: aha, thanks
12:17 emersion: i should add a driver filter to this page
12:18 imirkin: oh right. we don't support C8 pre-nv50. probably should... o well.
12:18 pq: How does C8 work, what does it mean?
12:19 imirkin: emersion: oh that is just a cheap shot -- https://drmdb.emersion.fr/devices/60ed09688930
12:19 imirkin: that brings down the percentages just coz there are no connectors (and thus no planes)
12:19 emersion: imirkin: i think it's a render-only device?
12:19 imirkin: pq: indexed
12:19 emersion: yeah, that's right, should probably filter those out
12:19 pq: imirkin, yes, but how? Where is the palette? How is it used?
12:20 imirkin: pq: it's used by fbcon (fbdev?) optionally, the palette is in gamma
12:20 pq: so, you take the C8 value, and use it as an index on all three channels of the gamma table?
12:20 imirkin: yep
12:21 pq: ok, thanks
12:21 imirkin: there is support in modetest too (i added it)
12:21 emersion: would be nice to document that :P
12:24 imirkin: emersion: btw, where do you get the data from?
12:24 emersion: imirkin: nice people !
12:25 tanty: :)
12:26 imirkin: depending on the kindness of strangers, eh
12:26 emersion: the alternative would be to buy a whole lot of devices
12:26 imirkin: anyways, ftr all nv50+ support FP16 scanout. but not in that kernel apparently.
12:27 imirkin: yeah :)
13:43 kisak: 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:49 hakzsam: it should be applied asap, it breaks a bunch of things
13:49 kisak: okay, will do
14:15 jcristau: i filed https://gitlab.freedesktop.org/mesa/mesa/-/issues/2727 earlier, and i'd like jrmuizel to have access. is that possible somehow?
14:21 jcristau: daniels: ^ do you know?
14:32 daniels: jcristau: i'm not aware of anything, sorry
14:34 jcristau: thanks :( that's sort of inconvenient..
14:34 jekstrand: kisak: Yeah... that was very much my bad. :-(
14:34 jekstrand: I was sure I'd run it in CI multiple times.
14:34 jekstrand: :(
14:35 ajax: jcristau: i've added him to the mesa group as a Reporter, he should be able to see it now
14:36 jcristau: thanks ajax!
14:36 ajax: np
14:36 ajax: well, specifically to the mesa/mesa project
14:37 ajax: apparently Guests (the default) can only see confidential issues they've created, Reporters can see them all.
14:39 ajax: nothing like bugzilla's "add this specific person to the cc list for this specific bug", afaict
16:29 nroberts: 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:20 daniels: nroberts: it's trying to put it into an environment variable, and failing ... https://gitlab.com/gitlab-org/gitlab-runner/issues/10123
17:20 gitbot: GitLab.org issue 10123 in gitlab-runner "powershell runner is confused by Unicode curly quote marks" [Category:Runner, Devops::Verify, Group::Runner, Opened]
17:21 nroberts: urg, ok, that’s pretty annoying. I guess I can just change it to straight quotes then
17:21 nroberts: thanks
17:41 ldiamond: 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:16 airlied: oh man do I really want in on this mux discussion
19:33 vsyrjala: run away!
22:08 karolherbst: 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:09 karolherbst: I don't see why it's clang-10 related or did they get rid of the multi lib build option?
22:18 mattst88: karolherbst: I'm not sure. in gentoo we've finally switched away from using the split shared libraries
22:19 mattst88: 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:03 airlied: karolherbst: fedora just changed the packaging
23:03 airlied: but yeah please push it already
23:18 karolherbst: mattst88: mind testing it with this patch and report back (or trigger the merge or so)
23:18 mattst88: karolherbst: sure, will do