hegstal has quit [Remote host closed the connection]
sumac has joined #wayland
reillybrogan has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
blue__penquin has joined #wayland
aquijoule_ has joined #wayland
aquijoule__ has quit [Ping timeout: 480 seconds]
reillybrogan has joined #wayland
sumac has left #wayland [#wayland]
shrnbld has joined #wayland
<shrnbld>
i'm not sure if it would be better to ask here or somewhere else, but when running sway, i can open firefox and signal-messenger from alacritty but not bemenu-run or wofi--dmenu, could anyone point me in the direction of a log to check or possible cause? i'm on arch and running firejail too
nerdopolis has joined #wayland
boistordu has joined #wayland
shrnbld has left #wayland [WeeChat 3.1]
boistordu_ex has quit [Ping timeout: 480 seconds]
srh1605 has joined #wayland
srh1605 has quit []
srh1605 has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
sozuba has joined #wayland
sozuba has quit [Quit: sozuba]
dcz_ has joined #wayland
srh1605 has quit [Ping timeout: 480 seconds]
NoGuest17 has joined #wayland
NoGuest17 has quit [Remote host closed the connection]
NoGuest17 has joined #wayland
pnowack has joined #wayland
sca has joined #wayland
tzimmermann has joined #wayland
hardening has joined #wayland
danvet has joined #wayland
tzimmermann has quit [Quit: Leaving]
tzimmermann has joined #wayland
sca_ has joined #wayland
sca has quit [Ping timeout: 480 seconds]
rasterman has joined #wayland
rgallaispou has joined #wayland
Arnavion has quit [Remote host closed the connection]
jgrulich has joined #wayland
hegstal has joined #wayland
hegstal has joined #wayland
hegstal has quit [Remote host closed the connection]
Arnavion has joined #wayland
<pq>
ifreund, as an aside, I find it curious that wl_surface.frame can create wl_callbacks with aarbitrarily high object ID. The wl_callback is released by the done event, so I kinda thought the ID would be free for re-use in the client, even if the wl_callback was not freed. Hmm.
ecloud has quit [Ping timeout: 480 seconds]
hegstal has quit [Remote host closed the connection]
ecloud has joined #wayland
<pq>
ifreund, as for running out of IDs, proxy_create() calls wl_map_insert_new() which... no error explicit handling. :-(
<pq>
ifreund, I think you have have found a real bug.
<ifreund>
wl_map_insert_new() returns 0 on error, but nothing checks it :/
<pq>
well
<pq>
I think 0 should just lead to the server disconnecting, because it's not a valid object IS.
<pq>
*ID
<pq>
but that happens only for memory allocation errors
<pq>
the thing not checked is that client-side allocated object ID must be < WL_SERVER_ID_START.
<ifreund>
and this was triggerd by moving the client to a tag that's not being displayed, which means the done event isn't sent on any of the callbacks until the client is displayed again
<ifreund>
gotta go now, be back in ~1 hour
<pq>
but then again, if the ID exceeds that limit, the server will probably see it as a protocol error
<pq>
ifreund, oh! So the done events were never sent, that explains why the ID grows.
<pq>
ifreund, so I think the error checking could be better, but it's not a silent malfunction or security problem, because the server will detect a bad object ID and disconnect the client.
<pq>
or so I think
ecloud has quit [Ping timeout: 480 seconds]
ecloud has joined #wayland
aleasto has joined #wayland
aquijoule_ has quit [Ping timeout: 480 seconds]
richbridger has joined #wayland
<kennylevinsen>
test msg - sorry (I haven't been able to write here for a while it seems, despite registration)
<mceier>
kennylevinsen: it worked
<kennylevinsen>
yeah, seems to pass now - odd :S
<kennylevinsen>
got angry server messages yesterday
reinist12 has joined #wayland
<reinist12>
MrCooper: They never handled me on LLVM they are as crazy deluded shithoses as you, losing everything against me in the end, they handled themselves. It takes talent to be as stupid to not understand dx11 and dx12 might be even worse though, since all of that is only structures and enums and gdpiplus as backend, they are just assembled for opengl devicevia opengl drivers pipeline objects, only gallium3d backend stubs need to be generated instead , and
<reinist12>
this is fully automatically generated, by linking the the relevant library and inlining callsites. Dudes you are totally crazy, it is not like collabora closed source context copy will perform better, in fact it will perform worse
<reinist12>
and you do not seem to remember your own stuff, it just flips pointers of the structures, no copy is ever performed in such cases, and hence it outperforms collabora implementation very certainly
<wrl>
are we really going to do this again
<reinist12>
I do not really care, i am out, considering that all the ideas came from me, you are and probably will be scum to me till the end, i am better off my own
reinist12 has quit []
<pq>
I blame the "new freenode". He was happy ranting alone in freenode before. :-p
nerdopolis has joined #wayland
<wrl>
lol
pnowack has quit [Quit: pnowack]
pnowack has joined #wayland
pnowack has quit []
pnowack has joined #wayland
FLHerne has joined #wayland
<ifreund>
pq: I'm not sure the server will detect a bad object ID if it is 0, instead it will likely pass the 0 id from the callback to wl_resource_create(), which uses 0 as a sentinel to say "use an available ID"
srh1605 has joined #wayland
<pq>
ifreund, that would be bad.
<ifreund>
from what I can tell, libwayland will only send a 0 id to the server if memory allocation fails, but a malicous client could easily do so
<pq>
a malicious client does not need to use libwayland-client to begin with
d_ed has joined #wayland
<ifreund>
exactly
<pq>
ifreund, see line 797 in connection.c
<ifreund>
\o/
<pq>
but I'm worried about the !arg.nullable
<pq>
new_id can't be nullable AFAIU, so why even check...
<ifreund>
yeah that seems fishy
<swick>
urgh, libwayland client can't set a timeout for wl_display_dispatch*?
blue__penquin has quit []
<pq>
no, use the other functions instead if you care about not blocking
<pq>
dispatch_pending never blocks
<pq>
the other part is wl_display_read_events() and friends
<swick>
well, I want blocking but only until the timeout is reached
<pq>
no timeouts, sorry
<pq>
you get to implement your own timer
<swick>
fun
<pq>
if you use poll(), it takes a timeout
<pq>
and poll() is what you would use anyway with the read_events API
<pq>
or epoll or...
<swick>
okay, yeah, isn't that bad actually
<pq>
cool
pastly-antispam has quit [Quit: WeeChat 2.3]
<Levans>
I've been thinking a lot about the interaction between the proposed wp_transaction and sub-surface caches, and it's a bigger can of worm than I expected...
<soreau>
pq: you can't just use select() on the fd to see if it's readable before calling dispatch?
<pq>
Levans, congratulations, now you know why I try to keep a distance. :-D
immibis_ has left #wayland [#wayland]
<Levans>
Basically, I can't think of a way to give a coherent semantics to "adding a sync subsurface to a wp_transaction". Is this something that is actually expected to be used by clients?
immibis has joined #wayland
<Levans>
Because at this point, I'm thinking maybe it should just be declared a protocol error, because it does not make any sense... ._.
<pq>
soreau, you can, and if you have other threads (you may not even know you have), you have a chance to block anyway.
<pq>
soreau, IOW, that works in isolation, yes.
<MrCooper>
Levans: I was wondering if it might be easier to just forbid synced sub-surfaces being part of a transaction... but there might still be some interesting corner cases, e.g. if a surface becomes a synced sub-surface while it's part of a transaction?
<jadahl>
Levans: it doesn't need to be hard, if the responsibility is pushed to the client. e.g. the current approach is that subsurface group commits "atomically", but if wp-transaction is used on a subset of the subsurface group, the subsurface group atomicity is not guaranteed anymore
<Levans>
The other alternative I have in mind would be to have wp_transaction override the subsurface protocol: if a subsurface is added to a wp_transaction, it is forced into desync mode, even if it should inherit sync from its parent.
<jadahl>
i.e. a subsurface is, according to itself, "applied". after this, if there is a wp-transaction, it acts on the individual state the subsurfaces resulted in
<pq>
jadahl, erm... I'd rather ban sub-surfaces completely from a transaction than do that.
<soreau>
pq: I see
<jadahl>
pq: that makes no sense
<pq>
jadahl, you can always stick the root surface of a sub-surface tree in a transaction.
<jadahl>
would make it impossible to do e.g. yuv video frame redirection etc
<pq>
just not surfaces whose role is sub-surface
<immibis>
i have no familiarity with what you are talking about but please don't force implementors to implement silent workarounds to things that could just be protocol errors.
<immibis>
that has never ended well
<Levans>
jadahl: but if wp_transaction is applied after the subsurface logic, then that means a very counter-intuitive behavior for the subsurface state, it is added to the transaction after the root surface of the tree is committed ? Meaning it's still kind of synchronized to the parent, but not completely?
<gitlab-bot>
wayland issue (Merge request) 26 in wayland-protocols "unstable: Add surface group transaction protocol" [New Protocol, Opened]
<jadahl>
Levans: the point would be that it'd be possible to clearly define the semantics without having the two being entangled (i.e. one can change the two extensions in isolation)
<MrCooper>
the discussions we've been having to me indicate that's not realistic
<Levans>
If it's going to be something like "technically it's supported but it has weird semantics and nobody is going to use it in any case", I'm thinking it should be either forbidden or given explicit and clear semantics.
<Levans>
The most meaningful behavior from a client point of view I can think of is "adding a subsurface to a wp_transaction overrides the subsurface sync mechanism, meaning the subsurface is now directly synchronized to the transaction rather than its parents". That makes some very simple interaction between the two protocols, that should be pretty robust to future evolution, no ?
<Levans>
Also, I would expect this to be what feels most natural from a client point of view
<swick>
this is exactly how I intuitively thought the protocol was supposed to work until I learned that it isn't
<MrCooper>
that could do the trick
<jadahl>
having synchronized subsurfaces stop being synchornized subsurfaces doesn't seem sane; would rather go pq's path and disallow it completely
<JoshuaAshton>
swick: Throttling frame callbacks is still an issue here btw
<JoshuaAshton>
For example in Dark Souls 3, if you drop below 45fps for a little while, (as would with your throttling), then you get kicked
<JoshuaAshton>
With the occlusion protocol, there's no need for throttling, we can just return VK_ERROR_OUT_OF_DATE_KHR and the game will work fine
<JoshuaAshton>
Once we have OUT_OF_DATE_KHR, the game destroys its swapchain and goes on like usual
<swick>
yeah, I get that but with or without your suspension protocol it is valid compositor behavior to throttle frame callbacks
<swick>
which is why the protocol would not solve the fundamental issue
<JoshuaAshton>
Right, but that is not the problem the protocol is trying to solve
<JoshuaAshton>
The protocol is meant to solve this situation for when a surface gets suspended (so it's probably occluded)
<JoshuaAshton>
I'm not really interested in solving the "compositor decided to randomly throttle X window" case because it doesn't happen in practice anywhere that matters.
<JoshuaAshton>
Like, the surface occlusion thing is an actual problem that needs solving and is affecting users right now
<JoshuaAshton>
The hypothetical about a random compositor throttling frame callbacks isn't
<swick>
gnome does throttle frame callbacks
<JoshuaAshton>
In what situations?
<swick>
jadahl: ^
<MrCooper>
I only know of compositors holding back frame callbacks while the surface isn't visible anywhere, which is consistent with that JoshuaAshton is saying
<MrCooper>
*what
<zamundaaa>
When the surface is visible then it won't completely hold back frame callbacks
<zamundaaa>
throttling could be used to drop the client down in refresh rate perhaps but I can't imagine that anything else would be sensible compositor behavior
<swick>
there also is this whole vrr thing
<zamundaaa>
That doesn't concern the issue at hand though, does it?
<zamundaaa>
If the compositor drops down to 30fps then the client won't have major problems because of that
<pq>
VRR means no reliable frame rate
<swick>
it sure does. if the compositor takes a while to draw a frame and uses vrr to still present it the next frame callback will shift
<swick>
frame callbacks just don't guarantee any stability
<JoshuaAshton>
That could be a problem in some titles but it is not related to surface suspension
<zamundaaa>
Clients have to (and do in almost all cases) cope with unstable frame rate. A complete hang is what creates the issue
<swick>
well that's not the point here is it?
<swick>
you said any blocking in vkQueuePresentKHR is throwing off the game
<swick>
as long as we use frame callbacks in the FIFO present mode those things can result in it blocking for at least a bit
<JoshuaAshton>
Yes, but specifically in reference to people alt-tabbing/switching workspaces right now
<swick>
sure, thats one manifastation of that problem
<swick>
but papering over the underlying problem whenever a valid compositor manages to trigger it is just not a good idea
<JoshuaAshton>
I don't think it's papering over the problem -- even in the instance we don't care about frame callbacks (MAILBOX or IMMEDIATE ;p) we still want to report occlusion to the application this way
<swick>
yeah, sure, that's why I said somewhere that the idea of the protocol is fine in general but the whole rational in there is about fixing broken apps
<JoshuaAshton>
This just so happens to solve this problem in one way, but also has plenty of other advantages
<zamundaaa>
joshuAshton: there is only a problem when the frame time grows too large, right? For example if a game uses the frame time for physics a 3s frame time can be a big problem. But if it's still under 100ms or sth like that it's not a big deal
<zamundaaa>
Or is there another problem I don't see
<swick>
well it doesn't solve the problem, you just get lucky on some more compositors
<pq>
I do think this is papering over the problem. but then again we cannot go and fix the games.
<swick>
we kind of can
<JoshuaAshton>
zamundaaa: Ehhh dt isn't really the problem, it's more that multiplayer games don't like it for either connection or not having a consistent framerate
<swick>
none of them use the vulkan API directly
<JoshuaAshton>
swick: There is no luck about it, what part is lucky
<ifreund>
both sway and river will temorarily hold back on frame callbacks while performing and atomic configure sequence of multiple views at once in order to coordinate a frame-perfect resize
<swick>
it's luck that none of the compositors you care about implement a valid feature in a way to trigger your bug
<swick>
oh boy, even more fun stuff
<JoshuaAshton>
swick: Then what do you want us to do to report occlusion via DXGI_PRESENT_TEST without having occlusion information? And how do you want us to not block on Present without this right now?
<zamundaaa>
joashuaAshton: ok. It's the same rationale though - an unexpected blocking call is bad but a drop in framerate has to be covered for either way
<gitlab-bot>
KhronosGroup issue (Pull request) 1364 in Vulkan-Docs "WIP: Add the VK_EXT_present_timing extension" [Extension, System Integration, Open]
<JoshuaAshton>
We can't just not use FIFO when the app requests it.
<JoshuaAshton>
i mean
<JoshuaAshton>
urg
<swick>
sure you can
<swick>
and with the present timing extensions you can even make it work well
<swick>
(but then we can also make it work well in the WSI)
<JoshuaAshton>
There is also the issue of native Vulkan games that already exist
<JoshuaAshton>
and Vulkan games running through Proton
<JoshuaAshton>
that both hit this issue
<JoshuaAshton>
this doesn't address that
<JoshuaAshton>
It would be possible to write a layer potentially but... honestly, that's much more of a hack than just fixing the underlying problem causing presentation to hang (which it shouldn't).
<swick>
yeah, the present call should not block
<swick>
but surface suspension is just not the right tool to fix it, the present timing stuff is
<JoshuaAshton>
I think both are completely valid tools for the problem
<swick>
well, I think you're absolutely wrong
* JoshuaAshton
shrugs
<swick>
the one fixes the underlying issue, the other one papers over the issue for some compositors
<swick>
and tbh, with the wayland tools we have right now we might even think about a mesa quirk
<JoshuaAshton>
then you'd be mesa quirking every game
<swick>
basically guaranteeing a certain refresh rate for FIFO to not block
<zamundaaa>
swick: but that's also bad
<zamundaaa>
applications should completely suspend rendering when in the background
<zamundaaa>
so you'd be adding a huuge number of quirks
<swick>
yeah, sure, but all other solutions require changes in compositors/protocols
<JoshuaAshton>
and?
<zamundaaa>
swick: adding quirks for thousands of apps is not just infeasible but a much more hacky way to do it than a proper protocol
<swick>
it's not thousands of apps. proton can just do the quirk itself for example
<JoshuaAshton>
I don't think we would, I think we would much rather just call you broken because this isn't an issue on any other platform :)
<JoshuaAshton>
Like, we really don't want to have to add hacks for stuff that can actually be solved
<swick>
but then why don't you want to solve it and just paper over it?
<JoshuaAshton>
And adding special wayland-only present timing paths is pretty silly
<JoshuaAshton>
swick: Because this isn't papering over the problem
<JoshuaAshton>
This solves the occlusion case
<swick>
I'm repeating myself
<JoshuaAshton>
You can argue about whatever crap completely unrelated to the protocol but it still solves it for that case
<JoshuaAshton>
and has other advantages
<swick>
you won't convince me otherwise
<swick>
and you're also repeating yourself
<pq>
We do not tend to do one-shot protocol extensions to fix individual problems in Wayland without very good reasons.
<pq>
JoshuaAshton, if you justify the surface suspending extension based on "release resources", I can easily see it taken well. If you justify it with "make badly designed apps not fall over", I have much harder time.
<swick>
same
<pq>
Wayland also had absolutely no problem being the odd window system out. We have plenty of experience about that, because we think that some new radical ideas could make things better.
<pq>
like "no global coordinate system"
<pq>
it causes problems, yes, but it also opens new opporutnities
<pq>
maybe we need a new Wayland extension that gives clients what they actually (think they) want: vsync ticks?
<pq>
to replace frame callbacks in things like EGL swapInterval
<kennylevinsen>
very much NACK - we don't have any ticks at all if no one is submitting anything :(
<kennylevinsen>
it would be annoying if we had to synthesize timers, especially with VRR...
<swick>
the present-timing thing is exactly what we need
<pq>
kennylevinsen, KMS does. You can query the KMS timings, and it does *not* meant you would necessarily be sending a Wayland event at refresh rate.
<pq>
there is an old proposal from CrOS IIRC, than only delivers vsync timings when they change or when they might drift too far, and otherwise sends no events. The client can do the timers on its own.
<kennylevinsen>
swick: you mean the thing you've talked about for timing when a submission should start?
<pq>
this would be useful for APIs like EGL's swap interval, which have old-school assumptions that no longer always hold, but when they do hold, they would work as intended.
<gitlab-bot>
wayland issue (Merge request) 45 in wayland-protocols "WIP: RFC: present-timing: Enhanced presentation timing requests and events" [New Protocol, Opened]
<swick>
only looked at the title :<
<pq>
swick, btw. did you have a look at the simplified CM shader for Weston?
<swick>
pq: yes. did I forget to comment?
<pq>
I think you did :-)
<pq>
or if you left an emoji reaction, those do not generate email notifications AFAIK
<pq>
ooh, *that* present-timing
<swick>
yeah, but even if we manage to get rid of the frame callback with it clients which use present mode FIFO and present with a fixed interval will run into blocking in the acquire call
<swick>
but using FIFO and then requiring to run at a fixed rate is just broken
<pq>
Are you referring to apps which intentionally block in a call to throttle their framerate?
<swick>
well, I don't care why apps want to run the game loop at a fixed rate or how they block but when theye use FIFO (and we fixed the frame callback thing) then frames are scheduled for some later point in time and the compositor releases them again some time after that so if it releases them at a slower rate than the game loop runs at, the acquire call will again block on the compositor releasing
<swick>
the buffer
<swick>
so we basically pushed the problem from the present call to the acquire call
<swick>
but at least that's how the spec says things should behave
<pq>
aha
<swick>
maybe on windows you actually get a fixed refresh rate but that's just not how wayland behaves
<pq>
I was thinking of apps that, using EGL terms, set swap interval to 1, look at the display refresh rate, and expect to be ticking at the refresh rate when calling eglSwapBuffers in a busy-loop.
<pq>
hmm, I guess these two are not that far off from each other, except in my case the blocking a wanted side-effect, while in your case blocking is unexpected?
<swick>
yeah, your case is a special case of mine
<swick>
(i think)
<swick>
the vulkan WSI is just not a great fit for wayland
<swick>
so the problem with just adding a present mode which just presents images at a fixed inerval is the backpressure of the swapchain images
<swick>
really hard to explain
<pq>
I think I got it. Because of FIFO, no frame is ever dropped, so if you produce faster than consume, the queue would grow without bounds. But since you have a limited number of buffers, you hit a roadblock at some point.
<swick>
yeah
<pq>
Makes me wonder what would control the production rate.
<pq>
Gamma-correct sRGB blending merged in Weston. :-)
<swick>
nice!
<swick>
I guess they just look at the mode and then time everything themselves
flibitijibibo has joined #wayland
<pq>
FIFO mode has the potential to become a latency nightmare, so why do games use it?
<swick>
tbh, they probably just do everything that works on windows
<swick>
don't know
<pq>
maybe they also allocate only two buffers in the swap chain?
<swick>
yeah, if you only allocate the minimum amount of images for FIFO the latency can be good
<pq>
IOW, making the worst case possible from a winsys perspective.
<swick>
but the point is still that they can only acquire images as fast as the compositor releases them
<pq>
ruins frame rate if you happen to composite bypass
<swick>
and if you have to run at a fixed rate or you break... well, that's bad
<swick>
wsi implementations return a minimum amount of images for a specific swapchain so you should have enough so that we can have direct scanout and one buffer more for the client
<JoshuaAshton>
pq: Latency is also much better if you present then acquire your next image
<JoshuaAshton>
as opposed to acquiring then presenting
<pq>
all this can be solved by... a full-frame copy >_<
<JoshuaAshton>
(under FIFO)
wolfshappen has joined #wayland
<pq>
JoshuaAshton, yes, but why use FIFO in the first place? It seems to make everything so much harder.
<pq>
wait, actually no, I didn't understand why present-acquire-delay is better than acquire-present-delay. If you acquire *after* delay, then surely you have much better chances of not needing to wait for a buffer to become available?
<JoshuaAshton>
To sum it up simply, it's because acquire is the blocking call here (be it blocking on CPU from fences or GPU from semaphores). Doing present acquire ensures that when the app actually wants to present, it's not hanging around from acquire
<JoshuaAshton>
Doing acquire present results in inverse frame cadences and about 1 frame of latency iirc
<pq>
oooh, you have the delay built into acquire
<JoshuaAshton>
Well, Mesa does that -- it would be even better if Mesa signalled the semaphores when the acquire was done instead
<JoshuaAshton>
*semaphores + fences
<JoshuaAshton>
but ye
<JoshuaAshton>
Right now Mesa waits on the CPU and signals immediately
<pq>
I thought you would do the delay explicitly yourself, and not rely on winsys blocking you. In the game code, not Mesa.
<JoshuaAshton>
Ah, nobody does delays themselves
<swick>
I'm confused why anyone thinks acquire-present is a good idea?
<pq>
See also my rant about the naive main loop.
<JoshuaAshton>
The only people that do that are frame limiters
<swick>
JoshuaAshton: just fyi, it always has to block on the CPU side for images to become available
<swick>
the fence/semaphore is just for the GPU work to finish
<JoshuaAshton>
Under Wayland and X11, yes
<swick>
kind of everywhere
<JoshuaAshton>
On Windows you actually get a semaphore iirc
<swick>
eh, maybe not
<swick>
yeah, sure, but do you always get a non blocking call
<JoshuaAshton>
Not sure if always
<pq>
on Wayland, once we start sending release fences, then no need to CPU wait - that might break more apps :-D
<JoshuaAshton>
but you can
<swick>
pq: the problem is that we first have to generate those fences in the compositor and that's why you still have to wait on the CPU side, no?
<JoshuaAshton>
Well acquire gives you *either* fences (cpu) or semaphores (gpu)
<pq>
swick, yes, the client needs to wait for the release fence to arrive via Wayland.
* JoshuaAshton
wants timeline semaphores
<pq>
mind, I have no idea of the differences between any of the sync primitives
<swick>
at this point I think I understood most of it
<pq>
as I've seen are "fence fds" which are something you can import to e.g. GL and make the GPU wait on.
<JoshuaAshton>
tl;dr sum up: fence is waited on by cpu, semaphore is waited on by gpu, timeline semaphore is both
<JoshuaAshton>
there is slightly more nuance but that's the tl;dr
<JoshuaAshton>
*can be both
<pq>
JoshuaAshton, so what's the fd then?
<swick>
I mean, the problem with the acquire call in vulkan with wayland is the implicit/explicit sync missmatch
<swick>
eh, wayland and X11
<JoshuaAshton>
pq: What fd are you referring to, sorry? You can import sync primitives by fd
<swick>
yeah, and there is a few of them
<swick>
sync_file, drm_syncobj, and one more I think
<pq>
JoshuaAshton, yeah, the ones you can feed to eglDupNativeFenceFDANDROID()
<pq>
from EGL_ANDROID_native_fence_sync
<pq>
it has "fence" written all over it, but it can be waited on GPU by importing, and on CPU by poll()'ing.
<swick>
yeah, drm fences and vulkan fences are different things
<JoshuaAshton>
I don't think there is much distinction between sync primitive types in EGL or underlying in Mesa -- in Vulkan they are much more distinct
<pq>
way past my EOD, so see'ya!
<JoshuaAshton>
o/ take care
<swick>
bye
<swick>
anyway, the reason why you don't get a fence or a semaphore out of the acquire call is that the buffer has implicit fences attached to it in the kernel and the vulkan fences/semaphores are not drm fences at all
<swick>
there is a patch which allows the wsi to extract those implicit fences and then import them into vulkan
<swick>
but apparently there is some inconsistencies in how the implicit fences are used so that extracting them can become an issue
<daniels>
EGL_ANDROID_native_fence_sync is very much sync_file only
aleasto has quit [Quit: Konversation terminated!]
aleasto has joined #wayland
aleasto has quit [Remote host closed the connection]
aleasto has joined #wayland
aleasto has quit []
aleasto has joined #wayland
d_ed has quit [Ping timeout: 480 seconds]
jgrulich has quit [Ping timeout: 481 seconds]
mcf_ has joined #wayland
mcf has quit [Quit: quit]
mcf_ has left #wayland [#wayland]
mcf has joined #wayland
tzimmermann has quit [Quit: Leaving]
rasterman has quit [Ping timeout: 480 seconds]
rasterman has joined #wayland
mcf has quit []
mcf has joined #wayland
aleasto has quit [Remote host closed the connection]
meirand2 has joined #wayland
danvet has quit [Ping timeout: 480 seconds]
Arnavion has quit [Ping timeout: 480 seconds]
meirand2 has left #wayland [#wayland]
st3r4g has joined #wayland
reinist12 has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
<reinist12>
it does not take a genius to understand that mesa allows licenses like public domain on the derivative works, everything could be closed, i am working on security those days , cause i have absolutely everything available, i need to handle people who acheived nothing to defend real people, and my partners will anyways do that better then "heros" from nato, to the people who faught to nato and foreign countries safety, an got nothing from it, but danger
<reinist12>
and local souverranity issues, so real people there need to be defended by my partners and forces that are real ones to them, not fictive and never reachable. In many ways that is what you are, like a freak abuser similar to the ones who went against me, with no acheivements, so we need to handle all of those too on the way, if there will be souverranity issues to estonian independence because of nutters like this.
Arnavion has joined #wayland
rasterman has joined #wayland
dcz_ has quit [Ping timeout: 480 seconds]
reinist12 has quit []
fluix has joined #wayland
pnowack has quit [Quit: pnowack]
d_ed has joined #wayland
d_ed has quit []
st3r4g has quit [Quit: おやすみ]
srh1605 has quit [Ping timeout: 480 seconds]
Seirdy has quit [Quit: exiting 3.2-dev]
soreau has quit [Remote host closed the connection]
soreau has joined #wayland
st3r4g has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
hardening has quit [Ping timeout: 480 seconds]
Seirdy has joined #wayland
st3r4g has quit [Quit: おやすみ]
radu242 has quit [Remote host closed the connection]