ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
<JoshuaAshton>
riteo: Without commit_queue, FIFO is completely broken which results in this behaviour, there is no overlap
<JoshuaAshton>
That's why we are shipping it in SteamOS so early, it's required in order to not regress massively. You just stall in QueuePresent (before present happens) if your last frame has not been presented yet
<JoshuaAshton>
That's how "FIFO" is implemented right now :P
<JoshuaAshton>
It also depends on the compositor only sending `frame` once it has presented a new buffer for your surface, and not every vblank
fmuellner has quit [Ping timeout: 480 seconds]
<JoshuaAshton>
> If it works fine on XWayland but not Wayland then something is really wrong
<JoshuaAshton>
Yes it works fine on XWayland, as it has it's own internal queue in the XServer -- Mesa Wayland WSI does not do such, I suggested that in the past as a stop-gap and daniels told me it was not possible as there are applications expect QueuePresent to do a wayland commit, and that's basically ABI at this point, which makes sense but is also bleh
fmuellner has joined #wayland
<JoshuaAshton>
Anyway, the best way to check this sort of thing is GPUVIS
<JoshuaAshton>
Highly recommend checking that out if you haven't, it's also very easy to use on the SteamOS Devkit Client.
<riteo>
JoshuaAshton: Thanks a lot, now I realize what you meant all this time
<riteo>
also thanks a lot for the tool, I definitely need better tooling if I want to start making more sense out of the black magic of graphics
<riteo>
so uh, this is pretty much a lost battle from the start without a proper queue. I'll consider my 2000Hz hack more than enough for the time being then :P
<riteo>
once that works out I'm sure that we can find a better solution. It's hard to measure any difference if the frame times are that messy and I seriously don't feel like going "blind" on these kinds of optimizations, especially as I don't have much experience
<riteo>
I might lower the tickrate though, let's see
nerdopolis has quit [Ping timeout: 480 seconds]
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
fmuellner has quit [Remote host closed the connection]
<Company>
MrCooper: btw, we talked about software rendering and using 565 instead of RGBA8 - I tried that recently to see if it does anything with GTK and ran my benchmark with LP_NUM_THREADS=1 LIBGL_ALWAYS_SOFTWARE=1 with both
<Company>
I got 35fps with RGBA8 and 30fps with RGB565
<Company>
so there's not much of a benefit to be found inside GTK itself I guess
<MrCooper>
heh, I guess 565 isn't as optimized as 8888 in llvmpipe
<Company>
I suspect the bottleneck isn't memory with GTK
<Company>
though most of the work we do is blitting glyph masks
<Company>
but my assumption is that setup overhead is more relevant than the actual blitting
<Company>
my main concern with going with 565 is the overhead of setting it up
<Company>
the whole fbconfig selection machinery inside GTK needs to choose it - and it very much doesn't ever want to right now
<Company>
plus you run into the issue that you have no alpha channel, so you need to restyle your UI and get rid of rounded corners and shadows
<Company>
so my gut says it's not worth doing, but I might change that opinion with profiling from gnome-shell that shows that its compositing gets loads faster
<Company>
I think the time is way better spent on minimizing damage regions and optimizing shaders
kts has quit [Quit: Leaving]
alatiera has joined #wayland
leon-anavi has joined #wayland
<kennylevinsen>
Company: re: kms commit, you don't need to copy ASAP, just before the next completed pageflip
<Company>
kennylevinsen: I have no control over the buffer if I wl_surface_attach() it
<Company>
so I need to copy before
<kennylevinsen>
the virtio-gpu driver decides when the pageflip completes, so who says it couldn't wait until buffer release? :)
leon has joined #wayland
<Company>
it could - but at that point you run into all the problems you have with a 2-buffer swapchain in a regualr app
leonanavi has joined #wayland
<kennylevinsen>
Not quite - the two buffers locked there are not part of a two-buffer swapchain
leon-anavi has quit [Ping timeout: 480 seconds]
<kennylevinsen>
it's two locked buffers out of an N-buffer swapchain owned by some KMS client
<Company>
I was more thinking about the host side
<Company>
virt-manager or gnome-boxes
leon has quit [Ping timeout: 480 seconds]
<kennylevinsen>
yeah, but the need for 3 buffers in the swapchain is to account for the next render buffer - which exists somewhere inside the VM
<kennylevinsen>
the need for 4 is a bit hairier, I'd have to draw stuff to understand what would happen :P
<Company>
you're also assuming that all apps in the chain immediately release the buffer when they don't need it anymore
<kennylevinsen>
No I was assuming they'd release it some time after it was superseded, with pageflip delayed until that point
<Company>
I was thinking that one buffer is stuck in qemu, one in boxes, one in the host's compositor and suddenly that's quite a few
<kennylevinsen>
this is all hypothetical of course, but only the host compositor should be holding buffers if this was to support scanout
<kennylevinsen>
qemu and boxes would just be forwarding a dmabuf
<Company>
sure
<Company>
but once your system is under load, that forwarding might take a bit
<pq>
JoshuaAshton, "games are not event driven", yeah, that is getting old. Maybe one day someone designs a game engine in a more modern design that separates screen updates from all the rest. I did read the game-loop pattern article, and I think it stops where we would only begin.
i509vcb has quit [Quit: Connection closed for inactivity]
<kennylevinsen>
Company: well, if load is causing forwarding that message to take significant time, then I think it's fair to consider the system unresponsive and performance to be best effort
<kennylevinsen>
significant time being some large fraction of the refresh cycle
<Company>
sure - but that's the 3/4 buffer cases in a regular app, too
<kennylevinsen>
no, the 3/4 buffer case is due to latching
<kennylevinsen>
2 of those buffers are stuck waiting exactly a refresh cycle, the 3rd is the next buffer in the compositor, 4th the next render buffer
<Company>
actually, you're assuming that doesn't happen in boxes or qemu
<Company>
GTK syncs to the frame cycle, so you have latching there, too
<kennylevinsen>
there could possibly be issues there - it would be up to the client to send off the dmabuf as soon as possible of course to not delay things
<pq>
JoshuaAshton, "games are discrete simulations" - yes, but what I and emersion imagine does not conflict with that at all. That article you mentioned already has all the pieces. The only thing missing is to take the rendering out of the fixed course of the event loop and stop doing blocking platform function function calls that cannot be woken up arbitrarily.
<kennylevinsen>
my idea would fall apart if it decides to wait entire refresh cycles with it
<Company>
I think it's unreasonable to assume clients don't do that
kts has joined #wayland
<kennylevinsen>
well, it's not an arbitrary client here, it's specifically a qemu viewer client designed for the task
<kennylevinsen>
using qemu-specific APIs, with contracts to uphold
<kennylevinsen>
could just say "don't grab the buffer until you're ready to show it" for example
<Company>
I don't think that works
<kennylevinsen>
I don't see why it wouldn't, but we're also arguing over a half-baked idea
<Company>
you want your viewer to use a toolkit so that you can manage your vm window
<kennylevinsen>
honestly, a much bigger issue in scanout would be that the buffers from the client might not be scanot capable and getting dmabuf hints working right would be a pain
<Company>
it would be pain to get it right for all drivers I suppose
<Company>
but for the big 3 drivers almost everything is scanoutable, no?
<Company>
(intel, amd, nvidia)
<kennylevinsen>
Company: tbh, a toolkit-less VM viewer would be fine for me, but there's a difference between something being impossible and it being hard to get Gtk to adhere...
<kennylevinsen>
Company: hahahaha, no it's much safer to assume that almost nothing is scanoutable
<Company>
I read the code and it looked like the Vulkan wsi doesn't even look at the scanout flag
<kennylevinsen>
if the buffer doesn't match the *current* buffer format you might need a modeset for example
<Company>
yet it was difectly scanouted fine
<Company>
so I'm not too worried
<emersion>
for these drivers, the scanout flag is ignored, but some modifiers are scanout-capable and some not
<Company>
it's probably an 80/20 thing where 80% of the stuff just works and 20% are so hard to get right that people just give up
<emersion>
historically, the scanout flag has been ignored when using modifiers, because supplying modifiers to mesa would mean "if KMS supports this modifier, assume scanout"
<emersion>
not in mesa we properly propagate that flag, but drivers still ignore it
<emersion>
now in mesa*
<Company>
in GL
<Company>
but not in Vulkan
<emersion>
in vulkan we could use the private mesa ext
<Company>
I'd much rather the flag went away and it'd be encoded in modifiers
<emersion>
the flag cannot be encoded in modifiers, the modifiers only represent the tiling
<emersion>
buffer layout
<emersion>
not things like placement, alignment, etc
<Company>
sure
<MrCooper>
I did mention that before :)
<Company>
people aren't even using modifiers properly yet, I don't think anyone's gonna deal with yet another thing in the near future
<kennylevinsen>
whether a modifier can scanout also depends on the format and plane and such
<MrCooper>
pq: yeah, it's mind-blowing that games relying on rendering to have certain performance characteristics for correctness to be considered state of the art in 2023
<kennylevinsen>
e.g., most modifiers on my old intel can scanout ARGB8888 but some can also scanout NV12 and YUYV
<kennylevinsen>
and some planes only accept some modifiers
<Company>
kennylevinsen: to me as a dmabuf consumer modifiers are per-fourcc anyway
<kennylevinsen>
with e.g. my last primary plane supporting fewer modifiers than the first two
<kennylevinsen>
so even if an app can scanout on my first screen it might not work on my third
<Company>
basically a dmabuf comes with a 96bit GUID that identifies it and I have to carry that thing around
<kennylevinsen>
fair, I'm looking at the modifier and format identifiers directly
<MrCooper>
think of scanout as the 97th bit
<Company>
MrCooper: that doesn't work, because all the APIs want just 96bits
<Company>
well, the good ones, v4l still just wants 32
<emersion>
the scanout flag is only relevant for allocation
<kennylevinsen>
even if you had that bit, such buffer is not necessarily scanoutable
<emersion>
it's not relevant for import
<kennylevinsen>
as mentioned, it might work for scanout on one monitor but not the next, or might not match the output configuration and require modeset
<Company>
I'm aware of all of that - but it doesn't change the fact that I carry 96bit GUIDs and that's all I can do, because nobody supports anything else
<kennylevinsen>
what would you use the bit for if you had it?
<Company>
to give it to whoever needs it
<kennylevinsen>
... does anyone need it? the compositor doesn't, and no one else can scanout
<Company>
whoever allocates the buffers
<Company>
vapi or qemu I guess
<kennylevinsen>
why not just feed it the dmabuf hints?
<kennylevinsen>
i guess qemu could also just mimic the host GPU capabilities
<Company>
because there's no "dmabuf hints" - if there was a libdmabuf with a dmabuf_hints_t and I could just hand that to them, that'd be neat
<Company>
but that's not how the world works - at least not today
<kennylevinsen>
that's what qemu would have to be able to absorb if you want any scanout success
<Company>
any guaranteed scanout success
<Company>
so far I'm going for "accidentally works"
<kennylevinsen>
allocating scanoutable buffers that never scanout is not a good idea
<kennylevinsen>
before dmabuf hints, direct scanout was more of a "if the stars and moons aligned on a day that started with the same letter as your name" ordeal...
<pq>
pac85, usually there are multiple necessary conditions to kick off a new frame rendering, not any single event.
<Company>
it seems to work so well that Valve hasn't complained about Wayland games not getting scanout
<Company>
or have they?
<Company>
s/Wayland/Vulkan/
mvlad has joined #wayland
<MrCooper>
Xwayland was getting lucky for hysterical raisins
<ofourdan>
the best ones, always.
<MrCooper>
(always allocating scanout capable buffers, which can be bad as well when scanout isn't possible anyway for other reasons)
<Company>
ofourdan: btw, you know you've got a Youtuber fanboi?
<Company>
or rather: rarely, only when the guests are interesting
<Company>
emersion: yeah, you have an opinion, he doesn't like you at all
<ofourdan>
heh
<emersion>
it does seem like i have a special place in their heart, but also, it's not just about me
* emersion
shrugs
<kennylevinsen>
you have other fanboys, don't worry
<emersion>
lol
<Company>
at least now you know someone reads your comments in merge requests
cmichael has joined #wayland
<pq>
Company, KMS does not have buffer release events, it only has page flip events, which means what happens in the host side of a VM situation cannot affect how many buffers the quest could benefit from.
<pq>
Company, the only way how direct scanout from a VM guest through host to hardware can work is to delay the page flip event to the guest app until the new framebuffer has been forwarded *and* the previous framebuffer has been made idle, which tends to decimate framerate as there is no room to pipeline through all the layers.
glennk has quit [Ping timeout: 480 seconds]
karolherbst has quit [Remote host closed the connection]
karolherbst has joined #wayland
<pq>
ManMower, riteo, kennylevinsen, the wl_event_queue has unbounded storage to hold incoming events. The "tiny wayland buffer" that overflows is actually in the compositor side.
kts has joined #wayland
<alatiera>
speaking of wayland-protocols
<alatiera>
I was thinking of making a joke MR about adding ext_keylogger_v1
<alatiera>
but I am not sure if that would be taken jokingly or it would be annoying
<pq>
There is no joke that everyone would take as a joke, so I think a flame war or at least bad PR would be guaranteed.
<Company>
alatiera: you have 4 months to come up with good phrasing for that joke
<pq>
please don't
<pq>
it can only hurt us
<pq>
there was another incident this year, but I've fortunately forgot what it was about.
<Company>
I don't think ext_keylogger is funny, because Wayland security is not meme status
<alatiera>
"do everything x11 does" is the meme though
<Company>
ext_x11_v12 would be funnier
<pq>
If you file a MR, maintainers must take it seriously regardless if it's a joke. That takes effort. If maintainers shrugged it off as a joke, that could be used as a weapon against them "they don't even bother telling why not".
<kennylevinsen>
pq: Yeah, so as long as the client can read_events it should stay alive even if it never dispatches...
<pq>
kennylevinsen, yup. All the way until OOM.
<Company>
alatiera: it'd probably be funnier as a github gist though, because that's how that meme goes
<alatiera>
Company: it's now a proper repo!
glennk has joined #wayland
<Company>
you could file an MR for ext_keylogger_v1 against it!
<alatiera>
yes but then I'd have to interact with those people
<soreau>
I couldn't wait for an extension so I implemented printer support in the compositor..
kts has quit [Ping timeout: 480 seconds]
<soreau>
a keybinding to run a script that screenshots the screen and calls lp. done.
<Company>
pq: yeah, I think with the current API you pretty much always want to copy the buffer, which is fine for desktop apps I guess, but you won't get good results in GL benchmarks
<davidre>
I wonder if they expect compositors to implement those protocols (if there ever will be any)
<Company>
though who runs GL benchmarks in a VM?
kts has joined #wayland
<Company>
davidre: "they" is composed of too many groups of people to have a clear answer for that
<Company>
like, a lot of "they" is people who want to stop Wayland from happening because they like their X11 setup and don't want to change - they don't care at all what happens, as long as it doesn't make X11 go away
<soreau>
'they' are too comfortable writing questionable code in the wm and just putting it on a loop in a script, so 'who cares if the wm dies?' :P
<pq>
Company, indeed. IIRC there was even a Weston issue about running: host, weston, qemu, weston; and complaining that framerate is half of what it should be without copying in qemu.
<pq>
and you could make it run at full rate if you adjusted each Weston's timings carefully
<pq>
(repaint-window weston.ini option)
<soreau>
hax
<pq>
yes
<soreau>
sounds kinda like wlroots max_frame_time or whatever it's called
<pq>
possibly
<Company>
it should really have some kms interface to do a swapchain
<soreau>
well, not a wlroots-specific concept but impl. in many wlroots compositors
<Company>
to do this well
<pq>
yeah, well... that's also not what KMS is for, really
kts has quit [Ping timeout: 480 seconds]
<kennylevinsen>
soreau: the implementation differs a bit, but same concept yeah
<pq>
it's just really convenient for VMs to offer a KMS driver, because most userspace software already works on KMS, right up until it becomes inconvenient when the VM behaviour differs from hardware behaviour. Like cursor hotspots and swapchains.
<Company>
it's a kernel module, it could just swap the memory behind the fd!
<Company>
yeah, it gets tricky at some point
<pq>
Company, then it would also need to make sure the other memory has the same contents as the original, because guest userspace does incremental drawing...
<Company>
I imagine people want rootless clients in a VM
<emersion>
pq, and then scaling and multi-output layout and …
<pq>
thankfully I think rootless clients is something no-one would try to shoehorn through KMS, but there are lower hanging culprits. Like the user resizing the VM viewer window and expecting the VM to resize accordingly in it.
<Company>
yeah
<pq>
the cursor hotspot thing was implemented in KMS recently, along with a way to allow VM viewers hijack the cursor plane position without breaking userspace by having userspace promise to not use cursor planes for anything else than the cursor of the one... err, aggregate of all mouse/pointer decives exposed to the guest.
<pq>
a really common setup, but ugh the special-casing just to get KMS working well enough
nerdopolis has joined #wayland
<kennylevinsen>
I wonder what happened to virtio-wl...
<davidre>
Company I was trying to refer to the repo is now the thing not githubgist anymore
privacy has quit [Quit: Leaving]
<davidre>
Where the specific repo I know of is empty and I doubt mainstream compositors would implement anything
vsyrjala has quit [Remote host closed the connection]
nerdopolis has quit [Ping timeout: 480 seconds]
nerdopolis has joined #wayland
Company has joined #wayland
sima has quit [Ping timeout: 480 seconds]
manuel1985 has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
stooov has joined #wayland
<stooov>
ola people. I noticed that in wayland, chrome|brave|webkit's pointerlock hides the pointer but doesn't hold it in place - and it can hit the edge of your screen. have a go: https://svelte-dj-knob.netlify.app/
<stooov>
it works fine (pointer reappears where it began the lock) on firefox, X11, or if your pointerdown even is within about 20px of the edge of the page.
nerdopolis has joined #wayland
<soreau>
stooov: it might be that the compositor you're using doesn't implement pointer lock correctly? have you tried others?
<soreau>
the web app you linked to seems to be working correctly in wayfire