Hello,
Is hardware acceleration supported in the debian image ? If a take a window and drag it fast with the mouse the CPU load increase up to 60%, and if the window is playing video CPU is full, but on the other hand video from a capture device is playing smoothly (15% CPU where on other board with full acceleration it’s a 3% CPU)?
Nicolas
Hi @Ntis,
Do you mind trying this image bellow and enabling the drivers of freedreno/glamor?
http://builds.96boards.org/releases/dragonboard410c/linaro/debian/15.11/
Please let me know if it improves the performance.
Hi,
I’m affraid this is the one I already use, I will try again this evening from beginning. In fact I realize that to get hardware acceleration onto the windowing system we should use wayland or somethong of this kind that support acceleration, lsde don’t get this natively ? it can explain the window dragging over consumming CPU ?
But for the glimagsink (or v4l2 acquisition, I’ll check this evening too) I get a 15% CPU for (I presume) colorspace conversion that can be done in GPU mode normally ?
If you haven’t already, follow the instructions for enabling glamor for 2d accel. It isn’t the default yet, but IME 2d performance is better with that, compared to using xf86-video-freedreno+XA.
But in either case, with glimagesink you are doing YUV->RGB + scaling on the GPU. My guess would be that 15% cpu utilization could just be texture upload… you didn’t mention the resolution of the stream that you are playing back, but for higher resolutions it seems plausible.
For both playback and window moving case, ‘perf’ is a nice command-line tool for profiling. You might need to install dbg packages for a few things (xserver/mesa/etc), but ‘perf record -g -a sleep 5’ in the background while you are moving windows or playing video, and then ‘perf report’.
Hi,
So I had a try with glamor (in Xorg.0.log is see glamor initialized) so I think it’s ok and I see some difference in rendering (large rectangle flickering on window exposure, like a backbuffer repainting)
But nothing in performance. for exmaple juste try to drag the file folder and CPU increase up to 50% and a lag in the moving is seen.
My gstreamer simple pipe (I ommit the reslution that’s right : PAL in 720x576 16bits 25fps from an easycap so not a high resolution) and I already have the 15% CPU with glimagesink (fakesink let determine that it is the rendering which take time) and you’re right it should be the colorspace conversion which is done with CPU (for comparison same gstreamer pipeline on a raspberry2 -less powerfull board if I can! 
- with GPU enabled take only 2/3% CPU.
I try to use perf but some packet are missing (linux-tools-4.2) and I don’t fnd it but a simple top let figure out the CPU usage :s
glimagesink was port on the dragonboard gpu ? if not this couls explain the 15% drawn by gstreamer
hmm, regarding perf, I guess linux-tools doesn’t have to exactly match the kernel version if you have one from something close to same kernel version, maybe you could force install somehow? I’m not sure, someone who knows debian better might be able to help there.
I don’t have it with me today, but tomorrow I’ll get out my db410c (with fedora+lxde, so should at least be a similar setup), and see what I can see.
I will mention, that these sorts of things could depend heavily on the window mgr, etc. Not sure what setup you were using on the r-pi2? (x11+openbox? Or weston?)
re: glimagesink port to dragonboard, afaiu the linaro releases should be using glimagesink. There shouldn’t be anything adreno specific about it (it’s all just generic opengl APIs), although maybe in the r-pi2 case they had some customized version of glimagesink for zero copy (to avoid the texture upload)?
EDIT: btw, I guess you should be able to reproduce the same issue with videotestsrc plus some caps filter to force same resolution and yuv format? If so, that is probably the easiest way for me to reproduce.
In fact I don’t find any linux-tools at all on the standard debian package I list.
For the videotestsrc it seem’s you can do something like :
gst-launch-1.0 videotestsrc ! video/x-raw,format=YUY2 ! glimagesink
with this I get a 60% cpu load (certainly due to the video formatting from rgb to yuv before sending to glimagesink)
for the rpi2, I remember a thing of zero copy stuff but not sure it was implemented. And for the hardware acceleration I don’t really know what they use on their rasbian, but dragging window shows some cpu ‘peak’ up to 16%
Draggiing windows is just a ‘symptom’ that make me think that gpu is not used, my main problem is to use gstreamer to display acpatured video, blend an image on top of it and record it :s
oh, right… yeah, videotestsrc will have some overhead of it’s own. IIRC videotestsrc had some different test patterns (incl. solid color)? Maybe one of these is less CPU overhead? Also, I guess we need to be sure that videotestsrc is outputting directly YUV (rather than converting in sw before glimagesink).
hi,
GPU is definitely being enabled in the Linaro release. The lag you are seeing is likely something related to the WM (openbox in our default images). If you try different WM you will see different results. Some folks have reported that kwin has ‘better’ performances/visuals when it comes to moving windows. gnome-shell runs quite well too. I was recently told that adding compton in the default image improves the situation a lot, but I haven’t tried that yet. I was planning to test that and include it in the next release if that ‘fixes’ the problem.
We used to default to gnome-shell for our images which was quite good looking, but was causing other annoyances… i don’t think there is a perfect answer (wayland?) to be honest… and right now we have kind of settle down on LXDE for the default graphics in all our 96boards images… so if we find some tricks to make it better, we can add the change, but changing the default desktop to something else might be more difficult to achieve…
oh, just fwiw, w/ glimagesink you could force software rendering and compare cpu load… ie:
LIBGL_ALWAYS_SOFTWARE=1 gst-launch …
one other thought, with glamor xvimagesink should also work… I wouldn’t expect it to be much different on CPU load, but w/ lxde (non-composited wm) it might save a blit…
Hello,
Thanks for all these explanation. No doubt that gpu rendering were activated, otherwise performance would be horrible with resolution we have now…
I was surprised of these artefacts while doing some action that I hadn’t seen on other less powerfull boards, and as I prefere understand why before continuing my work I asked :).
I was suspecting those window manager, it’s difficult to understand why so different manager exists, not totally accomplished, so much effort in different ways :s
Bref, for the glimagesink LIGL_ALWAYS_SOFTWARE did the trick bump of CPU ! 
In fact just to figure out, I was tricked by the ‘top’ 
As I say, it was 15% CPU, but in fact in top the percent is mentionned by CPU in the detailed while the overall is the quarter lets tell 4% so I found the rpi2 performance !
In all thanks to all for your response, and if someone knows how to make a soft that blend an image on a gstreamer flow, then record and show in live I’m interested 
Cheers
Nicolas
