06:34 himal: Hi all, Need your opinion on removing __must_check in drmm_add_action_or_reset return. Sometimes caller might only want warning message and action cleanup if drmm_add_action_or_reset fails with no real use of return handling
07:33 MrCooper: DavidHeidelberg: what is that 5% number based on? I didn't notice any significant change, didn't really do a lot of measurements though
07:34 MrCooper: DavidHeidelberg: it's hard to come up with a plan because nobody has any clue what the issue might be, the problems appear essentially random
07:34 DavidHeidelberg: MrCooper: I'll be honest, it's pulled out of my ...., but in general what is guaranteed is smaller size and the perf can vary from 0-15% in general
07:35 MrCooper: like, I was running with LTO enabled on all my machines for at least about a year without any issues, but when we tried enabling it in the Fedora build, it immediately broke radeonsi
07:35 MrCooper: DavidHeidelberg: actually for me LTO binaries were bigger IIRC
07:36 MrCooper: might depend on compiler flags though
07:36 DavidHeidelberg: MrCooper: hmm, that is kinda against what LTO do, maybe some IPO got engaged and optimized something better for perf instead of size..
07:38 DavidHeidelberg: just recently enabled LTO for minetest and got 15% (client) and 19% (server) size down
07:39 DavidHeidelberg: MrCooper: for the perf, have you tried some intensive parallel deqp? in normal GL/VK workload it'll be probably not impactful, but on restrained CPU it may show up
07:39 MrCooper: nope
07:39 DavidHeidelberg: *constrained
07:40 MrCooper: I normally run the test suites only once per Mesa build, so LTO most certainly adds more build time than it could save at runtime
07:40 DavidHeidelberg: MrCooper: what do you think about idea like this: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28684 ?
07:42 MrCooper: there should be some LTO build job in pre-merge CI, or it'll just break
07:44 DavidHeidelberg: MrCooper: in general it's usually easy to fix and what I'm not sure if it justify the extra +- 2 min of linking (which can be more when CI is loaded)
09:36 mupuf: DavidHeidelberg: Would be good to know if LTO has an impact on test execution speed though
09:37 mupuf: oh, I see your comment now
12:57 demarchi: sima: https://gitlab.freedesktop.org/demarchi/maintainer-tools/-/jobs/57497721
12:57 demarchi: #4 1.088 Fedora 28 - x86_64 - Updates 127 MB/s | 30 MB 00:00
12:57 demarchi: #4 9.709 Fedora 28 - x86_64 43 MB/s | 60 MB 00:01
12:58 demarchi: still using fedora 28. From the .gitlab-ci.yml:
12:58 demarchi: image: $CI_REGISTRY/$CI_PROJECT_PATH/dim-fedora:latest
12:58 sima: yeah we should probably switch over to fdo ci templates
12:58 demarchi: do we have a more recent image?
12:58 demarchi: how to updat?E
12:58 sima: I think manually run the image stage or something
12:58 sima: and pray
12:59 demarchi: hum... I'm not sure where that is maintained though
12:59 sima: demarchi, I think if you run the image stage in your own fork it won't impact the main one
12:59 demarchi: - docker build -t $CI_REGISTRY/$CI_PROJECT_PATH/dim-fedora -f Dockerfile.fedora .
13:00 demarchi: ohh... now I see. Should have searched for that file
13:00 sima: there's some gitlab ui magic to kick off the optional stages
13:01 demarchi: Dockerfile.fedora.... hum. Maybe it all work if I just change that file ?
13:01 demarchi: only:
13:01 demarchi: changes:
13:01 demarchi: - Dockerfile.fedora
13:01 demarchi: - .gitlab-ci.yml
13:01 sima: yeah I think we've changed it
13:02 sima: or maybe igt originally was an optional stage you could click
13:02 demarchi: I will try that, thanks
13:03 sima: hm seems to have been like this from the start, but maybe review changed it
13:03 sima: it's like 6 years ago, memory kinda unreliable :-)
13:13 demarchi: yesterday I wanted to get my -fixes pull request done and decided to check a few things dim... end result: 3+ MRs to dim, and -fixes not sent
13:14 demarchi: at least the MRs are out now... let me prep the fixes pull
13:14 demarchi: mripard: you may want to take a look at https://gitlab.freedesktop.org/drm/maintainer-tools/-/merge_requests/49 since the move of drm-tip to gitlab changed the default remote name for new setups
14:32 demarchi: sima: not sure if it's intended, but apparently it also pushes from the MR
14:32 demarchi: sima: https://gitlab.freedesktop.org/drm/maintainer-tools/-/jobs/57501627
14:32 demarchi: 972ae0c080f8: Pushed
14:32 demarchi: I'd expect the final push to be skipped and only really done when merged to master. But... well, it worked :)
14:45 demarchi: it fails later in the check part though as it can't find the image
14:58 sima: demarchi, it should push to the container registry for your fork
14:59 sima: and also get it from there again ...
15:04 daniels: now it fails for other reasons https://gitlab.freedesktop.org/drm/maintainer-tools/-/jobs/57504607
15:04 daniels: the first two were ephemeral - don’t use mutable tags, and also just use fd.o ci-templates already
15:37 demarchi: daniels: I was refering to https://gitlab.freedesktop.org/drm/maintainer-tools/-/jobs/57503229
15:37 demarchi: ERROR: Job failed (system failure): Error response from daemon: no such image: docker.io/library/sha256:142d45726fe9d3931e5f98959f90050d8cdfdff58f1253588674fa1fc3a84b55: image not known (docker.go:570:0s)
15:38 daniels: I know, that’s the ephemeral failure I’m referring to, which is likely caused by mutable tags, which doesn’t happen if it uses ci-templates like it should
15:39 demarchi: daniels: like in igt?
15:39 demarchi: image: $CI_REGISTRY/$CI_PROJECT_PATH/build-fedora:commit-$CI_COMMIT_SHA
15:41 daniels: yeah
15:42 demarchi: ok, lemme try
16:52 vsyrjala: why is drm_color_ctm_3x4 (seems to be some amdgpu private uapi) in uapi/drm_mode.h?
19:07 demarchi: daniels: any idea what's the error showing up now in https://gitlab.freedesktop.org/demarchi/maintainer-tools/-/jobs/57513128 ?
20:38 daniels: demarchi: using docker to build images isn’t supported
22:11 demarchi: it seems using the one from igt as example wasn't a good idea
22:12 demarchi: daniels: I went to read the docs at https://gitlab.freedesktop.org/freedesktop/ci-templates/-/blob/master/doc/templates.rst?ref_type=heads and used that instead
22:13 demarchi: it's now passing
23:57 bwidawsk: It appears when you lease objects, their state is reset. I had hoped to take over objects with their state in tact. Assuming this is by design, is there any way to lease while preserving state?