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
The_Company has quit []
fmuellner has quit [Ping timeout: 480 seconds]
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
migro has quit []
lockywolf_ has quit []
evon37788 has joined #wayland
lockywolf has joined #wayland
evon37788 has quit []
evon37788 has joined #wayland
evon37788 has quit []
immibis has joined #wayland
evon37788 has joined #wayland
evon37788 has quit []
evon37788 has joined #wayland
evon37788 has quit []
evon37788 has joined #wayland
slattann has joined #wayland
evon37788 has quit []
evon37788 has joined #wayland
evon37788 has quit []
evon37788 has joined #wayland
evon37788 has quit []
evon37788 has joined #wayland
evon37788 has quit []
evon37788 has joined #wayland
evon37788 has quit []
evon37788 has joined #wayland
abeltramo53912 has joined #wayland
abeltramo5391 has quit [Read error: Connection reset by peer]
evon37788 has quit []
evon37788 has joined #wayland
cvmn has joined #wayland
evon37788 has quit []
evon37788 has joined #wayland
evon37788 has quit []
evon37788 has joined #wayland
evon37788 has quit []
caveman has quit [Remote host closed the connection]
professorclueless35 has quit [Remote host closed the connection]
evon37788 has joined #wayland
professorclueless35 has joined #wayland
evon37788 has quit []
evon37788 has joined #wayland
evon37788 has quit []
evon37788 has joined #wayland
evon37788 has quit []
evon37788 has joined #wayland
jgrulich has joined #wayland
professorclueless35 has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
evon37788 has quit []
evon37788 has joined #wayland
professorclueless35 has joined #wayland
evon37788 has quit []
evon37788 has joined #wayland
professorclueless35 has quit [Ping timeout: 480 seconds]
kts has joined #wayland
professorclueless35 has joined #wayland
evon37788 has quit []
professorclueless35 has quit []
danvet has joined #wayland
evon37788 has joined #wayland
manank_ has joined #wayland
manank_ has left #wayland [#wayland]
evon37788 has quit []
evon37788 has joined #wayland
evon37788 has quit []
evon37788 has joined #wayland
dcz_ has joined #wayland
evon37788 has quit []
jgrulich has quit [Remote host closed the connection]
evon37788 has joined #wayland
eroux has quit [Remote host closed the connection]
evon37788 has quit []
evon37788 has joined #wayland
evon37788 has quit []
eroux has joined #wayland
evon37788 has joined #wayland
evon37788 has quit []
tzimmermann has joined #wayland
evon37788 has joined #wayland
evon37788 has quit []
jgrulich has joined #wayland
evon37788 has joined #wayland
evon37788 has quit []
evon37788 has joined #wayland
rasterman has joined #wayland
evon37788 has quit []
evon37788 has joined #wayland
manuel_ has joined #wayland
rgallaispou has quit [Remote host closed the connection]
evon37788 has quit []
evon37788 has joined #wayland
evon37788 has quit []
evon37788 has joined #wayland
mvlad has joined #wayland
evon37788 has quit []
evon37788 has joined #wayland
evon37788 has quit []
gschwind has joined #wayland
evon37788 has joined #wayland
evon37788 has quit []
evon37788 has joined #wayland
<marex>
mvlad: I'm not sure whether this is appropriate question here, but I was wondering -- when I run boot splash like psplash or plymouth, and then start weston, the mode is reinitialized and there is flicker -- is there some way to seamlessly hand-off from splash screen to weston ?
chipxxx has quit [Read error: Connection reset by peer]
chipxxx has quit [Remote host closed the connection]
chipxxx has joined #wayland
evon37788 has joined #wayland
<marex>
mvlad: nice, that seems to be exactly what I'm looking for
<marex>
mvlad: thanks !
evon37788 has quit []
evon37788 has joined #wayland
evon37788 has quit []
evon37788 has joined #wayland
evon37788 has quit []
<pq>
emersion, I don't think we have ever averted from compositor or client side complications when designing Wayland extensions. E.g. the surface transactions extension, or sub-surfaces.
<emersion>
pq, right, but here having per-surface color representation can be seen as undesirable complexity
<emersion>
because no real-world client would make use of it, yet it would make all compositors more complicated
<pq>
emersion, if I have to maintain a GL texture per wl_buffer+wl_surface combination in Weston, that's peanuts compared to what I've been doing already in the name of CM&HDR.
<pq>
emersion, my only real concern is whether app code can actually make use of the extensions when they want to.
<emersion>
ack
<pq>
vyivel, I think damage existed before regions, and there is no apparent benefit from using a region object for damage, so no-one bothered.
evon37788 has joined #wayland
evon37788 was banned on #wayland by pq [evon37788!*@216.181.83.3]
<pq>
adjusted a bit for quit/join floods
<pq>
emersion, if you can make the case that putting everything on wl_buffer is ok for apps, then I'm fine with that.
<emersion>
it may be ok for apps, but still has issues
evon37788 has quit []
<emersion>
mainly, that the complexity isn't gone if the CM protocol still has per-surface linear/srgb
<pq>
no, I really meant *everything*
<emersion>
ah, i see
<pq>
including everything from the CM&HDR extension
<pq>
The only reason we have been putting stuff on wl_surface is because of EGL not having API to put stuff on the wl_buffer.
<emersion>
it may be okay if we implement EGL exts in mesa
<emersion>
but not sure this is an acceptable solution
<emersion>
tying stuff to wl_buffer also has its own issues
<emersion>
mainly, there is no buffer commit
<pq>
I don't know. I do know that there are people who would love a cross-OS EGL API for stuff.
<emersion>
so, we'd essentially need to spec that the color-representation and CM metadata needs to be attached to the buffer before any wl_surface.attach request
<emersion>
and cannot be changed after that
<pq>
yeah
<pq>
I'd be ok with that, I think.
<pq>
that could cause otherwise unnecessary reallocation of buffers when a window moves from one output to another
<emersion>
that's true
<pq>
OTOH, resizing is by far much worse, so moving to another output seems insignificant
kts has quit [Quit: Leaving]
<emersion>
time to add a whole new object to address this: wl_buffer_view /s
<pq>
we already have wp_viewport
<pq>
and in wl_shm you can allocate a big pool and play with that
<pq>
actually, you would not have to reallocate a dmabuf to change color metadata, but you would need to re-create the wl_buffer
<JEEB>
cheers, will check when I get a moment (probably after $dayjob)
<JEEB>
also I found out that my 2015 macbook actually has both colorspace and HDR stuff exposed
<JEEB>
via 915
<JEEB>
also I wonder if there's interest in attempting to plug in libplacebo into weston as a PoC. it is not super-optimized hw block using, but does let you get opengl/vulkan shader based conversions and it has interfaces for ICC handling (including SDR<->HDR graphics white remap)
<JEEB>
so you could for example as a first step set the drm backend to BT.2020+PQ, and then have libplacebo map the expected-sRGB-by-default buffers into that color space
<JEEB>
then if/when the interface where you tell the window/buffer/whatever color space, that could then be mapped.
<JEEB>
it's shader based so when passthrough of a surface is not possible in compositing it would require whatever passing it into a shader would require
<pq>
but what about the shader output? Weston still needs to composite after that.
<JEEB>
depends on how it all works, but if weston then needs to do additional changes then either import or copy is required
<JEEB>
just wondered whether weston was settled for "we will write our own shaders for the shadered path" VS "it would be interesting to see what existing solutions there are"
<emersion>
pq, how much code is the shaders part of CM&HDR?
<emersion>
i suppose one can drop the yuva2rgba() part?
<emersion>
if wl_shm YUV isn't supported?
<emersion>
and more code even
<pq>
yeah, if you do that otherwise. But it's currently missing everything that color-representation can change.
<pq>
no, wl_shm YUV is already supported
<emersion>
it doesn't look that bad tbh
<emersion>
i mean, my compositor doesn't support it, and i'm not interested in adding it
<pq>
right
<JEEB>
I think the most fun thing in SDR vs HDR was how graphics white was no longer in the same location :P
<JEEB>
which I think was found out in BT.2390 or so
fmuellner has joined #wayland
<pq>
JEEB, I see libplacebo has done a lot of interesting work, but I think we have to do our own learning in Weston as well, IOW implement everything from first principles.
<JEEB>
so SDR was either 80 nits (sRGB definition?) or 100 nits (either BT.1886 or something else?) according to which spec you follow, and then in HDR the best practice was to map that to 203 nits
<pq>
JEEB, looking at what libplacebo does would be really nice, but the license conflicts with Weston's, so I don't think I can much.
<pq>
JEEB, I suspect that the SDR white level need to be adjustable. Maybe even end-user adjustable, which then affects the relative available HDR range above it, which then factors into tone mapping.
<pq>
JEEB, we also have ideas to account for the viewing environment.
<JEEB>
alright. Niklas Haasn is the author of that whom I fed with various specs and I think he has some of the best understanding of these things right now, so I'd recommend poking him if you have questions regarding things esp. in the graphics domain. there were discussions regarding libplacebo licensing but as an external library it was kept as LGPL. the readme does note that > Please open an issue if you have
<JEEB>
a use case for a BSD2-licensed libplacebo.
<JEEB>
graphics domain specifically in writing shaders for such color space etc conversions
<JEEB>
pq: and yes I think having adjustment on that is a Good Idea
slattann has quit []
<jadahl>
pq: why would libplacebo's libgpl2.1 conflict? it's not like it'd be the first
<pq>
Haasn has commented on our discussions before at times
<JEEB>
yea I recall him linking issues :)
<pq>
jadahl, it stops me from copying code from libplacebo into weston, which is what I would probably most want to do.
<jadahl>
it stops you from copying, but it doesn't stop you from using it
<JEEB>
yeh and that answers my original question: there is no wish for poking into libplacebo-in-weston
<JEEB>
:)
<pq>
right, but do I actually win much by using it? I worry it might hinder research and experimentation.
<pq>
JEEB, yeah... I don't know libplacebo at all, but using an external library feels like it could hinder at times.
<jadahl>
research and experimentation by copying libplacebo bits into weston means you'd have a lgpl weston, and you wouldn't ship those, but you could still experiment couldn't you?
<JEEB>
I don't recall any good gotchas from the top of my head, but it'd just mean that you'd have to go through those as well if you implement similar conversion paths etc.
<JEEB>
and it's good to have a straight answer right away :)
<JEEB>
NIH is fun, lets you learn after all
<pq>
JEEB, anyway, Weston's full-shader path is two-pass: composition pass reads all input wl_surface, converts to blending space, and blends into a temporary framebuffer. Then the second pass encodes the temp into an actual framebuffer.
<pq>
JEEB, the second pass should also be easy to off-load to KMS.
<pq>
jadahl, what good is that if I can't share it? I definitely do not want to muddy Weston's licensing.
<pq>
jadahl, I would also need to throw all that code away and start from scratch instead of polishing it for upstream.
<pq>
JEEB, I've also noticed that even experts do not always agree on how something needs to be implemented, so if Weston ends up doing different than libplacebo, that a good opportunity to discuss and compare how they got there.
<emersion>
JEEB: i'd be interested in experimenting with libplacebo in wlroots, but I know nothing when it comes to CM
<pq>
I almost suggested libplacebo for wlroots instead :-)
<emersion>
pq: what would you say is a good first step for CM in a compositor?
<pq>
to me the Weston project is more of research than building a product
<emersion>
follow the same path as Weston as explained in the issue? or with insight something else?
<pq>
emersion, weston started with linear blending, then added a way to set an ICC profile for an output.
<pq>
emersion, in hindsight, I don't see anything wrong with the path Weston has taken so far. But it's also the long way around.
<emersion>
I see. for ICC profiles what are the ingredients? 3D LUT?
<pq>
Mutter is taking a different path AFAIU, aiming to get HDR ASAP and CM later. I wouldn't do it like that, but it's an option.
<pq>
fullscreen exclusive window HDR, was it?
<emersion>
ah, I'd agree with you here
<pq>
emersion, for ICC profiles, you first want to choose a CMM. LittleCMS or something else, that handles the ICC files and more.
<emersion>
right
<pq>
a CMM can map from one color space to another, which gives you the ability to construct a 3D LUT that you can use in your own rendering.
<emersion>
so I'd ask the CMM to construct a 3D LUT to map sRGB to the output's ICC profile space?
<pq>
next you will hit problems with 3D LUT having poor precision, big size, and maybe also poor performance, so you want alternatives
<pq>
yes
<JEEB>
i consider icc a super (and sub)set of standard colorspace handling
<pq>
yeah
<JEEB>
so if you implement conversion to linear and then to.output I consider that part 1, even if you implement only h.273 stuff
<JEEB>
(common coding points)
<pq>
if you want to handle ITU-T etc. standard colorspace stuff, you may be better off without ICC, but then you have no ICC support.
<emersion>
pq: the alternative is the color matrix?
<emersion>
is that the same as KMS CTM?
<JEEB>
> the matrix
<pq>
emersion, 1D LUT + matrix is one alternative.
<emersion>
JEEB: referring to Weston's shader here
<JEEB>
ah
<pq>
a parametric curve is better than 1D LUT in precision (and performance?) but is also less flexible
kts has joined #wayland
<JEEB>
pq: i think you can build upon the standard stuff when adding icc. you already have linear/xyz mapping in place
<JEEB>
i think.that is how mpv/öibplacebo also grew
<pq>
emersion, if you a CMM and ICC profiles, going from 3D LUT to something better is a big step, because the CMM is probably not giving you that directly.
<pq>
*if you use
<emersion>
pq: so you need math?
<pq>
emersion, Weston has a LittleCMS plugin in order to access the internal representation of the color pipeline constructed by LittleCMS.
<emersion>
ouch
<pq>
each stage in that pipeline may of several different types, 3x 1D LUT and matrix are just an example, and the ones that Weston current handles.
MrCooper_ has joined #wayland
<pq>
the pipeline is also not optimized, to it may have e.g. multiple consecutive matrices, because of how the pipeline is built from profiles.
<emersion>
x 1D LUT is KMS GAMMA_LUT?
MrCooper has quit [Ping timeout: 480 seconds]
<emersion>
3x*
<pq>
so you want to squash as many elements as you can, and delete identity elements
<emersion>
right
<pq>
then look at the remaining pipeline and see if it fits in what your renderer implements
<pq>
if it fits, nice: you got your matrices and LUTs and stuff
<pq>
if not, use a 3D LUT
<pq>
...and this is where Weston upstream is right now.
<pq>
JEEB, that also depends on your internal architecture. In Weston we are aiming to represent everything as LittleCMS pipelines first, optimize them, then fit them to the renderer and KMS pipeline when possible.
<pq>
of course, one can invent their own arbitrary pipeline abstraction
<pq>
then plug in things standards, ICC files, etc. and optimize that and map to renderer/KMS API
<pq>
damn, I'm hungry, lunch time was an hour ago
<jadahl>
pq: you can share a tainted weston as an experiment, but to ship, you'd have to upstream your improvements to libplacebo and then depend on the new version
<jadahl>
and fwiw, been talking to swick about experimenting with libplacebo in both gtk and mutter
<pq>
jadahl, good. You do that, so I don't have to learn yet another project. ;-)
<JEEB>
pq: my random typos were due to moving onto the balcony to finally have lunch :)
<JEEB>
and littlecms start-off makes total sense if you come from an imaging background
<pq>
I didn't. :-)
<JEEB>
and/or you specifically had hw blocks which ate similar luts or so
<JEEB>
:)
<pq>
I had no background, really.
<JEEB>
mine was getting into video encoding as a teenager, then 2012 did baby's first encoder and now I've ended up doing hacking on FFmpeg, mpv etc
<JEEB>
so for me the triplets are what I am.accustomed to thinking in :)
<JEEB>
matrix coeffs/primaries/transfer
<JEEB>
and then icc for me is just a much more freeform definition of what those define
devilhorns has joined #wayland
<pq>
I certainly wouldn't mind if someone experimented with libplacebo in Weston, bit I cannot promise it would be good for Weston upstream. Or that it would not be.
<pq>
*but
<JEEB>
yeh, and I already have way too many things on my todo list kn FFmpeg / mpv :) the little brain cells I have left after $dayjob
MrCooper_ has quit [Ping timeout: 480 seconds]
<JEEB>
just mostly wanted to poke if people knew it or had opinions
<JEEB>
:)
chipxxx has quit [Remote host closed the connection]
<swick>
the things I have to figure out there are how libplacebo would plug into gtk's renderer and clutter
<swick>
gtk has a single shader source, just like weston now and clutter just pieces together shader code which seems to fit libplacebo more
<swick>
it's also not clear to me if there is a way to get an abstract representation of the transform so we can offload parts of it
<swick>
the adjustable media white is nice and all but if it's just for adjusting between different standards and not arbitrary display+viewing environment combinations it's kind of useless
<JEEB>
I recommend bringing it up on #libplacebo @ Libera I think? libplacebo has different operational modes methinks. just shader generation or more.
MrCooper has joined #wayland
<swick>
yeah, I had a look already and didn't discard the idea of using it
<swick>
unfortunately I also really don't like the code
<swick>
oh yeah, and still no idea how this fits in with our own compositing
<swick>
we need some approx linear space for blending and scaling
<haasn>
11:36 <pq> JEEB, would that imply that Weston will be having an extra full-frame copy of each wl_surface? <- no, it integrates directly into your existing shaders
<haasn>
pq: feel free to ask me if you need me to waive the LGPL license on any particular shader bits of libplacebo
<haasn>
I wrote pretty much 99% of it so I have more or less free license to give away parts of the code as I please
andyrtr has joined #wayland
<haasn>
pq: re: ICC profile handling in libplacebo the long-term plan is to reimplement the entire ICC engine in pure GLSL so we don't need to go through a 3DLUT at all, right now we use 3DLUTs for it still (with tetrahedral interpolation they can be quite small, but still)
<haasn>
but I want to offload stuff to be as close to the pure specified-in-the-ICC-profile math/tables as possible
<haasn>
(in some distant future I see libplacebo not even depending on LittleCMS)
jmdaemon has quit [Ping timeout: 480 seconds]
andyrtr has quit []
<JEEB>
ah, I clearly didn't check the user listing
<haasn>
swick: my own opinion is that for something like gtk et al. you'd only really benefit from libplacebo if you have a scenario where you need to generate code dynamically based on schanging input requirements, for example, if you have an ICC with some unknown internal struct and you want to generate the right shader to encapsulate it
<haasn>
or if you want to handle arbitrary colorspace conversions from A to B, which may or may not involve OOTF, tone mapping, gamut mapping, and so on
<haasn>
if you have a *fixed* list of requirements then you'd be better off pre-generating those shaders and shipping them as static pre-compiled blobs or something
<haasn>
but libplacebo was designed to handle the case of combinatorial explosion
<haasn>
when you have so many parameters that pre-generating static shaders would be impossible and you need runtime shader generation
<JEEB>
yeh, that is true re: pre-generation and (if possible) compilation, if you have a limited subset
<haasn>
something like 80%-90% of lines in libplacebo are concerned with a use case that seems out-of-scope for you (yuv->rgb video rendering, upscaling/downscaling, debanding/dithering, custom shaders, ...)
<haasn>
it's mostly designed for the video playback use case, so we have code for frame interpolation, deinterlacing, helpers for decoding loops, hwdec interop, getting frames into/out of system RAM
<haasn>
whether or not the remaining 10%-20% are useful to you, I don't fully know; it depends on how strongly you care about dynamic handling of different possible color space combinations / ICC profiles
<haasn>
or whether you care about something like higher-quality upscaling/downscaling
<pq>
haasn, awesome, thank you!
<haasn>
the one thing I am definitely planning on working on is ceasing to treat ICC profiles as black boxes / 3DLUTs
<haasn>
but this is _not_ the status quo
<swick>
yuv->rgb, scaling and dithering are all things we do in compositors
<haasn>
heh, well then I mean, fair enough
<swick>
or rather should do
<swick>
there also is a difference in how you generate your shader: libplacebo has inline shader code being glued together but I don't see a reason why you couldn't generate a fitting shader variant from a single source file just like weston and gtk do
andyrtr has joined #wayland
<pq>
haasn, how do you intend to change ICC profiles from black box to something else?
<haasn>
pq: analyze the ICC contents using littlecms introspection
<haasn>
manually upload the relevant 1D LUTs / 3D LUTs contained within
<pq>
haasn, vitaly wrote that for Weston, and it's upstream now.
<haasn>
I have some WIP code for this in some stashed branch
<haasn>
pq: got a link?
<pq>
It only handles 1D LUTs and matrices so far, because other types we cannot handle in Weston's GL-renderer yet.
<swick>
but tbh, the weston approach seems much cleaner and easier to me
<haasn>
yeah actually looking at my code again this is very similar to my idea, basically taking apart the cmsPipeline and iterating through the cmsStage
<pq>
haasn, that seemed to be only possible way to get access to the pipeline contents.
<haasn>
indeed
<haasn>
I dimly remember banging my head against this API as well
<haasn>
swick: the other reason, besides it being able to handle more dynamic scenarios with dynamic shader glueing, is the philosophical reason of wanting the control logic and the shader logic to be adjacent, rather than in separate files; we used to do the "big single shader with a pile of #ifdefs" in mpv's (old/deleted) legacy GL renderer and it was a nightmare to work with
<pq>
haasn, our idea is to translate even ITU-T standards into cmsHPROFILE and then feed through this optimizer, but I'm not sure how well that will work once we start adding gamut/tone mapping.
<haasn>
there's also the part where libplacebo needs to glue together multiple shaders into a single shader (e.g. for handling luma and chroma planes via different code paths but merging them into a single vec3), and the part where we may need to split off the shader and re-sample from the result at arbitrary points in the pipeline (e.g. as a result of user shaders, a use case you probably
<haasn>
don't have to worry about in weston)
<haasn>
pq: it's certainly an approach I can see working, although I personally don't like depending on littlecms for core logic because littlecms/ICC is not really geared for the ITU-R centric video use case
<haasn>
I mean tellingly they don't even support HDR yet, but also stuff like BT.1886 and HLG and OOTFs thrown into the mix
<haasn>
that's why I'm trying to use littlecms only for ICC parsing and do most of the actual logic (gamut mapping etc.) myself
<haasn>
we already do gamut mapping in libplacebo though it can be improved, one of my long-term goals also is to have flexible soft gamut mapping (so no hard-clipping)
<swick>
haasn: well, I can't tell you because I don't understand the code and the interleaving of shader code and CPU code definitely doesn't help me here
<haasn>
but I don't think you need to care about this in a wayland compositor because I think that doing this should be left to the video player (mpv, vlc, ...)
<haasn>
and instead mpv/vlc should have a protocol way to bypass color management in the compositor and handle it themselves
<haasn>
the use case for cms inside a compositor is: 1) well-behaved sRGB content, 2) pngs/jpgs with embedded ICC profiles
<haasn>
3) video games et al. with well-behaved PQ output
<haasn>
but even yuv/rgb conversion seems out of scope to me, though I understand I've lost that ideological battle :p
<pq>
haasn, yes, we only need to ensure the cmsStages we put it are unharmed until hitting the optimizer.
<pq>
haasn, every time some says "we should have a way to bypass color management", I get the urge to hit something. :-/
<pq>
*someone
<swick>
yeah, getting tired of having to have that conversation
<pq>
haasn, you do get a Wayland protocol to say "my image has been rendered for this very output specifically", but you don't get to say "skip color management".
<haasn>
right, or at the very least get it into a well-defined state (e.g. linear float or PQ or whatever) with known metadata and output characteristics (and access to the display metadata / ICC profile inside the program)
<pq>
haasn, a big reason why very often one wants to push YUV data as-is from video decoder into a Wayland compositor is the KMS off-loading.
andyrtr has joined #wayland
<swick>
haasn: so does libplacebo even create a description of the transform or does it only output a blackbox shader?
<haasn>
swick: blackbox only
<pq>
A very popular use case is to play 4k HDR or whatnot video on a system where doing a simple blit of each video frame on the GPU is too slow.
<swick>
yeah... that alone is a big issue
<haasn>
I was planning on redesigning the pl_renderer to construct a scene graph before transforming it into shaders but that API is out-of-scope for you so it wouldn't be of any use
<swick>
yeah I fear we need something like that
<haasn>
it might be an interesting thing to think about for some libplacebo v6 redesign
<haasn>
but libplacebo is more trying to be the thing you plug into the other side of that abstraction, to go from your transform description to shaders
<swick>
mh, but that might be enough as well
<swick>
oh well, I don't think I can get around playing around with it
<haasn>
fair
<haasn>
swick: that design looks like what mpv used to do
<haasn>
before we had to rewrite it in this way before it became unmaintainable
<pq>
heh
<haasn>
(and libplacebo is the rewrite of when _that_ became unmaintainable because of exponential explosion in the complexity of all the simultaneous requirements)
<pq>
and Weston used to piece together pieces of strings to create shaders before, then migrated to this because the old thing looked unmaintainble
<haasn>
haha
<haasn>
different use cases, I feel
<pq>
yeah, Weston's pipeline in that shared is actually pretty rigid.
<pq>
*shader
<pq>
pre-determined elements that you either use or don't
<pq>
with parameters
<pq>
not unlike KMS, really, and not accidentally either
<pq>
since a big goal for us is to able to to off-load stuff to KMS when it happens to fit
<haasn>
you have a big four-way tradeoff of (performance, compatibility, extensibility, simplicity)
<haasn>
and libplacebo decided to compromise on none of the first three
<haasn>
you want something like (performance, compatibility, simplicity) because extensibility is not your major goal
<JEEB>
yea f.ex. if the hardware can do mixing of N layers then you can instead of doing mixing yourself just use layers in KMS etc
<haasn>
libplacebo also leans towards extensibility and compatibility over performance, for example we need to support anything from GLSL 110 (for VLC GL renderer back-compat) up to GLSL 460+ (for new features like subgroup operations)
<haasn>
so sometimes that means going for a simpler algorithmic approach that works on all systems versus something hyper-tuned for modern pipelines (like kms offloading etc.)
<haasn>
we also need to support GLES and desktop GL simultaneously.. and also compute shaders and fragment shaders simultaneously...
<haasn>
doing it all with macros works to some extent but at some point you just hit the breaking points
<pq>
KMS is essentially a fixed-function pipeline where most of the element are missing.
<pq>
right, having to support different shader languages or variants is something I'm very very glad to not have to do. :-)
<swick>
dunno, might need vulkan support sooner or later
<swick>
and KMS color pipeline is also likely going to evolve into a more complex and to some degree configurable pipeline
<swick>
but for us performance means literally not doing any work
<pq>
We would have to find a pipeline description that can roughly fit both KMS and libplacebo - then libplacebo could be very useful for realizing the shader path.
<swick>
and to do that we need a way to lower transformations, whatever they might be to a more general representation
<swick>
and that's what I fear won't be possible with libplacebo
<pq>
yeah, you probably wouldn't use libplacebo to *produce* a pipeline description, but it could *take* a pipeline description and turn it into shaders for the fallback path.
<haasn>
well it would be nice if we could do both
<haasn>
I'll have a think about it
<haasn>
basically you want something in between pl_shader_color_map
<haasn>
and its implementation
<swick>
the question is what all the fancy libplacebo features are worth when we can't lower them
<swick>
i.e. you'll probably end up using a very small and trivial subset
<pq>
A pipeline description would need to be as high-level as possible, but then offer stage by stage lowering functionality when needed.
<swick>
yeah but for example libplacebos tone mapping would be a block box we can't lower
<pq>
it should be a string of elementary stages
<swick>
indeed, but that's not what libplacebo provides
<pq>
but each elementary stage should be as high-level as possible, like "this is inverse PQ curve".
<pq>
not today, but we're talking about wishes, right? :-)
<JEEB>
:)
<pq>
and hopes
<pq>
Weston is currently using the LittleCMS pipeline description, because did not feel like inventing its own, and don't know of others.
<pq>
yet, Weston did have to invent its own for its GL-renderer, but that is very rigid - OTOH it is infinitely extensible because it's just internal code and shaders.
<pq>
It also deliberately mimicks what KMS of today could have offered.
<pq>
haasn, KMS off-loading is simple in one aspect: you have just two binary choises to make. a) off-loading post-blending operations, and b) off-load pre-blending and blending operations. Take it or leave it. No intermixing with shaders.
fahien has joined #wayland
fahien has quit [Ping timeout: 480 seconds]
alarumbe has joined #wayland
<haasn>
pq: sounds like a project for the libplacebo rust rewrite
<haasn>
that will invetiably happen
<haasn>
inevitably*
kts has quit [Quit: Leaving]
<pq>
as long as you also expose a C ABI, it's hard to imagine Weston being rewritten ;-)
<pq>
till tomorrow \o.
<haasn>
my original wish was to write libplacebo in Haskell and use an internal EDSL to represent all shader operations
<haasn>
that you could lower to whatever representation you wanted
<haasn>
but sadly, a single global RTS lock prevented that dream from ever coming to fruition
<swick>
haasn: well, let's just say I'd be interested in that rewrite (and rust sounds very good)