06:42 <kbouhara> hello guys, Is there a way to send more than 32bits in a spi transfer using spidev interface ?

11:42 <kroon> Still confused.. What API should one use for doing fast 2D blitting ?

11:42 <kroon> I see gpu-viv-g2d is one way

12:29 <kroon> according to g2d_test I should be able to full hd blits at 95 fps ..

12:30 <kroon> but the g2d api is barely documented

14:07 <dv_> kroon: this is actually a grey area

14:07 <dv_> and:

14:07 <dv_> <kroon> for my case, it seems unnecessary to first decode the video into one memory area, and then use the gpu to write the same data to the framebuffer

14:07 <dv_> this is true only if you dont need to resize or color convert the frame

14:08 <dv_> most software packages are written to be generic in that regard, so they require at least this frame -> framebuffer blit , with the IPU, CPU, or GPU

14:08 <kroon> dv_, true

14:12 <kroon> in my case i just want a static background image drawn, and then use Qt5 to render qml elements on top of it. and I suspect there is a better way to do this, than to let qt5, via opengl, draw the background image in each frame

14:12 <dv_> there isnt

14:12 <dv_> qt5 will not redraw it all the time anyway

14:13 <dv_> oh, well I assume you mean with "background" a separate framebuffer

14:13 <dv_> thats probably the best approach for you. draw the static image to the background framebuffer (fb0 I think), then use the other framebuffer for qt5

14:14 <kroon> as I understand it, qt5 will render the complete scene in every frame

14:14 <dv_> hmm with opengl es probably yes

14:14 <kroon> I did try rendering the image in fb0, and then have qt5 render into fb1 overlay

14:14 <dv_> overall it is not a big deal though. the gpu is fast enough for that

14:15 <kroon> but performance seemed even worse than letting qt5 do all the rendering into fb0

14:15 <dv_> there are corner cases where the screen updates are very small. in these cases, software rendering is faster, unless the gpu has special swapbuffer rect extensions.

14:15 <dv_> hmm

14:16 <dv_> well then you have no choice. compose it all with the gpu.

14:16 <kroon> this is at full hd

14:16 <dv_> jnettlet, I think we can agree that the gpu can handle fullhd 2d scenes

14:17 <kroon> and, this is on a wandboard solo, i know its not the most powerful. but seeing g2d_test do blits at 95 fps felt promising...

14:18 <dv_> hell, I was able to render a 1080p30 and a 720p stream at the same time

14:18 <dv_> so whats this qt5 UI you are rendering?

14:18 <kroon> but thats the vpu and ipu working right ?

14:18 <dv_> is it complex?

14:18 <dv_> no

14:18 <dv_> vpu+gpu

14:19 <kroon> dv, no its not that complex, but when I turn of the background image, performance is much better. so, im trying to be sure I use the best way to render the background

14:19 <jnettlet> dv_, yeah piece cake. A lot has to do with the memory speed and bandwidth.

14:19 <jnettlet> what is the background?

14:19 <kroon> and using OpenGL for doing a 2D blit seems wrong, when there is dedicated hw for 2d as I understand it

14:20 <jnettlet> kroon, use the 2d core of the gpu

14:21 <kroon> jnettlet, how do I access the 2d core ? is it the gpu-viv-g2d library ?

14:21 <jnettlet> kroon, directly yes.

14:21 <dv_> jnettlet: you need to use g2d over qt

14:21 <dv_> not easy

14:21 <kroon> jnettlet, you think it would be better to use g2d for drawing the background image, than doing it the Qt5/OpenGL way ?

14:22 <jnettlet> that is where I am a bit confused.

14:22 <jnettlet> well, you would want to use Qt5/GLES way to be most efficient.

14:23 <jnettlet> are you rendering a desktop or two windows, one as an overlay?

14:24 <kroon> I'm using the eglfs backend. I've tried rendering everything in fb0, result is ok. Then I tried rendering the bg in fb0, and let qt5 render in fb1 overlay, but performance seemed even worse

14:25 <dv_> IPU compositing is probably slow

14:25 <dv_> jnettlet: it is easier to just use GLES, yes, because it is already integrated in qt5

14:25 <dv_> including specific make flags for imx6

14:26 <dv_> g2d would be a completely new graphics backend

14:26 <dv_> just use qt5 for everything then

14:26 <kroon> dv_, I can hook into Qt5 renderloop, and do things before rendering

14:27 <kroon> So I was hoping I could access the GL colorbuffer, and do a fast blit there before Qt starts rendering the scene

14:40 <jnettlet> kroon, is this being rendered with Qt Quick?

14:40 <kroon> jnettlet, yes

14:43 <jnettlet> kroon, does the background change?

14:44 <kroon> jnettlet, no its a static image

14:44 <jnettlet> and you are playing a video over the top of it?

14:45 <kroon> jnettlet, no, just some quick control elements

14:45 <jnettlet> kroon, and this is a problem?

14:46 <kroon> jnettlet, well sort of, I get 14 fps in full hd

14:46 <kroon> oh, not sure about that number actually

14:46 <kroon> but, if I skip drawing the background image, everything is much smoother on screen

14:48 <jnettlet> kroon, can you run your app with this env variable set. QSG_RENDERER_DEBUG=render

14:48 <jnettlet> that should give you a better idea of what is holding things up

14:50 <kroon> jnettlet, ok, will do. but, so you think a wandboard solo should be able to render at QML scene at 1920x1080 ? It was cinematic-experience that was showing 15 fps

