00:21ajax: anholt: https://ajax.fedorapeople.org/glx-xlib-results/
00:28anholt: grr. I've got an asan vk driver, and I'm ld-preloading libasan, but I'm not getting backtraces from the leaks. :/
11:27tanty: anholt, would you find some time to take a look to at
12:21pq: 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:23pq: wflinfo --platform=x11_egl --api=gles3 is happy to choose the GPU I want
12:23emersion: i've seen code that takes DRI_PRIME into account in the surfaceless platform
12:23emersion: but maybe it's broken
12:25emersion: hm, or maybe i'm misremembering
12:25emersion: because i can't find it again
12:25pq: a new issue it is then
12:26emersion: maybe i mix it up with the x11 driver
12:26emersion: yeah, i mixed it up
12:27emersion: hopefully fixing it is a one-line change
13:34emersion: daniels: ack on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7992 ?
13:44daniels: emersion: yep, merging now, thanks!
15:12emersion: pinchartl: alex deucher
15:13emersion: ah, daniel cc'ed him already
15:17pinchartl: emersion: I suspected so. thanks :-)
15:30danvet: emersion, not documenting plane type property is an oversight tbh
15:30danvet: not sure why I missed that
15:31danvet: emersion, I'd just whack it under this one https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#plane-composition-properties
15:32emersion: "composition" :P
15:32emersion: ok, will do
15:32danvet: "stuff remotely useful for compositors"
15:32danvet: tbh it's a nice dumping ground
15:32danvet: maybe rename it to "Standard Plane Properties"
15:32emersion: danvet: how much should we duplicate between the prop docs and the enum docs?
15:33emersion: yeah, maybe we should do that
15:33emersion: all plane props affect composition
15:34danvet: emersion, I thought for enum props we aim to only document the string, not the enume?
15:35danvet: so I say dupe it
15:35emersion: we just need to be careful to update both, if we touch either
15:35danvet: I think that's what we've generally done
15:35danvet: otherwise this becomes too painful for userspace peopel to read :-)
15:36emersion: maybe we should drop the internal kernel details from the props, and just add "Kernel developers, see enum drm_thing"
15:36danvet: at the bottom I tend to sprinkle the hints for driver developers, like which function this is set up with
15:36danvet: those can then link to more places
15:36danvet: like "This value is set when calling drm_universal_plane_init()"
15:36emersion: hm, yeah. iirc many props have a lot of internal kernel details
15:37emersion: we're also missing FB_DAMAGE_CLIPS from the list btw, i'll need to add that
15:37danvet: yeah, but should be fairly minimal
15:37danvet: nope that should be somewhere
15:37emersion: there's a whole section about it
15:38emersion: but it's just… there, not referenced from anywhere else
15:39danvet: yeah that's misplaced
15:39emersion: it's hard to Ctrl+F in the page as a user-space dev because of all of the kernel internals
15:39emersion: so i'd prefer to have it listed in "plane properties" too
15:40danvet: oh it's there, but the subheading level is too low to show it
15:41emersion: it's there, burried after a lot of kernel function docs
15:41danvet: emersion, what about moving the driver api doc to the right object heading further up (plane or crtc or whatever)
15:41danvet: and just leaving the overview section there?
15:42emersion: hm, sorry, i don't get it
15:43danvet: also I guess we really need a new overview for plane properties in general
15:43emersion: you mean moving the docs for e.g. drm_plane_create_blend_mode_property under "plane abstraction"?
15:43emersion: strong +1 for this
15:43danvet: lemma type up something
15:44danvet: https://paste.debian.net/1177136/ like this
15:44danvet: but for all of them
15:45emersion: yup, looks good!
15:45emersion: will do that
15:45danvet: maybe with better english or so
15:46danvet: emersion, also I think we should move IN_FORMATS out of the section in drm_blend.c
15:46danvet: and make a proper Standard Plane Properties section
15:46danvet: with that + type
15:46emersion: hm, so
15:46danvet: I think having all the blend related stuff in drm_blend.c feels good
15:47emersion: ok, got it
15:47danvet: but separate patch I guess
15:47emersion: yeah, will try to logically split that up
15:47emersion: lots of patches to write, eh
15:47danvet: also perhaps s/FB_DAMAGE_CLIPS/Damage Tracking/
15:47danvet: or so
15:48danvet: yelling headings is a bit much :-)
15:48emersion: yup, agreed
17:35jenatali: 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:39dcbaker[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:40dcbaker[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:41dcbaker[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:42sumits: 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:50sumits: ^^^ danvet, mlankhorst_, seanpaul, mripard, fyi please
17:53anholt: jenatali: I'd focus on just getting to warnins clean.
17:53jenatali: anholt: Sounds good, thanks
18:09dschuermann: 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:28dcbaker[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:38dschuermann: dcbaker[m]: where did you ping me? I must have overseen that. but thanks, I'll have a look
18:38dschuermann: when is the next point release?
18:39dcbaker[m]: right now
18:43dcbaker[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:44dschuermann: normally, I see these, not sure how it slipped. but feel free to write directly if that happens again :/
18:47dcbaker[m]: Okay, will do
18:51dschuermann: dcbaker[m]: thx for holding back the patch. please skip it for now, it needs some more investigation
18:52dcbaker[m]: No problem
18:54pendingchaos: dschuermann: I think the know the issue: https://pastebin.com/raw/Kins6hwW
18:54pendingchaos: "aco/spill: only prevent rematerializable ..." fixed this, but it isn't backported
18:56kisak: looks like it's also queued for 20.2 https://cgit.freedesktop.org/mesa/mesa/commit/?h=staging/20.2&id=02cd25463df74e17c799a29201028bc92fafe3f8
18:58pendingchaos: I think 20.2 will need either a revert or something like that diff then
19:01dcbaker[m]: sigh. I missed that and just released 20.2.5
19:02dcbaker[m]: do I need to revert that and make a 20.2.6?
19:03dcbaker[m]: 20.2.5 was the last planned 20.2 release
19:04dcbaker[m]: pendingchaos, kisak , dschuermann : ^
19:05ajax: why, in 2020, does anyone want gles1 compatibility
19:06dcbaker[m]: Are you really expecting sanity in 2020?
19:15mareko: dcbaker[m]: yes, I have backports locally, just need to send them out
19:15dcbaker[m]: mareko: awesome, thanks!
19:18ajax: dcbaker[m]: touché
19:18anarsoul: ajax: is it rhetorical question?
19:19ajax: not... entirely
19:19ajax: https://github.com/KhronosGroup/OpenGL-Registry/pull/451 and https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8113
19:21pendingchaos: dschuermann: these seem to be the two fossils which regressed in 20.2.5 because of the patch: https://pastebin.com/raw/S6mnmSt1
19:21pendingchaos: seems, in a release build, f12017 compilation doesn't crash (unlike uber_subgroup) but it probably miscompiles
19:26dcbaker[m]: dschuermann, pendingchaos: I pulled the other patch as well, and that gets fossil-db passing on 20.3
19:40pendingchaos: dschuermann: f12017's benchmark at ultra settings with 20.2.5 doesn't look obviously incorrect
19:42pendingchaos: also seems the rdr2 fossil crashes for polaris10 but not gfx1030
19:57pendingchaos: dschuermann: summary of fossil regressions: https://pastebin.com/raw/xdqqEUZ9
21:05dschuermann: 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:08dcbaker[m]: dschuermann: no worries, I should have noticed that anyway. Do you want me to revert that patch, or pull the fix?
21:08dschuermann: I think pulling the fix is the safer option
21:19dcbaker[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:33kisak: thanks dcbaker
21:34dcbaker[m]: https://gitlab.freedesktop.org/mesa/mesa/-/pipelines/245056, good to go?
21:39dschuermann: dcbaker[m]: yes, perfect and thanks alot :)
21:40dschuermann: radeonsi must be a flake or otherwise unrelated
21:40dcbaker[m]: otherwise unrelated
21:40dcbaker[m]: CI is rather a mess on 20.2, it's my fault
21:41dcbaker[m]: which is why I missed this in the first place on that branch
21:41dcbaker[m]: release in process
21:41dcbaker[m]: thanks all
22:35danvet: agd5f, accidentally read some code and stumbled over c920888c604d7
22:35danvet: it's behind #ifdef DEBUG_FS, but that's still uapi
22:36danvet: can you pls move this into debugfs before we ship this?
22:42danvet: also typed some mail
22:43danvet: ended up a bit a sermon, but I figured maybe some people didn't know so better to type it all up
22:45agd5f: danvet, if you want to revert that one and the documentation fix for it, Acked-by: me
22:45agd5f: sorry I missed that
22:45danvet: agd5f, dont worry, stuff slips through
22:46danvet: and it's already in Linus' tree, so no need to rush imo
22:46danvet: imo revert or move to debugfs is all fine
22:46danvet: best case some igt discussion with a standard debugfs, but really not required
22:47danvet: I guess in a way kms properties are massive success, way to easy to quickly add more uapi :-)
22:51danvet: 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:52danvet: I mean beyond the usual people who hang our here anyway
23:32anholt: robclark: sweet. allocating threads for the slow cores too is cutting a630-gles3 from 6.5 to ~5 minutes.
23:34robclark: I wonder if deqp-runner should be big/little aware and adjust the sizes of chunks of tests :-P
23:34anholt: 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:35anholt: (I don't think rayon pins its threads, but maybe I'm wrong)
23:35robclark: yeah, probably
23:35anholt: actually, it wouldn't I don't think, since I'm making a 9 thread pool in this case for 8 cpus.
23:52anholt: 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:52anholt: 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:55robclark: yeah, it would be nice if there was indirection/abstraction between test cases and runners
23:56robclark: maybe for bonus points, keep track of how long different groups of tests take to run on average and auto load-balance
23:56anholt: this doesn't feel that hard inside deqp-runner. hardest bit is probably deciding on a file format for describing the test sets
23:56dcbaker[m]: machine <-> machine? json all the way
23:56anholt: dcbaker[m]: human to machine
23:56robclark: 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:56dcbaker[m]: oh, not json then :)
23:57anholt: aka not .gitlab-ci/bare-metal/arm64_a630_gles_others.sh
23:57dcbaker[m]: yaml or toml are my preferences for human consumable
23:58ajax: no but seriously nvidia's driver exposes a GLES1 compatibility extension in a core context
23:58ajax: i have _so_ many questions
23:58anholt: 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:59robclark: ajax: lol
23:59ajax: like... you can use the matrix stack, but only if you use fixed-point? and you _wanted_ this?