For someone getting started with Red/System programming on the Raspberry Pi, what is the best way to access the GPU for 3D rendering? Can this method also be used for Rebol3 on the Raspberry Pi?
My OpenGL binding for Red/System would be the starting point:
http://red.esperconsultancy.nl/Red-OpenGL
I'm currently working on extending it for the Raspberry Pi. The current binding is for desktop OpenGL. For Raspberry Pi and other small platforms, I'm working on an OpenGL-ES binding. Further, OpenGL needs an environment on the target platform. The binding has several backends, such as SDL, but these don't work on the Raspberry Pi as it uses EGL in combination with its own environment as defined by Broadcom. I'm also working on extra backends for those.
Bindings for Red, including this one when Raspberry Pi support is finished, can be used to base REBOL 3 extensions on, with my Red/REBOL 3 bridge:
http://red.esperconsultancy.nl/Red-REBOL-3
However, writing such an extension is an extra effort.
The site in the answer by Kaj de Vos is no longer works.
You may find its mirror useful:
https://github.com/red/RS-fossil-mirror
Or the red/code repository:
https://github.com/red/code/tree/master/Library/OpenGL
Related
I'm developing an operating system targetting the ARM architecture, more specifically, a RaspberryPi 4B. For that I've already managed to use the "Mailbox Property Interface" to draw some shapes on the screen. Out of curiosity I would like to know if it was possible to use OpenGL (or OpenGL ES, preferably) to render future more complex graphics. If possible, how do I do it?
You want to find out which driver the usual Raspberry Pi software uses, then adapt that driver to work on your OS. This is the code that interprets your OpenGL commands and translates them to the GPU's native language. Note there is both a kernel part and a user-space part.
It's probably not worth trying to write your own. Graphics is a whole field of study, it's like writing another OS just for the graphics card.
I intend to pursue this course from Free-Electrons (https://free-electrons.com/training/embedded-linux/) as a self-learner. They use Atmel SAMA5D3 Xplained board. My question is: can I use Raspberry Pi 3 instead of the Atmel board for completing the labs? If yes, would it be too much effort for someone who is almost a newbie in this field?
A comparison between the two boards can be found here (in Italian): http://www.campana.vi.it/blog/confronto-raspberry-pi3-beaglebone-black-sama5d3-xplained/. Rasp Pi3 seems to win in almost every respect, except for the number of GPIO pins and the price of Pi is around £30 vs £79 for Atmel (checked today). I'd really love it if the Pi could be used for this course.
Thanks in advance for any help.
As sawdust stated, the main parts that will differ are the u-boot and kernel labs because they are specific to the SoC and board. They may not be so easy to adapt. The main issue is that they are all about getting a system booting on the platform so the followings labs depend on them.
The buildroot lab will differ a bit because of the different SoC but is way easier to adapt. Also, you won't be able to do the "Filesystems - Flash file systems" lab at all because the RPi doesn't have any NAND flash. That is one of the main reason why we are using the SAMA5D3 Xplained.
So I am trying to run a LibGDX game which uses LWJGL as a backend on my Raspberry Pi 3. I tried various gl driver combinations on the pi:
experimental driver: game start but crashes soon after with JVM Errors, totally unstable
no experimental driver: software rendering seemes to be used, very slow
propretairy driver only (mesa uninstalled): LWJGL fails at initializing gl and crashes (stacktrace below)
Since I think the proprietary driver is the most stable GL driver I intend to use it. Also, I know that OpenGL is working because of glxgears an JOGL working fine.
So, has anybody any hint or an idea where to start looking? Is this a LWJGL issue or a GL driver issue?
Thank you in advance,
Manuel
Stacktrace:
Exception in thread "LWJGL Application" com.badlogic.gdx.utils.GdxRuntimeException: OpenGL is not supported by the video driver.
at com.badlogic.gdx.backends.lwjgl.LwjglGraphics.createDisplayPixelFormat(LwjglGraphics.java:322)
at com.badlogic.gdx.backends.lwjgl.LwjglGraphics.setupDisplay(LwjglGraphics.java:216)
at com.badlogic.gdx.backends.lwjgl.LwjglApplication.mainLoop(LwjglApplication.java:144)
at com.badlogic.gdx.backends.lwjgl.LwjglApplication$1.run(LwjglApplication.java:126)
Caused by: org.lwjgl.LWJGLException: Could not init GLX
at org.lwjgl.opengl.LinuxDisplayPeerInfo.initDefaultPeerInfo(Native Method)
at org.lwjgl.opengl.LinuxDisplayPeerInfo.<init>(LinuxDisplayPeerInfo.java:61)
at org.lwjgl.opengl.LinuxDisplay.createPeerInfo(LinuxDisplay.java:831)
at org.lwjgl.opengl.DrawableGL.setPixelFormat(DrawableGL.java:61)
at org.lwjgl.opengl.Display.create(Display.java:846)
at org.lwjgl.opengl.Display.create(Display.java:757)
at com.badlogic.gdx.backends.lwjgl.LwjglGraphics.createDisplayPixelFormat(LwjglGraphics.java:314)
... 3 more
LWJGL and LWJGL3 do support the open-source (Mesa) OpenGL driver. The numerous demos of Minecraft Java Edition for Raspberry Pi demonstrate this.
In fact LibGDX runs smoothly on a Raspberry Pi 3 as shown by PokeMMO.
The right direction is to pursue the open-source driver, which at the time of writing is no longer labeled experimental. In fact it is the only way to use accelerated 3D graphics on a Raspberry Pi 4.
Since I think the proprietary driver is the most stable GL driver I intend to use it. Also, I know that OpenGL is working because of glxgears and JOGL working fine.
JOGL has the advantage of supporting both the proprietary GLES driver (for a Pi Zero) as well as an OpenGL backend. The proprietary driver cannot run full OpenGL though, so it may appear to work only because the Pi 3's CPU is sufficient to run glxgears in software rendering at full speed.
I am developing a computer vision system to control orientation of two mirrors to track stimuli in field of view.We are sending coordinates to motor over network and trying to track as smoothly as possible.
I have two questions regarding this :
1.Is Python suitable for this kind of project . I have already coded it in Python and find it very easy to use.
I am running Raspbian on raspberry Pi but found that it's not a real time os. We are sending command every 20 ms to the server built on raspberry Pi. Should I switch to arduino or patch the Linux kernel for this application.
Python, combined with OpenCV, is one of the best candidates for this task.
As mentioned in the comment above, the "real-time" issue is OS related. I personally recommend an Arduino-based solution, even though that puts more burden on the hardware design. You could also check the new IoT solutions from Intel, they have a wide range of boards.
I'm developing a cross-platform application and am not very familiar with the Mac platform. I use Qt for the GUI. I use a QGLWidget to make sure the drawing (with QPainter) is done in OpenGL.
My project built fine in XCode and runs. However, drawing is slow as hell, in situations where on Windows and Linux machines speed is not an issue. The Macbook has an Nvidia GPU, whereas the Windows machine has only onboard intel graphics.
When I look at the binary, it seems that while linking to QtOpenGL lib, it does not explicitely link to the GL lib itself.
How can I test if hardware acceleration is working or software fallback rendering is doing the job?
Shouldn't my binary link to the GL lib, or is this hidden as being a recursive dependency?
The best way to see what OpenGL implementation is using is to print the value of glGetString(GL_VENDOR) and glGetString(GL_RENDERER), this should help pinpoint the problem.