ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
lbia has joined #wayland
lbia has quit [Ping timeout: 480 seconds]
tyzef has joined #wayland
aswar002_ has joined #wayland
tlwoerner_ has joined #wayland
fvok4 has joined #wayland
gildekel_ has joined #wayland
Arnavion- has joined #wayland
nurupo_ has joined #wayland
nniro_ has joined #wayland
zmike_ has joined #wayland
ids1024_ has joined #wayland
dri-logger has joined #wayland
bim9262_ has joined #wayland
Ariadne_ has joined #wayland
mblenc has quit [resistance.oftc.net larich.oftc.net]
gildekel has quit [resistance.oftc.net larich.oftc.net]
tyzef- has quit [resistance.oftc.net larich.oftc.net]
nurupo has quit [resistance.oftc.net larich.oftc.net]
eroc1990 has quit [resistance.oftc.net larich.oftc.net]
agd5f has quit [resistance.oftc.net larich.oftc.net]
anarsoul has quit [resistance.oftc.net larich.oftc.net]
aswar002 has quit [resistance.oftc.net larich.oftc.net]
i509vcb has quit [resistance.oftc.net larich.oftc.net]
jkl has quit [resistance.oftc.net larich.oftc.net]
ebassi has quit [resistance.oftc.net larich.oftc.net]
sevz has quit [resistance.oftc.net larich.oftc.net]
fvok4_ has quit [resistance.oftc.net larich.oftc.net]
seanpaul_ has quit [resistance.oftc.net larich.oftc.net]
bim9262 has quit [resistance.oftc.net larich.oftc.net]
Arnavion has quit [resistance.oftc.net larich.oftc.net]
danieldg has quit [resistance.oftc.net larich.oftc.net]
danshick has quit [resistance.oftc.net larich.oftc.net]
nniro has quit [resistance.oftc.net larich.oftc.net]
kelnos has quit [resistance.oftc.net larich.oftc.net]
ids1024 has quit [resistance.oftc.net larich.oftc.net]
Crocodillian has quit [resistance.oftc.net larich.oftc.net]
codingkoopa321 has quit [resistance.oftc.net larich.oftc.net]
mcf has quit [resistance.oftc.net larich.oftc.net]
jlco has quit [resistance.oftc.net larich.oftc.net]
tlwoerner has quit [resistance.oftc.net larich.oftc.net]
dri-logg1r has quit [resistance.oftc.net larich.oftc.net]
Ariadne has quit [resistance.oftc.net larich.oftc.net]
Momentum has quit [resistance.oftc.net larich.oftc.net]
zmike has quit [resistance.oftc.net larich.oftc.net]
<pq>
emersion, since you mentioned; how does that Vulkan doing TF decoding work with pre-mult-in-electrical alpha? Can you get it right, or did you just decide it's close enough?
<emersion>
so…
<emersion>
we don't use the _SRGB vulkan format for buffers with an alpha channel
<emersion>
so yeah, i suppose global alpha is kind-of the same situation
<pq>
what do you with alpha-ful formats?
<emersion>
we use _UNORM, and manually do the decoding
<pq>
alright
<emersion>
still don't think it's a good idea to encode the exact behavior in the spec, but oh well
<emersion>
like, if you spec that the protocol multiplies encoded values, then it's impossible to do gamma-correct blending
<pq>
yes, I'm about to reply something like that
<emersion>
i don't really want to encourage clients to do gamma-incorrect stuff
junaid_ has quit [Remote host closed the connection]
kts has joined #wayland
junaid has joined #wayland
mblenc1 has joined #wayland
mblenc has quit [Read error: Connection reset by peer]
neniagh has quit []
kts has quit [Ping timeout: 480 seconds]
<pq>
emersion, is it so in libwayland that the compiler will not warn about unhandled values for switch (char), but it does for switch (enum)?
<emersion>
-Wswitch is only about enums
<pq>
thanks
<emersion>
i don't know of an option to warn about missing default case for non-enums
<emersion>
there is -Wswitch-default, but it would also warn if there is no default case for enums, even if all enum members are covered
<pq>
ok
kts has joined #wayland
cmichael has quit [Remote host closed the connection]
cmichael has joined #wayland
narodnik2 has joined #wayland
narodnik has quit [Read error: No route to host]
junaid has quit [Quit: Lost terminal]
guru__ has quit [Remote host closed the connection]
guru__ has joined #wayland
<emersion>
> Premultiplying into electrical color channels (here alpha does not count as a color channel!) would have an issue with DRM_FORMAT_AYUV...
<emersion>
pq, what do you mean here? YUV count as "color channel" no?
<pq>
you never multiply A into Y, U or V
<pq>
hmm, or do you...
<emersion>
hm, so that is more of an issue with the existing wording i suppose?
<pq>
yeah
<pq>
I've never heard of pre-multiplied YUV, but as long as YUV->RGB is a simple matrix operation, I guess pre-mult could... work... hmm, but the neutral value for U,V is not zero
<emersion>
yeah…
<pq>
but I think from linear math perspective it should be equivalent?
<emersion>
applying transparency to YUV should probably leave UV as-is and only affect Y?
<emersion>
hrm, or would it…
<pq>
we need to recall that luma (Y) is not luminance
<pq>
since we're talking about non-constant luminance YCbCr encodings
<emersion>
does it even make sense to premult YUV channels?
<emersion>
does it help when compositing?
<emersion>
since no-one uses YUV with alpha channel, we can probably decide to define it to whatever we want?
<pq>
emersion, what about TF encoding on darkness formats? The usual TFs give more precision near zero, but human vision is more sensitive in the dark, so darkness formats would need more precision near 1.0. :-)
<emersion>
ow :<
Fischmiep has joined #wayland
<emersion>
i also have no idea how TFs work with YUV tbh
<pq>
H.273 can tell you
<pq>
just look for the ()' operator, that's the TF. Electrical values are marked with ', mostly.
<pq>
the most common case is that TF is applied on RGB, and afterwards there is a matrix converting to YCbCr + quantization range encoding
<pq>
that is the non-constant luminance way
<pq>
i.e. the simplest form
<emersion>
that makes sense
<emersion>
to decode YUV into RGB and you get TF-encoded values
<emersion>
so decode*
cmichael has quit [Quit: Leaving]
cmichael has joined #wayland
<emersion>
if we wanted to, we could specify the same for darkness
<emersion>
D' = 1 - R'
kts has joined #wayland
<emersion>
so just like YUV, if one decodes D into R, they get TF-encoded values
<pq>
sure
<pq>
that just doesn't make premult-in-raw-pixel-value work
<emersion>
yeah
<pq>
like it doesn't work for YCbCr
<emersion>
hm, why is that?
<pq>
the encoding to u8 or what you have needs an offset, and you need to keep the offset intact
<emersion>
i'm not following i think
<pq>
Pb, Pr range is [-0.5, 0.5], and that then gets offsetted to be able to encode it in UNORM
<emersion>
i mean, premult-in-raw-pixel-value only works for RGB, no?
<pq>
multiplying RGB matches multiplying YPbPr (all electrical here), but that does not translate to simple multiplication of YCbCr
<pq>
yes
<pq>
maybe should even say, only for full range raw RGB, that is, UNORM.
blathijs has joined #wayland
<emersion>
zamundaaa[m]: so your point is that for a compositor with gamma-incorrect blending, optical and electrical values are the same?
<emersion>
that sounds like a weird definition to me, but i'm no expert…
<emersion>
to me, a compositor with gamma-incorrect blending never converts to optical values
<emersion>
but the meaning of optical values remains the same as for gamma-correct blending
<pq>
I agree with emersion here
Company has joined #wayland
<zamundaaa[m]>
emersion: in KWin we have the issue that we can't default to linear blending yet because some Intel and ARM iGPUs have surprisingly severe performance issues with it
<zamundaaa[m]>
The shaders that do color management still work and get used when conversions are needed, even without linear blending though
<emersion>
that's fine
<emersion>
i don't plan to do gamma-correct blending for GLES2 or Pixman
<zamundaaa[m]>
If you want to not have to do conversions to optical values in a compositor with gamma-incorrect blending, you can just not support the protocol in there, right?
<emersion>
i'd still want to support the protocol with today's KMS and with my GLES2 renderer
<zamundaaa[m]>
Then the only reasonable way forward I see is to leave it entirely undefined. Because requiring pre-mult-in-electrical to also make this alpha value be multiplied in electrical space doesn't sound useful to me
<pq>
yes
<emersion>
my preference would be to leave it undefined, and then make it defined if color-representation alpha_mode is set
<emersion>
(or advertised?)
<pq>
would it follow alpha-mode like I suggested, or?
<emersion>
also keep in mind that some users may prefer gamma-incorrect blending
<emersion>
so even if gamma-correct blending would be inexpensive with old Intel and ARM, some compositors may still have a reason to keep their gamma-incorrect mode
<zamundaaa[m]>
Sure, and that's fine, but that doesn't mean these compositors have to support this protocol
<zamundaaa[m]>
The point is for clients to offload their own rendering, if we can't define the exact behavior at least eventually, then it's not that useful
<zamundaaa[m]>
Maybe we should just add an event to the global, saying which behavior the compositor applies?
<zamundaaa[m]>
Then the client can decide whether or not it's acceptable for its use case
<emersion>
there are many things that are "undefined" when it comes to sub-surface offloading and such
<emersion>
and pq said it may not be desirable to fully define everything
<emersion>
zamundaaa[m]: gamma-correct vs gamma-incorrect is almost like a user preference, it seems very weird to me to gate protocol support behind that
<zamundaaa[m]>
Sure, defining everything may not make sense, but this protocol is purely an optimization, not a user visible feature
<pq>
I think the whole debate on alpha-multiplier is a testament to defining too much being a bad idea for extension that are intended to gain wide adoption.
<pq>
zamundaaa[m], Julian was promoting the optimization aspect, but you turned that down.
<pq>
so what's the actual goal here? Off-load mathematics or semantics to the compositor?
<zamundaaa[m]>
Can you link where I turned it down? Pretty sure I didn't; offloading to the compositor as an optimization is the sole purpose of the merge request
<zamundaaa[m]>
I don't see how you could interpret that in this way
<pq>
You'll see in my reply.
<zamundaaa[m]>
What I'm saying there is that this protocol doesn't have to define everything by itself. It's fine if the exact blending behavior is specified somewhere else later
<emersion>
pq, i agree with your proposal wrt. alpha-mode interactions
junaid has joined #wayland
<pq>
zamundaaa[m], what is it in optical blending that makes those old GPUs so slow? Is it half-float render target?
rv1sr has quit []
JayBeeFOSS has joined #wayland
JayBeeFOSS has quit [Remote host closed the connection]
<zamundaaa[m]>
Rendering to dmabufs instead of a GL_RGBA16F texture did seem to help on Intel at least, so it could also be a driver bug. I haven't spent too much time looking at it yet though
riteo_ is now known as riteo
guru__ has quit [Remote host closed the connection]
guru__ has joined #wayland
cmichael has quit [Quit: Leaving]
Philippe has joined #wayland
mart has quit [Quit: Konversation terminated!]
t3st3r has joined #wayland
t3st3r has quit []
Philippe has quit [Quit: Leaving]
guru__ has quit [Remote host closed the connection]
guru__ has joined #wayland
cvmn has quit [Remote host closed the connection]
caveman has joined #wayland
caveman has quit [Remote host closed the connection]
caveman has joined #wayland
kts has quit [Quit: Leaving]
caveman has quit [Remote host closed the connection]
caveman has joined #wayland
leon-anavi has quit [Quit: Leaving]
flom84 has joined #wayland
caveman has quit [Remote host closed the connection]
guru__ has quit [Remote host closed the connection]
guru__ has joined #wayland
ofourdan has quit [Remote host closed the connection]
guru__ has quit [Remote host closed the connection]
guru__ has joined #wayland
garnacho has quit [Remote host closed the connection]
garnacho has joined #wayland
garnacho has quit []
garnacho has joined #wayland
garnacho has quit [Remote host closed the connection]
garnacho has joined #wayland
mblenc has joined #wayland
Brainium has joined #wayland
mblenc1 has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
mblenc has quit [Ping timeout: 480 seconds]
mblenc has joined #wayland
JakeSays1 has joined #wayland
JakeSays has quit [Ping timeout: 480 seconds]
mblenc1 has quit [Read error: Connection reset by peer]
mblenc1 has joined #wayland
mblenc has quit [Ping timeout: 480 seconds]
ofourdan has joined #wayland
mblenc has joined #wayland
mblenc1 has quit [Read error: Connection reset by peer]
shtrom has quit [Ping timeout: 480 seconds]
shtrom has joined #wayland
shtrom has quit [Ping timeout: 480 seconds]
shtrom has joined #wayland
Leopold has quit [Ping timeout: 480 seconds]
mart has quit [Quit: Konversation terminated!]
junaid has quit [Remote host closed the connection]
mohit81582263 has quit [Quit: mohit81582263]
mohit81582263 has joined #wayland
mblenc has quit [Ping timeout: 480 seconds]
mblenc has joined #wayland
Brainium has quit [Ping timeout: 480 seconds]
Leopold_ has joined #wayland
roussinm has joined #wayland
mvlad has quit [Remote host closed the connection]
<zamundaaa[m]>
TIL amdvlk still uses wl_drm for creating buffers :/
<emersion>
yeah, they know about this
<emersion>
(i've reported this issue to them)
<zamundaaa[m]>
I found out about this from a user reporting mvp crashing on Plasma 6 because of that. I hope not a lot of people have amdvlk installed...
<emersion>
mpv?
<emersion>
yeah, i hope so too. next wlroots will drop wl_drm completely