ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput | register your nick to speak
paulk-bis has quit [Ping timeout: 480 seconds]
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
Dami_Lu has quit []
Dami_Lu has joined #wayland
pbsds has quit []
pbsds has joined #wayland
lanodan_ has quit [Ping timeout: 480 seconds]
lanodan_ has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
paulk has joined #wayland
reductum has quit [Remote host closed the connection]
reductum has joined #wayland
Company has quit [Quit: Leaving]
kts has joined #wayland
danvet has joined #wayland
dcz_ has joined #wayland
mvlad has joined #wayland
tzimmermann has joined #wayland
rasterman has joined #wayland
gschwind has joined #wayland
fmuellner has joined #wayland
tlwoerner_ has joined #wayland
Satan3 has joined #wayland
danshick_ has joined #wayland
noarb- has joined #wayland
abdur_ has joined #wayland
seanpaul_ has joined #wayland
flibit has joined #wayland
reductum_ has joined #wayland
everfree_ has joined #wayland
fmuellner has quit [synthon.oftc.net larich.oftc.net]
reductum has quit [synthon.oftc.net larich.oftc.net]
Seirdy has quit [synthon.oftc.net larich.oftc.net]
genpaku has quit [synthon.oftc.net larich.oftc.net]
danshick has quit [synthon.oftc.net larich.oftc.net]
flibitijibibo has quit [synthon.oftc.net larich.oftc.net]
Lyude has quit [synthon.oftc.net larich.oftc.net]
Satan has quit [synthon.oftc.net larich.oftc.net]
WhizzWr has quit [synthon.oftc.net larich.oftc.net]
noarb has quit [synthon.oftc.net larich.oftc.net]
abdur has quit [synthon.oftc.net larich.oftc.net]
seanpaul has quit [synthon.oftc.net larich.oftc.net]
everfree has quit [synthon.oftc.net larich.oftc.net]
tlwoerner has quit [synthon.oftc.net larich.oftc.net]
fmuellner has joined #wayland
genpaku has joined #wayland
Seirdy has joined #wayland
WhizzWr has joined #wayland
audgirka has joined #wayland
Lyude has joined #wayland
kts has quit [Quit: Leaving]
<emersion>
what's the best strategy for correct srgb blending in a GLES2 shader?
<emersion>
two render passes, one to convert input to linear + blend, one to convert final buffer to srgb again?
<emersion>
what are the best formats to use for the FBs?
<pq>
two passes, yes, and you could be lucky to off-load the latter pass to KMS too.
<pq>
I have no recollection of the sRGB texture support in any GL, what it would require.
<pq>
but it could be an option, and likely a performant one if supported
<emersion>
there are additional exts for EGLSurface, but we don't use these in wlroots
<pq>
a format for the blending buffer using optical values; 8 bpc is no-go. 10 bpc might be just enough. I'd go with 16F when possible.
<emersion>
for both buffers?
<emersion>
both swapchains*
<pq>
um, both what?
<pq>
for the temporary blending buffer
<emersion>
okay, and not for the final buffer?
<emersion>
ah, linear
<vsyrjala>
the automagic srgb blend stuff doesn't work?
<pq>
the final KMS framebuffer can be whatever you use now, since it's again electrically encoded
<emersion>
vsyrjala: which one?
<emersion>
pq, yeah, that makes sense
<vsyrjala>
isn't there a knob to turn that on?
<pq>
only the temp buffer needs extra precision
<pq>
vsyrjala, I think that wlroots link from emersion explains why not.
<emersion>
is the highp important?
<emersion>
vs. mediump
<pq>
emersion, in a word, it's a mess.
<emersion>
:D
<pq>
I just use highp in a desperate attempt to get me as much precision as possible.
<emersion>
lol
<pq>
because otherwise I think the GLSL spec allows very very poor precision
<emersion>
in practice how does it turn out with mesa?
<pq>
hint: the spec precision ranges do not even align to sensible things like "8 bpc"
<emersion>
any difference there?
<pq>
I never tried without.
<pq>
it also totally depends on the GPU
<emersion>
ok
<pq>
I just pick the highest and hope for the best.
<pq>
could this be one reason why people think compute shaders are simply superior...
<pq>
8 bpc is not enough to encode optical values from material that was originally 8 bpc electrical. You need always at least a couple bits more precision, or go to floating-point.
fmuellner has quit [Ping timeout: 480 seconds]
<JEEB>
16f is what I often see being utilized
<pq>
It's good for HDR optical too, I believe. 10 bpc is not.
<pq>
emersion, btw. I made Weston just outright require GL ES 3 for color management. Dealing with all the extensions ! needed with GL ES 2 started to be painful.
<pq>
*I needed
<pq>
with the right extension it's possible to write your own read-modify-write blending code, so you could but back on the temp buffer precision, but I don't know if that's worth it.
<pq>
*cut back
devilhorns has joined #wayland
<emersion>
i'm currently trying to poke at EGL_EXT_image_gl_colorspace in mesa
<emersion>
but it won't buy much if we want to blend in output colorspace…
<pq>
you can choose where you want to blend in
<pq>
many HDR monitors only accept standard signals, so blending in that standard space at least for those monitors makes sense
<pq>
I mean standard color space like BT.2020 that potentially have nothing to do with what the monitor is capable of.
<emersion>
i'm wondering if we should restrict color management support to Vulkan
<pq>
maybe not a bad idea
<pq>
a pretty good idea, actually, I think
<pq>
it's a lot of work to get just one renderer do the stuff right
<pq>
if you keep in mind that maybe someone one day wants to let your GL ES renderer support the same, that should be a nice plan
<emersion>
maybe we should go all-in and use compute shaders
<emersion>
hm
<pq>
sounds cool
<emersion>
this would skip the need to have an intermediate buffer
<pq>
ah, texturing from all windows in a single "draw"?
<pq>
would be really nice to see someone do that
<pq>
but it also closes the door from doing the same in GL ES one day, I guess