00:44 mareko: alyssa: unsynchronized mappings of textures are pretty much unsupported by gallium
00:45 mareko: for textures, you have just 3 options due to tiling: read, read+write, write+discard
00:45 mareko: *write+discard_range
00:46 alyssa: mareko: :+1:
00:46 alyssa: this wasn't "I have an app breaking this", it's "I'm reviewing a glthread enablement patch and trying to audit our driver"
02:00 Lynne: dj-death: getting a segfault in anv_CreatePipelineLayout with your patchset
02:02 Lynne: err, that was the validation layer messing up as usual
02:03 Lynne: your patchset does work, though it can't seem to extract descriptors from multiplane images yet
02:34 robclark: re: pp someone should remind alyssa when she is back that the upstream way to remove something is to break it and wait a year to see if anyone notices
05:22 ccr: :D
06:00 dj-death: Lynne: yeah, I don't think it can work for us with multiplanar stuff
06:00 dj-death: Lynne: we're using multiple descriptors to implement that in the driver
06:03 dj-death: Lynne: looks like we're supposed to write more data :(
06:03 dj-death: Lynne: looks like it's untested by CTS
07:16 dj-death: Lynne: should be easy to fix though
07:57 zzoon[m]: airlied: Dave please review !22202 when you're available.
07:59 zzoon: I tested h265 decoding only on gen9 and want to test on other gens
08:00 zzoon: Is there any prioritized generations to work?
08:01 zzoon: And it'll be great to recommend products to work/test for the feature.
08:01 zzoon: like nuc..or something.
12:50 karolherbst: what was the number one has to pass to drm.debug to see rejected modes?
12:52 vsyrjala: 0xe gives most useful kms debugs. can't remember what the specific bits there do
12:54 karolherbst: okay, let's see if that's less spammy then
14:15 karolherbst: uhh.. can we convince userspace to not add garbage modes?
14:15 karolherbst: if 4k@60 is not advertised, maybe not add it?
14:16 karolherbst: and well.. fail the modeset?
14:16 gfxstrand: Except for when it can and except the panel is being stupid
14:16 karolherbst: well
14:16 karolherbst: the driver rejected the 4k@60 modes
14:17 karolherbst: just apparently userspace doesn't care about any of this
14:17 gfxstrand: cwabbott: How are we doing on !22191 now?
14:17 karolherbst: but yeah, I'm aware that silly displays exists
14:17 gfxstrand: cwabbott: I think I got things sorted out so the bits are GPL-safe.
14:17 karolherbst: but there are like 100 modes
14:17 karolherbst: and userspace thinks: yes, that's probably a stupid display, lets add modes
14:17 karolherbst: it also does so for internal displays afaik.. uhhh
14:18 karolherbst: anyway
14:18 karolherbst: userspace should stop doing this
14:18 karolherbst: I'd rather have the kernel do it
14:19 karolherbst: it doesn't even make sense... why isn't a 4k@120 mode added even though it's a 4k@120 display?
14:19 karolherbst: there is no logic to it
14:20 cwabbott: gfxstrand: don't you want to land my series first?
14:38 gfxstrand: cwabbott: I pulled the needed two patches from yours and ended up tweaking them a bit.
14:39 gfxstrand: cwabbott: Once I started thinking about those bits and GPL, I realized they were going to need even more reworking. I think I've got them correct now.
14:39 gfxstrand: cwabbott: At which point your series is just the SPIR-V patch
14:39 gfxstrand:probably should have said that on GitLab last night.
14:55 karolherbst: is there a way to specify the `max bpc` property, but per mode? If not I guess it's fine for the driver to just use a lower one
15:09 eric_engestrom: reminder that the 23.1 branchpoint is in just under 2 weeks, on april 12 :)
15:09 eric_engestrom: (https://docs.mesa3d.org/release-calendar)
15:09 eric_engestrom: if you have a bug that needs to be fixed before the final 23.1.0 release, please add it to https://gitlab.freedesktop.org/mesa/mesa/-/milestones/42
15:24 MrCooper: karolherbst: yes, the driver is supposed to use lower effective bpc as needed
15:25 karolherbst: okay
15:25 karolherbst: so I check if each mode is reachable with e.g. 6 bpc (instead of 16 as done with some HDR displays) and then in the atomic check I just start with the highest supported one and go down to 6 until it works, right?
15:26 MrCooper: something like that, yeah
15:38 gfxstrand: dj-death: !22191 changed a bit if you want to give the first 3 or so another read
15:44 dj-death: gfxstrand: sure
16:22 danvet: robclark, should I smash that fix into drm-next? or you'll push it into drm-misc or some place?
16:23 robclark: danvet: the doc fix.. go for it
16:24 danvet: mlankhorst, or maybe you backmerge and smash it into drm-misc-next?
16:24 danvet: machine here is busy building drm-fixes merges
17:09 jannau: karolherbst: we prevent userspace from inventing modes by not exposing the "scaling mode" connector property for the apple kms driver. gnome already uses that. kwin will in the next release: https://invent.kde.org/plasma/kwin/-/issues/144
17:09 jannau: but I suppose you can't remove that from a driver which exposes it currently
17:10 jannau: kwin at least just adds the modes and doesn't do anything if a atomic_check fails
17:13 karolherbst: mhhh
17:14 karolherbst: yes, so we still don't enable atomic by default in nouveau :'(
17:14 karolherbst: and I have no idea why
17:16 jannau: at least I'm in the comfortable situation that I can't support custom modes since the driver can only select modes the dcp firmware offers
17:16 karolherbst: yeah... I wonder if GSP also solves the situation for us 🙃
17:18 karolherbst: I mean.. I know it makes kinda sense for external displays, because.. $edid_things
17:19 karolherbst: currently with my fix this are the modes I get: https://gist.githubusercontent.com/karolherbst/cf51d4a3dc2acff25868c5faa6359d34/raw/e3d72e494d0445ccd01d126d70a5b63e3c1b3d93/gistfile1.txt
17:19 karolherbst: and I'm wondering if we really need them all :)
17:20 jannau: I wouldn't be surprised if there is an interface to program custom modes but without documentation or a public API in macOS I don't want to support that
17:20 karolherbst: I suspect macos just adds modes themselves
17:22 jannau: not sure, I'm more under the impression that Apple says "works for me" (with Apple made displays). users seems to work around that by using modified EDIDs
17:23 karolherbst: uhh
17:23 karolherbst: sounds like something apple would do
17:23 karolherbst: but maybe also the way to go
17:23 karolherbst: if hw vendors would be stricter at just not supporting garbage hardware, that hardware would be off the market in seconds
17:24 karolherbst: but I also have a HDMI to DP adapter which... converts modelines in a very scuffed way
17:24 karolherbst: so the 4K@60 mode on HDMI needs 600MHz, where on DP you kinda want 540 instead...
17:25 karolherbst: or that's usually waht you get
17:25 karolherbst: but it's so above 600 that we have to reject it unless you lower the bpc
18:10 agd5f: danvet, heads up, I sent a second PR for 6.3 this week: https://patchwork.freedesktop.org/patch/529798/
18:11 danvet: agd5f, yeah it's compiling rn
18:11 danvet: agd5f, I figured since the 2nd doesn't include what's in the first I pull them separately
18:11 agd5f: danvet, thanks
20:52 alyssa: error: failed to add native library src/gallium/auxiliary/libgallium.a: Unsupported archive identifier
20:52 alyssa: uhhh
20:52 alyssa: karolherbst: rust is not happy with me
20:53 alyssa: oh https://github.com/rust-lang/rust/issues/107334 nice
20:54 alyssa: let's try bumping rust
20:54 alyssa: rustup++
20:57 alyssa: on 1.68.0,
20:57 alyssa: none of my bindgen works
20:57 alyssa: 1.68.2, same deal
20:58 alyssa: mesa_rust_util missing crate, uh ok
20:58 alyssa: ninja cleaning in case that was it
20:58 alyssa: it was not
20:59 alyssa: it looks like there are supposed to be rlibs that are missing?
20:59 alyssa: no, they're there in my build
21:00 alyssa: missing -Drust_std=2021, ah lol
21:00 alyssa: why is that an option
21:02 alyssa: rust_std=2021 is the default why did it not work lol
21:02 alyssa: dcbaker: meson bug?
21:03 alyssa: (rust_std=none should default to rust_std=2021 since that's in our default_options in the mesa top level project, so why doesn't it?)
21:06 alyssa: "One issue you might come across is, that the Rust edition meson sets is not right. This is a known meson bug and in order to fix it, simply run meson configure $your_build_dir -Drust_std=2021"
21:06 alyssa: I sure can read docs!
21:11 gfxstrand: Someone quick! Talk me out of moving normalize_cubemap_coords to nir_lower_tex()
21:11 gfxstrand: My only argument against it is that it's not really idempotent
21:27 zmike: well surely there's more useful things to be doing
21:27 zmike: than causing new CI merge fails
22:04 alyssa: do you really want to play CI bingo
22:58 karolherbst: alyssa: because of a meson bug
22:58 karolherbst: sooo
22:58 karolherbst: fun thing
22:58 karolherbst: if you add a new languge to an existing build dir, the default options aren't taken into account
22:58 karolherbst: same thing happens if you add C or C++ later
22:58 karolherbst: or if you change the defaults later
23:21 alyssa: yeah I saw after
23:21 alyssa: :(