07-13-2019, 12:41 PM
(This post was last modified: 07-25-2019, 01:10 PM by Brian Beuken.)
Now that we have the Pi4 on the market, we have to finally accept that some differences exist between the different versions of Raspberry, (and libs they use)
For the most part we can build projects on the Zero, 1, 2, 3, A or B/B+ with no real care about the hardware as long as we are running the same OS we build on. That updates every 2 years or so but even so it tends to be compatible, so a project built on a new Stretch or Buster OS will work fine on a Jesse or older system.
The only real issue is that some machines are much slower than others and have less memory. Those kind of things can be dealt with by just checking that your project runs on a minimum specification, and using good optimisation.
But the Pi 4 introduces a wrinkle in that nice level of family compatibility, becuase it has a totally different approach to graphics and graphic code written for the older Pi's won't work on them, nor will Pi 4 code work on the older systems
There's 2 ways to tackle this.
1 Use Multiple configurations... where you create a specific build for a specific target system, or group of systems.. ie one build for the 1,2,3 and 1 for the 4.
Thats an easy option, and you can just build in pre-process values to set up the correct build.
2 Runtime detection of the target.
Where you actually try to work out what Pi you are running on, and then branch your code to do one set up for the older systems and another for the later ones.
There's pros and cons to both methods but for the most part, the only real difference between the units is graphics, oh and memory, but graphics is the killer. So lets try and do a simple detect and based on the results of that detect set up graphics accordingly.
There's no system call that automatically tells you what machine you are working on, but there are files on the system that you can read
/sys/firmware/devicetree/base/model
or
/proc/device-tree/model
These can be read in and parsed by your init systems to give you the info you need and set up the correct system. Once we know we're on a Pi2 we can use ES2.0 and BCM EGL, instead of X11 (trying to work out a DRM system though) and Mesa EGL for Pi4.
If you plan to incldue OpenGLES3.0+ features you can also set up conditional tests to do one draw system or another...probably routed through a simple render class that is instansiated depending on the type.
We can also get a good idea of how much memory our system has by reading
/proc/meminfo
Since there's bound to be a tendancy to assume you have 3 or 4GB of memory free, this will allow you to know roughly how much you can use, though be careful again as the Pi4 dynamically allocates GPU memory when needed so you can only use such info as a rough guide.
I'll use these info systems as a means to put together a general new graphics system that readers can replace the current systems with and upload the code as soon as I can.
For the most part we can build projects on the Zero, 1, 2, 3, A or B/B+ with no real care about the hardware as long as we are running the same OS we build on. That updates every 2 years or so but even so it tends to be compatible, so a project built on a new Stretch or Buster OS will work fine on a Jesse or older system.
The only real issue is that some machines are much slower than others and have less memory. Those kind of things can be dealt with by just checking that your project runs on a minimum specification, and using good optimisation.
But the Pi 4 introduces a wrinkle in that nice level of family compatibility, becuase it has a totally different approach to graphics and graphic code written for the older Pi's won't work on them, nor will Pi 4 code work on the older systems
There's 2 ways to tackle this.
1 Use Multiple configurations... where you create a specific build for a specific target system, or group of systems.. ie one build for the 1,2,3 and 1 for the 4.
Thats an easy option, and you can just build in pre-process values to set up the correct build.
2 Runtime detection of the target.
Where you actually try to work out what Pi you are running on, and then branch your code to do one set up for the older systems and another for the later ones.
There's pros and cons to both methods but for the most part, the only real difference between the units is graphics, oh and memory, but graphics is the killer. So lets try and do a simple detect and based on the results of that detect set up graphics accordingly.
There's no system call that automatically tells you what machine you are working on, but there are files on the system that you can read
/sys/firmware/devicetree/base/model
or
/proc/device-tree/model
These can be read in and parsed by your init systems to give you the info you need and set up the correct system. Once we know we're on a Pi2 we can use ES2.0 and BCM EGL, instead of X11 (trying to work out a DRM system though) and Mesa EGL for Pi4.
If you plan to incldue OpenGLES3.0+ features you can also set up conditional tests to do one draw system or another...probably routed through a simple render class that is instansiated depending on the type.
We can also get a good idea of how much memory our system has by reading
/proc/meminfo
Since there's bound to be a tendancy to assume you have 3 or 4GB of memory free, this will allow you to know roughly how much you can use, though be careful again as the Pi4 dynamically allocates GPU memory when needed so you can only use such info as a rough guide.
I'll use these info systems as a means to put together a general new graphics system that readers can replace the current systems with and upload the code as soon as I can.
Brian Beuken
Lecturer in Game Programming at Breda University of Applied Sciences.
Author of The Fundamentals of C/C++ Game Programming: Using Target-based Development on SBC's
Lecturer in Game Programming at Breda University of Applied Sciences.
Author of The Fundamentals of C/C++ Game Programming: Using Target-based Development on SBC's