14:51 <jnettlet> kroon, let me check the stats. That is a GC880 instead of the GC2000, but you really aren't doing any heavy rendering.

14:51 <jnettlet> although the memory bandwidth on the solo is kind of crap. Let me check the specs.

14:53 <jnettlet> kroon, you are using a Yocto image?

14:54 <kroon> jnettlet, thanks for looking things up. im not claiming to be an expert on this stuff, but when g2d_test showed it was blitting at 95 fps, I was hopeful

14:54 <kroon> jnettlet, yes

14:55 <jnettlet> kroon, it could be that QML is sending things through some sort of slow path. Possibly doing something in software and causing the GPU to have to wait around. What does CPU usage look like?

14:56 <jnettlet> if this really can't be optimized out then I would probably recommend rendering to a smaller scene and then upscale with hardware. I would use that as a very last resort though

15:00 <kroon> jnettlet, http://pastebin.com/DKacucdD

15:00 <kroon> thats one frame I guess

15:01 <bfederau> I use a custom videosink (QtGStreamer: qt5videosink) and our video stream is interlaced. The standard GStreamer 1.0 deinterlacer (within playbin) cause some heavy performance drops (choppy video and a higher CPU load). Is there a way to do HWaccel de-interlacing with the gstreamer-imx? I use Kernel/BSP 3.0.35-4.1.0. BTW the imxeglvivsink doesn't work for me on X (http://pastebin.com/U9BxySSk)

15:10 <jnettlet> kroon, okay so there are a couple of things there that could be causing a slow down. You should look up the QSG_VISUALIZE env variable. That will draw colors over your scene for things like overdraw, or batches etc

15:10 <jnettlet> I think that will give you a quick visual of what is most likely the problem.

15:15 <kroon> hmm ok. i wonder if thats a commercial-only feature, cause im not seeing anything special, tried "changes", "batches", "overdraw"

15:18 <kroon> I gotta run now, thanks for the help jnettlet, dv_

15:19 <dv_> bfederau: you can try the deinterlace modes of imxipuvideotransform

15:23 <bfederau> dv_: ah I totally failed to see this option. Thanks for the hint.

15:23 <bfederau> dv_: I will try it

15:26 <dv_> note that the deinterlacer can only be used by one process at the same time

19:01 <apxiii> Hi! Anyone had port pinouts for Embedsky E9 Mini PC?

20:12 <kroon> dv_, jnettlet, I added a fps counter by hooking into QQuickView::afterRender() signal. With a background image, im getting ~25 fps, which is ok I guess. If I hide the background image I get ~45 fps, which looks much more smooth. I did look at the Qt profiling data and found some problems that I've fixed

20:14 <kroon> So, if I could get a 2d blit using g2d, with a freq. of 95 times per second, I still hope it would be an improvement compared to using the Qt5/OpenGL api, no ?

20:17 <kroon> If I also remove the Quick control sliders I'm using, i get 60 fps. They seem to generate lots of triangles ...

20:22 <kroon> oh, more like ~80 fps. I was limiting it

20:33 <otavio> kroon: did you ping me sometime ago?

20:34 <kroon> otavio, yes but I forgot what it was about :-)

20:35 <otavio> lol

20:37 <kroon> otavio, by the way, if you want to move the linux-imx-rt recipe into some more "experimental" repo I'm fine with that. I can understand Daianes concern about having not fully tested kernels in meta-fsl-arm

20:37 <otavio> kroon: I prefer to keep it there ;-)

20:37 <otavio> kroon: if I can pester you, I am fine ;)

20:38 <otavio> kroon: what is all this Qt FPS stuff you guys been discussing?

20:38 <kroon> otavio, ok, good :)

20:38 <otavio> kroon: did you see the patch I added to qtmultimedia?

20:39 <kroon> otavio, yes but I'm not sure if it applies to my usecase. I'm just not sure what would be most efficient way of blitting a 2D image on the framebuffer, and then render QtQuick elements on top of it

20:43 <otavio> I am not a graphics guy ... so blitting means nothing for me ... will research for it...

20:46 <kroon> otavio, there is g2d_test application that uses the g2d library, but I cant find any descent API documentation other than the .h file, which isn't much unfortunatley ..

20:47 <kroon> g2d_test claims it's doing 95 fps blitting in full hd, if I understand its output correct, so I'm hoping it uses the 2d core, and is faster than the 3d core

20:52 <otavio> ah I see

21:17 <dv_> <kroon> dv_, jnettlet, I added a fps counter by hooking into QQuickView::afterRender() signal. With a background image, im getting ~25 fps, which is ok I guess. If I hide the background image I get ~45 fps, which looks much more smooth. I did look at the Qt profiling data and found some problems that I've fixed

21:17 <dv_> how do you add the background image?

21:17 <dv_> why not just add a fullscreen image in qml as the background?

21:17 <kroon> dv_, thats what I meant. I have "Image { ... }" in the root context

21:17 <dv_> ah

21:18 <dv_> hmm

21:18 <dv_> you are absolutely sure it is using GLES and not regular GL?

21:21 <kroon> dv_, "ls /usr/lib/libGL*" only yields /usr/lib/libGLESv2.so*, no libGL.so* files

21:21 <dv_> strange. it shouldnt be that low. the image should just be a texture

21:22 <kroon> even on a wandboard solo .. ?

21:23 <kroon> its a big texture, 1920x1080 ...

21:24 <kroon> should i increase some kind of gpu memory maybe ..