01:51 anarsoul: zamundaaa: you forgot to update source hash for wayland protocols in !32038
01:53 anarsoul: it breaks mesa build on archlinux arm: https://gist.github.com/anarsoul/c304c5c05faf1a93eeffb9db2ec3f6ae
02:24 Kangie: Hi all, where's the best place to ask someone to approve a CI run on a mesa MR? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33725 for reference.
02:34 mattst88: Kangie: file an issue in https://gitlab.freedesktop.org/freedesktop/freedesktop/ and request fork/CI permissions
02:36 Kangie: thanks, done. I should have bit the bullet and requested it yesterday.
04:10 uriah: Kangie: btw, i have a small edit to the mesa ebuild incoming
04:10 uriah: tested today
04:10 uriah: it'll be hopefully pushed to my repo tonight
04:11 uriah: digetx: thanks again, working smoothly now
04:18 uriah: just wondering too though... i still use my haswell hardware... your MR mentions it only works with TigerLake+ GPUs... is it still the case?
04:18 uriah: if so, i don't really have time for a while to try porting to haswell, but if you added changes that would help, i'd be willing to test
04:22 uriah: oh wait, maybe i can just try setting INTEL_VIRTIO_SKIP_HW_VERSION_CHECK to true in mesa like you suggested?
04:27 Kangie: Excellent
04:27 uriah: Kangie: yeah really happy with results
04:27 uriah: oh btw
04:27 uriah: i'm on the oftc-matrix bridge, do highlights show up messed up?
04:27 uriah: sorry if that's the case
04:28 Kangie: No, it all seems fine here.
04:29 uriah: good.
04:29 uriah: i can finally tab complete
04:29 uriah: might've just been on ios element
04:29 uriah: whew
10:26 tzimmermann: javierm, sima, after our recent discussion, i went through all the DRM code and resolved the easy cases where it touches dma-buf import_attach fields. resolving that would hide much of the implementation in prime helpers. for starters, i'd post the core changes plus some simple drivers for review. ok?
10:27 javierm: tzimmermann: great
11:00 daniels: alyssa: if I'm reading it right, n_tiles_h == n_tiles_v, or 2*n_tiles_v?
11:03 daniels: alyssa: so 1920x1080 ARGB8888 would be 32 horizontal tiles (30 used, 2 to round to pot) x 32 vertical tiles (17 used, 15 to round to n_tiles_h since it can't be n_tiles_h/2 == 16)?
11:14 tzimmermann: removing the dma device from the dma-buf import is currently not realistic though
11:15 zamundaaa[m]: anarsoul: oops, sorry
11:15 zamundaaa[m]: Looks like someone else is taking care of that already
11:55 digetx: uriah: haswell uses crocus driver, while virtio is only hooked up to the iris driver in mesa; supporting crocus should be doable in general, but it's not a priority; so haswell won't work with nctx today, maybe later
11:56 uriah: ok i see, thanks for the info
11:57 uriah: INTEL_VIRTIO_SKIP_HW_VERSION_CHECK is therefore irrelevant to my hardware eh?
11:57 digetx: yes
11:57 uriah: alright
11:57 uriah: well, i have other newer hardware i can test on, i'll let you know
11:57 digetx: cool
11:57 uriah: circa 2017
11:58 uriah: how about blob support in haswell, for vaapi?
11:58 uriah: does some of it work, or not really yet?
11:59 uriah: i'll be patient if not :)
12:02 digetx: vaapi is managed by a separate media driver and is not supported, I haven't touched it in nctx
12:03 uriah: oh ok
12:03 uriah: i think i remember this from september yeah ok
12:05 digetx: vaapi may work with amd nctx, though never tried to test it
12:10 uriah: vaapi works yes
12:10 uriah: it is part of mesa
12:10 uriah: just regular libva
12:10 uriah: for amdgpu i mean
12:12 uriah: i guess for the haswell setup i'll just use vaapi in bare metal linux
12:15 uriah: digetx: you'll probably work on xe before crocus, right?
12:15 uriah: since it's newer hardware
12:17 digetx: yes
12:17 uriah: alright
12:17 uriah: well if i find time, i'll maybe give crocus a shot
12:17 uriah: would be a fun way of improving my knowledge, but no guarantees
12:22 uriah: obviously, there are fewer and fewer crocus users out there nowadays
12:48 mripard: mairacanal: tursulin: ack for https://lore.kernel.org/r/20250113101100.1373856-1-mripard@kernel.org ?
12:53 tursulin: mripard: sounds reasonable - acked on the ml
13:06 mripard: tursulin: thanks :)
13:31 alyssa: daniels: for which modifier?
13:31 alyssa: for GPU tiled: ARGB8888 is 4 bytes per pixel so 64x64 tiles to fill the 16K page
13:31 alyssa: so round to 64x64: 1920x1088
13:32 alyssa: so 30x17 tiles
13:33 alyssa: for twiddled: the whole thing rounds up to 2048x2048 and is effectively one big 2048x2048 tile (fully interleaved bits). yeah, you probably shouldn't use twiddled ;P
13:34 alyssa: rounding to power-of-twos only happens for twiddled and for the compression metadata
13:34 alyssa: the body buffer of gpu-tiled is rounded only to tile size
13:34 alyssa: (except when the gpu-tiled image is smaller than a page-size tile, i.e. smaller than 64x64 for rgba8)
13:35 alyssa: (this lets us pack multiple mip levels together into a single page)
13:35 daniels: alyssa: sorry yeah, that was GPU-tiled
13:36 daniels: alyssa: fwiw, my misreading came from 'for large images, n x n or 2n x n tiles are used (n power-of-two)'
13:36 daniels: maybe 'for large images, the tile size must be ...'
13:41 alyssa: ah I see. yeah, I can reword that
13:42 alyssa: i feel like we need a ranking of vendors by insanity of their tilings
13:42 alyssa: like, Arm < Apple < .... <<< AMD
13:42 daniels: the final frontier of accessibility: making your docs readable for people who have lost the ability to think / will to live from writing CTS
13:43 alyssa: heh
13:43 alyssa: might be clearer just to give the table first
13:44 alyssa: and then as a non-normative remark explain where the #s came from
13:44 alyssa: (after)
13:47 fomys: Hi, I have an issue while applying this patch: https://lore.kernel.org/all/20250218101214.5790-4-jose.exposito89@gmail.com/, how should the trailers look like?
13:47 fomys: If I let dim do its stuff, it removes the Signed-off-by after the Co-developped by, which makes checkpatch not happy
13:47 fomys: If I put the SoB twice (after Co-dev-by and last), checkpatch is also not happy
13:47 fomys: Should I remove the Co-dev-by?
13:48 daniels: alyssa: yeah, I like that
13:48 alyssa: :+1;
13:49 alyssa: daniels: if you're wondering how that explanation got the way it is, it's because I wrote before dropping out of math ;)
14:24 ccr: "math - not even once"
14:52 mairacanal: mripard, i also acked in the ml - thanks for documenting this
14:53 mripard: mairacanal: you're welcome, thanks for the review
15:07 eric_engestrom: cmarcelo: next step is merging, which I just did; thanks again for the MR!
15:11 eric_engestrom: cmarcelo: to be picked up in mesa, this will need 1) a deqp-runner release (anyone can push a git tag but I think emma & faith are the only ones with the creds to publish it), and 2) bump the version in the $mesa/.gitlab-ci/container/build-deqp-runner.sh
15:20 alyssa: daniels: "Plus would apply pretty obviously to compression." could you elaborate?
15:21 alyssa: dumb "dump and copy" isn't going to work with compression unless we set the stride to something really wonky
15:21 stsquad: digetx I'm still trying to see why you have VK_KHR_display available to your guests and I'm confused as virglrenderer doesn't list it in _vn_info_extensions
15:21 alyssa: (I think we did this with AFBC at one point but I'm not convinced it's a good idea. and at least the "pretend it's LINEAR" convention I have now seems to work with every compositor I've tried so I'm hesitant to mess with it.)
15:22 daniels: alyssa: stride of compression == 8 * (ROUND_UP(w, 16) / 16)?
15:23 stsquad: digetx: should I expect to see something like a19f5c49 * vkr: support VK_KHR_maintenance6 - with the entry added and a dispatcher to map from guest to backend?
15:23 alyssa: daniels: at the DRM level it's not planar
15:23 daniels: alyssa: _raises ten eyebrows_
15:23 alyssa: I just copied how AFBC works :p
15:24 daniels: AFBC is more naturally interleaved though, rather than cbuf followed by metadata buf - that's much more like CCS/DCC which do use aux planes for the separate compression data
15:24 daniels: that helps future-you because you can explicitly specify the offset rather than 'by convention, ...'
15:24 alyssa: hmm, ok.
15:25 daniels: (I mean, just pass the same BO rather than have them live in separate allocations, but you can pass the offset separately)
15:25 alyssa: right, ok.
15:25 daniels: ty :)
15:25 alyssa: the "By convention" here is "match exactly what the vendor driver does (and we have exhaustive unit testing to confirm that), just in case"
15:26 alyssa: theoretically we can do otherwise...? But I've never tried and the prop driver doesn't and there's no use case that I know of for it so I can see it breaking in fun ways on current/future hw
15:27 daniels: oh yeah, for sure
15:27 alyssa: although maybe that's ok and we end up growing a second set of modifiers then..? IDK
15:27 daniels: it's just trading one implicit API (cbuf + 128B align) for a more explicit API
15:28 daniels: and given what you said about the display format being renderable but not sampleable, I'm not sure I trust them to retain sensibility in future :P
15:28 alyssa: yeah, for sure
15:29 alyssa: is switching to 2 DRM planes, but nevertheless requiring that the allocations are back-to-back (+128b align) sane?
15:29 alyssa: can't tell if this is the best or the worst compromise here :p
15:29 alyssa: (I guess it's not relevant if Mesa is the only producer and Mesa internally has this as contract. But..)
15:30 daniels: yeah, that's a totally reasonable constraint, and you can reject import if it fails
15:30 alyssa: ack. I'll type that out and see what blows up then, thanks :)
15:30 daniels: np!
15:52 jannau: mripard: Hej, alyssa notified me. we can chat here as well
16:13 jannau: dt-bindings are one part where I'd love to have to discuss the design. The display system on the machines is complex and powerful but due to the firmware based display controller it differs quite a bit from other DT based hardware
16:14 mripard: it might be a stupid question, but afaiu most of the complexity comes from the firmware interface, and that's why you want rust. Would you have an easier time creating some kind of library in Rust, that would be usable to C drivers? That way you both get an easier time to upstream it, but also the safety Rust provides?
16:14 mripard: and yeah, I can definitely help with bindings as well
16:17 sima: mripard, panthor folks seem to have concluded that the library approach is too much pain, everyone else didn't even try
16:17 sima: but yeah I tossed that option in too, just doesn't seem to work that well
16:18 alyssa: also, we already have rust GPU driver that needs to get upstreamed as rust
16:18 alyssa: and once that's upstream, together with Lyude's KMS bindings upstreamed
16:18 alyssa: well, there's hopefully not much left needed extra for a pure rust KMS
16:19 mripard: it looks like dp-alt is (was?) a concern and had a lot of impedance mismatch with the rest of the kernel already
16:19 mripard: I guess my concern was that throwing Rust into the mix would create more mismatch
16:20 mripard: but yeah, anyway, I guess the takeaway is I can help with the bindings if needed :) Any binding you want help with in particular?
16:21 jannau: dp-alt is 90% done (remaining 90% are suspend fixes and cleanup) and is except for the kms driver in C anyway
16:22 daniels: sima: I think a self-contained leaf which only took a state and serialised it into firmware RPC, plus parsing firmware RPC and serialising it to more tractable small events, would be way less friction than what Panthor/Ranthoriirrrrrr attempted
16:23 sima: daniels, yeah probably
16:23 sima: daniels, but then you're stuck with the same issue as panthorriir if you want to go further
16:24 jannau: the usb3 and usb-pd/port controll driver exists and there's little benefit in implementing the phy drivers in rust so they are C as well
16:25 sima: alyssa, jannau I guess only if you have more needs than rkms, so dp or hdmi helpers probably, drm_bridge maybe (but I'd be surprised if you need that)
16:27 mripard: daniels: is that the new name? Ranthoriirrrrrr is pretty inconvenient to use. Like, how many r does it have?!
16:27 jannau: the two main interactions between between kms and the firmware are page_flip/modeset and getting the list of supported modes from the firmware
16:27 jannau: more than strawberry
16:28 daniels: mripard: I only ever called it that to troll them into getting a better name, so they discontinued the entire project and replaced it with one with a three-letter name
16:28 mripard: daniels: good job, congrats :)
16:29 alyssa: the old name adds extra R's every day
16:29 daniels: thanks, one of my proudest achievements
16:29 alyssa: the new name switches between "tear" and "tyre" every day
16:29 mripard: daniels: I think I would have called it daniel
16:29 alyssa: preserve the tradition of date-dependent names
16:29 daniels: alyssa: Rewrite it in Rust! Rust! Rust! Rust!
16:29 daniels: alyssa: tyr is pronounced with a soft g
16:29 daniels: mripard: <3
16:30 alyssa: daniels: what about the p? is it silent?
16:30 daniels: depends whether or not you're subscribed to the enterprise edition
16:32 alyssa: ah yea
16:32 jannau: with those two interaction points it using a rust library might be a working solution but the goal is explicitly to have a user to upstream rust bindings needed by the 20k gpu rust driver
16:33 alyssa: silent for fedora, pronounced for rhel
16:33 jannau: planned after seeing nova-core
16:37 digetx: stsquad: have you checked the extension presence with archlinux rootfs? are you using intel or amd card?
16:47 stsquad: digetx was that on your gist?
16:47 stsquad: digetx: currently I'm testing with an aarch64 buildroot image for venus=on
16:48 stsquad: digetx: or is this just an archlinux x86 install?
17:17 stsquad: currently intel backend
18:01 stsquad: https://0x0.st/8A5e.txt
18:01 stsquad: digetx: x86, archlinux rootfs, no VK_KHR_display reported ^
18:21 zmike: mareko: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33632
21:59 Company: how stupid is the idea of using Vulkan raytracing for rendering GUIs?
21:59 Ermine:. o O (GTK with RTX off/GTK with RTX on)
22:00 daniels: Company: yes
22:01 Company: yeah, essentially - we have a CommandList and I could translate that into an acceleration structure instead of into draw commands
22:02 daniels: you could!
22:02 daniels: but you shouldn’t
22:02 airlied: sounds like a great summer of code project :-P
22:03 Company: yeah, that's ultimately the idea
22:03 Company: I could use it to finally learn how raytracing works
22:04 Company: but if it's so stupid that I end up with 3fps then it's not really worth it
22:05 airlied: I think it might be 3fps but worth burning a student learning something new on
22:05 Sachiel: should be great for screen mirroring and realistic window shadows
22:06 Company: yeah, that's the other thing - once you have built it, you can also figure out fun things to do with it
22:06 Company: also, I'd have a reason to buy one of these new GPUs
22:10 airlied: lavapipe can raytrace :)
22:10 Company: but then I'm at 0.03fps instead of 3fps
22:12 karolherbst: smh, just use NPUs to predict the result or something
22:14 airlied: yeah build a model of every rendering of a desktop ever
22:14 airlied: and guess what the next frame is
22:15 airlied: you fund a large startup instead of one gsoc student
22:16 Company: I could just use nvidia's framegen stuff
23:18 anarsoul: mareko: are you around?
23:18 anarsoul: I have a few questions about https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31942
23:19 anarsoul: it hurts lima badly in several ways
23:21 anarsoul: the most important one for varyings that are used for sampler coordinates
23:22 anarsoul: for 2d sampler if it's not in .xy or in .zw it requires an extra mov which is an extra instruction and in addition to that it drops coordinate precision to fp16
23:24 anarsoul: so it's not only 25% performance drop e.g. in glmark2 -b texture, but also breaks textures with dimensions > 1024
23:30 anarsoul: and in general, lima (or rather Mali Utgard) doesn't like arbitrary packing of varyings due to ISA restrictions. Basically it cannot load vec2 varying from .yz or vec3 from .yzw, it requires an extra mov (and an extra instruction)
23:35 anarsoul: I'm not really sure how to fix it
23:43 anarsoul: I opened https://gitlab.freedesktop.org/mesa/mesa/-/issues/12702 for that