ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
feaneron has quit [Quit: feaneron]
fmuellner has quit [Ping timeout: 480 seconds]
Brainium has joined #wayland
kasper93 has quit [Remote host closed the connection]
kasper93 has joined #wayland
glennk has quit [Ping timeout: 480 seconds]
Consolatis has quit [Ping timeout: 480 seconds]
Consolatis has joined #wayland
Brainium has quit []
nerdopolis has quit [Ping timeout: 480 seconds]
mceier has quit [Ping timeout: 480 seconds]
mceier has joined #wayland
naveenk2 has joined #wayland
karenw has quit [Ping timeout: 480 seconds]
glennk has joined #wayland
Sid127 has quit [Ping timeout: 480 seconds]
dcz has joined #wayland
___nick___ has joined #wayland
___nick___ has quit []
Sid127 has joined #wayland
Tom^ has joined #wayland
aelius_ has quit [Remote host closed the connection]
aelius has joined #wayland
coldfeet has joined #wayland
naveenk2 has quit [Ping timeout: 480 seconds]
sima has joined #wayland
Hypfer has joined #wayland
aelius has quit [Ping timeout: 480 seconds]
tzimmermann has joined #wayland
zzyiwei has joined #wayland
Tom^ has quit [Remote host closed the connection]
Tom^ has joined #wayland
<zzyiwei>
Hi, I'm curious about why does explicit synchronization protocol require drm syncobj timeline instead of being sync file based. Taking Vulkan API as an example, QueuePresent can generates a sync file as the gpu out-fence for the display to wait on, while AcquireNextImage consumes a sync file from the display side as the gpu in-fence for the app to wait on before rendering to the wsi image again.
<emersion>
zzyiwei: vulkan uses binary syncobjs
<emersion>
timeline syncobjs can be re-used and support more features
<zzyiwei>
you mean more features beyond the interaction with Vulkan API? what would be an example? much appreciated
<zzyiwei>
even for the potential support of timeline semaphore through wsi, it could be still via sync file across the ipc boundary
<zzyiwei>
the vk implementation is able to do an empty submission during QueuePresent, which takes the wait points and export a sync file for them. Meanwhile, the wsi layer can store the signal points to the wsi image.
readyonidealist has joined #wayland
readyonidealist has quit [Remote host closed the connection]
<zzyiwei>
the next ANI would be able to take the signal points out from the image, and signal them from the host side on a separate thread upon the signaling of the display release fence
<emersion>
that creates new objects/FDs each frame
<emersion>
also doesn't support wait-before-submit
<zzyiwei>
display side consumes a fd, and returns a fd. Not necessarily new?
suzukimitake has joined #wayland
<zzyiwei>
okay, the main take folks have disagreement is likely _who should be blocked_
<zzyiwei>
while chatting with Android friends, we kinda agree that display shouldn't be blocked _indefinitely_, while passing along a timeline syncobj allows it
<zzyiwei>
so if the app would like to shoot its own feet, blocking it within QueuePresent makes more sense to me. We then only pass along a materialized dma-fence
<zzyiwei>
guaranteed to signal in finite time
<zamundaaa[m]>
zzyiwei: the app can block its own surface being updated at any time by just not updating it
kts has quit [Quit: Konversation terminated!]
<zzyiwei>
yes, but then the display side don't have to worry waiting on something never signals. So what'd the benefit or win of sending over a drm syncobj timeline?
<zamundaaa[m]>
You have to worry about waiting for something that will signal in "finite time" too
<zamundaaa[m]>
It could mean that it will only signal in 10ms, or in 10s
<zzyiwei>
indeed, most of them still enforces sort of timeout. e.g. On Android, there's a 5sec hard timeout on the sync file
<zamundaaa[m]>
5s is not ok, and in many situations neither is 10ms
<zamundaaa[m]>
You may miss a frame or multiple on the compositor side either way
<zzyiwei>
5s is before taking the buffer, e.g. queued up in the per app specific channel
<zamundaaa[m]>
If you already have that infrastructure, then what's the problem?
<zzyiwei>
I get your point of using timeline isn't any worse than sync file in that sense ; )
<zzyiwei>
haha...sorry if I made you feel that way. English is not my 1st language xD
<zzyiwei>
the problem goes back to how timeline semaphore gets supported via Vulkan WSI, a.k.a. how to allow an app to pass a timeline semaphore to QueuePresent
<zzyiwei>
Per I mentioned earlier, with just sync file to sync between the app and the compositor, an app is able to create a random timeline sempahore and pass to QueuePresent.
<zzyiwei>
The swapchain itself doesn't have to own a timeline.
kts has joined #wayland
<zzyiwei>
When a swapchain gets created, it can start a _timeline tracking_ thread. App makes use of some timeline semaphore, and finally passes along to QueuePresent. The driver is able to just submit the wait part to export a sync file, while storing the signal points to the wsi image itself. Upon the acquire of the same wsi image, the driver then can push a struct like {wsi image, release fence} to the
<zzyiwei>
_timeline tracking_ thread. That thread gets waked up and sync_wait the release fence till signal then immediate vkSignalSemaphore of those signal points stored in the wsi image.
<zzyiwei>
That might be able to drop the dependency of drm syncobj
kts has quit [Ping timeout: 480 seconds]
atticf has quit [Remote host closed the connection]
<zzyiwei>
I _guess_ that would make some non-DRM based implementations happier, and would also make remote implementations (e.g. virtio-gpu venus) on top of those downstream drivers happier, when synchornizing with wayland server. Especially for the case of those downstream drivers not doing implicit fencing..
<zamundaaa[m]>
You can't delay things on the driver side
atticf has joined #wayland
<zamundaaa[m]>
The surface needs to be committed in vkQueuePresent, with sync information attached
<MrCooper>
zzyiwei: making it sync_file-based wouldn't allow the presentation to be queued before the corresponding GPU work
<zamundaaa[m]>
Using a thread to work around that just sounds like a lot of work
<MrCooper>
zzyiwei: it's basically what the previous explicit-sync protocol does, and it means there's no tangible benefit from explicit sync vs implicit (which can pass the same fences via the dma-buf's implicit synchronization object)
naveenk2 has joined #wayland
<zzyiwei>
well...the benefit is per said, but just not the upstream implementations...probably don't care that much. I don't know anything about NV proprietary drivers, but I couldn't expect a _correct_ implicit fencing from it based on past experience.
<MrCooper>
yeah, the nvidia driver intentionally doesn't handle implicit sync, which means it doesn't interoperate correctly with apps & drivers relying on it
<zzyiwei>
Hi MrCooper, calling QueuePresent before QueueSubmit feels like not a critical usage..?
<MrCooper>
you'd have to argue that with the people who are pushing for it, not me
<zzyiwei>
ah...makes sense. I'm just curious. No offence ^^
<MrCooper>
none taken
<MrCooper>
but yeah, AFAIK at this point there's no Vulkan (let alone GL) API which actually allows taking advantage of that
<zzyiwei>
zamundaaa[m]: what has been delayed on the driver side? do you mean more better not blocking too much in QueuePresent?
<zzyiwei>
delegating to a separate thread to do host side signal ops isn't much work, and it only has to be one thread per chain. It's like a fence monitoring thread for all the display release fences.
<zamundaaa[m]>
I guess I don't fully follow what you're proposing
suzukimitake has quit [Remote host closed the connection]
<zzyiwei>
For the timeline semaphore sent through QueuePresent, it gets split up to the wait part and signal part. The wait payloads (there can be multiple timeline semaphore sent together) will turn into a sync file once materialized to dma-fences, and the sync file is sent over to the display. The signal part means when display no longer scans out from the image and fully releases it, and we track the semahores
<zzyiwei>
along with the signal values in the wsi image itself. When the app proceeds N frames and acquires the same wsi image again, the AcquireNextImage call is able to ask the _timeline tracking_ thread to wait on the display release fence (the received sync file) to signal and do host side signal operation to complete the "signal part" on behalf of the display.
fuipitsutech has joined #wayland
fuipitsutech has quit [Remote host closed the connection]
stillfuipitsu has joined #wayland
<zamundaaa[m]>
Sounds like a possible implementation. Not sure I see the point to support timeline semaphores for presentation if you're gonna stuff it into a sync file again in the end
<zamundaaa[m]>
If you have a platform that supports neither implicit sync nor timeline semaphores I guess it's a valid workaround
<zzyiwei>
The tricky part is then hidden in the implementation, while the api design for swapchain timeline semaphore can be cleaner. Hopefully easier for devs, since they don't have to create some semaphore and then referencing special swapchain timeline.
<zzyiwei>
yeah...that's the norm for downstream drivers
<zzyiwei>
layering on top of those while trying to do synchronization with display server is quite challenging
<zzyiwei>
(challenging in the sense of not pulling down FPS noticeably)
<zzyiwei>
Thanks for all the context and details so far! Really appreciated that folks still willing to chat about this though it's been quite a while after the protocol landed. Gotta sleep now
Tom^ has quit [Read error: Connection reset by peer]
Tom^ has joined #wayland
<zzyiwei>
I was mainly asking on behalf of my Android friends, where on Android, it's already explicit sync file between the apps and display process (SurfaceFlinger). So if the vk api design has the potential to be transparent of drm syncobj timeline, that'd be a pure win for them I bet.
<zzyiwei>
At least would make their life easier...hopefully xD
zzyiwei_ has joined #wayland
zzyiwei_ has quit []
stillfuipitsu has quit [Remote host closed the connection]
<MrCooper>
zzyiwei: QueuePresent cannot be safely offloaded to a thread with the Wayland platform, it risks hitting spurious protocol errors
kts has joined #wayland
<MrCooper>
in general, transparently offloading stuff to threads isn't really in the spirit of Vulkan
<MrCooper>
zzyiwei: specifically, QueuePresent must call wl_surface_commit before it returns to the app
codegigolito has joined #wayland
codegigolito has quit [Remote host closed the connection]
FreeFull has quit [Quit: Lost terminal]
rasterman has joined #wayland
Core1122 has joined #wayland
<Core1122>
MrCooper: QueuePresent won't be offloaded to a thread. Internally it could submit and export a sync file sent to the display. AcquireNextImage is the call that would offload the signalling of the wsi timeline semaphore to a thread. On that thread, it polls the display release fence and then signals the timeline semaphore to the intended signal values stored during QueuePresent.
<Core1122>
Hmmm, the irc client on my phone got my nickname wrong, but whatever xD
<Core1122>
I was mainly describing the sync file based _workaround_ for downstream drivers not drm syncobj based.
<Core1122>
For most mesa drivers, they could just add the stored point back to the timeline semaphore along with the display release fence during the AcquireNextImage call, so that a separate thread can be avoided for them.
Core1122 has left #wayland [#wayland]
Core1122 has joined #wayland
<Core1122>
Fixed my nickname...I bet
<kennylevinsen>
still Core1122
Core1122 has left #wayland [#wayland]
zzyiwei is now known as Guest15473
zzyiwei has joined #wayland
<kennylevinsen>
instead of hacking around in the WSI to work around downstream drivers lacking syncobj support, wouldn't it be better to add syncobj support to the downstream drivers? :)
<zzyiwei>
Challenge too tough! gotta quit and join them to fix their thing...
<zzyiwei>
so we are looking for a sweet spot that the existing ecosystem is happy and peaseful
<kennylevinsen>
so the issue is an old/broken downstream driver, and you're trying to implement newer features on the old driver without changing it
* kennylevinsen
has no idea what the stance in mesa is about that
<zzyiwei>
finally fixed my nickname...yeah!
<zzyiwei>
probably not old broken driver...Mali DDK...Adreno proprietary...NV proprietary
<zzyiwei>
some powervr driver...
<zzyiwei>
they are just not there yet to embrace drm, or maybe one of them will never be there
fmuellner has joined #wayland
<zzyiwei>
They still have pretty decent market share for mobile/desktop platforms of the end users. I wish we could give a 2nd thought to not leave them on the table =p
<kennylevinsen>
I honestly have no idea if mesa's WSI generally adds code to support external drivers, or expects those drivers to bring their own WSI nvidia-style :|
<kennylevinsen>
and without knowing that I can't really contribute much to the discussion
<zzyiwei>
oh. I wasn't talking about mesa wsi layer
<kennylevinsen>
downstream WSI can do whatever is needed to work with downstream drivers
<zzyiwei>
for mesa, the explicit sync code path works great with the current Wayland sync protocol. I was just saying the sync file based design can also work seamlessly with mesa wsi layer as well (no extra thread). If two protocols exist, mesa certainly pick the drm syncobj based on. No doubt and no need to add a new code path there
<zzyiwei>
The difficulty resides in downstream WSI doing explicit synchronization with Wayland compositors
<kennylevinsen>
I doubt it would get traction, but you could try to propose a sync-file protocol. The current protocol was made this way because it's better, and we can only really design for what the kernel supports. Downstream drivers are always a question mark, and we can only really assume that they'll eventually support what is in the kernel
<zzyiwei>
Makes sense to me.
<kennylevinsen>
vendors of downstream drivers are also free to join in on reviews during protocol design if they have concerns, it can't really be upstream's responsibility to guess what happens inside random third party proprietary codebases :|
kts has quit [Ping timeout: 480 seconds]
<zzyiwei>
Again, makes complete sense to me. shame on the laziness (including myself).
<linkmauve>
zzyiwei, all of these proprietary drivers have free drivers existing in Mesa, why would you continue to use them if they are worse?
<zzyiwei>
not necessarily worse to be fair, from the pure rendering pov, putting display integration aside
Tokoyami has quit [Quit: ~@~]
Tokoyami has joined #wayland
<kennylevinsen>
the question is more if they're observed to be notably better to justify still using them - in some cases the answer might be "yes"
<zzyiwei>
another niche case is that mesa virtio-gpu venus driver does care about those downstream implementations...the guest VM can be a nice Linux distro, but the host side is XXX could be some close source thing and could be Android, etc
<zzyiwei>
or even one day if Venus can support Linux VM running on Windows host (need someone familiar with win32 external memory bits to hook things up)
<zzyiwei>
drm syncobj via Venus over those non-drm drivers is sooo tricky, while binary semaphore is much easier from Vulkan to Vulkan...sorry shame on me
<kennylevinsen>
note that closed source != syncfile instead of syncobj. E.g., a windows host or closed source driver could have an easier time with timeline syncobjs
<kennylevinsen>
it's just that you specifically have some out of tree Linux drivers that have not yet implemented syncobj, most likely because they only update their drivers as need arises (hence "old")
coldfeet has quit [Quit: leaving]
<zzyiwei>
nice open drivers in mesa all have vdrm support ready(or mostly ready). I'm also a fan of that tech these days. The only unfortunate thing is those left for Venus to deal with are either not quite okay with implicit fencing. Venus has to implement drm syncobj on top of standard Vulkan API on the host OS side, which might be possible but still hacky. So in a lot of cases, Venus has to block the wsi submission to workaround broken fe
coldfeet has joined #wayland
<kennylevinsen>
as mentioned, while I don't think it will get a lot of traction, you can try to propose a sync-file based protocol
<kennylevinsen>
I'm sure the people working on venus in mesa would themselves raise concerns if they had any
<zzyiwei>
So if the Linux side GPU<->display can be synced via sync file, Venus can get it for free. No free meals! Venus is also on the niche side, so I don't have the stance to steer in general. As I mentioned earlier, I was mainly asking on behalf of friends in Android this time. Hopefully a surger spot can be found in the recent VK wsi timeline semaphore debate.
<zzyiwei>
Thanks! I'll start with filling an issue after getting some sleep xD just past 3am
coldfeet_ has joined #wayland
zzyiwei has left #wayland [#wayland]
coldfeet has quit [Remote host closed the connection]
iomari891 has joined #wayland
DodoGTA has quit []
DodoGTA has joined #wayland
FreeFull has joined #wayland
coldfeet_ has quit []
Tom^-laptop has joined #wayland
Tom^ has quit [Read error: Connection reset by peer]
iomari891 has quit [Read error: Connection reset by peer]
khlsvr has joined #wayland
iomari891 has joined #wayland
<khlsvr>
Hey. Moved to wayland and installed wofi. I have used to running `redshift -O 2500` in the evenings from the rofi's -show run. Now with wofi I try replicate it with its `wofi --show run` running `gammastep -O 2500` but it doesn't recognize these parameters/flags and defaults to launching my browser. AI suggests making a wrapper script. Creating dozens small scripts for every
<khlsvr>
variation is not maintainable. `gammastep -O 2500` from terminal works as expected. I see only couple issues on wofi's github page and not many stars, I guess people are using something else for this stuff?
Tom^-laptop has quit [Remote host closed the connection]
<kennylevinsen>
you didn't install wayland, but installed a display server that implements the wayland protocol. You should ask in a forum/channel/etc. for that display server or desktop enviroment
<kennylevinsen>
e.g., if you're using sway, #sway over at libera chat
shoragan has quit [Read error: Connection reset by peer]
shoragan has joined #wayland
iomari891 has quit [Ping timeout: 480 seconds]
tzimmermann has quit [Quit: Leaving]
Tom^ has joined #wayland
nerdopolis has joined #wayland
coldfeet has joined #wayland
Moprius has quit []
MrCooper_ has joined #wayland
MrCooper has quit [Ping timeout: 480 seconds]
feaneron has joined #wayland
bwbuhse_ has joined #wayland
bwbuhse has quit [Ping timeout: 480 seconds]
bwbuhse_ is now known as bwbuhse
iomari891 has joined #wayland
dcz has joined #wayland
Tom^ has quit [Remote host closed the connection]
robclark has joined #wayland
<robclark>
MrCooper_: re "making it sync_file-based wouldn't allow the presentation to be queued before the corresponding GPU work"... has anyone actually demonstrated/measured a case where this is needed? Android just uses sync_file's, which seems like evidence that sync_file is sufficient. And by the time ioctls come to the kernel, you already have the syncobj's backed by dma_fence. So using syncobj maybe lets you pipeline a _tiny_ bit
<robclark>
of latency, but seems like a solution for a problem that doesn't exist..
<robclark>
"it's basically what the previous explicit-sync protocol does, and it means there's no tangible benefit from explicit sync vs implicit (which can pass the same fences via the dma-buf's implicit synchronization object)" ... no explicit sync still gets you the benefit of not accidentally over-synchronizing
aelius has joined #wayland
MrCooper_ is now known as MrCooper
<MrCooper>
robclark: as I wrote before, AFAIK Vulkan doesn't actually support queue-present-before-queue-submit yet, however some people (not me) are pushing for it, which is one of the main reasons for the Wayland protocol being based on drm_syncobj
<robclark>
ok, maybe you aren't the right person to ask.. but still leaves me with the question about whether this is actually needed
<MrCooper>
the ship sailed a couple of years ago I'm afraid
<MrCooper>
anyway, not sure what the problem is with drm_syncobj
<robclark>
just seems like unneeded complexity
iomari891 has quit [Ping timeout: 480 seconds]
<MrCooper>
complexity where?
cyrinux9490 has quit []
cyrinux9490 has joined #wayland
mahkoh has joined #wayland
dcz has quit [Remote host closed the connection]
dcz has joined #wayland
<mahkoh>
syncobj avoids having to pass file descriptors for every frame.
<mahkoh>
What is the status of the next wayland.xml release?
<mahkoh>
I a world where vulkan gets support for syncobj, neither party would have to deal with sync files or any per-frame file descriptors at all.
<mahkoh>
*in
<robclark>
MrCooper: sync_file support is ubiquitous.. syncobj is not, and is additional work to support in driver, etc..
<robclark>
mutter wl also seems to have some bug where sometimes it gets off by one resulting in wrong frame being display.. I haven't quite figured out what is going on there yet, but at some point I'm going to have to waste some time tracking that down. It is harder to mess that up when you are passing a sync_file every frame
<robclark>
mahkoh: I've not seen any benchmarks that show not passing a fd every frame is gaining you anything
<robclark>
so, maybe ship has already sailed, but that won't stop me grumbling about it being the wrong decision ;-)
<kennylevinsen>
doing something every frame is always worse than *not* doing something every frame when the work gains you nothing, even if it's not expensive enough to impact game fps
<kennylevinsen>
so one is definitely better than the other, and is capable of some things syncfile is not - even if we don't need it yet
<kennylevinsen>
I'm also not sure how between two equal Linux kernel drm subsystem features one is "ubiquitous" and the other not - it's well supported by drivers, and high level user-space code does not concern itself with either - it's only really in platform glue one has to decide, and there it seems obvious to pick the better option when designing something new :/
<MrCooper>
robclark: so you haven't figured out what the problem is, but you know it's related to drm_syncobj... based on what?
<robclark>
it is hard to reproduce but so far I only see it if kernel exposes SYNCOBJ_TIMELINE
<kennylevinsen>
well it could be, but having a bug doesn't really mean anything - it's just a bug
<mahkoh>
There would be no need for drivers to support syncobj at all if syncobjs coulde be created and manipulated via a dedicated device node, e.g. /dev/syncobj, instead of only being accessible via compatible drivers.
dcz has quit [Read error: Connection reset by peer]
<mahkoh>
As far as I know, none of the syncobj logic relevant here has any driver interaction at all.
dcz has joined #wayland
<robclark>
kennylevinsen: my point is that it is something harder to screw up with sync_file
<MrCooper>
waiting for a timeline point to signal isn't really harder than waiting for a sync_file to signal
<kennylevinsen>
I don't see one but in one compositor as evidence that something is easier to screw up - there is no syncfile implementation to compare to and all other compositors handle it just fine
<kennylevinsen>
*bug
<MrCooper>
I haven't seen (reports of) such an issue with mutter
<robclark>
it might not be a mutter bug, I don't understand what is going on there enough to make that claim yet
<kennylevinsen>
I have most certainly made bugs with much simpler things, and that's not in any way or form evidence that it's easy to screw up, just evidence that I fucked up (a rare occurrence, I know)
<robclark>
but I do know passing sync_file's has been rock solid for a long time on various other winsys's
flokli has quit [Quit: WeeChat 4.5.1]
<MrCooper>
from my PoV the drm_syncobj protocol has been rock solid *shrug*
flokli has joined #wayland
<kennylevinsen>
make sure to at least file a bug against Mutter for the observation so it can be looked into :/
dcz has quit [Read error: Connection reset by peer]
dcz has joined #wayland
dcz has quit [Read error: Connection reset by peer]
dcz has joined #wayland
feaneron has quit [Ping timeout: 480 seconds]
feaneron has joined #wayland
Tom^ has joined #wayland
ramblurr_ has joined #wayland
ramblurr has quit [Ping timeout: 480 seconds]
ramblurr_ is now known as ramblurr
fmuellner has quit []
fmuellner has joined #wayland
mahkoh has quit [Quit: WeeChat 4.6.2]
Tom^ has quit [Remote host closed the connection]
Tom^ has joined #wayland
<Guest15473>
Hmmm, zwp_linux_explicit_synchronization_v1 looks to be exactly the one. Chromium's exo wayland server implements it, which supports both its native clients as well as headless vm clients doing wayland passthrough to the host (e.g. on ChromeOS). Since the protocol is already there, I'll abstain myself from making any more noise here. Whoever cares is able to add more implementations of it ; )
Guest15473 is now known as zzyiwei
Tom^ has quit [Read error: Connection reset by peer]
<zzyiwei>
sorry, I messed up my nickname again..
zzyiwei has quit [Quit: leaving]
Tom^ has joined #wayland
Tom^ has quit [Remote host closed the connection]
Tom^ has joined #wayland
<kennylevinsen>
(that protocol actually came from Chromium and it's official status is "deprecated")
coldfeet has quit [Quit: Lost terminal]
feaneron has quit [Ping timeout: 480 seconds]
dcz has quit [Quit: Konversation terminated!]
Tom^-laptop has joined #wayland
Tom^ has quit [Ping timeout: 480 seconds]
oLphMw0s has joined #wayland
<oLphMw0s>
Hi. Do I understand correctly, that there is no way in wayland to to create a window or draw anything to the screen without an extension like xdg-shell?
glennk has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
<kennylevinsen>
oLphMw0s: we don't consider them "extensions" - the core protocol only defines very common concepts, wayland-protocols is the package that contains the official "functional" protocols built on top of that
<kennylevinsen>
early on core tried to have the ability to put *something* on screen as an MVP but that was a Bad Idea™
<kennylevinsen>
and yes, xdg-shell is the (official, stable) protocol that defines how traditional desktop "windows" and "popups"/"context menus" are created
<kennylevinsen>
to many GPU buffers, you use linux-dmabuf - each protocol is small and only tries to define one isolated and composable piece of functionality