00:08 alyssa: dj-death: I dunno
00:08 alyssa: We're not using gitlab CI, so there's that
00:09 alyssa: planned Asahi CI is all arm64 for other reasons
00:09 Company: dj-death: the Intel Vulkn YUV support is not the best, isn't it?
00:11 Company: GTK and GStreamer finished their YUV dmabuf support and now I get to experience what those dmabufs do to Vulkan drivers
00:12 Company: https://i.imgur.com/McmjokC.png was the start, but I got it to assert now
00:14 Sachiel: I thought that guy liked to be green
00:15 Company: https://paste.centos.org/view/38d903f9
00:15 jenatali: dj-death: that's one of the reasons I'm not thrilled about the idea of that approach going into common code. I don't think meson MSVC solutions can do that mixed native+cross thing
00:15 Company: though maybe I should check validation layers first, I might be doing something stupid
00:15 jenatali: That approach = using clc at compile time
00:23 karolherbst: DemiMarie: use a client cert :P
00:32 alyssa: jenatali: i ain't doing this in nir_builder https://gitlab.freedesktop.org/asahi/mesa/-/blob/main/src/asahi/lib/shaders/geometry.cl?ref_type=heads#L237-331
00:34 jenatali: I mean, I get it. It's elegant and clever. It's just also a nightmare to build on Windows (or maybe just with MSVC)
00:34 dj-death: jenatali: I'm almost there with android/arm/etc..
00:35 dj-death: jenatali: doing a host build of intel-clc just to generate our NIR
00:35 dj-death: Company: well you might be the first using it
00:35 alyssa: dj-death: tbf, raytracing :D
00:36 dj-death: alyssa: yeah I don't want to impose that on people
00:36 jenatali: dj-death: right, I don't think meson + MSVC can do that
00:36 dj-death: jenatali: :(
00:36 alyssa: dj-death: ...I do ;P
00:36 alyssa: this is part of my long game to force CL adoption ;P
00:36 Sachiel: dj-death: autotools can, let's rewrite the build system
00:37 dj-death: Sachiel: out.
00:37 dj-death: alyssa: if you do some generic stuff, I could be happy to switch over to that
00:41 Company: dj-death: that's good to know - I should probably file lots of bugs then?
00:42 dj-death: Company: start with one
00:42 Company: I think I have 3 already ;)
00:51 alyssa: dj-death: generic?
05:39 dj-death: alyssa: should be
05:39 dj-death: alyssa: sorry, I mean if you manage to make some of the RT stuff reusable
13:23 mripard: sima: any opinion on how to solve https://lore.kernel.org/dri-devel/20231207-kms-hdmi-connector-state-v5-8-6538e19d634d@kernel.org/ ? Basically, swick[m] would like more documentation, especially around whether YUV is supported or not. The HDMI spec allows it, vc4 allows it, but i915 doesn't. vsyrjala feels like it's a mistake to enable it at all.
13:24 mripard: I'd be inclined to just drop that patch since it's getting clear we're not going to have a consensus
13:30 sima: mripard, aren't we just at the "people talk past each another" phase?
13:30 sima: or I'm just confused
13:32 DemiMarie: <tleydxdy> "it should be possible if you can..." <- Someone already wrote a driver but it will take a while to get native context support, if ever. Test signing is fine for this.
13:32 sima: also I don't see what we're gaining by dropping that patch, I guess you'd still end up with the infoframes helper setting the infoframes to support broadcast/full range on ycbcr?
13:36 vsyrjala: the infoframe helpers don't handle yuv quantization range
13:37 vsyrjala: yuv is not a standard thing across kms atm
13:37 sima: don't you need to set the bits right in there?
13:37 vsyrjala: it's done in the drivers
13:37 sima: sure the encoder needs to be programmed to match too
13:38 vsyrjala: i mean the infoframe is set up by explicitly by each driver when transmitting yuv. the helper will not help
13:38 sima: oh I thought that's already in there
13:39 alyssa: dj-death: oh, I'm not touching RT for years lol
13:40 sima: the can't we just add a line that it's kinda up to the driver how this works with ycbcr and done?
13:41 vsyrjala: the problem with yuv is that we also need some way to configure the matrix, so need a new prop anyway. i think it would probably be better to roll the matrix+quantization range into that single prop so that it's easier to see what combos are actually supported
13:42 sima: yeah but if someone gets around to that we can do the usual uapi backwards dance fun and figure out something?
13:42 vsyrjala: and having a prop called "RGB..." that also magically affects YUV is a bit confusing
13:42 mripard: vsyrjala: the whole point of this series is for drivers not to have to prepare infoframes
13:42 sima: unless the idea is that vc4 is so wrong it has to be reverted
13:43 vsyrjala: imo vc4 is wrong. they magically extended the meaning of that prop without consulting anyone
13:43 dj-death: alyssa: heh, okay, then maybe I'll drop GRL before you get to that
13:44 mripard: sigh. sure. let's put the blame on an undocumented property on the one that used it I guess.
13:44 sima: yeah the property is extremely not documented
13:44 sima: which this patch set tries to fix
13:44 vsyrjala: i mean the name is literally "RGB...". if that's not enough docs I don't know what is
13:44 sima: and i915 kinda did ... never
13:45 mripard: the RGB is not a good argument. i915 is using Limited 16:235 for bpc > 8 bits, even though that doesn't make any sense
13:45 mripard: but somehow that was ok?
13:45 vsyrjala: it's at least less wrong
13:45 vsyrjala: didn't we also have some earlier series that tried to come up with a new standard prop for all this? what happened to that one?
13:46 vsyrjala: one without such terrible name/semantics
13:46 emersion: there are other cases where a prop enum entry with "RGB" in it is meaningless
13:46 emersion: "Colorspace" IIRC
13:47 vsyrjala: colorspace just sets up the infoframes exactly as requested. so if you tell it rgb, we send "RGB" in the infoframe
13:47 mripard: I guess my question is now then: we have a property that is widely used, and aside from a few historical mistakes, works for everyone
13:47 emersion: user-space can't know whether it's RGB or not, vsyrjala
13:47 mripard: *why* should we need a new one
13:47 emersion: so drivers now ignore the "RGB" part
13:48 vsyrjala: the plan was to come up with a new property. what happened to that one?
13:49 mripard: you're not answering
13:49 vsyrjala: that was a question to emersion
13:49 sima: mripard, btw where's the docs for the color space thing? I seem to be blind
13:49 emersion: vsyrjala: conflating RGB/YUV into the Colorspace prop was a bad idea to begin with
13:50 mripard: sima: the color space thing?
13:50 emersion: even with kernel feedback, there are issues
13:50 sima: mripard, yeah
13:50 vsyrjala: we need new props anyway. so i think if we just keep extending these old crap ones we are painting ourselves in the corner, and we definitely will end up with a totally unusable/confusing uapi
13:50 emersion: e.g. you modeset, kernel decides to switch to YUV, and then there is an intermediate state where the infoframe still signals RGB
13:50 mripard: sima: I'm not entirely sure what you mean :)
13:51 vsyrjala: yes, we all know the Colorspace props is not usable with the automagic yuv fallback. hence the plan to come up with a better prop. i though someone was working on that?
13:51 emersion: i don't think so
13:51 sima: mripard, the docs for the "Colorspace" property
13:52 sima: I've found them, but they helpfully don't have a list of values for that enum so was hard to find
13:52 vsyrjala: the enum values are a direct 1:1 mapping to HDMI/DP specs
13:52 emersion: sorry, i mixed things up, it's not Colorspace, it's COLOR_ENCODING
13:52 sima: I'd just put links there and into the docs for the broadcast stuff
13:52 sima: oh right
13:52 vsyrjala: and the exposed anum values change depending on whether it's DP or HDMI because naturally those don't agree
13:53 emersion: or is it?
13:53 emersion: well, i don't remember
13:53 emersion: some prop somewhere had this issue
13:54 sima: emersion, that's on the plane
13:54 mripard: sima: I'm not using it in my series, so I haven't really looked at it
13:54 emersion: hm, so yeah, "Colorspace" was the culprit probably, sorry for the noise
13:54 emersion: it has "BT2020_RGB" and "BT2020_YCC"
13:54 emersion: at least amdgpu ignores the _RGB/_YCC part
13:54 emersion: not sure what i915 does, but if it doesn't ignore the suffix, it's broken
13:55 vsyrjala: i915 sets up the inforframe exactly as instructed by the prop. nothing else is touched. that is all that prop is supposed to do
13:56 sima: mripard, oh I got confused, I thought we already had a prop to control the state->hdmi.output_format you're adding
13:56 vsyrjala: i think amdgpu attached other meanings to that prop, which is wrong
13:56 mripard: sima: no, so far it's only a set of fallbacks in the code
13:57 mripard: there was some work to let the userpace set it somehow, but it's not merged yet
13:57 zamundaaa[m]: vsyrjala: no, it's up to the driver to make it work, no matter if userspace sets RGB or YCC
13:57 zamundaaa[m]: Userspace literally cannot make it work otherwise
13:58 vsyrjala: no. that is not what that property was added for. people have corrupted it's meaning to be a mess
13:58 emersion: vsyrjala: introducing a prop with no correct way userspace to set it is a kernel mistake
13:58 vsyrjala: hence the plan to add a new property without this mess
13:58 emersion: now it's up to i915 to make it work with the current uAPI
13:58 vsyrjala: yes. we know it's crap. we need a *new* prop
13:58 emersion: no
13:58 zamundaaa[m]: A new property doesn't fix the old property being broken
13:58 emersion: existing compositors are using it
13:58 vsyrjala: there is no way to make that prop work
13:58 emersion: there is, amdgpu does
13:59 vsyrjala: and what happens when you set some xvycc/etc value in there? answer: it's just broken
13:59 zamundaaa[m]: You just don't expose those values if they don't make sense
13:59 swick[m]: I have opinions but am stuck at a meeting
14:00 zamundaaa[m]: Feel free to introduce something that works better, but don't break userspace because it's not a nice API
14:00 vsyrjala: everyone already seemed to agree to add a new uapi. and then somehow people didn't and just extended the broken mess to other compositors in the meantime?
14:08 zamundaaa[m]: The new uapi is about kms offloading, not about signalling. At the HDR hackfest we agreed to just continue using HDR_OUTPUT_METADATA and Colorspace with slight changes to make them useful
14:08 zamundaaa[m]:looks if anyone actually documented those changes
14:11 zamundaaa[m]: boo, they were not documented. I'll write something up later today
14:14 pq: mripard, FWIW, the limited range for non-8-bpc formats is also derived from the 16:235. But the YUV chroma channels do not use 16:235, no matter what bpc. They have a different range for limited. But YUV luma channel does use it.
14:14 vsyrjala: someone needs to then rip out all the non-sensical values from that prop, and figure out what values are actually left and how each interacts with rgb vs. yuv output. for both hdmi and dp since the values are different
14:15 vsyrjala: yeah, 16:235 when thought as a ratio is correct for deep color rgb as well
14:15 pq: vsyrjala, I think that is what amdgpu did when they added support for "Colorspace".
14:16 pq: at least that's where doc patches I recall seeing went
14:16 vsyrjala: we still have all those non-sensical values in the prop. and iirc the last discussion we had concluded that there are problems with the current values in making the automagic yuv fallback actually correct
14:17 vsyrjala: i think the problem was that for non-bt2020 cases there was technically no common colorspace between the rgb and yuv values
14:17 zamundaaa[m]: according to drm_info, amdgpu only supports Default, BT709_YCC, opRGB, BT2020_RGB, BT2020_YCC
14:18 vsyrjala: isn't opRGB the renamed adobeRGB? so that defintiely doesn't make sense
14:18 pq: BT2020_RGB and BT2020_YCC are equivalent, too, but preserved for backward compat
14:19 pq: I'm slightly surprised to see BT709_YCC and opRGB.
14:21 JoshuaAshton: I don't really see why we need a new prop, the old one with the fudging works fine for us on SteamOS.
14:21 pq: if you pretend the nonsense values are not a reflection of anything that could ever be useful, sure
14:22 pq: i.e. it's fine if all you care are "Default" and BT2020
14:22 JoshuaAshton: I think it's fine for the driver to figure out what to send depending on whether YCbCr vs RGB is selected, and I don't see why people are up in arms about it
14:22 JoshuaAshton: What's the usecase I am not seeing?
14:23 any1: JoshuaAshton: Robustness
14:23 JoshuaAshton: Robustness to what?
14:23 zamundaaa[m]: The problem is the other values where the driver can't automatically select these values
14:23 JoshuaAshton: Oh?
14:23 pq: the reasons why the nonsense values exist to begin with, which I don't know
14:23 JoshuaAshton: zamundaaa[m]: Which values?
14:24 any1: JoshuaAshton: When you have poor signal quality, YCbCr is likelier to work.
14:24 JoshuaAshton: Ok?
14:24 pq: any1, this is not that.
14:24 JoshuaAshton: ^
14:24 pq: https://drmdb.emersion.fr/properties/3233857728/Colorspace
14:24 any1: Oh, ok.
14:24 zamundaaa[m]: But IMO if there's an actual use case for those broken values, adding a new property when userspace actually knows and/or controls YUV vs RGB, would be the way to go, and not removing the one that's being used right now
14:24 zamundaaa[m]: JoshuaAshton: RGB_Wide_Gamut_Floating_Point would be one of the broken values for example
14:25 JoshuaAshton: This is about the vsc colorimetry infoframe not the pixel encoding format
14:25 JoshuaAshton: zamundaaa[m]: The legacy thing that to my knowledge nothing ever implemented in any physical display?
14:26 JoshuaAshton: I could definitely be wrong about that, but I have never seen it on the myriad of analysers and reference displays
14:27 pq: any1, "Colorspace" property does not control RGB vs. YUV at all. The problem is, most of its values are correct only for either RGB or YUV, and userspace won't know nor control which signal color model the driver picks.
14:28 zamundaaa[m]: I don't know which ones in that list are actually a thing in practice, just that they're nonsense
14:28 JoshuaAshton: Oh I totally agree that they are nonsense to be exposed at all :D
14:29 pq: The "Colorspace" values exist in HDMI and DP specs, but this is not a usable UAPI for setting most of them.
14:32 JoshuaAshton: I don't think it makes sense for userspace to set most of these anyway...
14:33 JoshuaAshton: Really it makes more sense to just expose eg. { "Default" "BT2020" "BT709" "DCI_P3" }, then we can actually have conversations about other values when a usecase arrives...
14:33 JoshuaAshton: rather than bunging random infoframe enums into drm properties in some flawed way
14:34 JoshuaAshton: I think we can still salvage the current property, by just deprecating the other variants completely and giving them a name like "Reserved1" or whatever
14:35 JoshuaAshton: Then, no driver would expose those enum values as supported, and if userspace tried to use them, it'd just get rejected because its not supported.
14:36 JoshuaAshton: That's really the only way without breaking uAPI or introducing a new prop
14:38 JoshuaAshton: I guess there might be userspace stuff using DP_COLORIMETRY_BT2020_YCC right now actually... nevermind, bleh
14:40 vsyrjala: how would DCI_P3 even work with yuv fallback?
14:41 JoshuaAshton: I don't think it would -- it's intended for eDP on mobile displays from what I recall
14:42 JoshuaAshton: Which don't ever do chroma subsampling/non-RGB pixel formats, so it was never added as it was never needed
14:42 DemiMarie: For KMS my biggest concern is ensuring that the kernel is secure against malicious displays.
14:42 JoshuaAshton: malicious displays are not a concern with any of this
14:43 DemiMarie: Yeah
14:52 vsyrjala: so is someone this time actually going to go and rip out most of values from those props and fully document how each reamining value interact with both inforames/msa/vsc and the actual output signal?
14:53 daniels: if a display wants to display something other than what it gets fed, there are easier ways to do that than gaming colorimetry
14:53 sima: yeah "this is how it's actually used" docs for "Colorspace" would be great
14:53 daniels: ^
14:53 sima: I was screaming quite a bit at the docs since I couldn't believe at first that was there was the actual docs and kept looking for the real thing
14:54 vsyrjala: does anyone recall who was working on that unified not-'Broadcast RGB' quantization range prop?
14:54 sima: bonus points if the common code then does stuff like limit DCI_P3 to eDP like JoshuaAshton said and stuff like that
14:54 vsyrjala: i can't seem to find the series in my mailbox right now
14:54 JoshuaAshton: vsyrjala: I think swick[m] was?
14:54 vsyrjala: i don't know why eDP is a factor here. eDP could use YCbCr as well
14:55 pq: Are you confusing not-'Broadcast RGB' with the new color pipeline design?
14:55 JoshuaAshton: oh nvm
14:55 JoshuaAshton: he was just involved
14:55 JoshuaAshton: https://lore.kernel.org/dri-devel/20231207-kms-hdmi-connector-state-v5-8-6538e19d634d@kernel.org/
14:55 vsyrjala: pq: no. there was a proposal for a property like that quite a while back
14:56 pq: huh, cool
14:56 vsyrjala: i wanted to check if the plan there was to cover ycbcr as weell
14:56 vsyrjala: but i guess the whole thing fell through the cracks
14:56 JoshuaAshton: vsyrjala: To clarify, yes it can, but the purpose of it is mainly for Android phones etc, and those type of mobile displays only accept RGB.
14:56 JoshuaAshton: The check should probably only allow DCI_P3 if the display is RGB only
14:56 JoshuaAshton: Not eDP
14:57 vsyrjala: i wouldn't add anyhting that conditional into the uapi until we know it's really needed
14:57 vsyrjala: hence why i think wiping the slate clean would have been the right approach all along
14:58 JoshuaAshton: Sure, I would go as far as to say that we pull that for now even, and just keep it to { Default, 709, 2020 }
14:58 pq: how is 709 different from "Default"?
15:00 JoshuaAshton: pq: Fair point...
15:01 JoshuaAshton: There is no difference in the dp vsc enum for that, default is 709, but I think it makes sense to have Default separate regardless though so we don't ruin our chances of implementing stuff that is non-DP or non-HDMI down the line
15:02 pq: hmm... but what would be the definition of "default" then? How would you render for it?
15:02 JoshuaAshton: Consider that the "un colormanaged default" :b
15:03 pq: usually "default" is needed when drivers picked something automatically before implementing the propr, and not all drivers agreed to do the same thing.
15:03 JoshuaAshton: I mean... it's worth noting that even if you send 709 vsc colorimetry to most displays, you actually just get their native gamut
15:03 JoshuaAshton: so maybe we just don't even encode 709 and just have "Default"..?
15:04 JoshuaAshton: * @DP_COLORIMETRY_DEFAULT: sRGB (IEC 61966-2-1) or
15:04 JoshuaAshton: * ITU-R BT.601 colorimetry format
15:04 JoshuaAshton: I guess you are just informing the display of the container colorspace of what you are sending -- so actually it being native gamut is just their interpretation ;b
15:04 pq: "no idea", yeah, ok. Just get something out.
15:05 pq: funny that doc, since sRGB, BT.601 and BT.601 are all different.
15:06 pq: yes, I said BT.601 twice.
15:07 vsyrjala: because of the revisions?
15:07 pq: PAL vs. NTSC aka. 525 vs. 625(?) lines
15:07 vsyrjala: did 601 have ntsc stuff in it too?
15:07 pq: IIRC
15:08 pq: I think it just happens to match NTSC primaries & white point
15:08 vsyrjala: i know it originally didn't specify a bunch of things, but later revisions added them
15:08 pq: they share the CICP value
15:09 pq: H.273 is my cheatsheet nowadays
15:33 pq: Why wouldn't DCI_P3 work with YUV? Just pick any RGB->YUV matrix. Or is that about what hardware interface specs actually support?
15:34 pq: vsyrjala, IIRC it was hwentlan who went through the pains of trying to understand "Colorspace" the last time.
15:36 vsyrjala: dci-p3 == rgb, according to dp and cta-861
15:37 pq: nothing stops anyone from taking that and converting to YUV
15:37 swick[m]: so, finally had time to read the backlog
15:37 swick[m]: but yeah, we changed the meaning of Colorspace and HDR_OUTPUT_METADATA to be usable now
15:38 vsyrjala: pq: but you can't then tell the display that it's dci-p3, because to do that you have to tell it that you're transmitting rgb
15:38 swick[m]: doing the Colorspace selection properly simply requires use space to have control over the cable format and we don't have that
15:38 swick[m]: nor was there an easy way to get there
15:39 pq: vsyrjala, ok, so it's about signalling specs.
15:40 swick[m]: but user space should get control over the cable format, and there should be properties that control only the infoframe and not the color pipeline etc
15:41 swick[m]: and we also should start versioning the API or something so we can throw away a bunch of properties and not have to worry about their interactions
15:42 swick[m]: versioning, or caps, I don't really care, but we need this for the color pipeline api anyway
15:42 vsyrjala: just defining a new prop with a _different_ name, and ripping out the old one should be all the versioning you need
15:43 swick[m]: the ripping out the old one is the issue
15:43 vsyrjala: meh
15:43 zamundaaa[m]: vsyrjala: compositors are using the old one right now. Removing the property is a uAPI break
15:43 swick[m]: hence, versioning or caps
15:43 swick[m]: and we kind of should probably start doing that rather sooner than later
15:45 vsyrjala: zamundaaa[m]: so is changing the meaning of the uapi randomly
15:45 vsyrjala: at least when you rip it out you will know whether anything works or not
15:46 zamundaaa[m]: It's not a uAPI break to change something broken to work
15:46 zamundaaa[m]: Noone is relying on the property sometimes not doing the expected thing, depending on variables the compositor has no control over
15:47 daniels: I believe Kodi uses the old one and very much expects that behaviour to not change, even if it is objectively bad
15:47 zamundaaa[m]: Kodi too is not relying on BT2020_YCC to not work with rgb signalling
15:47 swick[m]: how can it? you select a Colorspace that's depending on the pixel format but you get arbitrary pixel formats
15:48 swick[m]: indeed
15:48 vsyrjala: zamundaaa[m]: i915 implements the original uapi. so if someone now runs one of those compositors on i915 it will not work
15:48 swick[m]: it didn't work before
15:48 swick[m]: that's the entire point
15:48 swick[m]: there is literally no way anyone uses the Colorspace prop on i915 and it works
15:48 vsyrjala: it did because the compositor wouldn't try to use those properties
15:49 swick[m]: if a compositor uses them or not is however not in control of other drivers
15:49 swick[m]: sorry, but this is just not a useful conversation to have
15:49 zamundaaa[m]: If you really insist on not fixing the property, then removing it entirely from i915 is indeed the right thing to do
15:49 vsyrjala: it can't be fixed until someone redefines it property
15:50 vsyrjala: *properly
15:50 swick[m]: it is defined properly now
15:50 swick[m]: it's not great, but it works
15:50 vsyrjala: no. it has a kinds of values that can never work
15:50 swick[m]: and no one has to expose them
15:50 vsyrjala: and no one defined what values are supposed to be left, and how they work
15:51 swick[m]: we kind of did, but failed at documenting it, so that's fair
15:51 zamundaaa[m]: The documentation definitely needs updating to reflect userspace expectations, and I'll volunteer to do that
15:52 zamundaaa[m]: But i915 either needs fixing, or you need to at the very least stop advertising the property at all
15:53 vsyrjala: i can "fix" it once someone comes up with a solid idea what it should look like.
15:54 zamundaaa[m]: In terms of what's actually relevant for userspace in practice, just select the correct BT2020 variant, no matter if userspace sets BT2020_YCC or BT2020_RGB
15:54 vsyrjala: bt2020 is the easy part. it's the rest that's a huge mess
15:55 zamundaaa[m]: Indeed, but the rest also isn't actually used by anyone
15:55 vsyrjala: well, supposedly there is at least one value outside those two that has to work in a consistnet way
15:55 zamundaaa[m]: That would be "Default", which I think doesn't need fixing
15:56 vsyrjala: it needs to be defined what colorimetry we signal in each infoframe/msa/vsc case, and what we are supposed to transmit
16:02 vsyrjala: in the future i hope no one will again make backwards incompatible changes to an existing property. if we had defined a new property with the new semantics then i915 would not have gotten broken by compositors starting to use those new semantics
16:03 emersion: all we made is make an existing property more sensible
16:04 emersion: the cost of introducing a new prop is too high just to fix this
16:04 swick[m]: the problem is that adding a new one would also have been no great because it would still rely on the kernel to figure out the actual infoframe to send
16:05 vsyrjala: we have literally ended up doing all the work you would have to do for a new prop. +500% more arguing
16:05 swick[m]: so we'd have to add one more once we give user space control over the cable format and exclusive control over the color pipeline
16:05 zamundaaa[m]: FWIW I think a better way to do this could've been to introduce a new enum value, "BT2020", without RGB or YCC
16:05 zamundaaa[m]: But it's too late for that now
16:06 swick[m]: ah true
16:06 emersion:shrugs
16:06 emersion: a new enum value would be new uAPI, which means new IGT tests and all of the bikeshedding
16:07 vsyrjala: there are igt tests for this modified behaviour?
16:07 emersion: this vs. just making things work when they were nonsensical before
16:07 emersion: if there are any IGT tests, they'd be broken if the driver picks YUV either way
16:07 emersion: ie, flaky
16:09 emersion: anyways, i'll go do other stuff now, i have nothing else to add, and still think it was a perfectly reasonable choice
16:09 zamundaaa[m]: Would everyone here be okay with... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/bVunKnYZWCCQEIjvJDlNmtcr>)
16:10 swick[m]: perfect
16:11 emersion: sgtm
16:11 emersion: actually, the last bit may make userspace more complicated
16:11 emersion: maybe better always expose both
16:12 zamundaaa[m]: Okay, then I need to describe what I mean with that better
16:12 zamundaaa[m]: Because I'm referring to values like opRGB, where no YCC variant exists at all
16:13 zamundaaa[m]:sent a code block: https://matrix.org/_matrix/media/v3/download/matrix.org/OpcIyYAKRiGPDpIVMkMDPYQg
16:14 vsyrjala: what i'd want to see is "these S are the exactly set of enum values that you can use, they mean exactly X when transmitting RGB, and exactly Y when transmitting YCbCr"
16:14 vsyrjala: + make the property registration filter out/reject all the other values
16:22 zamundaaa[m]: I don't think writing such a table is really necessary. The rule for when to use which is quite straight forward
16:36 Company: alyssa: I wrote a new renderer for GTK, and it's apparently a *lot* slower specifically on Asahi - any idea what could cause specifically asahi to be slow?
16:36 Company: alyssa: context: https://gitlab.gnome.org/GNOME/gtk/-/issues/6413
16:59 Company: it turns out it might be that people are using flatpaks and flatpak on asahi still uses software rendering
17:49 alyssa: Company: yeah the flatpak thing would do it
17:50 alyssa: for the !flatpak case.. IDK, can someone get me an apitrace?
17:50 Company: is there a tool to check GPU load?
17:52 alyssa: no(t yet)
17:53 alyssa: though that's probably not the actual problem, IME
17:53 alyssa:fixed a bunch of stupid stuff in the past month, would like to check perf on asahi-next
17:53 Company: alyssa: you could compile gtk4 yourself and make an apitrace btw :)
17:54 DemiMarie: Company: So Asahi is probably just the canary in the coal mine here, Qubes OS is going to be hit just as hard.
17:54 Company: asahi-next the kernel or asahi-next Mesa?
17:54 alyssa: mesa
17:56 Company: DemiMarie: I'm aware - the new renderer is terrible with slower GPUs (read: software rendering)
17:56 Company: but I'm trying to fix the small things first so it's good enough for the 4.14 release
17:56 Company: and then I'll look at adding a fastpath for those things
18:00 DemiMarie: Company: some way to keep software rendering at least usable would be great
18:01 Company: you can always switch to the old renderer
18:01 DemiMarie: is there a way to do that system-wide, maybe via an env var?
18:01 DemiMarie: and will the new renderer be at least usable before the old renderer is removed?
18:03 Company: it depends on what you mean with usable
18:05 sima: pq, https://lore.kernel.org/dri-devel/20240209165307.29856-1-xaver.hugl@kde.org/ since you're not on the cc list afaict
21:33 DemiMarie: Company: usable = “users will be able to get work done and Qubes OS doesn’t get a ton of bug reports”
22:08 Company: DemiMarie: the problem you will ultimately run into is that GTK is going to be modern GL/Vulkan, so you will need to either use GPUs or make sure the software renderers are capable enough
22:09 Company: but nobody works on optimizing those things, so I don't think it's a high priority
22:12 Company: note that I'm not harping on Qubes in particular here, there's a few different groups that claim they want these things
22:12 Company: there's random people who run age old computers for whatever reason
22:12 Company: and there's the kiosk use case
22:13 Company: which is usually just a thin client connecting to some cloud thing
22:57 KungFuJesus: Just curious, does v3d have a chance of getting the DualSrcBlend & TesselationShader features in Vulkan?
22:58 KungFuJesus: i.e. is the hardware capable of it, or are all of the hardware capabilities features for vulkan already exposed?
23:49 alyssa: KungFuJesus: dual src, absolutely yes
23:49 alyssa: tess is... complicated
23:59 KungFuJesus: of course, with a 16k page kernel, the vulkan driver spits a hung kernel stack trace and basically hangs the system. With a 4k page kernel, it crashes X and Wayland but the system kind of survives
23:59 KungFuJesus: not entirely sure what to make of that, yet