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
<pac85>
I'd appreciate any advice and I'll certainly try to take inspiration from your work to see if ai can bring that idea back to life
<pac85>
(Sorry about the typos and messy sentences, it's late here)
pac85 has quit [Remote host closed the connection]
pac85 has joined #wayland
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
Consolatis_ has joined #wayland
Consolatis is now known as Guest927
Consolatis_ is now known as Consolatis
Guest927 has quit [Ping timeout: 480 seconds]
ybogdano has quit [Ping timeout: 480 seconds]
zebrag has joined #wayland
Consolatis_ has joined #wayland
Consolatis is now known as Guest935
Consolatis_ is now known as Consolatis
Guest935 has quit [Ping timeout: 480 seconds]
zebrag has quit [Quit: Konversation terminated!]
Consolatis_ has joined #wayland
Consolatis is now known as Guest941
Consolatis_ is now known as Consolatis
Guest941 has quit [Ping timeout: 480 seconds]
glisse has quit [Ping timeout: 480 seconds]
dri-logger has quit [Ping timeout: 480 seconds]
glisse has joined #wayland
glisse has quit [Read error: Connection reset by peer]
dri-logger has joined #wayland
glisse has joined #wayland
cvmn has joined #wayland
cvmn has quit [Ping timeout: 480 seconds]
bittin has joined #wayland
danvet has joined #wayland
cvmn has joined #wayland
astlep has joined #wayland
dcz_ has joined #wayland
Arnavion has quit [Remote host closed the connection]
Arnavion has joined #wayland
jgrulich has joined #wayland
<SardemFF7>
daniels: oh, where in France? (if you don’t mind my asking, on IRC :-) )
Arnavion has quit []
Arnavion has joined #wayland
jgrulich has quit [Remote host closed the connection]
mvlad has joined #wayland
hardening has joined #wayland
rv1sr has joined #wayland
<MrCooper>
pac85: not seeing how a Wayland compositor on top of an X server could provide any additional security compared to the X server itself
<kennylevinsen>
Also note that "vsync" (as referred to in games) and non-tearing are not the same. One intentionally maximizes latency, while the other is a sets a deadline for sending frames. Difference vs. Tearing and non-tearing is the difference between a too early deadline and no deadline, or possibly subframe latency difference.
elenapan has joined #wayland
<kennylevinsen>
Big difference, and causes part of the argument to be based on a false premise of no tearing == worst case render timings...
<MrCooper>
"vsync intentionally maximizes latency" isn't inherently true either, it's just that most games have very simple frame scheduling logic (if it even deserves that name)
<kennylevinsen>
Yeah hence "as referred to in games", i.e. what gamers associate with vsync...
jgrulich has joined #wayland
fahien has joined #wayland
Lucretia has quit [Remote host closed the connection]
Lucretia has joined #wayland
<pac85>
MrCooper: my idea is to have a wayland compositor running on top of X and bind it's socket in a sandbox. I'm not talking about improving security for unsandboxed apps
<MrCooper>
even so, X11 clients outside of the sandbox can access windows from sandboxed apps
<pac85>
MrCooper: interestinf merge request, however I don't use mutter and I don't think that's the problem. With mailbox say the client runs 10hz slower than the screen. Then 10 times in a second a frame has to be duplicated, if it runs 10hz faster then 10times a second a frame will be skipped. If the client has a variable franerate then frames will be skipped or duplicated all the time. This results in some level of stutter (perhaps j
<pac85>
(perhaps due to perhipheral vision?) And it looks less stuttery to me.
<pac85>
Full vsync is always smoother
<MrCooper>
pac85: what you describe is indeed inevitable with mailbox, but IME it results only in minor judder, not major stutter
<MrCooper>
the issue fixed by that MR does result in stutter though
<DemiMarie>
MrCooper: unsandboxed clients are fully trusted by definition.
<MrCooper>
not with a Wayland host display server :)
<pac85>
I don't think most games have very simple frame scheduling logic (if it even deserves that name), games are complex beasts with varying level of parallelism. Techniques to reduce latemcy when vsynced are a thing in the gaming industry but simply put, as soon as you have any level of paralelism between frames more frames = less latency
<pac85>
Vsync doesn't allow to have framerates above the refresh rate which makes you lose the input latency race at the start. It is well accepted within gamers and game devs that tearing is the preffered way for competitive games
<MrCooper>
pac85: most games just draw frames as quickly as possible, which isn't really "frame scheduling"; vsync with perfect frame scheduling (which may not be possible in practice, mind) would result in the same minimum (and better average) latency as mailbox
<pac85>
MrCooper: I think you are assumjgn some kimd of sequential structure to how game logiv is executed and frames are rendered, this isn't always the case
<pac85>
And the moment it isn't the case drawing as many frames as possibile is a requirement to get less input latency
<MrCooper>
I'm sure there are exceptions
<pac85>
Perhaps simole games
<pac85>
But in any case runninf as fast as posisbile woth tearing gives you less latency
<pac85>
So that's what they do
<pac85>
It's not them being stupid, it just hapoens to worl better and be simpler
caveman has quit [Quit: caveman]
<MrCooper>
yes, I'm talking about the non-tearing case though (tearing is utterly uninteresting to me)
<pac85>
Then mailbox+a lot of frames is the next best thinf without tearing
rgallaispou has quit [Read error: Connection reset by peer]
<MrCooper>
I just explained why that's not true :)
<DemiMarie>
MrCooper: what I am hearing is that for competitive gaming, the difference between non-tearing and tearing *alone* is enough to matter.
<pac85>
Thing is, some games do implement 'throttling', that is waiting before polling the inout and starting rendering
<MrCooper>
DemiMarie: I understand that
<pac85>
But you can't always do it+you can't precisely predict how long simulation+rendering takes
<pac85>
So latency is always more than running as fast as possibile because you need some headroom
bittin has quit [Remote host closed the connection]
<pac85>
So many games don't bother, I think it's dome by some mobile games
<DemiMarie>
pac85: are games basically busy-spinning at 100% CPU/GPU usage by design?
<DemiMarie>
Mobile games cannot do this without completely killing battery life
<MrCooper>
exactly; with mailbox, you don't have to worry about the headroom, but in exchange you get half a frame length worth of extra latency on average
<pac85>
DemiMarie: games give you a choice, vsync on or vsync off. Historically vsync on means waiting vblank ehile vsunc off means tearing amd yes 100% gou
<MrCooper>
and judder
<pac85>
Gpu*
<pac85>
MrCooper: also coanider that whem games runs at several hundred fps tearing is pretty hard to notice
<MrCooper>
I don't agree, it depends more on what changes between frames
<DemiMarie>
MrCooper: but it should be the user’s choice
<pac85>
Yes it should be like it has been for decades
<pac85>
MrCooper: more frames per second->less difference between frames
<pac85>
So tearing is less noticeable
<DemiMarie>
Think of gaming as to graphics as DPDK is to networking
<MrCooper>
DemiMarie: why but? does that contradict anything I wrote?
<DemiMarie>
At least AAA competitive games
<pac85>
Also even if it was possible to implement better frame scheduling (and the vast majority of games run gpu work in parallel with cpu work so I doubt much can be done) if games don't do it that's of no value for users
<pac85>
It remains a purely theoretical possibility as far as a user is concerned
<pac85>
Which is the kind of thing one shoukd take into account. We are not rewruting every possible clint out there and accommodating existing ones, even if it implies sacrifices in the protocol design (though I can't see the sacrifuce with a tearing protocol) just improves to user experience
<DemiMarie>
pac85: I must say that as a Qubes OS developer, supporting gamers is one of the biggest challenges.
<pac85>
DemiMarie: I'd imagine it would be pretty hard to have graphics accelleration passed through securely to a vm, given how large od a surface graphics APIs are, how is it handled currently?
<DemiMarie>
pac85: it isn’t, all rendering happens in software, which is why none of the recommended stuff has a beefy GPU
<pac85>
Oh I see
<pac85>
DemiMarie: doesn't this have implications for things such as battery usage even with regular use cases?
<DemiMarie>
The current plan is to rely on SR-IOV support from the GPU vendors. Intel has open-source SR-IOV support for Alder Lake GPUs (IIRC) but it is not upstream yet.
<DemiMarie>
pac85: yes, it does
<DemiMarie>
Made worse by developers treating software rendering as a fallback path that they do not optimize.
<MrCooper>
I remember reading a blog about how some shooter game (some Call of Duty?) uses pretty sophisticated frame scheduling to minimize latency, but I can't find it anymore :(
<MrCooper>
the fact that gnome-shell is usable with llvmpipe contradicts the "do not optimize" hypothesis
<pac85>
MrCooper: still there are plenty of people taking measurements on call of duty with and without tearing and results are just better when the gane runs at a higher framerate
<pac85>
DemiMarie: are current gpu virtualization techs not secure enough?
ManMower has quit [Ping timeout: 480 seconds]
<pac85>
MrCooper: also keep in mind that even with tearing you can improve input latency by employing some kind of frame scheduling technique when you have parallelism
<DemiMarie>
pac85: SR-IOV is (hopefully) secure enough, but consumer cards have not had it until recently. Other tech is not.
<pac85>
DemiMarie: so things like virgl are out of question I imagine, is it because virtual memory is handled somewhat losely in grapbics drivers?
<DemiMarie>
You can get “kept mostly secure by frequent patching and a lot of investment” (WebGL/WebGPU) but not more than that.
<DemiMarie>
pac85: the problem with virgl is that a huge amount of complex processing (such as shader compilation) happens on the host.
<qyliss>
DemiMarie: do you think Venus will make it any better?
<kennylevinsen>
pac85: I think you are discussing too many aspects of this at once, making the discussion a bit messy. E.g., input loop scheduling (and netcode related optimizations), competitive high-fps games at full throttle, smart games that only render what they need, subframe latency, etc.
<kennylevinsen>
it's more productive to discuss one topic at a time.
jmdaemon has quit [Ping timeout: 480 seconds]
ManMower has joined #wayland
<kennylevinsen>
Input processing and rendering is from our perspective entirely separate. The render samples whatever game state there is, which can be arbitrarily smart and affected by things more important than render schedule (e.g. netcode)
<DemiMarie>
qyliss: what is Venus?
<qyliss>
DemiMarie: vulkan virgl
<qyliss>
I've heard that the vulkan protocol is much simpler
<DemiMarie>
More secure, yes, but there is still the entire shader compiler
<kennylevinsen>
So from our perspective, we only have to care about the time between render start and scan out. Well-placed render atart lowers this for whole the frame, tearing for subframe.
<kennylevinsen>
And importantly: tearing usually implies busy-looping the GPU, out ruling smart *render* scheduling (but not smart input scheduling or anything else out of scope)
<kennylevinsen>
You could align the first tearline if you wanted, but scheduling implies throttling which would drop the number of tearlines - I.e. reducing the "benefit"
<kennylevinsen>
So not sure if anyone does that
<pac85>
kennylevinsen: I think if we want to talk about how different modes affect input latency it is worth talking about those things as they lead towards a true to real world answer. In any case a game does gpu and cpu work and to max out the gpu they have ti happen in parallel, as they do you now have a cpu loop waiting for the previous frame to finish to submit new gpu work, meaning you are waiting after having processed the input a
<kennylevinsen>
Now when you enable "vsync" you get room to be smart
<kennylevinsen>
They always happen in parallel
<pac85>
You could in principle wait a fence before presenting and make it all sequential afaik
<kennylevinsen>
True but then you're artificially making your game bad :P
<pac85>
Ik
<kennylevinsen>
Unless we think all games do something that horrible - which is 100% a game bug we shouldn't care about - then it doesn't make sense to discuss. Your argument was that games were "smart" after all.
<kennylevinsen>
s/all/many of the relevant competitive titles/
<DemiMarie>
qyliss: I want to see some well-resourced attackers try to compromose Venus.
<pac85>
kennylevinsen: the things is that games not being seauential makes schedluing frames for the vsynced case much harder
alatiera1 has joined #wayland
alatiera has quit [Ping timeout: 480 seconds]
<pac85>
Without vsync the total latency of the game itself is more than than the sum of tume taken by the cpu + time taken by the gpu becuase the cpu is waiting after duing it's work. Introducing some scheduling of the cpu work can bring it closer to the sum. If you now introduce another wait, this time for vblank, to me it seems like things just get more complicated
<pac85>
Not claiming there is no solution but I wonder hoe complex and how far from optimal it would be
<pac85>
In any case I see this discussion as hypothetical, I wonder whether their point of view on whether things could be improved by scheduling is seen by some as a reason to nit have a tearing protocol
<pac85>
To put it simply, would I have to convince you that that there are compelling reason to have tearing or has it been accepted that choice should be just given the end user?
<MrCooper>
making it user controllable makes sense to me (doesn't necessarily require a Wayland protocol though); I think it's important not to end up with a solution where users may accidentally hit tearing when they didn't explicitly ask for it though
agd5f_ has joined #wayland
zvarde198830 has joined #wayland
eroc19909 has joined #wayland
novakane_ has joined #wayland
bcheng_ has joined #wayland
WhyNotHugo_ has joined #wayland
kennylevinsen_ has joined #wayland
milesrout_ has joined #wayland
sumoon_ has joined #wayland
txtsd_ has joined #wayland
kchibisov_ has joined #wayland
tommybomb_ has joined #wayland
tsujp_ has joined #wayland
moses_ has joined #wayland
ecocode____ has joined #wayland
smurray_ has joined #wayland
elibrokeit_ has joined #wayland
enilflah_ has joined #wayland
dnkl_ has joined #wayland
tdeo_ has joined #wayland
Cwiiis_ has joined #wayland
ifreund_ has joined #wayland
d10n_ has joined #wayland
panzeroceania___ has joined #wayland
yongxiang_____ has joined #wayland
jgrulich has quit [Remote host closed the connection]
quantum5_ has joined #wayland
Lightsword_ has joined #wayland
daniels_ has joined #wayland
UndeadLeech_ has joined #wayland
eroc1990 has quit [synthon.oftc.net larich.oftc.net]
zvarde19883 has quit [synthon.oftc.net larich.oftc.net]
slim has quit [synthon.oftc.net larich.oftc.net]
ecocode___ has quit [synthon.oftc.net larich.oftc.net]
dnkl has quit [synthon.oftc.net larich.oftc.net]
milesrout has quit [synthon.oftc.net larich.oftc.net]
tdeo has quit [synthon.oftc.net larich.oftc.net]
Cwiiis has quit [synthon.oftc.net larich.oftc.net]
tommybomb has quit [synthon.oftc.net larich.oftc.net]
mcf has quit [synthon.oftc.net larich.oftc.net]
bcheng has quit [synthon.oftc.net larich.oftc.net]
inferiormartin has quit [synthon.oftc.net larich.oftc.net]
kennylevinsen has quit [synthon.oftc.net larich.oftc.net]
sumoon has quit [synthon.oftc.net larich.oftc.net]
novakane has quit [synthon.oftc.net larich.oftc.net]
moses has quit [synthon.oftc.net larich.oftc.net]
Lightsword has quit [synthon.oftc.net larich.oftc.net]
ifreund has quit [synthon.oftc.net larich.oftc.net]
yongxiang____ has quit [synthon.oftc.net larich.oftc.net]
elibrokeit has quit [synthon.oftc.net larich.oftc.net]
quantum5 has quit [synthon.oftc.net larich.oftc.net]
kchibisov has quit [synthon.oftc.net larich.oftc.net]
agd5f has quit [synthon.oftc.net larich.oftc.net]
tsujp has quit [synthon.oftc.net larich.oftc.net]
hwentlan_ has quit [synthon.oftc.net larich.oftc.net]
panzeroceania__ has quit [synthon.oftc.net larich.oftc.net]
smurray has quit [synthon.oftc.net larich.oftc.net]
UndeadLeech has quit [synthon.oftc.net larich.oftc.net]
Seirdy has quit [synthon.oftc.net larich.oftc.net]
d10n has quit [synthon.oftc.net larich.oftc.net]
txtsd has quit [synthon.oftc.net larich.oftc.net]
whynothugo has quit [synthon.oftc.net larich.oftc.net]
rektide has quit [synthon.oftc.net larich.oftc.net]
enilflah has quit [synthon.oftc.net larich.oftc.net]
daniels has quit [synthon.oftc.net larich.oftc.net]
that_guy has quit [synthon.oftc.net larich.oftc.net]
jekstrand has quit [synthon.oftc.net larich.oftc.net]
rektide has joined #wayland
kennylevinsen_ has left #wayland [#wayland]
jason_ has joined #wayland
jason_ is now known as jekstrand
ifreund_ is now known as ifreund
kennylevinsen has joined #wayland
hwentlan_ has joined #wayland
<kennylevinsen>
pac85: if you read the MR you'd see that we're just waiting for the required kernel features to manifest. Once there, the MR for tearing updates can proceed.
slim has joined #wayland
<kennylevinsen>
I for one would never, ever be interested in seeing tearing but I accepted the subframe latency argument as having some degree of merit
jgrulich has joined #wayland
pac85 has quit [Ping timeout: 480 seconds]
<DemiMarie>
kennylevinsen: is the difference that X11 uses the legacy kernel APIs?
Seirdy has joined #wayland
mcf has joined #wayland
inferiormartin has joined #wayland
<kennylevinsen>
well if it does something we can't do with the newer APIs yet then yeah it would have to be using the legacy APIs
<kennylevinsen>
xorg predates atomic commits by slightly over a decade I think
elenapan has quit []
fahien has quit [Ping timeout: 480 seconds]
elibrokeit_ has left #wayland [#wayland]
rtjure has joined #wayland
pac85 has joined #wayland
* emersion
working on a patch to bring async page flips to atomic rn
<emersion>
… just how many hw abstraction layers can amdgpu have
<pac85>
MrCooper: A protocol is indeed needed. Wayland currently doesn't provide any way for the client to tell the server anything at all regarding swap interval/present mode. This means that there really is no way to have fully vsynced app remain vsynced and currently mailboxed apps become tearing without a protocol.
<pac85>
looking forward to take a look at your patch when it will be merged. I took a look at amdgpu myself so now I'm curious. Is there going to be a way of querying async flip support for atomic modesetting explicitly?
<emersion>
yes
<pac85>
DemiMarie: xorg uses the legacy api+in some cases it blits directly to the front buffer
<DemiMarie>
pac85: sometimes it just drives the GPU directly in userspace IIUC
<DemiMarie>
emersion: speaking of GPU drivers, it appears that many of them do not work well under Xen or with IOMMU support enabled
<pac85>
DemiMarie: what do you mean excatly?
<DemiMarie>
pac85: I believe some of the drivers use MMIO from userspace (via sysfs)
<pac85>
Uh
<pac85>
Really
<DemiMarie>
Or (worse) `/dev/mem`
<emersion>
what kind of driver does that?
<pac85>
I don't think xf86-video-amdgpu does it
<pac85>
Not for presentation at least
<emersion>
oh, do you mean xorg drivers?
<pac85>
Haven't looked at the whole thing
<emersion>
it's less surprising if so
<pac85>
Still sounds weird
<DemiMarie>
Yes, xorg drivers
<pac85>
Perhaps some old drivers?
<DemiMarie>
Yup
<DemiMarie>
emersion: do the GPU drivers often not use the DMA API properly or at all?
<pac85>
The ones that support xorg not running as the root userd shouldn't be able to do it
<DemiMarie>
And do not
<emersion>
GPU drivers can't assume they run as root, and in general use a driver-specific kernel uapi
<pac85>
So I guess we are talking about pre kms drivers
<DemiMarie>
Correct
<emersion>
by "GPU drivers" i mean mesa
<pac85>
xf86-video used to implement 2d accellerstion 2d right? xf86-video-amdgpu just uses glamor
<DemiMarie>
emersion: how surprising is it that Qubes keeps having problems with amdgpu suspend/resume?
<emersion>
sorry, i don't know
<emersion>
maybe you could try explaining your problem in #radeon
<emersion>
with details etc
<DemiMarie>
more generally, is GPU pass-through support going to improve or is it always going to be hit-or-miss?
<emersion>
i have no idea
<DemiMarie>
Where could I ask about such things and find people who would know?
<emersion>
for amdgpu specifically, #radeon or the ML
<emersion>
if you have detailed info, you can open a bug report
<LaserEyess>
maybe, if you're lucky, some of them are hardware guys
<emersion>
"blame the hw designers" is a common (half-)joke among driver devs
<LaserEyess>
not very likely though, I bet it's pretty compartmentalized
<emersion>
yeah, i wouldn't have high hopes
<DemiMarie>
What I really want to know is why certain decisions were made
<LaserEyess>
and to be fair to both the driver teams and the hw teams; they have to support one of the most complex pieces of engineering ever made by humanity across not only 3+ OSes, but also multiple architectures (on linux) and multiple low level APIs taht need to map to their hardware
<LaserEyess>
it cannot be easy
<pac85>
I'm personally surprised to see a triangle on the screen given the amount of things that have to happen to get it there
<DemiMarie>
There is a huge difference between “this seems to work” and “this is secure against malicious input”, and there are various ways in which the Qubes team is trying to go that need the latter.
<LaserEyess>
DemiMarie: I don't think you're ever going to learn that, and most likely the answer is "this is what management approved"
<LaserEyess>
I deal with that on far less complex systems, and sometimes I come out of meetings just as baffled why a decision was made and I know all of the discussion behind it
<DemiMarie>
LaserEyess: even for technical stuff?
<LaserEyess>
yes
<DemiMarie>
specifically, what I would like to know is if the GPU is fundamentally capable of defending against malicious shader instructions
<LaserEyess>
I think you should never assume that it is even if the answer is "yes"
<DemiMarie>
Why do you say that?
<LaserEyess>
because no one can design a perfect system
<MrCooper>
LaserEyess: "amdgpu was also originally proprietary" is fake news, it was mostly refactored out of the radeon driver originally
<LaserEyess>
hardware bugs and hardware flaws exist
<DemiMarie>
I know
<LaserEyess>
MrCooper: they shared a lot of their code with the windows driver though, didn't they?
<DemiMarie>
looks at Spectre
<emersion>
MrCooper: ah, didn't know. with the common code bolted on?
<MrCooper>
LaserEyess: that's DC, which was added later
<emersion>
i see
<LaserEyess>
ok
<LaserEyess>
definitely not an expert so I guess I'm wrong
<DemiMarie>
My question is whether there are people looking for such flaws and if such flaws get patched (e.g. with GPU microcode updates) when found.
<MrCooper>
I was part of it :)
<LaserEyess>
well then, TIL, thanks for sharing that info
<MrCooper>
no worries
<LaserEyess>
DemiMarie: I would assume so, the linux driver team would definitely know the answer to that
<LaserEyess>
well, I hope they know the answer to that...
<MrCooper>
pac85: that ambiguity can be solved with the presentation timing protocol, doesn't necessarily require a special tearing protocol
repetitivestrain has quit [Remote host closed the connection]
repetitivestrain has joined #wayland
bittin has joined #wayland
<DemiMarie>
LaserEyess emersion: The question I usually ask is, “Would you trust this to provide isolation in a public cloud environment with untrusted guest administrators?”.
<emersion>
DemiMarie: for one thing, WebGL exists
<emersion>
mind, this doesn't mean everything is secure
<DemiMarie>
emersion: yes, and vulnerabilities are constantly found in it.
<emersion>
but there is motivation for vendors to avoid Bad Things from happening, at least
novakane_ is now known as novakane
fahien has joined #wayland
pac85 has quit [Remote host closed the connection]
pac85 has joined #wayland
pac85 has quit [Remote host closed the connection]
<LaserEyess>
DemiMarie: I am neither a computer scientist/developer nor security expert, but my intuition is to never trust computers to do the right thing, ever
<LaserEyess>
as for specifics on why, I can't say, I don't know anything about it
<LaserEyess>
¯\_(ツ)_/¯
Satan has joined #wayland
zebrag has joined #wayland
pac85 has quit [Remote host closed the connection]
pac85 has joined #wayland
thevar1a- has joined #wayland
thevar1able1 has quit [Ping timeout: 480 seconds]
alatiera1 is now known as alatiera
Satan has quit [Quit: Bad stuff happened]
Satan has joined #wayland
Satan has quit [Read error: Connection reset by peer]
Satan has joined #wayland
smurray_ has quit []
smurray has joined #wayland
rtjure has joined #wayland
daniels_ is now known as daniels
<daniels>
SardemFF7: Paris atm, Montpellier for a few days from tomorrow, back home next week
ybogdano has joined #wayland
pac85 has quit [Remote host closed the connection]
pac85 has joined #wayland
devilhorns has joined #wayland
rtjure has quit [Ping timeout: 480 seconds]
pac85 has quit [Remote host closed the connection]
pac85 has joined #wayland
thevar1a- has quit [Ping timeout: 480 seconds]
cool110 has quit [Ping timeout: 480 seconds]
cool110 has joined #wayland
<pac85>
MrCooper: Yes I think a good solution would be to have a protocol that can communicate all of the modes supported by vulkan then have the user decide how opengl's swap interval maps to it and perhaps the abukity to always force vsync (which I'd keep separate since some vulkan games expose 3 options).
cool110 has quit [Remote host closed the connection]
cool110 has joined #wayland
pac85 has quit [Remote host closed the connection]
pac85 has joined #wayland
pac85 has quit [Remote host closed the connection]
pac85 has joined #wayland
devilhorns has quit [Read error: Connection reset by peer]
devilhorns has joined #wayland
pac85 has quit [Remote host closed the connection]
pac85 has joined #wayland
that_guy has joined #wayland
mbalmer has quit []
MajorBiscuit has joined #wayland
pac85 has quit [Remote host closed the connection]
pac85 has joined #wayland
fahien has quit [Quit: fahien]
devilhorns has quit []
MajorBiscuit has quit [Quit: WeeChat 3.5]
soreau has quit [Read error: Connection reset by peer]
soreau has joined #wayland
cvmn has quit [Remote host closed the connection]
<swick>
tbh I think one way towards better scheduling would be to define a proper swapchain behavior first, with a negotiated swapchain length, proper release semantics and multiple surfaces
<swick>
then building a scheduling protocol on top of that
<emersion>
what's the motivation for swapchain length negotiation again?
ybogdano is now known as Guest1057
ybogdano has joined #wayland
ybogdano has quit [Read error: Connection reset by peer]
Guest1057 has quit [Ping timeout: 480 seconds]
<emersion>
MrCooper: hm, since mesa's x11 vulkan WSI does some clever stuff with Xwayland detection… do you think we need a way for Xwayland to tell mesa it supports immediate flips natively
pac85 has quit [Remote host closed the connection]
pac85 has joined #wayland
jmdaemon has joined #wayland
pac85 has quit [Remote host closed the connection]
pac85 has joined #wayland
<tleydxdy>
hmm if it handles xwayland differently is it possible for the display to be a native wayland window and have everything else get from xwayland?
eroc1990 has joined #wayland
<tleydxdy>
it's like hwoverlay but with x and wayland
eroc19909 has quit [Read error: Connection reset by peer]
eroc1990 is now known as eroc19909
<bwidawsk>
I see this when trying to build wayland, not sure if it's just me:
<emersion>
it means you're missing some DocBook stuff, bwidawsk
agd5f has joined #wayland
agd5f_ has quit [Ping timeout: 480 seconds]
pac85 has quit [Remote host closed the connection]
pac85 has joined #wayland
<bwidawsk>
weird, I swear it used to build...
<emersion>
the CI has the dep names for Debian I think
<emersion>
the website CI has them for Alpine
ybogdano has joined #wayland
pac85 has quit [Remote host closed the connection]
pac85 has joined #wayland
buh0 has quit [Quit: Bye!]
<swick>
emersion: in the one direction, making sure there are enough buffers for direct scanout, and however many images the client wants to create in advance
<swick>
in the other direction, making sure you're not wasting memory
rasterman has joined #wayland
<swick>
also, if the swapchain size is not as you'd expect and you rely on backpressure for timing, that also becomes a problem
dcz_ has quit [Ping timeout: 480 seconds]
ybogdano has quit [Ping timeout: 480 seconds]
ybogdano has joined #wayland
AndroUser2 has joined #wayland
pac85 has quit [Read error: Connection reset by peer]
mvlad has quit [Remote host closed the connection]
AndroUser2 has quit [Remote host closed the connection]
AndroUser2 has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
danvet has quit [Remote host closed the connection]
thevar1able1 has joined #wayland
thevar1able1 has quit [Remote host closed the connection]
thevar1able1 has joined #wayland
rv1sr has quit []
AndroUser2 has quit [Remote host closed the connection]
AndroUser2 has joined #wayland
AndroUser2 has quit [Remote host closed the connection]