On Sun, 13 Nov 2016 12:31:49 +0900 Carsten Haitzler (The Rasterman) <ras...@rasterman.com> said:
FYI - i disabled _drm_animator_register, _drm_animator_unregister, _drm_evas_changed from the ecore_evbas func struct for the drm engine and lo and behold... mouse moves smoothly and reliably. yes. there are "gpu goes slow" hiccups but the whole drm animator stuff is really bad - especially on an rpi. : ( the elementary_test animation is now pretty decent. its smooth (well i disabled the manual render messing the wayland engine was doing as per below). this needs some serious testing across a wide range of hw (slow and fast) and careful thought on mainloop blocking conditions and how this affects everything etc. > hmmmm. i'm reading this code and it seems broken. > > let's start with the simple one. > > 1) > ecore_evas_wayland_common.c: this shouldnt MESS with manual render at all. at > most it should just have > > if (wdata->reset_pending) return 0; > > added to the top "not going to do this" section in > _ecore_evas_wl_common_render () and remove all the other manual render > things. ecore evas already forces all rendring to be driven by an animator > out of the box. this animator should either be totally driven by frame > request events from wayland (compositor) itself OR at least hook it up to the > drm device... but either way this code is wrong as it messes ith the manual > render flag that is ALSO altered via api from ecore_evas "public api" calls > which are called by elm win etc. > > so this has to go... it's wrong at a minimum and likely causing issues. > > 2) > ecore_evas_animator_tick() has a region but NO TIMESTAMP. please look at > ecore_x_vsync.c and specifically ecore_loop_time_set() that uses the vblank > timestamp to get EXACT vblank timing into. this is a must for having a STEADY > animator with STEADY timepoints. a region - fine... but you need a timestamp > too. > > now to the nasty one... > > 3) > ecore evas drm engine using pageflips for animation. errrr... WHA? no. well > ok. tell me if i'm wrong. to be able to tick the animator the code DOES a page > flip... THEN uses the page flip event to drive the animator? what? this is > just wrong on so many levels. animators are not a RESULT of altering the fb > from some previous page flip. they are a tick that says "the screen scanout is > refreshing NOW and you should time your animations NOW to THIS point". i > suspect this code is a huge source of brokenness. why are we scheduling a > flip ... we don't even HAVE a new frame yet? i know i know... it's "simpler" > and you can get a flip event per output... BUT firstly the timestamp is not > even USED from the page flip event in the code i'm reading, secondly i have no > idea WHAT timestamp this would be (i know the vblank events are the vblank > interrupt timestamp). the pageflip COULD be some other time during scanout > (end of vblank, end of scanout? something else?). but either way it's not > used and should absolutely be. but ... in order to GET an event you have to > do a flip... and i'm reading ecore_drm2_fb_flip() and that is seemingly what > is being done to just get this event. it seems to be able to do a "null > flip" (flip the current buffer to itself), but i'm not so sure this is > reliable given the api and code - is output-next always null when we register > an animator with _drm_animator_register() ? > > what happens when we do a null page flip THEN do a real one? > > also here comes the stinker. what happens when we MISS a whole frame because > something went slow? we're scheduling from the mainloop. since we are asking > for the NEXT animator tick from a page flip... we only schedule a new page > flip once we already have figured something changed in the ecore_evas or the > animator is registered etc... imagine for a second we have a 16ms frame gap > (approx 60hz). what if we spend 18ms this frame rendering or doing something? > we MISS the next opportunity to page flip, so we actually have to wait another > 14ms for the next frame. thus we do either 60hz, or 30hz... but can never play > catch up and squeeze in another frame because we missed the opportunity to > schedule one. this scheme using page flips is broken "by design" in this way. > > please have a look at ecore_x_vsync.c. yes it's complex. it does whitelisting > of working drivers and handles some broken drm info stuff. it dlopens libdrm > to not have to link or compile against it at all. it also handles timeouts on > drm vblank events and after enough will switch to time based animation. but > ignore that... > > it uses a dedicated thread JUST for scheduling vblank events and reading them > so it will never miss one. in the dedicated thread ALL it does is schedule a > vblank and sleep waiting for it to happen (or a command from mainloop to stop > doing events, timeout in case of screen going off to fake animation ticks > while vblanks are mising or exit etc.). so it can never (on even a heavily > loaded system and irrespective of what the mainloop does) miss a frame... > unless it literally cannot manage to wakeup from the fd coming alive. call > drmHandlEvent, write the timestamp down an fd, check cancellation flag, the > come back to scheduling it again within 16ms. you'd have a fundamentally > broken system if this was not possible as this thread does nothing else. > there is a good reason it is done this way. > > i have found that we HAVE managed to lose frames and drop from 60 to 30hz and > the effects are not pretty. the drm engine really has to do the same. and i'm > not so sure you can use page flip events then as you have a completely > independent thread trying to use the drm fd to get these events and you don't > want IT flipping pages to the same or a new one... so you likely have to use a > separate drm fd like ecore_x_vsync.c does and rely on vblank events which are > passive. > > chances are this code should become common/shared. but what i am reading right > now smells of broken... and on my rpi i see broken... in fact the mouse just > doesn't ever (barely) render/move unless i hold it over an ibar icon that is > pulsing and animating... then it works, but move my mouse away... it basically > doesn't work. i suspect this pageflip "to myself" trick is to blame. yes the > vblank code only keys off a single screen and will ignore all other vblank > events. i guess this would have to be figured out somehow. > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > The Rasterman (Carsten Haitzler) ras...@rasterman.com > > > ------------------------------------------------------------------------------ > Developer Access Program for Intel Xeon Phi Processors > Access to Intel Xeon Phi processor-based developer platforms. > With one year of Intel Parallel Studio XE. > Training and support from Colfax. > Order your platform today. http://sdm.link/xeonphi > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
