camus has quit [Remote host closed the connection]
elongbug has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
camus has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
Company has quit [Quit: Leaving]
bmodem has joined #dri-devel
sgruszka has joined #dri-devel
bmodem1 has quit [Ping timeout: 480 seconds]
danvet has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
kerneltoast has joined #dri-devel
illwieckz has quit [Ping timeout: 480 seconds]
illwieckz has joined #dri-devel
tzimmermann has joined #dri-devel
illwieckz has quit [Ping timeout: 480 seconds]
jkrzyszt has joined #dri-devel
srslypascal has quit [Ping timeout: 480 seconds]
srslypascal has joined #dri-devel
illwieckz has joined #dri-devel
jernej has quit [Remote host closed the connection]
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
Jeremy_Rand_Talos_ has joined #dri-devel
jernej has joined #dri-devel
jernej has quit [Remote host closed the connection]
agd5f has quit [Ping timeout: 480 seconds]
rmckeever has quit [Quit: Leaving]
jernej has joined #dri-devel
dviola has joined #dri-devel
fab has joined #dri-devel
rasterman has joined #dri-devel
fab has quit []
fab has joined #dri-devel
Lucretia has quit [Read error: No route to host]
Lucretia has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
srslypascal has quit [Read error: No route to host]
srslypascal has joined #dri-devel
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #dri-devel
bmodem1 has joined #dri-devel
fab has quit [Ping timeout: 480 seconds]
bmodem has quit [Ping timeout: 480 seconds]
elongbug_ has quit []
elongbug_ has joined #dri-devel
rszwicht has joined #dri-devel
<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).
<digetx>
seems I should use drm-misc-next-fixes for the 6.2-rc fixes, not drm-fixes
bbrezillon has joined #dri-devel
devilhorns has quit [Remote host closed the connection]
devilhorns has joined #dri-devel
ppascher has quit [Quit: Gateway shutdown]
ppascher has joined #dri-devel
alyssa has joined #dri-devel
<alyssa>
robclark: anholt: dschuermann_: Venemo: How do we feel about enforcing clang-format?
<alyssa>
(over the parts of Mesa that are clang-formatted -- radv/aco, freedreno/turnip/ir3, panfrost and asahi)
<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
<alyssa>
The salient point for me is making sure contributors can stop thinking about code styling
<alyssa>
clang-format/rustfmt are a piece in that puzzle but not there all the way
<alyssa>
(certainly for me I'm finding "format on save" to be awesome for this)
<alyssa>
The earlier that formatting happens and the less manual intervention needed, the better
<DavidHeidelberg[m]>
I love these IDE which can do formatting as you go, but... pre-commit seems to be reasonable compromise :P
<alyssa>
autoformatting > lint, running on developer machines locally > running in CI, configuration in mesa git itself > sideband instructions explaining how to setup
<alyssa>
IMO
<DavidHeidelberg[m]>
(not talking about pre-commit as a bloated piece of software, talking about it as a pure git hook)
<alyssa>
DavidHeidelberg[m]: Heh, yeah. I tried formatting on InsertLeave which was magical and also annoying :-p
<alyssa>
format on save is the sweetspot for me, but we can't (and shouldn't) control people's editors
agd5f has joined #dri-devel
<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
<DavidHeidelberg[m]>
^
<alyssa>
where that will Do Approximately The Right Thing for devs as long as they have the right version of clang-format installed
<alyssa>
and if people want formatting to happen earlier they can setup their editors/IDEs as desired
<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
<robclark>
alyssa: clang-format makes a mess of things 5% of the time, which is annoying enough to say nak..
jkrzyszt has joined #dri-devel
<Frogging101>
What about if you can place a comment like /* clang-format off */
<Frogging101>
But yes, occasionally I find something more readable but clang-format says "no"
<Venemo>
alyssa: we would like to, just nobody knew how to
<Venemo>
alyssa: also would be nice to get rid of trailing whitespace and enforce that
<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
<tleydxdy>
doesn't git already have a way to detect/fix trailing whitespace?
<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.
<Wallbraker>
We also codespell and automatically format our cmake files.
<Frogging101>
also have to stop it from messing up tables
<Wallbraker>
As mentioned above, you can start and stop it.
<Frogging101>
maybe with /* clang-format off */
<Frogging101>
yeah
<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 ;-)
<Wallbraker>
Cared enough to NACK it
<Frogging101>
I assume that whomever flips the switch would be responsible for that, not you
<Frogging101>
I'm not strongly in favour or against though.
<robclark>
Wallbraker: well the alternative creates more headache ;-)
<tleydxdy>
one can always hand format things better, but that one would need to hand format every single commit
Haaninjo has joined #dri-devel
<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
<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
<Frogging101>
One can run clang-format themselves, too
<Frogging101>
I think the contributor's guide recommends this
<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.
<Wallbraker>
And you can don't have to learn the style, just press a button and it's correct.
<Wallbraker>
Why do a computers job 100%, rather then just 95% of the time. :p
<tleydxdy>
> One can run clang-format themselves, too
<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
<Wallbraker>
Frogging101: Unfortunately not, as there is a big risk that you will change unrelated things.
<Frogging101>
There was some simple construction I ran that restricted it to only the files I had changed
<Wallbraker>
git clang-format will do that, most of the time. Always a chance that things leak.
<Frogging101>
oh, yeah
<tleydxdy>
presumably one file have multiple comittors
<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.
camus1 has joined #dri-devel
pixelcluster_ has quit []
pixelcluster has joined #dri-devel
epoll has quit [Ping timeout: 480 seconds]
camus has quit [Ping timeout: 480 seconds]
epoll has joined #dri-devel
kts has joined #dri-devel
nehsou^ has quit [Remote host closed the connection]
devilhorns has quit []
RhineDevil has joined #dri-devel
cphealy has joined #dri-devel
jkrzyszt has quit [Remote host closed the connection]
<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?
gouchi has joined #dri-devel
<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
<alyssa>
but yeah
sgruszka has quit [Remote host closed the connection]
<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
<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
<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
<alyssa>
Wallbraker: Frogging101: FWIW my assumption is that any of the above is restricted to the folders that are actually 100% clang-formatted
<alyssa>
src/panfrost, src/asahi, maybe src/amd?, and I thought src/freedreno but I guess not actually
<Frogging101>
right
<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
jkrzyszt has quit [Remote host closed the connection]
<RhineDevil>
Ristovski: which one is mine?
<Ristovski>
RhineDevil: I assume "KABINI"
<Ristovski>
so UVD4.2
kts has quit [Quit: Leaving]
tzimmermann has quit [Quit: Leaving]
kimbro has joined #dri-devel
freemint has joined #dri-devel
kts has joined #dri-devel
anholt_ has joined #dri-devel
freemint has quit [Ping timeout: 480 seconds]
anholt has quit [Ping timeout: 480 seconds]
freemint has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
kimbro has quit [Ping timeout: 480 seconds]
freemint has quit [Remote host closed the connection]
freemint has joined #dri-devel
<sravn>
javierm: You almost got me on the last patch in the "use existing DSI write macros" series :-)
jolan has quit [Quit: leaving]
<javierm>
sravn: oh, the last one is buggy? I guess my sed fu failed me then :)
<javierm>
sravn: I read the email now
jolan has joined #dri-devel
<javierm>
sravn: ohhhh, the driver macro was a tricky one!
<sravn>
javierm: I will be good to clean up the mix of generic and dcs in this driver.
<sravn>
I verified the others - this was the only one
<javierm>
sravn: absolutely agreed. Thanks for looking, I did a sed -i but missed that discrepancy in that driver
<javierm>
sravn: btw, I noticed this when upstreaming the panel driver for the PinePhone Pro
<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
<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.
heat has joined #dri-devel
<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
kts has quit [Quit: Leaving]
freemint has quit [Ping timeout: 480 seconds]
lemonzest has quit [Quit: WeeChat 3.6]
karolherbst has quit [Quit: Konversation terminated!]
zaratustra has quit [Ping timeout: 480 seconds]
<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.
karolherbst has joined #dri-devel
zaratustra has joined #dri-devel
everfree has joined #dri-devel
anholt_ has quit [Remote host closed the connection]
freemint has joined #dri-devel
<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
<Frogging101>
Ah, so it's fine than file-level granularity
<Frogging101>
finer*
<Venemo>
RhineDevil: better ask that in #radeon
<Venemo>
Frogging101: yes, it only formats the lines you added
<Frogging101>
yeah, that makes sense
<bnieuwenhuizen>
Venemo: I thought the concern wrt clang-format was what happens with different clang-format versions, not difficulty about adding it to CI?
<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
anholt has joined #dri-devel
<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
<Venemo>
maybe it would be easier now?
<bnieuwenhuizen>
maybe if the difficulty was the clang-format in debian on the CI being too old I guess it would be easier now
<Venemo>
either way I'd prefer to enforce clang-format on the parts of mesa which do have a .clang-format file
<Venemo>
if some maintainers don't want it, that's fine, but I think we want it for RADV and ACO
<mupuf>
The only difficulty here is social, not code.
<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
<bnieuwenhuizen>
wait, I thought this discussion was kicked off by Alyssa about adding one
freemint has quit [Remote host closed the connection]
<Frogging101>
This discussion happened several months ago too
<bnieuwenhuizen>
if it already landed we should just copy/extend it :)
freemint has joined #dri-devel
<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.
<Frogging101>
as I understand it
<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
<mupuf>
Sorry, going to bed now. I'll check tomorrow :)
<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.
nehsou^ has joined #dri-devel
<Frogging101>
IIRC it put some things back together which I had deliberately separated with a line break because they were logically distinct operations
<Frogging101>
The operation had to be broken up somewhere to fit on a line, and I chose a good splitting point. clang-format disagreed
<Frogging101>
I might have been irritated if it messed it up post-merge.
<sravn>
javierm: I have never worked with regulators, but I am sure we can do better than today.
freemint has quit [Remote host closed the connection]
kimbro has joined #dri-devel
rszwicht has quit []
<LaserEyess>
is mesa 23 required for RDNA support?
<LaserEyess>
uhh, RDNA3*
freemint has joined #dri-devel
<Venemo>
LaserEyess: the very latest stable should work, let us know if you have issues with it
<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
<Venemo>
the point of clang-format IMO is that we finally stop having stupid arguments about code style on merge requests
<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"
<LaserEyess>
brand new 7900XT
<LaserEyess>
mesa 22.3.2
<javierm>
sravn: yep. Thanks for your review!
<DavidHeidelberg[m]>
Venemo: exactly, I hate bugging people to adjust code formatting when they can do more useful stuff instead
<LaserEyess>
gpu seems to be recognized by DRM, and probing works at least when I try to start my wayland compositor
<LaserEyess>
but mesa (I assume?) is throwing errors about the GPU being unsupported, or llvm is, idk
<LaserEyess>
llvm 14.0.6, maybe that's not new enough?
<pendingchaos>
I think you need llvm 15+
Haaninjo has quit [Quit: Ex-Chat]
<LaserEyess>
fantastic
<Venemo>
LaserEyess: that is a LLVM problem not a mesa problem
<LaserEyess>
so I have discovered
<Venemo>
this sort of problem is part of the reason why we made ACO
fab has joined #dri-devel
srslypascal has quit [Remote host closed the connection]
<danvet>
occasionally it takes drm-misc maintainers some time to do the rolling
srslypascal has joined #dri-devel
RhineDevil^ has joined #dri-devel
RhineDevil has quit [Ping timeout: 480 seconds]
camus1 has quit [Remote host closed the connection]
camus has joined #dri-devel
gouchi has quit [Remote host closed the connection]
rasterman has quit [Quit: Gettin' stinky!]
bgs has quit [Remote host closed the connection]
<karolherbst>
hum...
<karolherbst>
when did we do this weird render node renumbering thing on the kernel side?
<karolherbst>
where like nouveau could end up being card0 + renderD128 instead of 1/129?
<karolherbst>
I think it kills chromium perf
<karolherbst>
soo...
<karolherbst>
here is the thing
<karolherbst>
if I build wiht intel+nouveau chromium takes like 100% of the GPU and has massive FPS drops
<karolherbst>
if I build with only intel, everything is fine 🙃
<karolherbst>
and I suspect that chromiums DRM loader is totally bonkers anyway
ahajda has quit [Ping timeout: 480 seconds]
danvet has quit [Ping timeout: 480 seconds]
freemint has quit []
<DavidHeidelberg[m]>
:D
<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?
<bnieuwenhuizen>
card1/renderD129 for a second device*
<karolherbst>
no
<karolherbst>
yes
<karolherbst>
but no
<karolherbst>
today it's like random
<karolherbst>
in the past (tm) we were quite determinstic about iGPU being 0
<bnieuwenhuizen>
oh yeah, who gets 0 and who gets 1 is based on just racing on who adds their device first
<karolherbst>
_something_ changed and now things are just random
<karolherbst>
yeah sure
<karolherbst>
but
<karolherbst>
the point is, in the past it was almost always the iGPU being 0
warpme_____ has quit []
<karolherbst>
like.. I never ever see it not happening, but that changed sometime last year
<bnieuwenhuizen>
eh. that is luck I think? Does drm even have an idea which devices are iGPUs
<karolherbst>
nope
<karolherbst>
it's just how things rolled
<karolherbst>
maybe i915 got some code and loads way slower now.. no idea
<karolherbst>
point is: before 2022 I never ever see i915 not claiming card0 on any system
<bnieuwenhuizen>
well, as I said, it is a race so can be anything in what triggers drivers to initialize guess?
<bnieuwenhuizen>
or just driver init time
<karolherbst>
sure
<karolherbst>
but my point is.. application relied on card0 being iGPU, becuase that was in like 99.99% the cases true
<karolherbst>
and also chromium is just dumb here
<bnieuwenhuizen>
ehh, I'd bet it was just barely tested in a system with multiple GPUs
<bnieuwenhuizen>
but sigh :|
<karolherbst>
laptops?
<karolherbst>
I'd be surprised if that's not a test target
<bnieuwenhuizen>
well, no chromebooks with dGPUs so ...
<karolherbst>
mhh.. I think there was a way to trickc hromium...
<karolherbst>
anyway..
<karolherbst>
it worked fine in the past
<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)
<karolherbst>
yeah.. so there were users with that issue as well
<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
<bnieuwenhuizen>
but I guess applications directly talking to drm exposed themselves to a mess yeah ...
kimbro has joined #dri-devel
<karolherbst>
yeah...
<bnieuwenhuizen>
karolherbst: do you have a link/short description of what Chrome does and what issues it causes?