04:45 kode54: elongbug: what exactly is the example case for that patch set, anyway?
05:12 AndrewR: Hm, I was looking at https://www.x.org/wiki/Development/X12/ and noticed link to "Why X Is Not Our Ideal Window System" pdf 404-ed ..
05:12 AndrewR: but I think same pdf still alive here: https://www.talisman.org/~erlkonig/misc/
09:56 MayeulC: Since I upgraded my kernel to 6.1 (Arch Rolling), my second display (connected through DP MST) stopped working (it works until kernel modesetting kicks in). I got an amdgpu call trace that ends up in dc_link_allocate_mst_payload, where should I post it? (Fiji pro/R9 Fury).
09:58 MayeulC: Actually looks similar to https://gitlab.freedesktop.org/drm/amd/-/issues/2171 and https://bugs.archlinux.org/task/76934
10:23 danvet: PSA drm-next is now at -rc2, in case anyone needs a backmerge or something
10:23 danvet: probably will wait until -rc3 for merging pulls so we can ff to -rc3 because -rc2 really doesn't have a lot of fixes yet
10:27 tzimmermann: danvet, thanks. i'll send out the main drm-misc-next PR soonish. IIRC conflict resolution happens in drm-next?
10:32 danvet: tzimmermann, yeah, usually
10:32 danvet: and since it's all in drm-tip we should have the example resolution already
11:46 digetx: danvet: when drm-fixes will be at rc2/3?
12:12 danvet: digetx, it's at -rc2 now
12:12 danvet: just pushed it 1h ago or so
12:18 digetx: indeed, I was looking at the github mirror, thanks!
14:36 digetx: danvet: although no, it's 6.1-rc8 https://cgit.freedesktop.org/drm/drm-misc/tree/Makefile?h=drm-misc-fixes
14:36 digetx: am I missing something?
14:39 digetx: ah
14:40 digetx: seems I should use drm-misc-next-fixes for the 6.2-rc fixes, not drm-fixes
15:07 alyssa: robclark: anholt: dschuermann_: Venemo: How do we feel about enforcing clang-format?
15:07 alyssa: (over the parts of Mesa that are clang-formatted -- radv/aco, freedreno/turnip/ir3, panfrost and asahi)
15:08 alyssa: DavidHeidelberg[m]: and I are discussing the possible implementations of this, namely a git pre-commit hook to reformat and/or the clang-format linter to run in the sanity stage of the CI pipeline, preferably both
15:11 alyssa: The salient point for me is making sure contributors can stop thinking about code styling
15:11 alyssa: clang-format/rustfmt are a piece in that puzzle but not there all the way
15:12 alyssa: (certainly for me I'm finding "format on save" to be awesome for this)
15:12 alyssa: The earlier that formatting happens and the less manual intervention needed, the better
15:13 DavidHeidelberg[m]: I love these IDE which can do formatting as you go, but... pre-commit seems to be reasonable compromise :P
15:13 alyssa: autoformatting > lint, running on developer machines locally > running in CI, configuration in mesa git itself > sideband instructions explaining how to setup
15:13 alyssa: IMO
15:14 DavidHeidelberg[m]: (not talking about pre-commit as a bloated piece of software, talking about it as a pure git hook)
15:14 alyssa: DavidHeidelberg[m]: Heh, yeah. I tried formatting on InsertLeave which was magical and also annoying :-p
15:15 alyssa: format on save is the sweetspot for me, but we can't (and shouldn't) control people's editors
15:16 alyssa: the taxonomy I give above suggests that "autoformat in a git pre-commit hook, lint in CI in the sanity* stage" is maybe the way to go
15:16 DavidHeidelberg[m]: ^
15:16 alyssa: where that will Do Approximately The Right Thing for devs as long as they have the right version of clang-format installed
15:16 alyssa: and if people want formatting to happen earlier they can setup their editors/IDEs as desired
15:18 alyssa: * if this is feasible. I am unsure how expensive (in CPU time) it is to clang-format lint a properly formatted file/diff. If we have the clang-format hook I'd rather skip the lint (or push it to the build side instead of sanity) if the alternative would appreciably increase the CI bill
15:22 robclark: alyssa: clang-format makes a mess of things 5% of the time, which is annoying enough to say nak..
15:44 Frogging101: What about if you can place a comment like /* clang-format off */
15:45 Frogging101: But yes, occasionally I find something more readable but clang-format says "no"
16:06 Venemo: alyssa: we would like to, just nobody knew how to
16:07 Venemo: alyssa: also would be nice to get rid of trailing whitespace and enforce that
16:07 Venemo: I think these could be added to the sanity check in the CI, but nobody from our CI team knows how to do it, so it must be very complicated
16:08 tleydxdy: doesn't git already have a way to detect/fix trailing whitespace?
16:09 Wallbraker: We have clang-format in a pre-merge CI step in Monado, the node setup time for that step utterly completely dwarfs the execution time for clang-format.
16:11 Wallbraker: https://gitlab.freedesktop.org/monado/monado/-/jobs/34035564
16:11 Wallbraker: We also codespell and automatically format our cmake files.
16:13 Frogging101: also have to stop it from messing up tables
16:13 Wallbraker: As mentioned above, you can start and stop it.
16:13 Frogging101: maybe with /* clang-format off */
16:14 Frogging101: yeah
16:14 robclark: Frogging101: yeah, if you used clang-format from the beginning with new code, that would be an option.. but at this point it would be a pain to retrofit and on the long list of things I care about, that isn't one ;-)
16:15 Wallbraker: Cared enough to NACK it
16:15 Frogging101: I assume that whomever flips the switch would be responsible for that, not you
16:15 Frogging101: I'm not strongly in favour or against though.
16:16 robclark: Wallbraker: well the alternative creates more headache ;-)
16:16 tleydxdy: one can always hand format things better, but that one would need to hand format every single commit
16:19 robclark: I look at clang-format as just a rough guideline.. maybe with enough effort it could be made/configured better or whatever.. but that is time better spent IMHO
16:19 Wallbraker: It's honestly not that bad, and really makes it easier to code. Just being able to faceroll the keyboard to get the code out and then let clang-format make it pretty is a really nice thing
16:20 Frogging101: One can run clang-format themselves, too
16:20 Frogging101: I think the contributor's guide recommends this
16:20 Wallbraker: Also as a new person going into a project having clang-format makes it so you can skip the whole "this isn't formatted correctly" step of the review process. If clang-format agrees then it's good to go.
16:21 Wallbraker: And you can don't have to learn the style, just press a button and it's correct.
16:21 Wallbraker: Why do a computers job 100%, rather then just 95% of the time. :p
16:23 tleydxdy: > One can run clang-format themselves, too
16:23 tleydxdy: the issue I run into with this is it'll format other parts of the code where the commitor did not use clang-format
16:23 Wallbraker: Frogging101: Unfortunately not, as there is a big risk that you will change unrelated things.
16:23 Frogging101: There was some simple construction I ran that restricted it to only the files I had changed
16:24 Wallbraker: git clang-format will do that, most of the time. Always a chance that things leak.
16:24 Frogging101: oh, yeah
16:24 tleydxdy: presumably one file have multiple comittors
16:25 Wallbraker: Not sure how it deals with say you changing a line in a multi-line function call, if that will format the whole call or just that line.
17:39 RhineDevil: Hello, I have an AMD kabini APU with a Radeon HD 8210, would like to know, is it theorically possible to support hevc and 1920x1032 yuv420p10 video streams through vaapi?
17:42 alyssa: robclark: fair enough... for the code I wrote, other than static tables clang-format generally did the right thing, or at least got close enough I didn't care because the not thinking about formatting was more imporrtant
17:42 alyssa: but yeah
17:43 alyssa: robclark: oh... for panfrost/asahi, we're now 100% clang-formatted (.. it wasn't that hard), I assumed since freedreno had .clang-format files in tree it was the same
17:44 alyssa: Wallbraker: Interesting anecdote about the node setup time ... I mean, that's part of the cost too if we're currently not triggering any jobs for the sanity pipeline
17:45 alyssa: tleydxdy: re "formatting other parts of the code" when using it ... yes, that's why I bit the bullet and clang-formatted my subtrees entirely in one go
17:46 alyssa: Wallbraker: Frogging101: FWIW my assumption is that any of the above is restricted to the folders that are actually 100% clang-formatted
17:46 alyssa: src/panfrost, src/asahi, maybe src/amd?, and I thought src/freedreno but I guess not actually
17:46 Frogging101: right
17:46 alyssa: and in those parts, if you rerun clang-format for the whole dir it'll DTRT, just less efficiently than git clang-format would
18:05 Ristovski: RhineDevil: From what I can find, Kabini does not support HEVC, only MPEG2/4 and AVC/VC1
18:07 Ristovski: RhineDevil: https://www.x.org/wiki/RadeonFeature/#radeonuvdunifiedvideodecoderhardware
18:14 RhineDevil: Ristovski: which one is mine?
18:15 Ristovski: RhineDevil: I assume "KABINI"
18:15 Ristovski: so UVD4.2
18:57 sravn: javierm: You almost got me on the last patch in the "use existing DSI write macros" series :-)
19:01 javierm: sravn: oh, the last one is buggy? I guess my sed fu failed me then :)
19:03 javierm: sravn: I read the email now
19:04 javierm: sravn: ohhhh, the driver macro was a tricky one!
19:04 sravn: javierm: I will be good to clean up the mix of generic and dcs in this driver.
19:04 sravn: I verified the others - this was the only one
19:05 javierm: sravn: absolutely agreed. Thanks for looking, I did a sed -i but missed that discrepancy in that driver
19:09 javierm: sravn: btw, I noticed this when upstreaming the panel driver for the PinePhone Pro
19:10 javierm: there seems to be a lot of copy&paste for panel drivers, so there's still a lot of room for further consolidation and moving common code to helpers
19:13 sravn: javierm: There is even a script in the wild that generate the body of a panel driver. So for someone motivated there are possibilities.
19:14 javierm: sravn: I see. Was thinking something like the regulator framework that it's mostly data driven when registering the regulators, to avoid having boilerplate code
19:27 anholt_: alyssa: I am a huge fan of automatic, enforced formatting. Sometimes the code is uglier than handcrafted, but it means never negotiating over whitespace.
19:55 Venemo: Wallbraker, Frogging101 you can use 'git clang-format' which will only format the changes you made and leaves the rest of the code as it was. I use that with RADV and ACO
19:55 Frogging101: Ah, so it's fine than file-level granularity
19:55 Frogging101: finer*
19:56 Venemo: RhineDevil: better ask that in #radeon
19:57 Venemo: Frogging101: yes, it only formats the lines you added
19:57 Frogging101: yeah, that makes sense
19:57 bnieuwenhuizen: Venemo: I thought the concern wrt clang-format was what happens with different clang-format versions, not difficulty about adding it to CI?
19:58 Venemo: bnieuwenhuizen: it was a long time ago when the version of clang-format carried in slower distros lacked some features, but even back then it was a moot point because none of the team used those distros
19:59 Venemo: bnieuwenhuizen: last we spoke of it, mupuf said it is a difficult task and would take a lot of time, so I stopped bothering this topix
20:02 Venemo: maybe it would be easier now?
20:02 bnieuwenhuizen: maybe if the difficulty was the clang-format in debian on the CI being too old I guess it would be easier now
20:02 Venemo: either way I'd prefer to enforce clang-format on the parts of mesa which do have a .clang-format file
20:03 Venemo: if some maintainers don't want it, that's fine, but I think we want it for RADV and ACO
20:05 mupuf: The only difficulty here is social, not code.
20:06 mupuf: Alyssa just landed a mandatory clang format check a couple of weeks ago, and so did rusticl... so it seems like it should be easier now
20:07 bnieuwenhuizen: wait, I thought this discussion was kicked off by Alyssa about adding one
20:07 Frogging101: This discussion happened several months ago too
20:08 bnieuwenhuizen: if it already landed we should just copy/extend it :)
20:10 Frogging101: The point(s) in favour are uniformity and contributors not having to do it themselves. The point(s) against are that sometimes it makes changes that are not improvements, or are detriments.
20:10 Frogging101: as I understand it
20:13 Frogging101: Personally, I'm fine with just running it myself and taking or leaving its changes. But, I don't write/maintain/review a large amount of code
20:16 mupuf: Sorry, going to bed now. I'll check tomorrow :)
20:22 Frogging101: I recall that last time I used it, it made some of my code less readable. So I fixed the code in a way that made both me and clang-format happy.
20:25 Frogging101: IIRC it put some things back together which I had deliberately separated with a line break because they were logically distinct operations
20:26 Frogging101: The operation had to be broken up somewhere to fit on a line, and I chose a good splitting point. clang-format disagreed
20:27 Frogging101: I might have been irritated if it messed it up post-merge.
20:29 sravn: javierm: I have never worked with regulators, but I am sure we can do better than today.
20:37 LaserEyess: is mesa 23 required for RDNA support?
20:37 LaserEyess: uhh, RDNA3*
20:39 Venemo: LaserEyess: the very latest stable should work, let us know if you have issues with it
20:39 Venemo: Frogging101: we don't need to debate it, the teams who don't want it, should be allowed to not have it. but we want to have it in radv and aco
20:40 Venemo: the point of clang-format IMO is that we finally stop having stupid arguments about code style on merge requests
20:41 LaserEyess: Venemo: I am having issues, specifically "'gfx1100' is not a recognized procesor for this target" and "amd: LLVM doesn't support gfx1100, bailing out"
20:41 LaserEyess: brand new 7900XT
20:42 LaserEyess: mesa 22.3.2
20:43 javierm: sravn: yep. Thanks for your review!
20:49 DavidHeidelberg[m]: Venemo: exactly, I hate bugging people to adjust code formatting when they can do more useful stuff instead
20:49 LaserEyess: gpu seems to be recognized by DRM, and probing works at least when I try to start my wayland compositor
20:49 LaserEyess: but mesa (I assume?) is throwing errors about the GPU being unsupported, or llvm is, idk
20:50 LaserEyess: llvm 14.0.6, maybe that's not new enough?
20:52 pendingchaos: I think you need llvm 15+
20:55 LaserEyess: fantastic
20:57 Venemo: LaserEyess: that is a LLVM problem not a mesa problem
20:57 LaserEyess: so I have discovered
20:58 Venemo: this sort of problem is part of the reason why we made ACO
22:06 danvet: digetx, oh you meant drm-misc-fixes
22:07 danvet: that's for mripard to roll forward I think?
22:07 danvet: since we're after the merge window, you should use drm-misc-fixes for fixes now
22:07 danvet: see https://drm.pages.freedesktop.org/maintainer-tools/committer-drm-misc.html#where-do-i-apply-my-patch
22:08 danvet: occasionally it takes drm-misc maintainers some time to do the rolling
23:23 karolherbst: hum...
23:23 karolherbst: when did we do this weird render node renumbering thing on the kernel side?
23:23 karolherbst: where like nouveau could end up being card0 + renderD128 instead of 1/129?
23:23 karolherbst: I think it kills chromium perf
23:23 karolherbst: soo...
23:23 karolherbst: here is the thing
23:23 karolherbst: if I build wiht intel+nouveau chromium takes like 100% of the GPU and has massive FPS drops
23:24 karolherbst: if I build with only intel, everything is fine 🙃
23:24 karolherbst: and I suspect that chromiums DRM loader is totally bonkers anyway
23:29 DavidHeidelberg[m]: :D
23:30 bnieuwenhuizen: karolherbst: what is weird about it? card0/renderD128 for a first device and card1/renderD129 has been how we've done it for ages, no?
23:31 bnieuwenhuizen: card1/renderD129 for a second device*
23:31 karolherbst: no
23:31 karolherbst: yes
23:31 karolherbst: but no
23:31 karolherbst: today it's like random
23:31 karolherbst: in the past (tm) we were quite determinstic about iGPU being 0
23:31 bnieuwenhuizen: oh yeah, who gets 0 and who gets 1 is based on just racing on who adds their device first
23:31 karolherbst: _something_ changed and now things are just random
23:31 karolherbst: yeah sure
23:32 karolherbst: but
23:32 karolherbst: the point is, in the past it was almost always the iGPU being 0
23:32 karolherbst: like.. I never ever see it not happening, but that changed sometime last year
23:32 bnieuwenhuizen: eh. that is luck I think? Does drm even have an idea which devices are iGPUs
23:33 karolherbst: nope
23:33 karolherbst: it's just how things rolled
23:33 karolherbst: maybe i915 got some code and loads way slower now.. no idea
23:34 karolherbst: point is: before 2022 I never ever see i915 not claiming card0 on any system
23:35 bnieuwenhuizen: well, as I said, it is a race so can be anything in what triggers drivers to initialize guess?
23:36 bnieuwenhuizen: or just driver init time
23:37 karolherbst: sure
23:37 karolherbst: but my point is.. application relied on card0 being iGPU, becuase that was in like 99.99% the cases true
23:38 karolherbst: and also chromium is just dumb here
23:38 bnieuwenhuizen: ehh, I'd bet it was just barely tested in a system with multiple GPUs
23:38 bnieuwenhuizen: but sigh :|
23:38 karolherbst: laptops?
23:38 karolherbst: I'd be surprised if that's not a test target
23:39 bnieuwenhuizen: well, no chromebooks with dGPUs so ...
23:39 karolherbst: mhh.. I think there was a way to trickc hromium...
23:40 karolherbst: anyway..
23:40 karolherbst: it worked fine in the past
23:42 bnieuwenhuizen: FWIW I think with A+A it shouldn't have been working, as amdgpu tends (in my experience) to register in order PCI bus id, which leaves it up to the system ... (and e.g. on my Zen4 system the iGPU comes last)
23:42 karolherbst: yeah.. so there were users with that issue as well
23:43 bnieuwenhuizen: and for vulkan we strongly worked around this (+ the fact the loader also has no clue) by having a Vulkan layer in mesa that reorders devices to always put the windowing system devices at the first spot of the list
23:44 bnieuwenhuizen: but I guess applications directly talking to drm exposed themselves to a mess yeah ...
23:44 karolherbst: yeah...
23:46 bnieuwenhuizen: karolherbst: do you have a link/short description of what Chrome does and what issues it causes?
23:46 karolherbst: it causes high GPU load