03:00 jenatali: Meanwhile Dozen is >99% passing on hardware (NV). So close
03:12 HdkR: \o/
05:19 CounterPillow: \o/
06:21 tomeu: karolherbst: maybe armnn? but don't really know
06:52 tomeu: karolherbst: btw, there is a discussion here on the perf of int8 dot-products on Mali: https://community.arm.com/support-forums/f/graphics-gaming-and-vr-forum/9994/how-to-calculate-gflops-gops
10:28 karolherbst: tomeu: right... and spir-vs with that are already supported, I'm mostly wondering if I can test the arm version of that extension
11:11 sima: emersion, the async you commented on means tearing, usually the async on cursor means "allow more updates to hit the same frame"
11:21 pq: sima, does cursor-async then not allow cursor tearing?
11:24 sima: the one we currently have doesn't really
11:25 sima: well, it maybe does
11:25 sima: cursor-async is still a giantic mess :-/
12:00 zamundaaa[m]: Tbh whether or not the cursor actually tears is quite irrelevant to me at least
12:01 zamundaaa[m]: "Async" cursor updates + tearing on other planes would be enough
12:03 zamundaaa[m]: Hmm actually, as that's already allowed with the legacy cursor ioctls, is there any reason not to allow that with all drivers that support async?
12:08 Venemo: gfxstrand, zmike, alyssa, mareko Do you guys think there is any interest left in supporting NV mesh shaders in either VK or GL? if not, is it okay if I open a MR to delete its remnants?
12:27 zmike: it might be neat to support on zink+nvk at some point? I could imagine someone taking it as a hobby thing
12:29 Venemo: I know there are some users who want it
12:29 Venemo: if there is some willingness to eventually support it, I say let's keep the common parts of it for now
12:30 zmike: I'm not 100% against it since there's apparently that minecraft mod
12:47 CounterPillow: Doesn't Alan Wake 2 use mesh shaders extensively?
12:55 pixelcluster: mesh shaders themselves are still going to be supported
12:57 sima: zamundaaa[m], we could wire those up for drivers that support async on cursors
12:57 sima: once the infra for async=tearing for cursors gets there
12:57 sima: atm it's kinda the other async
12:57 sima: or if that doesn't work, a terrible hack that I should never have landed because it breaks the atomic state structure lifetime rules really badly
13:06 zamundaaa[m]: <sima> "atm it's kinda the other async" <- That doesn't matter though. Noone cares if the cursor actually does tearing
13:07 zamundaaa[m]: I'm saying it's fine to have tearing primary plane + "mailbox" cursor, in the same commit
13:08 sima: zamundaaa[m], yeah I got that, just wanted to add a bit of detail
13:08 sima: zamundaaa[m], the other thing is that at least in the drm core parts, cursor is just a plane with a flag so it's used for legacy cursor ioctls
13:08 sima: which means on many hw it's actually a full sized plane and can be used as such
13:09 sima: and there this combo is probably not what you want at all
13:09 sima: for small cursor planes it doesn't matter whether you tear or not, but if your cursor plane is the main game scene it kinda does
13:09 pq: cursor tearing can manifest as half a cursor at the top of the screen, and another half at bottom of the screen, right? Since it's not just tearing plane content update, but also plane moving?
13:10 pq: or even multiple cursor images on the same refresh cycle
13:11 sima: pq, I guess you could even have like two cursors at the same time
13:11 sima: or multiple teared ones
13:11 sima: like if you move in sync with scanout, you could probably have a _lot_ of teared partial cursors
13:36 Company: I'm confused
13:37 Company: Epiphany uses dmabufs to communicate between web process and ui process, and it uses dmabufs for that
13:37 Company: and it uses gbm to allocate these
13:38 Company: apparently on "Intel Corporation Raptor Lake-P [Iris Xe Graphics]" this selects a 3-plane dmabuf format
13:38 Company: but the Vulkan code can't import it
13:39 Company: and my TigerLake claims it can't import disjoint dmabufs
13:40 emersion: you need to check whether the FDs are the same memory object
13:40 emersion: then use a non-disjoint Vulkan import
13:41 emersion: see wlroots code for example
13:41 Company: so I get different fds and then have to figure out if they are the same thing?
13:41 emersion: the FDs will always be different
13:41 emersion: as in, the file descriptor numbers
13:41 Company: yeah, that's what I mean
13:42 Company: I've gotten dmabufs with the same fd numbers
13:42 emersion: if you send the same FD twice over a Unix socket, the other side will get two different file descriptors
13:42 emersion: same as dup()
13:42 Company: ah yeah - might have been libv4l or something then
13:43 emersion: different FD number doesn't mean different underlying memory object
13:43 Company: sure
13:43 emersion: and Vulkan's disjoint only cares about the latter
13:43 Company: I can fix that, I just need to figure out what to care about
13:43 Company: do you know which file in wlroots?
13:44 emersion: https://gitlab.freedesktop.org/search?search=VK_IMAGE_CREATE_DISJOINT_BIT&nav_source=navbar&project_id=12103&group_id=9759&search_code=true&repository_ref=master
13:44 emersion: somewhere around here
13:44 daniels: yeah, wlr is about the only place I've seen it handled correctly
13:45 Company: I didn't even know that's how it's meant to work
13:45 emersion: the meta is definitely to assume that all planes are the same memory without checking anything, and then pray for the best :P
13:46 emersion: the spec doesn't exactly help understand this stuff sadly
13:46 Company:did the opposite and avoided the praying in favor of black screens
13:46 Company: even if the spec did, it'd be hard to find because it's so huge
13:46 pq: ooc, why doesn't Vulkan check that itself?
13:47 Company: Vulkan wants you to add a flag to vkCreateImage() which is before it sees the fds
13:47 Company: the fds only appear once you bind memory I think
13:49 daniels: Vulkan dmabuf import is at least -3 on the canonical scale https://web.archive.org/web/20110721134718/sweng.the-davies.net/Home/rustys-api-design-manifesto
13:49 sima: emersion, didn't we have a discussion about kcmp syscalls about this topic?
13:50 sima: there's plenty of -5
13:50 sima: if you include cache coherency there's still plenty of -10
13:50 pq: I remember kcmp has been mentioned in the past few years.
13:50 emersion: i just use GEM handles to tell
13:50 emersion: iirc
13:51 sima: emersion, yeah but that needs a driver that doesn't refuse the import
13:51 sima: but I guess at that point you don't care anymore anyway
13:51 Company: daniels: "at least" is doing a lot of work in that sentence
13:51 daniels: Company: I'm feeling generous today
13:51 Company: daniels: there are a bunch of places that hit -7
13:51 sima: I mean the goal of dma-buf was to at least sometimes, make the formerly impossible possible
13:52 Company: like this one
13:52 sima: we got that :-D
13:53 daniels: sima: I thought the goal of dmabuf was to be a totally universal allocator that would solve all known problems
13:54 sima: nah we punted that to userspace :-P
13:54 Company: and now we're closer to world peace than to that
13:55 pq: that's a really nice gradient on the background of that webarchive page
13:55 Company: anyway, I'm going to get this working, dmabufs haven't defeated me yet and they won't in the future
13:55 sima: daniels, like the reason behind the "every driver yolos its own dma-buf exporter" was because the universal allocator was impossible
13:56 daniels: sima: i know, i know :)
13:57 sima: I'm kinda still surprised how often we actually managed to make it work
13:57 daniels: but yeah, I probably shouldn't make statements like that without explicit sarcasm indicators, given how much people seem to assume that 'dmabuf will translate my poorly-expressed hopes and dreams into proper solutions' is actually the intention and/or reality
13:57 sima: and how little we had to break given some of the really horrendous first implementations
13:58 daniels: well yeah, we did make it mandatory right
13:58 daniels: I mean, it's not some weird luxury option that you can enable if you're really fancy; it's something you need if you want to display anything at all
13:59 sima: dumb buffer + memcpy would still work
14:00 sima:should also enable the sarcasm indicator on all of this
14:05 Company: if people would spend a bit more time talking to each other, this would already improve things massively
14:05 Company: just because of the knowledge transfer
14:06 Company: because this channel is pretty much the only place where I can figure these things out - and only if I'm lucky and the right person sees this
14:13 MrCooper: emersion Company: I'd say GEM handles is the only way to be sure — even if the file descriptors reference separate dma-buf file descriptions, they could still reference the same underlying BO
14:14 emersion: yeah, it should be more reliable
14:14 Company: oof
14:15 Company: I'll wait for PFN_vkCheckDisjoint
15:00 hwentlan: Does anyone know who is responsible to ensure tiled display connectors are programmed in a consistent fashion, e.g.: that color management is programmed the same for all tiles? Should the DRM/KMS driver ensure that or userspace (DDX or compositor)?
15:03 pq: hwentlan, I would assume it's just a userspace convention since end users probably don't like it otherwise, and no other reason nor guarantee. Not that I've heard.
15:04 zamundaaa[m]: hwentlan: do you know what a display would do if you set one part with PQ as the TF but not the other?
15:05 zamundaaa[m]: If that works at least somewhat decently, definitely leave it to userspace to do it correctly
15:05 pq: hwentlan, what do you mean with color management, though? infoframe data?
15:06 hwentlan: we got an issue on some panel where color differs on the two tiles of a tiled display
15:06 hwentlan: the color differs because the crtc color management property (LUT or CTM, not sure) is only set on the master tile
15:07 hwentlan: the question is: is userspace messing up or should DRM/KMS propagate the master tile property to the other tiles
15:07 pq: oh that - definitely userspace, I'd say.
15:07 hwentlan: yeah, that would be my call as well
15:07 hwentlan: if userspace understands tiles it should ensure consistency
15:07 pq: I would not expect the kernel to even understand that the two connectors are the "same display" to begin with.
15:08 emersion: yeah, it's questionable why "tile" is a thing to begin with…
15:08 emersion: as a KSM prop i mean
15:08 emersion: KMS*
15:08 pq: ...I didn't know it's even a prop
15:09 hwentlan: on other OSes the driver will read the tiled display info and present the two tiles of a tiled display as one single output to the OS
15:09 zamundaaa[m]: emersion: probably because of the lack of good EDID parsing library when it was introduced
15:09 hwentlan: so I could see a solution where the driver abstracts that away entirely
15:10 hwentlan: but the solution that was built in KMS seems to put the ownership entirely onto userspace
15:10 pq: IMO either the kernel abstracts nothing here, or it abstracts everything by exposing all physical tiles on the same KMS connector, so userspace does not need to care. And then under the hood use as many CRTCs as it needs, and then it can even do gen-lock.
15:10 emersion: intel will try to gen-lock iirc
15:11 emersion: but there's no need to expose a TILE prop for that
15:11 hwentlan: amd hw will lock the timings as well. it will do so for any (DP) output where the timings are identical
15:11 emersion: ideally, gen-lock would be a KMS prop…
15:12 pq: is it possible that tile information can come from elsewhere than EDID?
15:12 pq: like DT?
15:12 emersion: good question
15:14 zamundaaa[m]: What's DT?
15:14 pq: device tree
15:26 hwentlan: fwiw, a quick grep only shows me what looks to be the "TILE" property in mutter code, not in sway, weston, kwin
15:27 zamundaaa[m]: yeah, supporting tiled displays is a very old task of mine for KWin
15:28 pq: weston doesn't do tiled monitors
15:28 zamundaaa[m]: It clashes with a bunch of KWin's abstractions and hasn't received enough attention yet
15:29 pq: heh, yeah, it's yet another level of abstractions, I remember seeing Mutter stuff years ago
15:32 shashanks: I guess it would be a good idea to implement a property like this only when the driver and the DDX/Compositor are in sync. It doesn't make sense to bet of half-baked implementations or do something for time being.
15:32 shashanks: This is not limited to just the CM props, but it needs to be implemented for each transformation
15:33 shashanks: Like rotation, scaling and everything else which can transform one CRTC/connector
15:33 pq: shashanks, what do you mean?
15:34 shashanks: I mean,if a user applies 90 rotation on one connector/CRTC, this should be duplicated on the tiled display as well, isn't it ?
15:35 emersion: that's up to userspace really
15:35 pq: yes, but it's userspace's responsibility, if the driver needs userspace two drive two connectors.
15:35 shashanks: that's the point, I don't think userspace can do every transformation, is there a userspace which does it already ?
15:37 zamundaaa[m]: Of course userspace can do every transformation
15:37 pq: userspace *chooses* the transformations
15:37 shashanks: then probably userspace will have to do a atomic_check on tiled display to see if that's even possible
15:37 shashanks: what if the HW has one scalar and we need two for the tiled display scaling
15:37 zamundaaa[m]: You need two whole crtcs to drive a tiled display
15:38 zamundaaa[m]: And yeah, userspace does need to do an atomic check to see if it can do hardware rotation, scaling and whatnot. There's no difference to a normal display (or rather, two normal displays)
15:38 hwentlan: userspace could always use GPU for the transform, if needed
15:38 hwentlan: e.g., in the hypothetical scenario of having two crtcs but one scaler the fallback path should be for userspace to do GPU scaling instead
15:39 shashanks: I am curios to see if there is a compositor who is handling it already ? Any suggestions ?
15:39 hwentlan: or, alternatively, to reject a config that requires scaling
15:39 zamundaaa[m]: shashanks: KWin scales and rotates with the GPU by default, and uses KMS for direct scanout if possible
15:40 hwentlan: shashank: I wonder if the "tiled discoloration bugs" should be filed as bugs with mutter in this case
15:40 shashanks: zamundaaa[m]: I mean for tiled displays
15:40 pq: hwentlan, yes.
15:41 shashanks: hwentlan: I am afraid that we will end up doing this for every tiled display test case in the end
15:41 hwentlan: this seems to be related: https://gitlab.gnome.org/GNOME/mutter/-/issues/1626
15:42 pq: shashanks, it doesn't matter, it's the right thing to do. Do not try to "fix it" in a driver.
15:42 hwentlan: I think with the way the TILE property was designed ten years ago it would have to work this way
15:42 hwentlan: alternatively we could consider abstracting all the TILE stuff away in the driver, but I'm not sure how to do that without fighting with DRM core
15:43 hwentlan: would need some way to tell DRM core to ignore tiling stuff and let the driver handle it
15:43 shashanks: hwentlan: https://gitlab.gnome.org/GNOME/mutter/-/issues/1626 this issue says mutter does it under X11 but not under weston
15:43 pq: I agree: either expose TILE and let userspace handle everything, or handle everything in the driver. No middle-ground.
15:43 zamundaaa[m]: hwentlan: you'd have to take away CRTCs from userspace
15:44 zamundaaa[m]: That's not gonna happen, userspace just has to do things correctly
15:44 pq: zamundaaa[m], CRTC stealing etc. is already a thing, at least on intel
15:44 zamundaaa[m]: :(
15:44 hwentlan: we steal pipes all the time as well
15:44 pq: you just fail to enable a CRTC that you thought was still unused
15:44 hwentlan: we do pipe split when it makes sense (for power, or because we need another pipe for a high pixel clock)
15:44 pq: ...once all CRTCs are actually used
15:44 hwentlan: and then reject atomic commits if we can't support the config
15:45 hwentlan: so all crtcs still look available, but you'll fail at atomic config
15:45 hwentlan: Manasi had a presentation about i915 pipe splitting for high-pixel-clock timings at XDC a few years back
15:45 shashanks: IIRC I915 applies the transformations on ganged-pipes in the driver, i think that's the stealing CRTC thing
15:46 hwentlan: amdgpu also applies transformations on "ganged pipes" in the driver, but only for ganged pipes the driver controls
15:46 zamundaaa[m]: we really need more feedback from atomic tests if that's the case. KWin will kind of handle such a situation, but not that well. EINVAL is not very expressive after all
15:46 hwentlan: the tiled display "ganging" isn't controlled by the driver
15:47 shashanks: hwentlan: what do you mean by that ?
15:47 hwentlan: we do need more info from atomic tests... but how to do that sensibly is a hard part
15:47 hwentlan: the AMD display driver will sometimes decide to use two pipes to drive one output
15:47 hwentlan: that output will be a single connector
15:48 pq: zamundaaa[m], what could you do if you knew, though?
15:48 hwentlan: but in the background we'll use two (or more) pipes to drive it
15:48 hwentlan: in this case the driver will ensure those pipes are programmed consistently
15:48 hwentlan: for tiled display we have two outputs
15:48 hwentlan: for the driver it looks like two independent outputs as it has no concept of tiled displays
15:48 shashanks: hwentlan: I understand that part of ganging, but why do you say tiled displays are not controlled by driver, what is different here ?
15:48 hwentlan: userspace controls the tiled displays and treats them as a single one
15:49 zamundaaa[m]: pq: I'd be able to just remove a crtc without testing the world beforehand
15:50 pq: zamundaaa[m], how about when lighting up a new output, start with the simplest possible configuration?
15:50 zamundaaa[m]: In the worst case, KWin can take up to a few seconds searching for connector<->crtc connections. And that's with assuming it can use all the crtcs
15:51 pq: ...seconds?
15:51 shashanks: hwentlan: Ok, I guess I had a mixed-up understanding on tiled display vs ganged-displays and I was mostly using that interchangeably.
15:51 zamundaaa[m]: Yes, seconds. I haven't encountered that in the wild yet, but for some of these tests, we have to allocate buffers
15:51 hwentlan: shashanks: the difference is that in the driver-controlled case the driver sees one connector and the driver reports one display to userspace. in the userspace-controlled case (the tiled display case) the driver reports two separate displays and userspace enables two separate connectors. the driver isn't aware currently that the two connectors are supposed to be the same
15:52 zamundaaa[m]: With more feedback we'd also know whether or not we're crtc-count restricted or bandwidth restricted
15:52 zamundaaa[m]: In the latter case, reducing the mode resolution or refresh rate could help, in the former, buffer allocations + atomic tests for these different modes would just be useless
15:53 hwentlan: Leo (not sure what his nick is) has been battling with long atomic checks in libliftoff as well. seems similar to the issues you're having in kwin
15:53 shashanks: hwentlan: yep, in this case it makes sense that the userspace handles mimicking of the transformations for tiled-displays (as driver is unaware if it), whereas driver does it for ganged-displays
15:53 hwentlan: lileo, ^^
15:54 hwentlan: shashanks, agreed
15:54 hwentlan: and we could consider pushing tiled display handling into the driver so it's treated like other ganged-display scenarios. but that would be a fair bit of work
16:04 zamundaaa[m]: hwentlan: it's in the scrollback, search for "what do you think of output properties in atomic ioctl?" on January 11th
16:05 zamundaaa[m]: sima: do you have a more concrete proposal written up anywhere yet?
16:07 zamundaaa[m]: It is hard when you have a whole compositor + effects ecosystem that assumes one logical output == one render output
16:07 zamundaaa[m]: We've slowly been moving away from that, for other reasons too, but it's not that simple. Or at least not fast to do
16:08 zamundaaa[m]: That describes about 80% of the problems we're dealing with in the graphics stack :D
16:09 hwentlan: I'm not sure what you mean with one logical output == one render output?
18:27 Company: from the "fun with Vulkan renderers" department, today: 23.3's Intel Vulkan renderer doesn't support the modifier that its GL renderer picks by default for AR24
18:28 Company: 0x0100000000000008
18:28 Company: 24.0 does
18:42 log123: Hello, not sure if this is the right place to ask but i'm trying to get NVK working on my setup, its got dual graphics and the IGP is detected by RADV fine but the dGPU RTX 2060 Max-Q [10de:1f12] seems to not get picked up for some reason, the OpenGL driver works as verified by switching with DRI_PRIME, I'm on kernel 6.7 running Mesa Git, but the kernel/mesa versions don't see to matter, i've tried 6.8 RC-2 and Mesa Stable also
18:43 log123: by dual graphics i should probably specify its an optimus non MUXed setup
18:54 daniels: Company: that’s why you have to check what all consumers support and pass that acceptable list to the producer when you allocate
18:58 Company: sure, technically webkit needs to send webkit its Mesa config so that it can check with Mesa to get a matching config to Mesa, so that the webkit can then send the matching Mesa config back to webkit so it can ensure Mesa can display the buffer
19:00 Company: or we just fallback and let the users complain to Mesa or Mesa that their Mesa config doesn't match Mesa's config and then the Mesa devs can make sure that Mesa can to the same thing as Mesa
19:00 Company: the Vulkan switch will be fun at least
19:02 Company: I do think that drivers should support the same dmabuf formats for Vulkan and EGL - and specifically pick a default format that both support, just to make issues like this not appear
19:03 Company: but I also think that it's so far not been an issue because there's not enough usage of Vulkan that it's worth not shipping a new modifier in EGL just because the Vulkan driver isn't ready
19:06 emersion: Company, there will always be situations where EGL doesn't match Vulkan in terms of format support
19:06 emersion: it's two separate codebases really
19:07 emersion: the classic one is radeon adding a format or modifier before RADV gets the chance
19:07 emersion: also maybe a format is really difficult to support in GL, but easier in Vulkan
19:08 emersion: or the other way around
19:08 emersion: depending on its usage
19:10 Company: sure, but it's also a bad idea to just assume everybody will surely do proper negotiation and just choose a default format at them that you know is unsupported by either of the two
19:12 emersion: it's a good way to ensure everybody is doing the right thing
19:12 emersion: the bug isn't in mesa for sure
19:12 zamundaaa[m]: It's a much worse idea to not do format modifier negotiation at all. The OpenGL component might be using an entirely different driver (like the proprietary AMD OpenGL one), or even a different GPU
19:12 emersion: or maybe it's coming from flatpak runtime or w/e
19:13 Company: considering that even Mesa can't do proper negotiation yet, I'll just wait for that to happen
19:13 emersion: what do you mean by mesa can't do proper negociation?
19:13 emersion: s/c/t/
19:14 zamundaaa[m]: Company: format negotiation is up to the clients allocating buffers, not Mesa
19:14 Company: Mesa does formats + modifiers somewhat decently (though GL lacks information about features of the formats, ie can you call glReadPixels() on them and Vulkan lacks the ability to enumerate by format and you have to guess the VkFormat for it)
19:14 emersion: mesa WSI does proper negotiation
19:14 Company: but there's also no way to communicate stride limitations for linear buffers and whatnot
19:15 emersion: that's not a mesa issue
19:15 Company: sure
19:15 emersion: it's an API issue for GL/Vulkan
19:15 emersion: and this doesn't prevent mesa from doing proper format+modifier negotiation
19:15 Company: but that's the argument you hear everywhere
19:16 emersion: format+modifier are orthogonal to stride alignment
19:16 Company: they cause the same problem - a buffer that can't be imported
19:17 emersion: sure
19:18 Company: things are just a whole lot easier for the existing situation if Vulkan and GL at least support the format/modifier combo they use by default
19:19 emersion: i don't see how that relates to your comment about stride
19:19 emersion: if there is proper format+modifier negotiation, then this isn't an issue at all
19:19 Company: sure\
19:19 Company: if everybody wrote perfect code, it wouldn't be an issue
19:20 emersion: there will always be bugs
19:20 emersion: bugs can be fixed, hopefully
19:20 Company: this is less "bugs" and more "missing features"
19:21 emersion: you make it sound like format negotiation is optional
19:22 emersion: it's not :P
19:22 Company: it seems to be in a lot of places
19:23 Company: lots of people implement it once they need it, but assume things just work before that
19:24 emersion: there are many ways to write bugs when you haven't read the docs (or when they don't exist yet)
19:24 Company: or when you want to get done and not have perfect code
19:25 Company: and just something that works
19:25 emersion: still, bugs and not missing features
19:25 Company: whatever you want to call it
19:35 airlied: hwentlan, daniels : yeah the tiled display stuff was pre atomic, the first implementation was all in kernel, but it broke a lot of assumptions
19:35 airlied: also userspace wants EDID
19:36 airlied: how do you expose tiled EDIDs if you have one connector?
19:36 emersion: toss a coin :)
19:37 emersion: but yeah, seems lik user-space can do a better job
19:37 airlied: though i cant remember if tbe main tile exposes a super mode in edis
19:37 airlied: edid, it probably did
19:39 mairacanal: i'm using a separated shmfs mountpoint to create my shmem-backed objects, but i'm not quite sure what would be the correct approach: (1) create a custom drm_gem_shmem_create() for the driver and basically copy and paste drm_gem_shmem_create() but using shmem_file_setup_with_mnt() or (2) add a mountpoint parameter to drm_gem_object_init() and create
19:39 mairacanal: a drm_gem_shmem_create_with_mnt(). i don't know if any other shmem driver has the interest to use huge pages...
19:43 dok: hi there, I am having issue with some shaders when using musl-libc and with radeonsi_dri, I am experiencing segmentation fault caused by not enough stack allocated for threads
19:44 airlied: mairacanal: probably go with the latter and see how messy it looks
22:22 Venemo: CounterPillow: the discussion was about the old nv mesh shaders extension, which currently nobody supports. the ext mesh shaders will definitely stay
22:23 Venemo: sorry for the late reply
22:57 daniels: emersion: I feel like if two of the four compositor developers are saying that compositors can do a better job, and one of the other two has done it for years already, then that's consensus :P
22:58 daniels: Company: I take the snark about Mesa or Mesa and Mesa's config to Mesa's config so Mesa can Mesa Mesa, but if you've ever run something in a container, or tried to bisect anything, then Mesa's semantics are not Mesa's semantics, unless you write those semantics exactly once and entomb them as ABI forever
22:59 daniels: Company: equally, embedded web views mean that WebKit is not necessarily WebKit
22:59 daniels: Company: if you're ever doing anything more complex, like interacting with codec APIs or window systems, you need to do modifier negotiation anyway
23:00 daniels: Company: and you can't say you were unaware because the canonical modifier doc literally spells out at great length that you must enumerate the acceptable downstream subset and pass those to the allocator; if we were just relying on wishful thinking and vibes then we wouldn't have bothered surfacing lists of explicit modifiers, but we'd have stuck with implicit 'errr yeah dunno really but let's hope the other side picks the same'
23:25 Company: daniels: my issue here was mostly integration between apps using GTK and other GL/dmabuf-using libraries - and the concrete case here was Webkit which sends dmabufs from its web process to the ui process and the web process uses EGL while someone decided to try GTK's Vulkan renderer
23:26 Company: and of course, in an ideal world we'd all negotiate things perfectly, but I fear some of those applications won't even if I provide them with all the necessary code to do it
23:28 Company: I will certainly make sure that GtkGLArea picks a dmabuf format/modifier that the Vulkan renderer accepts, when the Vulkan renderer is in use
23:28 Company: but there's also things like GStreamer with its GL pipelines that can be ade to spit out dmabufs
23:29 Company: and GTK might want to consume that, too
23:30 Company: of course, this is ultimately going to go in the other direction too - where Vulkan libraries produce dmabufs for GTK's GL renderer to consume
23:31 Company: and I'm sure the same thing is gonna happen in Qt and wherever else people smash libraries together
23:33 daniels: I'd love to tell you there's an easy way out, but there's not
23:34 daniels: if you're exchanging dmabufs, then you need to be exchanging acceptable format/modifier/etc sets before you do so
23:34 daniels: if that wasn't the case, we wouldn't have bothered typing up all the EGL/Vulkan/Wayland/KMS/... extensions
23:35 daniels: but it is, so we did, and if you want the benefits of just firing around nice zerocopy handles then you need to be doing the same
23:35 Company: I get that
23:35 daniels: if people get that wrong, then that sucks for anyone using those things, but there isn't a magic lever we can pull to make it work
23:35 Company: but I also get that people write code that works well enough and then they ship it
23:36 Company: and then it doesn't work for somebody else
23:36 Sachiel: people also write code that doesn't work at all, and still ship it
23:36 Sachiel: can't fix what can't be fixed
23:36 daniels: tldr: software
23:36 zamundaaa[m]: It could be useful to have a debug env for Mesa to pick a single random modifier and not support anything else
23:36 zamundaaa[m]: So that you can at least somewhat consistently test this kind of scenario
23:37 Company: and then they're gonna blame someone for that, and I can tell you it's not always the one who doesn't conform to the spec
23:38 Company: zamundaaa[m]: WebKit already has an env var to force a format/modifier combo so that seems like a common thing
23:38 Company: zamundaaa[m]: but are you talking about Mesa or Mesa here? ;)
23:39 zamundaaa[m]: About Mesa, obviously. Meaning, support the env var with all drivers
23:39 Company: like, the issue here is the EGL vs the Vulkan driver in the same process
23:39 daniels: Company: they can blame who they want, but the fix is the same: do the difficult thing people tried to avoid doing
23:39 Company: so you'd need to have 2 env vars
23:40 zamundaaa[m]: I really meant "random" as in "randomly chosen at init time"
23:40 daniels: (also, 'select the same thing for EGL and Vulkan' is not really a thing, given that Vulkan has fine-grained usage flags forming immutable allocations, and EGL/GL/GLES have ~no usage flags forming very mutable allocations)
23:41 Company: zamundaaa[m]: I think you want "make sure Vulkan and EGL both can do it" as well as "make sure Vulkan and EGL are different"
23:42 Company: the first one to make your code actually work in the ideal case
23:42 Company: and the second so once that works, you can ensure that negotiation also works
23:44 Company: daniels: I'm pretty sure in this case that wasn't the problem though, and it was just a lack of the newest feature getting into the Vulkan driver in time
23:45 Company: daniels: which is something that Mesa could have prioritized
23:51 daniels: Mesa doesn't prioritise making two wildly different APIs pretend to be the same in order to support people breaking the entire premise of buffer exchange
23:52 daniels: it's nice to have for sure, but it's fundamentally not a problem which can be solved
23:52 daniels: and there's plenty enough hardware around where you'll throw performance on the floor by trying
23:53 daniels: so the answer is always going to be a shrug and a link to https://docs.kernel.org/userspace-api/dma-buf-alloc-exchange.html#negotiation