As of 2012, your best bet was to implement your computation as a fragment shader in GLSL ES and find a way to represent the output as a RGBA (32-bit) texture.
Eben stated in this 2012 talk that OpenCL is not likely to be implemented, but that there may be an API developed in the future; the answer starts at 21:20, and Eben says "we may provide some way for ...
I would expect you to not experience a noticeable difference unless you are doing graphically heavy tasks, such as playing video.
However, it's difficult to gauge the optimal settings, as performance limits will vary depending on what applications are executing and user expectations.
The best thing you can do is experiment.
If you do want to change the ...
RAM is very crucial for Linux performance for couple of reasons:
Caches. Linux runs without free memory for most of the time. If some memory is not used by applications, it is used for caches which speeds things up. So no memory is ever wasted. If applications needs more memory, caches are freed so caches won't ever prevent applications needing more RAM ...
Not at present - there is only a framebuffer interface for display purposes. There is no OpenCL and no plans for it nor is there documentation available to create OpenCL. CUDA is Nvida only so isn't applicable. Once an OpenGL driver becomes available you may be able to engineer some calculations via the GPU but how useful that will be remains to be seen.
As of April 2015 GStreamer 1.2 included in Raspbian supports OpenMAX hardware accelerated H.264 encoding through omxh264enc.
I've done some benchmarking comparing:
MacBook Pro (Early 2011) dual-core i7-2620M 2.7GHz (Sandy Bridge) - 4GB RAM
RaspBerry Pi 2 Model B 900MHz quad-core ARM Cortex-A7 CPU - 1GB RAM
Sample file: 60s sample from the movie Alatriste (...
You can get a real-time view of memory usage using either the top or htop command. You may need to install htop if you get the message htop: command not found. Assuming you are using Raspbian, install it by running sudo apt-get install htop
These are the RAM splits and what they should be used for.
240/16 - This is best if you are going to be doing nothing graphical, for example if you were using the Pi as a server and have no GUI.
224/32 - This is probably best if you are using the pi with a basic graphical desktop environment, without 3D.
192/64 - The default, probably the best general ...
According to the official Raspberry_Pi twitter feed, GPU accelerated X.org is not yet available.
26 June 2012: @Raspberry_Pi :
The Wheezy beta's worth a go http://www.raspberrypi.org/archives/1435 - but X isn't hardware
accelerated yet. (It will be soon.)
Until 2014, the GPU firmware was closed source. OpenCL was not supported by the Pi until the VC4CL project, which has started to implement OpenCL on the VideoCore IV GPU used by all Pi models. The project's progress is also discussed on the Raspberry Pi Forums.
See Can I use the GPU for calculations? for the state of the GPU as of 2012, but much has changed ...
You can change the memory split using the raspi-config utility in either debian-wheezy or raspbian-wheezy.
Just run the utility: sudo raspi-config then select the memory split option (its about the 8th one in the list).
If the output of vcgencmd get_mem arm && vcgencmd get_mem gpu is
This means that GPU is using 128M.
This can be verified/changed in raspi-config Advanced Options, although I have not reduced the GPU myself. I am going from memory, but I think this is the default, possibly related to Camera. At least you now know where your memory ...
One easy solution is to get the Raspberry Pi itself to manage how the RAM is split between the CPU and GPU with dynamic memory split.
While raspi-config cannot do this for you, there are example settings for /boot/config.txt available on the forums.
I don't have any problem with this, although I am using a custom setup. In config.txt:
When I boot, I only have half the RAM:
And the correct amount appears to be allocated to the GPU:
> vcgencmd get_mem gpu
768 worked too; the docs claim the limit is ...
For CPU usage and system memory, try the htop command, its very detailed and customizable, if this doesnt work use top (or rather apt install htop).
GPU memory usage (amongst many other details) can be seen with /opt/vc/bin/vcdbg reloc stats. Total memory is at the top and free memory is at the bottom
Regarding the optimum CPU/GPU split. It really depends ...
This one may be useful.. GPGPU python library for the raspberry pi. https://github.com/nineties/py-videocore
A general-purpose GPU (GPGPU) is a graphics processing unit (GPU) that performs non-specialized calculations that would typically be conducted by the CPU
First of all, I give my best regards to @Milliways for suggesting to check 2 simple commands.
vcgencmd get_mem arm && vcgencmd get_mem gpu
Where is the missing 128MB memory?
Even if both raspi-config and /boot/config.txt says that the amount of memory available to GPU is 16MB, actual values are 880MB for CPU, 128MB for GPU.
root@mypi:~# vcgencmd ...
You can write high-level programs that run on the Pi's GPU using QPULib:
It's a programming language and compiler targeting the 12 vector processors (QPUs) inside the Pi's GPU. It aims to be easy to use and is implemented as an EDSL (Embedded Domain Specific Language) -- a lightweight alternative to a full-blown OpenCL ...
The Raspberry Pi foundation has been endorsing GPGPU on the Pi since 2014 , shortly after Broadcom released documentation for the QPU units inside the GPU.
An experimental OpenCL compiler was created by Simon J. Hall (the winner of the tightly related 2014 10,000 $ competition to make Quake run acceptably without using the GPU BLOB) : see here.
GStreamer is included in Raspbian and with its OpenMAX plugin it will use the hardware encoding capabilities of the Raspberry Pi.
See this link for a tutorial on doing what you're looking for:
If you're interested in transcoding, I've just posted an answer to another question that might interest you:
I believe the GPU is identical in all Pis and makes up 95% of the silicon. The remaining 5% is used by the relatively puny ARM core(s).
To monitor the RAM usage, you can run free -h -s 1. Every second (-s 1), a similar table will be displayed:
total used free shared buffers cached
Mem: 438M 146M 292M 0B 15M 102M
-/+ buffers/cache: 28M 409M
Swap: 99M 0B 99M
The line Mem: is ...
This was also asked over at Bitcoin.se.
The general consensus is that even if OpenCL were supported by the GPU, it would still achieve a poor hash rate because it only has one or two cores. Fast hash rates are achieved by many modern GPUs because they have several hundred cores which can run together in parallel.
Okay so I found a solution here: https://www.raspberrypi.org/forums/viewtopic.php?t=191087
use raspi-config to enable OpenGL (Full KMS)
remove "--disable-gpu-compositing'' from /etc/chromium-browser/customizations/00-rpi-var
is all you need to do to get the https://get.webgl.org cube spinning.
Works for me!
Currently, best two answers are from Raspberry PI's Liz and forum poster Simon (teh_orph):
"Accelerated X will be a solved problem soon; we've put engineering resource on it, and it's actively being worked on."
"I've finally gotten a handle on the AXI burst value (...) That's a 5x increase ...
CMA dynamically allocates memory to the GPU as required. When the amount of free memory available to the GPU falls below the 'low water mark' (cma_lwm), CMA will attempt to re-allocate some of the memory currently available to the ARM to be instead reserved for the GPU. You can think of this as 'minimum free memory' for the GPU.
If the GPU later frees up ...
No, there is no OpenCL on the Raspberry Pi as of 2014.
2018 update; there is now a work in progress.
The Arduino is a microcontroller not a SoC (think up to 16000x slower)
The Beagle Bone got some in 2015.
Odroids have had support since 2013?
Rock64 is missing support so far.
At the moment, it seems there is still no stable software to encode h264 video using the hardware, even if it has been officially announced that the Raspberry Pi does support h264 hardware-encoding. So, we cannot do a benchmark to compare performances to a regular PC.
I don't know if someone is working on the subject, but a developer from libav seems ...
This returns the same thing as reading /sys/class/thermal, i.e., the core temp. Reading the /sys file is preferable programmatically because it is just a sequence of open/read system calls, instead of a fork/execute plus a bunch of open/read/write with pipes.
How would I read the GPU temperature aswell?
The BCM2835/6 ...