Re: Weston on framebuffer?
On Thu, 21 Jul 2016 08:30:54 +0900 Carsten Haitzler (The Rasterman) wrote: > On Wed, 20 Jul 2016 21:49:57 +0200 Christer Weinigel > said: > > > On the framebuffer I don't perceive any lag at all between a keypress > > and the character appearing on the screen. > > > > With weston-terminal running I can drag the window around and even > > though it's not very fast and there's a bit of tearing it isn't too bad. > > The response when dragging feels ok. Keypresses feel laggy even though > > mouse motion doesn't, but I'm not sure if that's because I don't notice > > the lag when moving the mouse or if it is a real difference. > > well they are done by different things. the move will be done directly by > weston itself. it will be asked to begin a window move by the client and then > just do it itself. render the changes. key events have a different path. they > go to client, client handles it, draws new frame, then weston has to update > screen with that new frame. > > it seems to be either weston-terminal is just slow at drawing there and thus > is > ending up taking a while to draw, add another 200ms or so for weston itself > and > thats probably what's going on. The first. I recall people saying that weston-terminal is particularly bad at rendering performance. You might want to try a more "serious" terminal, though I'm not sure what to suggest. Just keeping a key pressed and looking the output of 'top' at the same time (via a remote login or serial) should tell you what eats the CPU if any. I would guess CPU is running at 100% and most of it is in weston-terminal. That would confirm that weston-terminal is just inefficient in its drawing. Thanks, pq pgpBGTxJJlmfx.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Weston on framebuffer?
On Wed, 20 Jul 2016 21:49:57 +0200 Christer Weinigel said: > Hi, > > On 07/20/2016 01:04 AM, Carsten Haitzler (The Rasterman) wrote: > >> With this I managed to get a desktop and was unable to start > >> wayland-terminal. Redrawing of the graphics felt fairly snappy, but the > >> lag from pressing a key on the keyboard until a character showed up in > >> the terminal was slow, probably between a quarter to half a second. > >> > >> So my question is if this is the performance I should expect with weston > >> on a 400MHz ARM9 and a dumb framebuffer? Have I done something stupid > >> and there are easy ways to speed it up? > > > when you say redraw is snappy... that implies that output is fast. so time > > from deciding to render and update and it appearing is very short. but you > > seem to have serious input lag which implies to me that it has nothing to > > do with your cpu speed and is something else deeper and more involved. time > > to trace things and see how they go. > > I put up a short video here: > > http://zoo.weinigel.se/misc/2016-07-20-213549.webm that's not snappy. :) startup takes quite a while. but after that moving the terminal window around is maybe getting you 6-7fps or so. > On the framebuffer I don't perceive any lag at all between a keypress > and the character appearing on the screen. > > With weston-terminal running I can drag the window around and even > though it's not very fast and there's a bit of tearing it isn't too bad. > The response when dragging feels ok. Keypresses feel laggy even though > mouse motion doesn't, but I'm not sure if that's because I don't notice > the lag when moving the mouse or if it is a real difference. well they are done by different things. the move will be done directly by weston itself. it will be asked to begin a window move by the client and then just do it itself. render the changes. key events have a different path. they go to client, client handles it, draws new frame, then weston has to update screen with that new frame. it seems to be either weston-terminal is just slow at drawing there and thus is ending up taking a while to draw, add another 200ms or so for weston itself and thats probably what's going on. weston reads input, sends 1 or more key events to client. client gets input now does some updates/rendering (let's say takes 200ms assuming weston terminal is slow-ish at rendering). let's now say client sends update buffer to weston. weston now gets it, spends 200ms rendering, then reads buffered input, sends backto client (it may have sent it before), but weston will be either rendering a frame (takes 200ms or a bit less) or sending events. not both. that means at least some events could take 600ms to come back to the screen (almost half a second) because weston got blocks then client renders, then come back to screen. so maybe 500ms on average. half a second. i think rendering is slow and due to the above it just adds latency to the point where you see it easily. you only have a single cpu. any cpu time used up one place cannot be used elsewhere. no multilpe cores. :) that's my guess. weston is either reading input + sending, or drawing, and the big blobs of time spent drawing mean it's not reading and sending. so that adds UP to ~200ms THEN client gets these. client may be still drawing a previous frame, so doesn't respond for a little bit. let's say 100ms. then client draws. let's say 100ms, then client sends new frame over to compositor. compositor gets frame, begins draw. now 200ms more. NOW you see what you just typed. 600ms later. more or less. which is about what it looks like. when moving a window, weston gets mouse events, weston redraws, repeat. so 200ms lag. speed up the drawing or allow drawing to happen in parallel and you're good. remember weston is the SAMPLE compositor. it will not have been tuned to run ultra-fast on your setup. you likely have a 16bpp display but what's actually going on is clients are rendering in 32bpp so taking longer to render that they would natively (like the text console), and then weston is likely rendering in 32bpp too... THEN it's down-converting to 16bpp for display. none of that is free. :) you will likely not find much support these days that doesn't involve down-conversion as everyone is handling alpha and thus 32bpp (yes you can do 16bpp+alpha mask for example, or pack argb into 16bpp and other imaginative ways of getting it). dropping the whole pipeline down to something like 16bpp+masks and a very carefully tuned pipeline would help. (the reason i say 16bpp + masks is you can do a memcpy for the 16bpp data direct to memory and since this doesn't convert it likely will be 2-3 times faster - on the compositor fb side. on the client side the mask can be pre-computed once for the window then just render 16bpp content, and with opaque regions - since all the drawing happens inside those, the compositor can skip blending entirely for regions inside the opaque rect
Re: Weston on framebuffer?
Hi, On 07/20/2016 01:04 AM, Carsten Haitzler (The Rasterman) wrote: With this I managed to get a desktop and was unable to start wayland-terminal. Redrawing of the graphics felt fairly snappy, but the lag from pressing a key on the keyboard until a character showed up in the terminal was slow, probably between a quarter to half a second. So my question is if this is the performance I should expect with weston on a 400MHz ARM9 and a dumb framebuffer? Have I done something stupid and there are easy ways to speed it up? when you say redraw is snappy... that implies that output is fast. so time from deciding to render and update and it appearing is very short. but you seem to have serious input lag which implies to me that it has nothing to do with your cpu speed and is something else deeper and more involved. time to trace things and see how they go. I put up a short video here: http://zoo.weinigel.se/misc/2016-07-20-213549.webm On the framebuffer I don't perceive any lag at all between a keypress and the character appearing on the screen. With weston-terminal running I can drag the window around and even though it's not very fast and there's a bit of tearing it isn't too bad. The response when dragging feels ok. Keypresses feel laggy even though mouse motion doesn't, but I'm not sure if that's because I don't notice the lag when moving the mouse or if it is a real difference. I tried to do a strace of weston-terminal, but it was a bit painful, it reads every file it can find in /usr/share/icons/default/cursors/ when it starts so strace took forever before the terminal would even show up. And for trying to do more advanced tracing, I don't quite know where to start. Are there any knobs in the source to do things such as dump timestamps for messages between the server and client? /Christer ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Weston on framebuffer?
On Tue, 19 Jul 2016 18:10:16 +0200 Christer Weinigel said: > Hi, > > I'm trying to port Linux to a Samsung S3C2416 based system (actually an > oscilloscope, http://blog.weinigel.se/2016/05/01/sds7102-hacking.html). > > The S3C2416 is a 400MHz ARM9 with a fairly dumb framebuffer, it has some > 2D acceleration (pixel/line drawing with alpha, copy rectangle with > alpha and/or color key) but as far as I can tell nobody has added Linux > support for it. > > I'm going to need some kind of GUI for the box and somebody mentioned > that Weston has framebuffer support nowdays. I turned on the Weston > config option in buildroot (2015.5) and managed to get something that > didn't work to begin with, the OS abstraction stuff requires support for > posix_fadvise but for some reason that didn't work with ulibc but I > hacked around that. libinput didn't like eudev and didn't want to > recognize a USB keyboard and USB mouse to begin with but I just > hardcoded the device type instead of relying on udev to tag the devices. > > With this I managed to get a desktop and was unable to start > wayland-terminal. Redrawing of the graphics felt fairly snappy, but the > lag from pressing a key on the keyboard until a character showed up in > the terminal was slow, probably between a quarter to half a second. > > So my question is if this is the performance I should expect with weston > on a 400MHz ARM9 and a dumb framebuffer? Have I done something stupid > and there are easy ways to speed it up? > > Is there any documentation on how to convert the framebuffer driver for > the S3C2416 to a KMS driver and how to add acceleration support? Can > weston use this? > > Or is wayland/weston not really suited for this kind of old hardware and > what should I use in that case? > > /Christer when you say redraw is snappy... that implies that output is fast. so time from deciding to render and update and it appearing is very short. but you seem to have serious input lag which implies to me that it has nothing to do with your cpu speed and is something else deeper and more involved. time to trace things and see how they go. -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
