Page MenuHomePhabricator

Broken vsync in latest efl git
Open, HighPublic

Description

When updating EFL to get the new shiny theme, I got some very weird behavior on my screen. Windows where updated late, switching desktop resulted in content from the wrong desktop. I first did think it was a theme issue and disable the pane effect when switching desktop, but some of the weird behavior remained. I did disable texture from pixmap, because historically, that has been resulting in also some weird behavior. It didn't solve anything, but next to it, there is the vsync enable/disable config, and I remember seeing some change getting in. So I did disable that and it did fix all my issue. I have reenable texture from pixmap and the pane effect between virtual desktop switch. Everything is working nominally, just no vsync :-(

cedric created this task.Tue, Mar 30, 9:19 AM
cedric triaged this task as High priority.

that vsync option simply sets the egl swap interval to 1 (ie vsync). ... the animator - i changed it to have an offset of 0.5 frames:

140b8af0435fb7455d62ea2185602d52510c91a2

has the commit - if u comment that out, but all this does it make the threaded vsync animator sleep for half a frame time before sending the vsync animator tick to the mainloop. the idea is that e's rendering will be offset by half a frame from clients so they are not playing a race condition over a frame - ie client renders at the same time e wants to render.

try commenting out the above and see. but i see no issues on any of my machines (rpi's, vbox instances, intel and amd gfx desktops and laptops).

Ok, will try that this evening and let you know.

I have commented out that line and still see the problem. I hadn't updated my efl in a while before that, so it could be change in the vsync code in efl that went in early February. I would have to see if any of those are the culprit.

Well ok - it's not that then. In feb I switched back to the threaded vsync by default - there's an env var to switch to/from thread vs inline. threaded is best if you don\t want to miss frames.

export ECORE_VSYNC_THREAD=1
export ECORE_VSYNC_NO_THREAD=1

they do what they say on the tin. having both will be confusing so .. pick one. :)

This has become extremely weird. I have just updated my computer with latest efl and enlightenment. I get some kind of vsync timeout somehow. Basically after some time a desk will stop updating. To get the update back, I either have to trigger enlightenment internal window to be displayed (menu, config, whatever) or switch desktop and it will unstuck the rendering. My past change on disabling vsync in Enlightenment or using the export environment variable do not help anymore. No idea at all where to look for what is going on. Looks like either a timeout somewhere or a driver that doesn't notify Enlightenment correctly.

That's odd. I did see a problem with intel drivers. the vsync events provide a timestamp. I did notice that sometimes my intel laptop would freeze - stop animating. I finally figured it out... the timestamp between 2 vsync events went BACKWARDS. so frame 101 had a timestamp BEFORE frame 100 (these timestamps are clock monotonic so should never go backwards - ever). This basically broken the vsync timing logic etc. - i added a check for this in efl git and a fprintf to stderr too when it happens. It's absolutely a driver bug (I talked to the dri devs and they all agree it should never happen but we can't easily figure out why it happens).

Now .. I wonder if you fall into some other logic hole somewhere? Odd that the desk switch/window open fixes it... I don't see what that might be pointing to. I gave the above driver bug example as a data point of something to look at? Is E complaining to stderr about time going backwards? does it do it just before the freeze? I see it happen to me sometimes but E now marches on and keeps working, so I assumed it was fixed. Is there some other problem now?

I will check the E logs and see if I see anything meaningful there.

ProhtMeyhet added a subscriber: ProhtMeyhet.EditedMon, Apr 19, 4:39 PM

Can you try if Numlock/Capslock does the same as Desktop Switching? Both trigger a lot of code and still mostly a CPU Interrupt, but also up from Kernel Code to Xorg and so on.

I haven't tested yet, but just in case, I have a dual screen setup. Could it be that we are getting a vsync event for each screen, while each screen would have its own monotonic clock, if mixed, maybe there would go backward?

the vsync handling filters out duplicates. what i have seen is they have the same frame count so it only cares about vsync events with a new frame count. so e.g. if you have 2 screens we see vsync from one with frame 123 and then another from the other screen with frame 123... then the next one is frame 124 for each etc. ... if we didn't filter we'd over-render, not "stop rendering" but perhaps there is a logic hole somewhere?

double check the screen config? both screens 60hz (or same refresh)?

They are not exactly the same refresh rate. One is 59.70 and the other 59.97 (yup). I wonder what happen when they diverge for long enough and we end up with one screen ahead of the other in term of frame count as after 5s at full refresh rate, it would be a full frame of difference. That could be the beginning of an explanation too.

that's common. it may mean e double-renders or misses a frame every few hundred/thousand frames or so when they diverge enough. i've had mis-aligned refreshes often enough without issues though...