▲ Top, ▼ Migrating vcio applications, ▼ Concurrent use of vcio2, ▼ Sample code, ▶ API reference
See sample program for further details.
See also vc4asm for a powerful and free QPU macro assembler.
If you have an application that uses the old vcio driver, e.g. hello_fft, you need to do the following steps to migrate to vcio2:
Now you application should use the new kernel driver it does no longer require root privileges to run if you grant access to /dev/vcio2.
The vcio2 device may be opened as often as you like. The only limiting factor is the amount of GPU memory available.
Calls to IOCTL_EXEC_QPU are strictly serialized. So no two applications can run code on the GPU simultaneously. However, they can run code alternately.
You should not use the /dev/vcio device or a character
device of the built-in vcio driver concurrently to /dev/vcio2.
The calls to this devices are not understood by vcio2 and may seriously
interfere with /dev/vcio2 access. E.g. the application using /dev/vcio
might disable the power of the GPU while another application is running
GPU code. Future versions of vcio2 might lock the other devices while /dev/vcio2
is open at least once.
This restriction does not apply to calls that are independant, e.g. reading the GPU memory size or even GPU memory allocations. The vcio2 driver and the vcio driver share a common mutex for this purpose. Only indirect dependencies are not tracked.
There are no more restrictions that I know of.
In the sample folder there is a simple sample application that utilizes the vcio2 device. It does some stupid computations by applying all available QPU operators to a bunch of constants.
Now the test application should print some pages of results to the console. Of course, you need to install the vcio2 driver before.