00:12 karolherbst: anybody up bringing this to chromiums dev attention? kind of not in the mood for those kind of discussions...
00:30 DavidHeidelberg[m]: fishing for R-b on nicely done extern + adding LTO build-test to CI: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20374
01:02 alyssa: anholt: ++
01:04 alyssa: mupuf: What I landed was the results of running clang-format over every file in panfrost/asahisuch that a lint would pass if you ran it.
01:05 alyssa: I didn't actually touch CI or add pre-commit hooks or anything, I planned to wait until folks were back in the office to have that discussion (and if people were on board, see if DavidHeidelberg[m] was interested in doing something for all the clang-format/rustfmt 'd code)
01:05 alyssa: rusticl *does* have a rustfmt lint in CI, though :)
01:06 alyssa: Venemo: ++
01:06 alyssa: OA
01:07 alyssa: DavidHeidelberg[m]: i tried to delete the postprocessing stuff a few years ago :(
01:07 alyssa: lots of people complained though I don't know if we found anyone who used it...
01:08 DavidHeidelberg[m]: alyssa: I would like to post the horror meme with axe, where pp comming back. But it's only a IRC.
01:14 ccr: "heeereee's bikeshedding!"
01:14 Frogging101: Code formatting pretty much is "the colour of the bikeshed", so I think any format discussion is automatically bikeshedding :P
01:41 graphitemaster: In C you can indent code with semicolons and for that reason it is the superior language
02:52 karolherbst: it has to be enforced by CI with a readonly rule file
02:52 karolherbst: and no discussions
02:52 karolherbst: nor exceptions
03:05 daniels: ^
03:32 Frogging101: "clang-format off"
03:32 Frogging101: The tool formats things badly sometimes. So why make this harder than it needs to be?
03:33 Frogging101: https://clang.llvm.org/docs/ClangFormatStyleOptions.html#disabling-formatting-on-a-piece-of-code
04:54 hays: Frogging101: disagree--it is helpful to have coding standards that are reasonable. arguing over which indenting style is better i will agree is bikeshedding though. but its important to have something in place
04:56 Frogging101: ah, my use of the term bike shedding wasn't necessarily negative
06:47 Lynne: quick question, is it possible that some drivers may signal more features for linear-tiled images than optimal-tiled images?
06:48 Lynne: neither nvidia nor radv do, all capabilities for each tiling are identical
07:26 Lynne: found a couple on my 960m, oddly enough it's the opposite of what I thought; linear tiled images have less features than optimal tiled images
07:26 Lynne: that saves me some work
07:50 mupuf: alyssa: I see, sorry for the confusion!
07:53 mupuf: My thoughts are that what we want is for CI to *check and fail* if the format is acceptable, not auto-format the code for us before pushing. And to prevent people having to change any of their setup, it would be best if this became a meson pass: Check the style before compilation, if it fails, either fail the compilation or re-format automatically.
07:53 mupuf:may prefer the "fail compilation" rather than auto-magic re-formatting
07:55 mupuf: Maybe we could start with the driver alyssa already converted, since all the work has already been done there, then we can extend it one driver at a time, as the different driver developers want to hop in it?
07:56 mupuf: And I guess we really don't want to enforce a uniform coding style across the project just yet, and rather just enforce a coding style per driver (or per file if *really* necessary)
07:58 mupuf: Frogging101: yeah, disabling auto-formating/warnings for specific sections we carefully worked on is IMO indeed the way to go :)
08:44 tzimmermann: danvet, i want to prepare the PR for drm-misc-next, but there's still a PR from the previous cycle. can you please first pull https://lore.kernel.org/dri-devel/20221124074615.ahflw5q5ktfdsr7k@houat/ ?
08:44 danvet: oops, I guess airlied missed that one
08:45 tzimmermann: danvet, it was too late in the cycle or just in that grey zone around -rc6 IIRC
08:45 danvet: huh
08:45 danvet: I can't find it in my inbox
08:46 tzimmermann: you're in cc
08:47 danvet: oh looked wrong month :-)
08:47 tzimmermann: danvet, shall I resend?
08:48 danvet: tzimmermann, nah it's go
08:49 danvet: I guess this means drm-next is open for business now, not next week
08:49 danvet: tzimmermann, I'll ping you when it's pushed
08:49 tzimmermann: thank you
08:49 danvet: tzimmermann, also did you see yesterday someone asking when drm-misc-fixes is rolled forward
08:49 tzimmermann: i missed that
08:49 tzimmermann: i can do this now
08:49 danvet: well they pinged me instead of misc maintainers :-)
08:51 tzimmermann: drm-misc-fixes is at v6.2-rc2
08:51 tzimmermann: thanks, mripard
08:52 mripard: sorry, I forgot to tell on IRC
08:52 mripard: but you're welcome
09:02 danvet: digetx, ^^
09:15 MrCooper: Lynne: it does seem possible in theory that linear would support more features than optimal-tiled (though it may be unlikely in practice)
09:36 danvet: tzimmermann, pushed
09:36 tzimmermann: thanks
09:44 tzimmermann: mripard, lol "Acked-in-principle-or-something-like-that-by"
09:46 mripard: and dim is ok with that! :)
10:01 danvet: dim is dim
10:21 mlankhorst: I don't get a part of the buddy allocator
10:21 mlankhorst: In amdgpu_vram_mgr_alloc, vres->base.start = max(vres->base.start, start)
10:22 mlankhorst: How is it calculated like that?
10:22 mlankhorst: with some wraparound magic
10:29 mlankhorst: to answer my own question, seems to be ignored in by io_mem_pfn()
11:03 digetx: tzimmermann: danvet: so, if I want to have a fix landed to v6.2-rc3, should I use drm-misc-fixes or drm-misc-next-fixes
11:03 tzimmermann: digetx, drm-misc-fixes
11:04 tzimmermann: it will go into drm-fixes and linus' tree once per week
11:05 digetx: ok, this matches the drm-misc doc
11:59 danvet: mripard, btw just noticed that there's also misc-next-fixes pending, so pls send pull requests for everything
11:59 danvet: or do I need to pick up an old one?
12:03 danvet: probably also means the wrong branch lands in for-linux-next
13:21 RhineDevil: Ristovski: Isn't it possible to partially increase hardware support for codecs in mesa3D? Could I have an idea as clearly as possible of how much of the decoding process takes place in mesa3d, in amd installed firmware and in amd hardware?
13:23 Ristovski: RhineDevil: The GPU itself has specialized hardware blocks for decoding video, if those HW blocks don't support a codec it simply is not possible to implement support for it
13:23 RhineDevil: As an example, vainfo -a shows me that vaapi on my machine supports MPEG2, VC1 and H264 with yuv240p and yuv420p pixel encoding, would be nice for example if it could support yuv420p10
13:25 Ristovski: I am not sure how specialized the HW blocks themselves are, afaik there are no public docs on them either
13:25 RhineDevil: Ristovski: how much specialized? is the entire processing needed for the format directly encoded? You can't just ask "ok give me this specific function for accelerating yuv420p encoding"?
13:26 RhineDevil: Ristovski: so it's AMD firmware deciding how to expose HW blocks and you know from that if it supports determinate pixel encoding?
13:27 RhineDevil: Like, if it supported yuv420p10 you'd see VA_RT_FORMAT_YUV420P10
13:28 RhineDevil: or a string like that telling you yes I support this pixel format
13:34 Ristovski: RhineDevil: for now this seems to be hardcoded in the driver code: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/amd/amdgpu/nv.c
13:34 Ristovski: I am not sure if there is some mechanism to directly query the HW blocks
13:36 alyssa: mupuf: Sure, sticking the checks in meson is an option in addition to / instead of git pre commit hook and CI
13:37 alyssa: panfrost and asahi are already converted, take your pick which to use as the test dummy
13:37 alyssa: asahi has fewer devs touching it so might be less disruptive
13:37 alyssa: (really it's just me and lina)
13:38 alyssa: both use clang-format off in a fe wplaces but rare
13:38 mupuf:thinks we shouldn't use git pre-commits for this, as it is quite likely to interfere with already-existing pre-commits mesa devs may already have
13:39 alyssa: OK
13:39 RhineDevil: Ristovski: uhmmm yeah judging from that seems there is no way to have custom vaapi stuff, god knows what their interfaces are and they're probably tight lipped about their patents and architecture details
13:40 alyssa: mupuf: meson build rule that runs the lint and (if it fails) fails the build with instructions on how to setup/run clang-format (including integrated with editor) then?
13:40 mupuf: And I believe checking the coding style in CI is not optional, as I am sure people don't always compile or commit the changes done by the compilation before submitting their series
13:40 mupuf: yeah, this sounds ideal to me
13:40 Ristovski: RhineDevil: That is most likely correct. Not to mention that the firmware for all the HW blocks is proprietary as well
13:40 alyssa: so then people hacking locally get the lint run and CI runs it too automatically
13:40 alyssa: without adding shit to the sanity stage
13:40 mupuf: and a switch to opt out from it so that distros don't have to add a build dependency
13:41 alyssa: and avoids the trap of "did not install clang-format so precommit hook didn't do anything and now CI is yelling at me"
13:41 RhineDevil: Ristovski: although in the kernel code I see no reference to pixel formats
13:41 RhineDevil: just the encoding
13:42 alyssa: mupuf: this *does* require devs to setup "autoformat on save or earlier"
13:42 alyssa: as opposed to doing it at the commit level
13:42 alyssa: since now if you're just experimenting you need it formatted right to build t at all
13:43 mupuf: true that...
13:43 mupuf: I guess meson can just fail to build if not formated correctly, then we would document the two solutions: pre-commit or reformat on save
13:43 alyssa: for me that's fine -- I configured vim to autoformat on save, so unformatted code never hits the disk
13:44 alyssa: => meson never sees unformatted code
13:44 alyssa: => lint always passes
13:44 alyssa: all competent editors and IDEs can do this
13:44 alyssa: but it *does* require deliberate configuration
13:45 alyssa: https://kate-editor.org/post/2021/2021-03-06-kde-code-formatting/ as an alternative used by a FOSS friend
13:46 jenatali: Are you thinking component-specific jobs, or a tree-wide job with a config for which directories need to be linted?
13:46 jenatali: Or maybe it's just based on where there's clang-format files
13:47 alyssa: jenatali: latter
13:47 jenatali: No but some directories have them but didn't do a full reformat so it'd need to be more scoped than that I think
13:48 jenatali: Interesting idea, for sure
13:49 alyssa: right, that's what I didn't realize
13:49 alyssa: I assumed the dirs with them were reformatted
13:50 alyssa: r600/sfn seems to be
13:50 jenatali: Oh maybe I'm wrong about that then
13:50 alyssa: I thought aco was but ?
13:51 alyssa: seemingly radv and freedreno were not
13:51 alyssa: and seemingly ir3
13:52 jenatali: I've been meaning to write a .clang-format for our internal codebase... That would've been a good thing to do while everyone was on vacation lol
13:52 Ristovski: RhineDevil: indeed, not sure where that gets queried from. FWIW the mesa side of things is in https://gitlab.freedesktop.org/mesa/mesa/-/tree/main/src/gallium/drivers/radeonsi, under the uvd/vce/vcn files
13:54 alyssa: jenatali: now you know why I yeeted in clang-format to my drivers over Christmas :-p
13:56 jenatali: Instead I tinkered with Mesa CI
13:57 RhineDevil: Ristovski: thank you, gonna take a look. Btw from what I've seen there must be a bug somewhere in mesa3d encoding handling before passing it to kernel and underlying hardware, because it doesn't properly encode stuff in needed format
14:36 alyssa: jani: re i915 display code, for iris maybe it makes sense to use kmsro?
14:36 alyssa: i915 display + xe renderonly
14:43 alyssa: zmike: welcome back
14:45 zmike:grumbles about the new fad being pre-merge code formatting instead of something more useful like rewriting glsl in rust
14:48 zmike: ci seems to work though
14:48 zmike: pluses and minuses
14:56 RhineDevil: Ristovski: encoder seems generic too
14:57 Ristovski: yeah, I didn't see anything specific for 10bit either, hmm
15:05 mupuf: zmike: welcome back!
15:06 mupuf: I kept Zink on radv clean while you were away :)
15:06 zmike: 💪
15:30 bnieuwenhuizen: alyssa: wrt meson clang-format: https://mesonbuild.com/Code-formatting.html
15:49 tzimmermann: in december there was a patchset to remove the ancient drivers for userspace modesetting. no one really commented, so there is currently no support for this?
15:58 mlankhorst: tzimmermann: most likely nobody noticed. :)
15:59 tzimmermann: i should r-b the patchset and silently delete them :P
16:42 jani: alyssa: it's one pci device for the whole thing, and I don't think there's a feasible way to split this between drivers
16:43 jani: alyssa: I mean xe render for discrete + i915 render and display for integrated works fine, because they're different devices
16:51 MrCooper: pendingchaos: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20482 seems incomplete, still getting Navi 14 GPU hangs with piglit gpu, reverting !20357 fixes them
16:51 MrCooper: pepp: ^
16:54 MrCooper: this is with LLVM 15.0.6, FWIW
16:56 pendingchaos: do you know what test?
17:13 danvet: alyssa, the kernel side needs fairly tight integration in handling mappings and stuff, and at that point doing the kmsro dance feels a bit like an academic exercise ...
17:13 danvet: could totally be done with aux bus and all that though
17:20 MrCooper: pendingchaos: no, but it happens pretty early on, takes less than a minute
17:36 Frogging101: KitsuWhooa: !
17:36 KitsuWhooa: Frogging101: !
17:46 alyssa: zmike: thank you for volunteering to rewrite the glsl compiler in rust
17:46 alyssa: jani: danvet: oh, right, ok. PCI. I have my head stuck so far up my arm that I didn't think about that.
17:47 anholt: alyssa: https://crates.io/crates/glsl jobs done, right?
17:48 anholt: (it's not)
17:48 alyssa: anholt: it builds, ship it
17:49 alyssa: (that was a joke, it's Rust code, there's no way it possibly builds)
17:52 alyssa:just discovered the ANV indirect draw GLSL shaders
17:52 alyssa: thanks I hate it
17:55 alyssa: bnieuwenhuizen: Hmm, ok. I don't think that would really plug in to either of the workflows we (mupuf DavidHeidelberg[m] and I) discussed so far but mh
17:56 danvet: alyssa, well linux doesn't really care whether pci or anything else, you can instantiate more struct device on top and use all the neat things either way
17:56 danvet: it's more that the hw is quite a bit a messy thing
17:58 DavidHeidelberg[m]: thou interesting, I didn't know that meson can do that, but since we have non-clang parts of Mesa, it would be probably hard to utilize
17:58 DavidHeidelberg[m]: oh, nevermind me, it can read the config and paths, so in theory it could work
18:22 bl4ckb0ne: what's the diff between a r-b and ack-by ?
18:23 bnieuwenhuizen: kernel or mesa?
18:24 bl4ckb0ne: mesa
18:25 bnieuwenhuizen: acked-by is roughly a "I didn't provide a full review but still think this should land"
18:26 bnieuwenhuizen: (hmm, interestingly enough we don't mention the meaning in https://docs.mesa3d.org/submittingpatches.html#reviewing-patches)
18:26 bl4ckb0ne: what's the minimum requirement to give a valid r-b beside reviewing the code
18:27 bnieuwenhuizen: reviewing the code :)
18:27 bnieuwenhuizen: "Review by non-experts is encouraged. Understanding how someone else goes about solving a problem is a great way to learn your way around the project. The submitter is expected to evaluate whether they have an appropriate amount of review feedback from people who also understand the code before merging their patches."
18:27 bl4ckb0ne: perfect, thanks
18:28 bnieuwenhuizen: of course if the submitter is new and doesn't have submit permissions I think whoever assigns it to marge should make sure the reviews are reasonable
18:29 bl4ckb0ne: should be good i believe
18:47 FLHerne: acked-by -> "what the patch says it does is a good idea"
18:47 FLHerne: reviewed-by -> "what the patch actually does is a good idea"
18:51 Kayden: also reviews are good from everyone, more eyes looking at it. acks are mostly only meaningful by someone seen as a kind of authority on the topic
18:52 Kayden: like if Rob acks freedreno code, it's good to go, if I ack freedreno code, it probably means I looked at it briefly and think it looks plausible, if a user acks it it's more of a "I think this fixes my problem so please land it" (but it might not be right at all) :)
18:52 Kayden: I think I heard someone say acks from random people are more like "woah, kewl dude", hehe
18:53 Kayden: but yeah more review is always appreciated!
18:59 bl4ckb0ne: in this case its a rather short commit fixing a bug i reported
19:00 bl4ckb0ne: im not at all familiar with the codebase but i poked at it a bit to fix it and gets the gist of the fix
19:01 Kayden: sounds good :)
19:44 jani: sometimes acked-by is also "I've seen it and I'm not opposed"
19:48 bnieuwenhuizen: jekstrand: actually browsing the patch submission documentation, where is the blurb you post when people get developer permissions from and should we add it to the docs?
19:48 jekstrand: bnieuwenhuizen: I just copy+paste from an old request. Yeah, we should probably put it in the docs somewhere.
19:55 pepp: MrCooper: ah :/ It seems I can't trigger the issue on navi21 so I'll test again with a navi10 tomorrow
20:19 Lynne: one of the worst things about vulkan is the requirement to allocate all your textures using drm tiling if you ever plan to export your textures as dmabufs
20:19 jekstrand: That's a feature, not a bug.
20:20 jekstrand: It's also pretty much a hard requirement if you want the client to be able to manage memory allocation
20:20 emersion: yeah, it's really important to negociate the modifier with the other side
20:20 Lynne: yeah, but drm tiling was rarely supported and often limiting when it comes to image formats, features and flags
20:20 jekstrand: Yup
20:21 jekstrand: And that's why you can't just up and export any image
20:22 Lynne: cuda export/import is both much worser and better
20:22 Lynne: worser, because you have to allocate all your vulkan images as cuda images, which you then import into vulkan
20:23 Lynne: better, because it operates via memory aliasing, so it doesn't care about tiling
20:23 jekstrand: Oh, it absolutely cares about tiling
20:24 bylaws: Is there a disassembler/assembler for modern nv architectures anywhere?
20:24 jekstrand: bylaws: There's a disassembler provided with the cuda packages
20:24 bylaws: Envyas seems to be far out of date with nouveau itself
20:24 jekstrand: Lynne: Whether or not they expose tiling to you is an entirely different question. ;-)
20:24 Lynne: jekstrand: well, yeah, it just always wants optimal tiling
20:25 jekstrand: That's because they're magically passing it side-band somehow
20:25 Lynne: ffmpeg used to allocate all vulkan frames using drm tiling because what if someone wanted to export them to vaapi, but I think vulkan video makes it pointless
20:25 bylaws: I assume I'm on my own for an assembler?
20:33 jekstrand: AFAIK, yes.
21:07 danvet: bnieuwenhuizen, jekstrand https://www.developercertificate.com/
21:08 bnieuwenhuizen: danvet: what I meant was https://gitlab.freedesktop.org/mesa/mesa/-/issues/7596#note_1622143
21:08 danvet: ah yeah that's a different one :-)
21:09 danvet: 6. is a bit a disappointment
21:10 bnieuwenhuizen: also getting less and less relevant I think now that anv/iris have a bunch of gitlab CI presence
21:11 jekstrand: Yeah, 6 is annoying
21:12 jekstrand: But, really, it's no worse than 4 and 5
21:12 bnieuwenhuizen: btw best part is specifying nowhere which drivers that are :)
21:12 jekstrand: lol
21:12 bnieuwenhuizen: like as long time contributor I know
21:12 jekstrand: I think at the time I wrote that, Igalia was doing their own disjoint CI stuff too.
21:12 bnieuwenhuizen: but all these new people?
21:13 jekstrand: As an ex-Intel person (emphasis on ex), I say we should try to drop it. :P
21:13 jekstrand: Someone's gonna kill me for that....
21:14 bnieuwenhuizen: well, with anv/iris having some Gitlab CI presence and Amber being what it is I think the time is right?
21:14 danvet: doit.jpg
21:15 jekstrand: bnieuwenhuizen: crocus ci?
21:15 bnieuwenhuizen: I mean this discussion started with this blorb not even in the docs so we have nowhere to update :P
21:15 jekstrand: lol
21:17 bnieuwenhuizen: crocus seems missing yeah :|
21:37 gawin: iirc Emma is providing some crocus devices. (gen 4 and gen 7.5 iirc) but not enabled by default iirc
21:38 anholt: right, but you don't have to wait for a third party to run your tests for you.
21:38 anholt: (unless the systems are down because gpu reset is so unreliable)
21:40 gawin: covering Amber iwould be super annoying igpus at that time weren't proving all features of dedicated gpus. also no bleeding edge features like support for uuid.
21:51 jenatali: I've said it before but it's discussions like this that make me so happy we managed to get Windows machines in CI for us
21:52 jenatali: And now we're even using deqp-runner like everyone else
22:12 danvet: bnieuwenhuizen, submit doc patch, conveniently leave out that last bullet :-)
22:13 jekstrand: WFM