ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
RAOF has quit [Remote host closed the connection]
RAOF has joined #wayland
Brainium has quit [Quit: Konversation terminated!]
Brainium has joined #wayland
glennk has quit [Ping timeout: 480 seconds]
Company has quit [Ping timeout: 480 seconds]
Company has joined #wayland
mclasen has quit [Ping timeout: 480 seconds]
feaneron has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
Brainium has quit [Quit: Konversation terminated!]
mxz__ has joined #wayland
mxz_ has quit [Ping timeout: 480 seconds]
mxz_ has joined #wayland
mxz has quit [Ping timeout: 480 seconds]
mxz_ is now known as mxz
Company has quit [Quit: Leaving]
feaneron has quit [Ping timeout: 480 seconds]
gryffus_ has quit [Ping timeout: 480 seconds]
bjorkint0sh has joined #wayland
bjorkintosh has quit [Ping timeout: 480 seconds]
sima has joined #wayland
gryffus_ has joined #wayland
tzimmermann has joined #wayland
rv1sr has joined #wayland
glennk has joined #wayland
Guest526 has quit [Remote host closed the connection]
cool110 has joined #wayland
cool110 is now known as Guest597
azerov has quit [Quit: Gateway shutdown]
azerov has joined #wayland
colinmarc has joined #wayland
<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
<colinmarc>
(or not-mesa Vulkan drivers like nvidia)
<colinmarc>
probably the same problem exists for openGL, I have no idea
<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.
<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:
<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
<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
<colinmarc>
spec
<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
kts has joined #wayland
<colinmarc>
(yet)
kts has quit []
leon-anavi has joined #wayland
leakleak has joined #wayland
kts has joined #wayland
sally is now known as Guest606
sally has joined #wayland
Guest606 has quit [Ping timeout: 480 seconds]
<colinmarc>
<LaserEyess> "question since I have a strong..." <- Wouldn't mpv just use Vulkan via mesa?
leakleak has quit [Remote host closed the connection]
<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
<JEEB>
similar to direct drm output where DRM has the APIs where the graphics interface is not available
<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?
<JEEB>
yea
<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.
<JEEB>
I expect some complaints, but at least my 2013 X230 works with the libplacebo vulkan usage
<haasn>
colinmarc: there is VK_COLOR_SPACE_PASS_THROUGH_EXT
kts has quit [Quit: Konversation terminated!]
<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
<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
rgallaispou has quit [Read error: Connection reset by peer]
rgallaispou has joined #wayland
<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.
<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
<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?
<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`.
<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
<zamundaaa[m]>
But I don't consider that a blocker for the Wayland protocol or for the implementation in Mesa
<colinmarc>
so as the temporary solution you would just take do the check whether the instance extension is enabled?
<zamundaaa[m]>
Yes
<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?
<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
<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
<zamundaaa[m]>
For example, Vulkan doesn't have any way to set the reference luminance
<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
<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
<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
<colinmarc>
as a temporary hack maybe that's slightly better?
<colinmarc>
or does the read-only thing just let you access the preferred one?
<zamundaaa[m]>
The client only sets an image description, you can't fetch it
<zamundaaa[m]>
About checking the instance, I have a local rebase of your MR where I added that
<zamundaaa[m]>
It's not that involved luckily
mclasen has joined #wayland
nerdopolis has joined #wayland
<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
<colinmarc>
* right? like `VK_MESA_image_alignment_control, * VK_MESA_image_alignment_control` or
<daniels>
it’s not Mesa-specific though, it’s Wayland-specific
<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
<zamundaaa[m]>
If you do that, it doesn't help apps a lot
<zamundaaa[m]>
They'd still need two code paths
<colinmarc>
sorry why two code paths?
<zamundaaa[m]>
One for Mesa, another for all other Vulkan drivers
narodnik has joined #wayland
mclasen_ has joined #wayland
<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 :)
<colinmarc>
and the implementation in mesa would be simpler too
<zamundaaa[m]>
Checking the instance extension is not complicated at all
mclasen has quit [Ping timeout: 480 seconds]
mclasen_ is now known as mclasen
<daniels>
why would non-Mesa drivers not support the single standardised way of doing HDR and CM under Wayland … ?
leonanavi has joined #wayland
mvlad has joined #wayland
<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
<colinmarc>
it just seems better to turn it on and off on the surface level rather than for the whole VkInstance
<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
<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
<colinmarc>
they're just as likely to try to do the passthrough thing
<colinmarc>
oh interesting, that's cool
<zamundaaa[m]>
Colin Marc: the issue on the Vulkan repo is exactly for putting it in the spec though?
<zamundaaa[m]>
And when NVidia implement it, of course they'll do the same thing
<colinmarc>
zamundaaa[m]: that issue says that *something* should go in the spec but not what
<colinmarc>
(I made the suggestion to extend the surface creation flags there as well)
leon-anavi has quit [Ping timeout: 480 seconds]
<zamundaaa[m]>
The way to fix that is to fix it, not to give up or make vendor specific extensions
<zamundaaa[m]>
Which would be more effort than deciding on some sentence to put in the spec anyways
<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
<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
<zamundaaa[m]>
Might be wrong though
<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
<colinmarc>
I'll try. would you prefer that the flag disables vulkan's use of cm surface or enables it?
<zamundaaa[m]>
Disable
<colinmarc>
disabling it seems better since that's the edge case
<colinmarc>
kk
Moprius has joined #wayland
<zamundaaa[m]>
Yes, otherwise 99.8% of Vulkan apps wouldn't get to do HDR on Wayland, which would be quite bad
<colinmarc>
well, it would mean existing apps have to opt in to hdr, right?
<colinmarc>
and for cross platform apps, there's something like dxvk setting those flags
<zamundaaa[m]>
Cross platform does not mean dxvk
<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
<colinmarc>
sorry, not dxvk, you're right. what sets those flags now, for like a windows vulkan app?
<zamundaaa[m]>
Nothing
<colinmarc>
does it just use the windows wsi and the wine deals with it from there?
<zamundaaa[m]>
There are no such flags for Windows afaik, that's what the "passthrough" thing is for
<colinmarc>
yeah okay I see how that's not relevant
<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
<colinmarc>
but I see your point and will do the inverse
<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
<zamundaaa[m]>
Even though the application code otherwise does the exact same
Brainium has joined #wayland
<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
<colinmarc>
I think we can add validation that if the disable flag is set, all swapchains on that surface have to use PASSTHROUGH
<colinmarc>
which is nice
<zamundaaa[m]>
yeah, that would make sense
gryffus_ has quit []
gryffus_ has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
tristianc670482 has quit [Read error: No route to host]
tristianc670482 has joined #wayland
narodnik has quit [Quit: WeeChat 4.3.5]
nerdopolis has joined #wayland
iconoclasthero has quit [Ping timeout: 480 seconds]
sewn has quit [Remote host closed the connection]
sewn has joined #wayland
bjorkint0sh has quit [Quit: "Every day, computers are making people easier to use." David Temkin]
tzimmermann has quit [Quit: Leaving]
Brainium has quit [Quit: Konversation terminated!]
Brainium has joined #wayland
zvarde198830320677919168587 has quit [Ping timeout: 480 seconds]
Company has joined #wayland
bjorkintosh has joined #wayland
Company has quit [Remote host closed the connection]
FreeFull has quit [Quit: rebooting]
FreeFull has joined #wayland
Company has joined #wayland
kts has joined #wayland
Brainium has quit [Read error: Connection reset by peer]
Brainium has quit [Quit: Konversation terminated!]
Moprius has quit [Quit: bye]
agd5f has joined #wayland
<Company>
colinmarc: technically there's other stuff you might want disabled
agd5f has quit [Remote host closed the connection]
<Company>
would you do custom extensions for all of those?
<Company>
the first thing that comes to mind is damage regions
agd5f has joined #wayland
coldfeet has joined #wayland
agd5f_ has quit [Ping timeout: 480 seconds]
<colinmarc>
Company: you mean there should be a mega extension? or that the pattern is a bit silly?
<Company>
I guess I'm wondering about a VK_EXT_disable_wayland_stuff with flags about features to disable
<colinmarc>
I'm not opposed, if someone wants to take that PR and run with it
<colinmarc>
I'm not read in on damage regions and why you'd want to disable them though
<Company>
ultimately, it's a general problem
<Company>
that it's unclear which of the wl_surface properties is managed by the Vulkan/GL wsi and which I should manage myself
<Company>
both for direct properties and for extension objects
<Company>
the damage thing is relevant because of buffer damage vs surface damage and fractional scaling
<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
agd5f_ has joined #wayland
agd5f_ has quit [Read error: Connection reset by peer]
<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)
agd5f_ has joined #wayland
<Company>
I wonder how that's handled on Windows or mac or Android
<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?
agd5f has quit [Ping timeout: 480 seconds]
<Company>
yes, but the compositor doesn't know if they are broken
<ManMower>
I'd be nervous about exposing a "client is probably buggy so just throw this big switch instead of fixing anything" extension
<ManMower>
which is kinda what a damage region disabler sounds like to me
<Company>
this is more about adding wl_fractional_scale_v2 and using an old nvidia Vulkan driver
narodnik has joined #wayland
<ManMower>
is the problem that the old driver uses damage instead of damage_buffer?
<Company>
or that it might compute the damage wrong
<Company>
because it doesn't know about this new protocol
<ManMower>
does a damage_buffer user need to know about the new protocol?
<Company>
I mean, I can technically not enable VK_KHR_incremental_present and hope the wsi doesn't set damage
<Company>
but nobody doesn't guarantee me that it won't touch it
<Company>
s/doesn't//
<ManMower>
the wsi needs to set damage or you aren't likely to see updated images
<Company>
no damage = full buffer damaged
<Company>
but it's a general question of who may create what extension object and who may set which property on the wl_surface
<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?
<Company>
I mean, Vulkan also uses wp_linux_drm_syncobj_surface_v1 (sometimes)
<Company>
in GTK, Vulkan manages (parts of) the main surface
<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
<Company>
but I suspect there's just too much overlap to untangle it that way
<Company>
opaque regions, assumptions about pixel alignment, et
<Company>
c
<zamundaaa[m]>
Company: buffer damage isn't affected by fractional scale v2, there should be no issues with that
<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
gryffus_ has quit [Read error: Connection reset by peer]
gryffus_ has joined #wayland
lsd|2 has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
hergertme has quit [Quit: Leaving]
coldfeet has quit [Remote host closed the connection]