00:21 ajax: anholt: https://ajax.fedorapeople.org/glx-xlib-results/
00:28 anholt: grr. I've got an asan vk driver, and I'm ld-preloading libasan, but I'm not getting backtraces from the leaks. :/
11:27 tanty: anholt, would you find some time to take a look to at
11:27 tanty: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6388
11:27 tanty: ?
12:21 pq: Does DRI_PRIME=1 or with device tags not work for EGL Surfaceless platform? My system Mesa 18.3.6 always insists on intel and my own built Mesa 20.2.4 always insists on AMD GPU.
12:23 pq: wflinfo --platform=x11_egl --api=gles3 is happy to choose the GPU I want
12:23 emersion: i've seen code that takes DRI_PRIME into account in the surfaceless platform
12:23 emersion: but maybe it's broken
12:25 emersion: hm, or maybe i'm misremembering
12:25 emersion: because i can't find it again
12:25 pq: a new issue it is then
12:25 emersion: https://gitlab.freedesktop.org/mesa/mesa/-/blob/master/src/egl/drivers/dri2/platform_surfaceless.c#L330
12:26 emersion: maybe i mix it up with the x11 driver
12:26 emersion: https://gitlab.freedesktop.org/mesa/mesa/-/blob/master/src/egl/drivers/dri2/platform_x11_dri3.c#L619
12:26 emersion: yeah, i mixed it up
12:27 emersion: hopefully fixing it is a one-line change
13:34 emersion: daniels: ack on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7992 ?
13:44 daniels: emersion: yep, merging now, thanks!
13:44 emersion: :)
15:12 emersion: pinchartl: alex deucher
15:12 emersion: <Alexander.Deucher@amd.com>
15:13 emersion: ah, daniel cc'ed him already
15:17 pinchartl: emersion: I suspected so. thanks :-)
15:30 danvet: emersion, not documenting plane type property is an oversight tbh
15:30 danvet: not sure why I missed that
15:31 danvet: emersion, I'd just whack it under this one https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#plane-composition-properties
15:32 emersion: "composition" :P
15:32 emersion: ok, will do
15:32 danvet: "stuff remotely useful for compositors"
15:32 danvet: tbh it's a nice dumping ground
15:32 danvet: maybe rename it to "Standard Plane Properties"
15:32 emersion: danvet: how much should we duplicate between the prop docs and the enum docs?
15:33 emersion: yeah, maybe we should do that
15:33 emersion: all plane props affect composition
15:34 danvet: emersion, I thought for enum props we aim to only document the string, not the enume?
15:35 danvet: so I say dupe it
15:35 emersion: yes
15:35 emersion: we just need to be careful to update both, if we touch either
15:35 danvet: I think that's what we've generally done
15:35 danvet: otherwise this becomes too painful for userspace peopel to read :-)
15:36 emersion: maybe we should drop the internal kernel details from the props, and just add "Kernel developers, see enum drm_thing"
15:36 danvet: at the bottom I tend to sprinkle the hints for driver developers, like which function this is set up with
15:36 danvet: those can then link to more places
15:36 danvet: like "This value is set when calling drm_universal_plane_init()"
15:36 emersion: hm, yeah. iirc many props have a lot of internal kernel details
15:37 emersion: we're also missing FB_DAMAGE_CLIPS from the list btw, i'll need to add that
15:37 danvet: yeah, but should be fairly minimal
15:37 danvet: nope that should be somewhere
15:37 emersion: there's a whole section about it
15:38 emersion: https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#fb-damage-clips
15:38 emersion: but it's just… there, not referenced from anywhere else
15:39 danvet: yeah that's misplaced
15:39 emersion: it's hard to Ctrl+F in the page as a user-space dev because of all of the kernel internals
15:39 emersion: so i'd prefer to have it listed in "plane properties" too
15:40 danvet: oh it's there, but the subheading level is too low to show it
15:41 emersion: it's there, burried after a lot of kernel function docs
15:41 danvet: emersion, what about moving the driver api doc to the right object heading further up (plane or crtc or whatever)
15:41 danvet: and just leaving the overview section there?
15:42 emersion: hm, sorry, i don't get it
15:42 emersion: oh
15:43 danvet: also I guess we really need a new overview for plane properties in general
15:43 emersion: you mean moving the docs for e.g. drm_plane_create_blend_mode_property under "plane abstraction"?
15:43 danvet: yeah
15:43 emersion: strong +1 for this
15:43 danvet: lemma type up something
15:44 danvet: https://paste.debian.net/1177136/ like this
15:44 danvet: but for all of them
15:45 emersion: yup, looks good!
15:45 emersion: will do that
15:45 danvet: https://paste.debian.net/1177137/
15:45 danvet: maybe with better english or so
15:46 emersion: :D
15:46 danvet:feeling uninspired
15:46 danvet: emersion, also I think we should move IN_FORMATS out of the section in drm_blend.c
15:46 danvet: and make a proper Standard Plane Properties section
15:46 danvet: with that + type
15:46 emersion: hm, so
15:46 danvet: I think having all the blend related stuff in drm_blend.c feels good
15:47 emersion: ok, got it
15:47 danvet: but separate patch I guess
15:47 emersion: yeah, will try to logically split that up
15:47 emersion: lots of patches to write, eh
15:47 danvet: also perhaps s/FB_DAMAGE_CLIPS/Damage Tracking/
15:47 danvet: or so
15:48 danvet: yelling headings is a bit much :-)
15:48 emersion: yup, agreed
17:35 jenatali: Hm... I'd like to add the d3d12 driver to a Linux CI pipeline now that it can build there, but it looks like they're all using Werror, and the driver's not warnings-clean (yet). Is there a pipeline I can add it to? Or do I need to get it warning-clean first?
17:39 dcbaker[m]: kusma: 67ae12931 Revert "st/dri: make sure software color-buffers are linear" doesn't make sense for 20.3 without the coresponding zink change, right?
17:40 dcbaker[m]: mareko: dffc27e5e1 radeonsi: fix small primitive culling with MSAA force-disabled and smoothing, has a lot of conflicts with staging/20.3 and I'm not sure how to resolve them. Could you provide a backport?
17:41 dcbaker[m]: kusma: also, could you look at the last patch on the staging/20.3 tree from you? I had to resolve some conflicts and I'm not sure if I did it correctly
17:42 sumits: hello drm-misc maintainers: I've had to push jstultz's fix onto drm-misc-next-fixes [https://patchwork.freedesktop.org/patch/408266/?series=84982&rev=1] - just letting you know for the next pull, please
17:50 sumits: ^^^ danvet, mlankhorst_, seanpaul, mripard, fyi please
17:53 anholt: jenatali: I'd focus on just getting to warnins clean.
17:53 jenatali: anholt: Sounds good, thanks
18:09 dschuermann: rfc: !8123 works around a game bug present in NMS which will appear when 6358 is getting merged. I would like to backport as well although it's a (small) optimization. the game devs are going to be informed and hopefully will fix it properly. But I don't want the game to break in the meantime.
18:28 dcbaker[m]: dschuermann: Not sure if you saw my last ping, but your "aco: fix DCE or rematerializable phi nodes" is causing fossil-db regressions on the staging/20.3 branch
18:38 dschuermann: dcbaker[m]: where did you ping me? I must have overseen that. but thanks, I'll have a look
18:38 dschuermann: when is the next point release?
18:39 dcbaker[m]: right now
18:43 dcbaker[m]: I pinged you here, I know dri-devel is pretty busy, so if there's a different way you'd prefer to me know
18:44 dschuermann: normally, I see these, not sure how it slipped. but feel free to write directly if that happens again :/
18:47 dcbaker[m]: Okay, will do
18:51 dschuermann: dcbaker[m]: thx for holding back the patch. please skip it for now, it needs some more investigation
18:52 dcbaker[m]: No problem
18:54 pendingchaos: dschuermann: I think the know the issue: https://pastebin.com/raw/Kins6hwW
18:54 pendingchaos: "aco/spill: only prevent rematerializable ..." fixed this, but it isn't backported
18:56 kisak: looks like it's also queued for 20.2 https://cgit.freedesktop.org/mesa/mesa/commit/?h=staging/20.2&id=02cd25463df74e17c799a29201028bc92fafe3f8
18:58 pendingchaos: I think 20.2 will need either a revert or something like that diff then
19:01 dcbaker[m]: sigh. I missed that and just released 20.2.5
19:02 dcbaker[m]: do I need to revert that and make a 20.2.6?
19:03 dcbaker[m]: 20.2.5 was the last planned 20.2 release
19:04 dcbaker[m]: pendingchaos, kisak , dschuermann : ^
19:05 ajax: why, in 2020, does anyone want gles1 compatibility
19:06 dcbaker[m]: Are you really expecting sanity in 2020?
19:15 mareko: dcbaker[m]: yes, I have backports locally, just need to send them out
19:15 dcbaker[m]: mareko: awesome, thanks!
19:18 ajax: dcbaker[m]: touché
19:18 anarsoul: ajax: is it rhetorical question?
19:19 ajax: not... entirely
19:19 ajax: https://github.com/KhronosGroup/OpenGL-Registry/pull/451 and https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8113
19:21 pendingchaos: dschuermann: these seem to be the two fossils which regressed in 20.2.5 because of the patch: https://pastebin.com/raw/S6mnmSt1
19:21 pendingchaos: seems, in a release build, f12017 compilation doesn't crash (unlike uber_subgroup) but it probably miscompiles
19:26 dcbaker[m]: dschuermann, pendingchaos: I pulled the other patch as well, and that gets fossil-db passing on 20.3
19:40 pendingchaos: dschuermann: f12017's benchmark at ultra settings with 20.2.5 doesn't look obviously incorrect
19:42 pendingchaos: also seems the rdr2 fossil crashes for polaris10 but not gfx1030
19:57 pendingchaos: dschuermann: summary of fossil regressions: https://pastebin.com/raw/xdqqEUZ9
21:05 dschuermann: dcbaker[m]: given the amount of regressions, may I ask you to create a 20.2.6 for us? sorry, I completely forgot that the patch was pending for 20.2 as well
21:08 dcbaker[m]: dschuermann: no worries, I should have noticed that anyway. Do you want me to revert that patch, or pull the fix?
21:08 dschuermann: I think pulling the fix is the safer option
21:19 dcbaker[m]: alright, I've pulled the patch and pushed the staging/20.2 branch again. Once that comes back (assuming the radv-fossil job is green) I'll make the release
21:33 kisak: thanks dcbaker
21:34 dcbaker[m]: https://gitlab.freedesktop.org/mesa/mesa/-/pipelines/245056, good to go?
21:39 dschuermann: dcbaker[m]: yes, perfect and thanks alot :)
21:40 dschuermann: radeonsi must be a flake or otherwise unrelated
21:40 dcbaker[m]: otherwise unrelated
21:40 dcbaker[m]: CI is rather a mess on 20.2, it's my fault
21:41 dcbaker[m]: which is why I missed this in the first place on that branch
21:41 dcbaker[m]: release in process
21:41 dcbaker[m]: thanks all
22:35 danvet: agd5f, accidentally read some code and stumbled over c920888c604d7
22:35 danvet: it's behind #ifdef DEBUG_FS, but that's still uapi
22:36 danvet: can you pls move this into debugfs before we ship this?
22:42 danvet: also typed some mail
22:43 danvet: ended up a bit a sermon, but I figured maybe some people didn't know so better to type it all up
22:45 agd5f: danvet, if you want to revert that one and the documentation fix for it, Acked-by: me
22:45 agd5f: sorry I missed that
22:45 danvet: agd5f, dont worry, stuff slips through
22:46 danvet: and it's already in Linus' tree, so no need to rush imo
22:46 danvet: imo revert or move to debugfs is all fine
22:46 danvet: best case some igt discussion with a standard debugfs, but really not required
22:47 danvet: I guess in a way kms properties are massive success, way to easy to quickly add more uapi :-)
22:48 agd5f: yeah
22:51 danvet: I guess if this helps that dc team gets the "kms properties need igt and everything" memo, we're better of and all good
22:52 danvet: I mean beyond the usual people who hang our here anyway
23:32 anholt: robclark: sweet. allocating threads for the slow cores too is cutting a630-gles3 from 6.5 to ~5 minutes.
23:33 robclark: nice
23:34 robclark: I wonder if deqp-runner should be big/little aware and adjust the sizes of chunks of tests :-P
23:34 robclark:ducks
23:34 anholt: robclark: I don't think so, you'll just have some threads left over at the end that hopefully drain from little onto the big cores.
23:35 anholt: (I don't think rayon pins its threads, but maybe I'm wrong)
23:35 robclark: yeah, probably
23:35 anholt: actually, it wouldn't I don't think, since I'm making a 9 thread pool in this case for 8 cpus.
23:52 anholt: thinking about board usage, spending 1:48 to accomplish a 52-second gles2 run is silly. I've got a630_gles_others with a script to manage batching up a bunch of small fractional runs already, and I could do the same-ish by like merging gles2 and gles3, but I have to be careful to manage runtime to keep results coming back fast (gles2+3+31 would be right around 10 minutes, which is a bit long, and where's sensible to put the short
23:52 anholt: vk_sysmem run?). What would be really nice is if I could express "here is a pile of mustpass lists and deqp binariess, and env var or deqp args variant runs for some of the mustpass lists, please divide the runs across the boards and load-balance for me and give a useful summary output at the end for each board.
23:55 robclark: yeah, it would be nice if there was indirection/abstraction between test cases and runners
23:56 robclark: maybe for bonus points, keep track of how long different groups of tests take to run on average and auto load-balance
23:56 anholt: this doesn't feel that hard inside deqp-runner. hardest bit is probably deciding on a file format for describing the test sets
23:56 dcbaker[m]: machine <-> machine? json all the way
23:56 anholt: dcbaker[m]: human to machine
23:56 robclark: or mapping it back to something sensible to gitlab? It is kinda nice to look at just one page to see "gles31 fails" rather than poking thru a bunch of jobs
23:56 dcbaker[m]: oh, not json then :)
23:57 anholt: aka not .gitlab-ci/bare-metal/arm64_a630_gles_others.sh
23:57 dcbaker[m]: yaml or toml are my preferences for human consumable
23:58 ajax: no but seriously nvidia's driver exposes a GLES1 compatibility extension in a core context
23:58 ajax: i have _so_ many questions
23:58 anholt: yaml seems like a feature for one less language for mesa maintainers to have to know. it does have the downside that I find it miserable to type.
23:59 robclark: ajax: lol
23:59 ajax: like... you can use the matrix stack, but only if you use fixed-point? and you _wanted_ this?