00:46 #dri-devel: DemiMarie: actually this should probably be on #_oftc_#wayland:matrix.org
06:22 colinmarc: FWIW, I don't think anyone mentioned the other blocker for CM&HDR, which is that there is no mechanism for applications using Vulkan to prevent mesa from creating cm surfaces if they want to do color management themselves
06:23 colinmarc: (or not-mesa Vulkan drivers like nvidia)
06:24 colinmarc: probably the same problem exists for openGL, I have no idea
06:29 colinmarc: the only proposal so far is to have `VK_COLOR_SPACE_SRGB_NONLINEAR_KHR` mean "don't do any color management plz" which has a few problems:
06:29 colinmarc: - there's no way to clients (not doing color management themselves) to tag SRGB content if that's actually what they want. they don't know if the compositor default is sRGB or just a dumb 2.2 curve, and without knowing the default they don't know how to transform their content.
06:29 colinmarc: - even if that is the hacky mechanism in Mesa, it's unlikely to make it into the vulkan spec, and unlikely that nvidia will play along if it's not in the spec
06:32 colinmarc: I'm happy for any progress on the protocol. I'll reiterate my outsider's perspective, which is that the fastest path to getting something shipped would actually be to just target only the driver path first, and not provide any facility for applications to do color management themselves. Then Vulkan needs to be changed, either to support all the operations that clients want to do or to have a "no color management on wayland plz" flag in the
06:32 colinmarc: spec
06:33 colinmarc: The driver path would support games, video players, and the like just fine. Obviously in Vulkan there's no way to set an ICC file or something like that
06:33 colinmarc: (yet)
08:21 colinmarc: <LaserEyess> "question since I have a strong..." <- Wouldn't mpv just use Vulkan via mesa?
08:23 JEEB: via libplacebo where the graphics API lets you configure that stuff it would probably be the primary means. for opengl the colorspace thing is effectively only supported on android, so there and on vulkan drivers that don't offer the colorspace extensions the wayland stuff would be utilized
08:24 JEEB: similar to direct drm output where DRM has the APIs where the graphics interface is not available
08:27 colinmarc: ok, so in practice it would use vulkan if available, and if not fall back to using wayland directly? there's no compatibility issue in that scenario, since there's no need to turn off color management in a driver that doesn't support it, I guess?
08:28 JEEB: yea
08:30 JEEB: I think when we switch to the libplacebo-based gpu-next by default it would probably make sense to default to vulkan as the API, as most testing with libplacebo is being done with vulkan.
08:31 JEEB: I expect some complaints, but at least my 2013 X230 works with the libplacebo vulkan usage
09:26 wlb: wayland-protocols Merge request !329 opened by David Redondo (davidre) xdg-toplevel-icon: Define that reusing a buffer is ok after wl_buffer.release https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/329
09:50 haasn: colinmarc: there is VK_COLOR_SPACE_PASS_THROUGH_EXT
10:05 zamundaaa[m]: Colin Marc: this was thoroughly discussed before, the driver must only create a color management surface if the app uses the Vulkan color management extension
10:09 zamundaaa[m]: If the app doesn't use the color management protocol through either Vulkan or Wayland directly, then it gets the same behavior as without the protocol entirely. I see no problem with that approach
10:31 colinmarc: <zamundaaa[m]> "Colin Marc: this was thoroughly..." <- Sorry, but where is this specified? It's one thing to say that will be the mechanism for Mesa, but Mesa isn't the only WSI implementation around.
10:31 colinmarc: Even if it were, VK_EXT_swapchain_colorspace is a pretty bad signal, imo. It's an instance level extension that just adds some enum values. An instance could be used for many different surfaces, and changing the behavior for all of them implicitly sounds like asking for trouble
10:32 colinmarc: enabling the extension and using PASSTHROUGH is imo the better option, but it's very tricky. What if you create a swapchain with sRGB or PQ and then create it with PASSTHROUGH after? does the cm surface get destroyed?
10:33 zamundaaa[m]: Colin Marc: https://github.com/KhronosGroup/Vulkan-Docs/issues/2307
10:33 colinmarc: the problem, as I see it, is that the protocol is proposing a novel mechanism: submitting buffers via a graphics stack but tagging them completely out of band. I think for a novel mechanism you need an explicit option. It wouldn't be crazy hard: you could just add a flag to `VkWaylandSurfaceCreateFlagsKHR`.
10:34 zamundaaa[m]: And yeah, I agree that an instance level thing is not perfect, and having a Vulkan extension to do this per surface would be nice
10:34 zamundaaa[m]: But I don't consider that a blocker for the Wayland protocol or for the implementation in Mesa
10:35 colinmarc: so as the temporary solution you would just take do the check whether the instance extension is enabled?
10:35 zamundaaa[m]: Yes
10:36 colinmarc: why not just not support apps that do both color management and vulkan together as a v1? am I correct in understanding that those apps don't exist right now, anyway?
10:36 colinmarc: then it would be either use vulkan and just get tagging + hdr metadata (for image viewing apps etc) or use wayland directly, but no vulkan
10:36 zamundaaa[m]: I expect there to be a lot of apps that want to use Vulkan to render, and the color management protocol to pass along information that Vulkan doesn't deal with
10:37 zamundaaa[m]: For example, Vulkan doesn't have any way to set the reference luminance
10:38 zamundaaa[m]: But that does not mean that all of these apps should reimplement the whole Vulkan WSI from scratch just for this one thing
10:43 colinmarc: in the mesa impl I actually had trouble getting access to the enabled instance extensions to switch behavior, but maybe someone more familiar with mesa knows how to do that
10:45 colinmarc: I just had an idea. what if instead of checking for the instance extension, mesa first checks whether there exists an image description for the surface already using the read-only thing? then it could create a surface only if one doesn't already exist
10:45 colinmarc: as a temporary hack maybe that's slightly better?
10:46 colinmarc: or does the read-only thing just let you access the preferred one?
10:47 zamundaaa[m]: The client only sets an image description, you can't fetch it
10:47 zamundaaa[m]: About checking the instance, I have a local rebase of your MR where I added that
10:48 zamundaaa[m]: It's not that involved luckily
11:16 colinmarc: what about adding the flag to VkWaylandSurfaceCreateFlagsKHR under a mesa-specific vulkan extension? There are other mesa-specific extensions, right? like VK_MESA_image_alignment_control or whatever
11:17 colinmarc: * right? like `VK_MESA_image_alignment_control, * VK_MESA_image_alignment_control` or
11:17 daniels: it’s not Mesa-specific though, it’s Wayland-specific
11:18 colinmarc: right now only mesa is going to support this new mechanism (tagging buffers out of band). the extension could be proposed more broadly but in the meantime it would be only for mesa
11:18 zamundaaa[m]: If you do that, it doesn't help apps a lot
11:18 zamundaaa[m]: They'd still need two code paths
11:20 colinmarc: sorry why two code paths?
11:22 zamundaaa[m]: One for Mesa, another for all other Vulkan drivers
11:41 colinmarc: I mean, I wasn't suggesting it because it's better for apps, I was suggesting it because it's more robust and explicit than checking the instance extension :)
11:42 colinmarc: and the implementation in mesa would be simpler too
11:42 zamundaaa[m]: Checking the instance extension is not complicated at all
11:54 daniels: why would non-Mesa drivers not support the single standardised way of doing HDR and CM under Wayland … ?
11:55 colinmarc: the single standardized way that's being proposed is not in the vulkan spec right now, nor on the way to being in the vulkan spec. I'm just suggesting that a different mechanism be part of the spec
11:56 colinmarc: it just seems better to turn it on and off on the surface level rather than for the whole VkInstance
11:57 colinmarc: my assumption was that nvidia wouldn't support hdr on linux right away anyway, and that if they do there's no reason they'd copy mesa's behavior it's not specified
11:57 LaserEyess: colinmarc: re: mpv, there's also a vo called dmabuf-wayland that this could be implemented for since it doesn't use vulkan/opengl at all
11:57 colinmarc: they're just as likely to try to do the passthrough thing
11:58 colinmarc: oh interesting, that's cool
11:59 zamundaaa[m]: Colin Marc: the issue on the Vulkan repo is exactly for putting it in the spec though?
11:59 zamundaaa[m]: And when NVidia implement it, of course they'll do the same thing
11:59 colinmarc: zamundaaa[m]: that issue says that *something* should go in the spec but not what
12:00 colinmarc: (I made the suggestion to extend the surface creation flags there as well)
12:01 zamundaaa[m]: The way to fix that is to fix it, not to give up or make vendor specific extensions
12:01 zamundaaa[m]: Which would be more effort than deciding on some sentence to put in the spec anyways
12:05 colinmarc: ok, I guess I thought the Mesa extension would be a step on the path to a proper one, but obviously I agree it shouldn't be vendor specific
12:07 zamundaaa[m]: I don't think you need a vendor specific extension before making an EXT one, as long as you can get two vendors to agree to it
12:07 zamundaaa[m]: Might be wrong though
12:08 colinmarc: I've never made an extension, but I'm happy to write the text for one if someone with an account wants to submit it
12:10 zamundaaa[m]: You can just make a MR at https://github.com/KhronosGroup/Vulkan-Docs/pulls
12:11 colinmarc: I thought that extensions took a separate path?
12:11 zamundaaa[m]: See https://github.com/KhronosGroup/Vulkan-Docs/pull/1529 for a previous extension that got added this way
12:12 colinmarc: I'll try. would you prefer that the flag disables vulkan's use of cm surface or enables it?
12:12 zamundaaa[m]: Disable
12:12 colinmarc: disabling it seems better since that's the edge case
12:12 colinmarc: kk
12:13 zamundaaa[m]: Yes, otherwise 99.8% of Vulkan apps wouldn't get to do HDR on Wayland, which would be quite bad
12:14 colinmarc: well, it would mean existing apps have to opt in to hdr, right?
12:14 colinmarc: and for cross platform apps, there's something like dxvk setting those flags
12:14 zamundaaa[m]: Cross platform does not mean dxvk
12:15 zamundaaa[m]: Any existing Vulkan code that can make use of the additional color spaces would have to be updated to not malfunction on Wayland specifically, and that's just not acceptable
12:17 colinmarc: sorry, not dxvk, you're right. what sets those flags now, for like a windows vulkan app?
12:18 zamundaaa[m]: Nothing
12:18 colinmarc: does it just use the windows wsi and the wine deals with it from there?
12:18 zamundaaa[m]: There are no such flags for Windows afaik, that's what the "passthrough" thing is for
12:18 colinmarc: yeah okay I see how that's not relevant
12:19 colinmarc: just to log it, having the flag be "enable cm" would manage the ambiguity with srgb, where it's not clear whether that means it should be untagged
12:19 colinmarc: but I see your point and will do the inverse
12:20 zamundaaa[m]: I think it's pretty clear that sRGB should be untagged, because otherwise just enabling VK_EXT_swapchain_colorspace would potentially change the colors
12:21 zamundaaa[m]: Even though the application code otherwise does the exact same
12:22 zamundaaa[m]: Apps that really care about colors and "correct" sRGB have to use the Wayland protocol to specify what they mean anyways, to even specify the rendering intent
12:27 colinmarc: I think we can add validation that if the disable flag is set, all swapchains on that surface have to use PASSTHROUGH
12:28 colinmarc: which is nice
12:37 zamundaaa[m]: yeah, that would make sense
16:30 colinmarc: zamundaaa: https://github.com/KhronosGroup/Vulkan-Docs/pull/2410
16:41 Company: colinmarc: technically there's other stuff you might want disabled
16:41 Company: would you do custom extensions for all of those?
16:42 Company: the first thing that comes to mind is damage regions
16:44 colinmarc: Company: you mean there should be a mega extension? or that the pattern is a bit silly?
16:44 Company: I guess I'm wondering about a VK_EXT_disable_wayland_stuff with flags about features to disable
16:45 colinmarc: I'm not opposed, if someone wants to take that PR and run with it
16:45 colinmarc: I'm not read in on damage regions and why you'd want to disable them though
16:46 Company: ultimately, it's a general problem
16:46 Company: that it's unclear which of the wl_surface properties is managed by the Vulkan/GL wsi and which I should manage myself
16:47 Company: both for direct properties and for extension objects
16:48 Company: the damage thing is relevant because of buffer damage vs surface damage and fractional scaling
16:48 Company: and not knowing which one the driver supports and then the damage rect is rounded back and forth between coordinate systems a few times, growing at each step
16:50 Company: I think there were also problems with frame callbacks, but I don't remember what that was about (or if it was GL only)
16:52 Company: I wonder how that's handled on Windows or mac or Android
16:55 ManMower: the buffer must be coherent outside of its damage regions anyway, so couldn't the compositor ignore damage regions (and assume full surface damage) if it's operating in a mode where they're probably going to be broken?
16:56 Company: yes, but the compositor doesn't know if they are broken
16:58 ManMower: I'd be nervous about exposing a "client is probably buggy so just throw this big switch instead of fixing anything" extension
16:58 ManMower: which is kinda what a damage region disabler sounds like to me
17:00 Company: this is more about adding wl_fractional_scale_v2 and using an old nvidia Vulkan driver
17:00 ManMower: is the problem that the old driver uses damage instead of damage_buffer?
17:01 Company: or that it might compute the damage wrong
17:01 Company: because it doesn't know about this new protocol
17:01 ManMower: does a damage_buffer user need to know about the new protocol?
17:02 Company: I mean, I can technically not enable VK_KHR_incremental_present and hope the wsi doesn't set damage
17:02 Company: but nobody doesn't guarantee me that it won't touch it
17:02 Company: s/doesn't//
17:03 ManMower: the wsi needs to set damage or you aren't likely to see updated images
17:03 Company: no damage = full buffer damaged
17:04 Company: but it's a general question of who may create what extension object and who may set which property on the wl_surface
17:05 ManMower: I think mostly you just give a subsurface to vulkan and let it do its thing. otherwise there will be state inconsistencies and your wsi can't possibly know what's going on?
17:05 Company: I mean, Vulkan also uses wp_linux_drm_syncobj_surface_v1 (sometimes)
17:07 Company: in GTK, Vulkan manages (parts of) the main surface
17:07 Company: not sure if that's necessary and we could just hand it a subsurface instead, but I guess that grew organically from the X11/GL code
17:11 Company: but I suspect there's just too much overlap to untangle it that way
17:11 Company: opaque regions, assumptions about pixel alignment, et
17:11 Company: c
17:15 zamundaaa[m]: Company: buffer damage isn't affected by fractional scale v2, there should be no issues with that
17:28 daniels: all drivers damage the full region when buffer_damage isn’t supported or use b_d when it is, so this isn’t a problem which needs solving