Raspberry Pi Forums

oldnpastit

It's a bit crude, but you can always just write debug output to the UART. There's lots of examples around on how to do that in a bare metal environment.

oldnpastit

The -mfloat-abi directive affects the way that function calls are made. With the 'hardfloat' option, floating point values get passed in the floating point hardware registers. With the ''softfloat" option, they get packed into integer registers in the caller, and then unpacked in the callee. Yo...

oldnpastit

Hi! I was playing around with the fast memcpy routines that get used on RPI, the ones from: https://github.com/bavison/arm-mem I noticed that if I compile these by hand, I end up with an unresolved external reference to align , which seemed a bit weird. $ arm-linux-gnueabihf-gcc -c -shared memcpy.S ...

oldnpastit

Won't the .dll be compiled for x86/Windows rather than ARM? So it would seem unlikely that it would work well.

oldnpastit

I could be wrong about this, but I think the image encode component only accepts YUV420 and YUV422 input formats (i.e. it won't do the colour conversion for you). I think the resize component might be able to help out though, as it probably will do the format conversion for you. (Or perhaps the imag...

oldnpastit

Also, doing this might yield some clues:

Code: Select all

sudo vcdbg log msg

oldnpastit

There's some code in RaspiStill.c which might be another place to start looking, in create_encoder_component() . I'm not sure whether the JPEG encoder component can actually accept RGB as an input - the actual hardware takes in YUV but it's possible that the VPU will convert from RGB for you. If you...

oldnpastit

Is there a point where the tradeoff changes? i.e. as rects get larger/smaller it worth doing them in DMA? I wonder if in real world situations, the CPU usage reductions have more of an effect than the lower fill rate? Possibly, but you're into having to invent artificial benchmarks to justify makin...

oldnpastit

Why not? Linux is not single tasking single threaded system. It's perhaps not, but it's a lot harder to justify making a change if the most obvious benchmarks appear to make things worse. So now I'm looking at seeing whether I can find some other bit of hardware that could do a better job. There se...

oldnpastit

It looks as though DMA fills may be a bit of a dead end. Using x11perf -rect500, I get ~1200 rectangles/second using the ARM (@900MHz) and ~660 rectangles/second using the DMA (tried core clock of 250MHz and 350MHz without much difference). The CPU load is a lot lower (~8% vs 100%) but that's obviou...

oldnpastit

So, after getting back to this, and digging a bit further, the FBIOFILLRECT ioctl is probably a non-starter. The fillrect() API in the kernel takes a colour argument that is an index into a translation table. This is what Documentation/fb/api.txt says: Pixels are broken into red, green and blue comp...

oldnpastit

Are you writing a kernel driver? If so, there are kernel APIs (e.g. msleep) for this sort of thing which you I would have thought would be easier to use rather than directly accessing the registers.

oldnpastit

I've just pushed (rewriting history) a slightly nicer version that makes valgrind (on a standalone test) much happier (9ebccf1).

oldnpastit

This seems to fix it for me:

https://github.com/luked99/userland/tre ... emleak_fix

Caveat: all I've tested is leak_test.c. I'd be happier if valgrind was quieter, but I think it needs to be told about how to correctly track vchiq calls, so it has a lot of false positives at the moment.

oldnpastit

If you change the loop in leak_test.c as below then the problem goes away: VCOS_THREAD_T th; vcos_thread_create(&th, "foo", NULL, thread_func, egl_state); vcos_thread_join(&th,NULL); //pthread_create (&thread_handle, NULL, thread_func, (void *)egl_state); //pthread_join (thread...

oldnpastit

I agree, it looks like the code is missing. eglReleaseThread() calls platform_hint_thread_finished() which doesn't do anything. That ought to be OK though because in platform_tls_get(), in khrn_client_platform_linux.c, it does: vcos_thread_at_exit(client_thread_detach, NULL); Valgrind will probably ...

oldnpastit

I've created a patch to accelerate fills in the bcm2708_fb framebuffer using the DMA engine[1]. It's here: https://github.com/luked99/linux/tree/fillrect This only adds support to the framebuffer driver, so doesn't make X11 go any faster (yet). It does seem to make the console slightly faster - catt...

oldnpastit

I could be wrong about this, but is the DMA code in the bcm2708_fb driver missing code to do L1 cache cleaning? Without this, most operations will work fine, but if you get unlucky, small regions (of the order of 8k pixels for a 16bit display) might come out corrupted. Presumably it needs something ...

oldnpastit

There's DMA support in the framebuffer driver now, which should be quite a lot faster for larger areas. It's accessed using the FBIOCOPYAREA ioctl().

oldnpastit

Isn't that the header that connects the breadboard to the pi?

http://www.adafruit.com/products/914

EDIT: too slow.

oldnpastit

I think for h/w cursor support you need to modify the X11 server module, xf86-video-fbturbo. Look at sunxi_disp_hwcursor.c.

EDIT: that doesn't seem to make use of the ioctl() though, which would surely be the right thing to do.

oldnpastit

So, assuming this is working, what's the next easy thing to do to make X go faster? The experience of previous work in this area suggests it's not easy. It might be interesting to see how far one can get by adding EXA support for GPU memory allocation: pixmaps allocated from the GPU memory ought to ...

oldnpastit

Thanks! Using xterm gives much more believable results. I find a get a small but noticeable improvement with the threshold set at 32k. Just constantly moving a large xterm, I was seeing around 50% CPU load from Xorg with DMA IRQs enabled, which went up to about 67% with the threshold high enough to ...

oldnpastit

Cross-compiling the kernel using cygwin or mingw is going to be very very painful! Your first problem will be building a gcc toolchain that runs under Cygwin and generates ARM6-hf binaries. Even the thought of doing that makes me feel ill! If you've got a Windows machine, you might be better off put...

oldnpastit

Well, that's a good question. There are several things that have made X go a bit quicker: 1. ARM optimizations in the X11 xorg fbturbo driver (user-side), by hglm This now uses some nifty VFP code to do blitting. This is nothing to do with DMA but has a big effect. 2. The DMA copyarea() support in t...

Search found 34 matches

Re: How to debug - J-link style

Re: Force compile for soft floatng point

Possible weirdness in fast memcpy routines?

Re: OneWireLinkLayer.dll on Raspberry Pi

Re: MMAL image encoding fails

Re: MMAL image encoding fails

Re: MMAL image encoding fails

Re: bcm2708_fb: dma-accelerated h/w fill

Re: bcm2708_fb: dma-accelerated h/w fill

Re: bcm2708_fb: dma-accelerated h/w fill

Re: bcm2708_fb: dma-accelerated h/w fill

Re: Hardware Timer

Re: Memory leakage with multithreaded EGL/OpenVG programming

Re: Memory leakage with multithreaded EGL/OpenVG programming

Re: Memory leakage with multithreaded EGL/OpenVG programming

Re: Memory leakage with multithreaded EGL/OpenVG programming

bcm2708_fb: dma-accelerated h/w fill

bcm2708_fb.c - DMA missing L1 cache operations?

Re: Memory access too slow?

Re: Question about mystery component in diagram

Re: Experimental enhanced X driver (rpifb)

Re: fbturbo - dma hardly ever gets used?

Re: fbturbo - dma hardly ever gets used?

Re: New V4L2 driver and OpenCV

Re: fbturbo - dma hardly ever gets used?