Raspberry Pi4

Exciting stuff,  the Pi 4 is here, its ~3 times the CPU power, but not yet a massive difference in GPU power, though there is a bit of a boost and it will improve as it settles in. Also it does have OpenGLES3.0 on board at last so it will be possible to write much better render functions to take care of instancing and other cool features that improve performance markedly.

On tiny concern is that it no longer uses the old Broadcom DispmanX video system to create render surfaces, it now uses tradtional X11 or DRM based windows, so that makes setting up for the Pi 4 the same as the other SBC's running linux and X11. This has good and bad sides

The good side, using mesa libs should ensure continued open source support.

The bad side.. well it breaks all the code in my book, DispmanX no longer works on my Pi4..Also I don't currently know how to use smaller renderbuffers, which was simple to do on the DispmanX system, so the buffers are now the same res as the screen we set. Thats nice in one way but it means more pixels to render and it impacts on speed.
This image below runs comfortably on a Pi3B  at 60fps, at 1080p res, but the render buffer is half that res and I can make it smaller still on lesser Pi's

But on the Pi 4 the render buffer is also 1920x1080 and even with the extra speed of the CPU and slight boost in GPU, it struggles to do 20fps. I am sure this can be overcome though, I just need to do a bit more research than I have so far.

Also it does mean we now have to build different builds for Pi4 and other Pi's or have a system for testing the version of Pi and setup accordingly.

Its a small annoyance really, but for beginners using my book, the 1st couple of chapters won't work now.. Lets hope it increases the traffic to the support site to find the solutions.

But for sure the Pi4 is exciting, the speed is impressive, and as software matures those video drivers will start to see 3.1 and 3.2 come on line...More memory too makes a big difference (I have a 4G one) it really will be fun to build something cool on it with less restrictions to worry about.

Up Core now working but what an effort

I got a replacement UpCore from Aaeon, and was pissed off when I tried to fire it up, no OS...ok, ok thats not a problem, this is a new one, so lets stick on an OS...

and nope.

try another

nope.

oh ffs...how much of a pain is this, I reflash the bios...
nope

So its dead Jim.

I open up another RMA request to send this one back, and get a slightly stroppy response that I havn't fully explained the issue, and I need to reflash the Bios, here's a link...hmm they clearly didn't read my mail when I pointed out in detail the issue and that flashing the bios did nothing.

I am mid way through typing my not too sarcastic reponse when I notice the link they send me is to a new BIOS....17, the one I used was 13.
I go to the link and notice 1 download has occured, so its a very new upload...

So putting the reponse to one side, I download and reflash with the new bios.

And so I try to install Ubuntu...and wow, its happening, its installing...nice graphical interface and everything..but it gets stuck after the region selection.

Hmm annoying but encouraged that it went further than before, I noted someone on the forums mentioned that the 1Gb models (I have a 1Gb) can suffer from over sized GPU allocation. So I reduced the memory allocation from max to 256MB, more than enough for my kind of work and tried again.

This time...it worked..no problems at all, installation took a while bit it did everything as expected. And at the end of the install, I followed the wiki's directions on installing the Up board Kernel.

It now works fine, totally awesome in fact. the Intel HD400 graphics are fast, it reports as a 3.1 system though it has extensions or tesselation (not compute though) and it absolutly blasts any of the current fast ARM chips out the water. Massive scores on GLMark2-es2
Quad cores, and a 16?? core GPU give it a lot more GPU and CPU grunt than even a rockchip 3399.

Its amazing.
It does suffer a little for lack of memory though, Ubuntu 18.04 is a bit greedier on memory than older OS's so sometimes there's a pause as the swap buffer kicks in, but overall its running all my test demo's just fine once libs are installed.

Amazing bit of kit for $99. a 2G is only $10 more. Their top of the line model with $4Gb and 64Gb eMMC is $169 represents something close to the power of a micro laptop, on a tiny PC board.

It even keeps up with its slightly more powerful Up^2 board, at least my 2G dual core celeron with Intel HD505 graphics.

But one thing about these boards, is they are basically small PC's really genuine PC's they can indeed load and run Windows 10. While the lower end ones represent great value for money for SBC fans, as the specs go up, so does the price and its hard to see why you should buy one unless its for a specific project, that needs a small board, rather than one of the many mini/budger or even 2nd hand PC's which can totally destroy these in sheer power/performance terms.

But for $99 I have a tiny board that can outperform a raspberry by a factor of 10 in every dept, and run OpenGLES3.1 so its a fun thing to mess with. It is without doubt the fasted sub $100 board in my collection, and by some margin. It can't quite match my base model Up*2 board (CPU is better, GPU is worse), but thats $150 for the base model, and considerably more if  you want more ram/better CPU.

There's also an UpCore+ model due next month, same form factor, much more powerful CPU, and base 2G 32GBeMMC mode, for $149 is a total bargain, but its over my $100 limit so I will pass on it.

Curious, and Up core getting sorted

Saw this today.
https://coral.withgoogle.com/tutorials/devboard-datasheet/
A new board being pushed by Google no less.

hmmmm very curious, I'm not actually very interested in machine learning but the idea of a machine with a copro that is capable of it, and therefore capable of slight more things is interesting.
Sadly though at $149 its outside my self imposed spend limit.. so unless I can get a test unit (hint hint...as if anyone reads this). I'll have to leave it.

Its so different from other SBC's it might be quite a challenge to get this puppy up and running and it seems the GPU is capable of ES3.1 but is an MP4 unit, so unless there's something cool going on, its not going to outperform too many of the competition in graphic terms.

Even so.
Curious.


Also my UpCore board which I've struggled to get working since it arrived, and had it in and out of the drawer of shame was sent back to the UpStore for repair/replacement. Happy to see that despite being a slow process they do acknowledge it can't install Ubuntu, so are hopfully fixing or replacing as I type.
Can't wait to try one of these actully working at full whack.

Been busy sorry

I'm focusing a lot more of my time on the Scratchpadgames.net forums, where I've been updating my most recent acquisitions and experiments as well as catching up (or trying to) on some issue with the book code, and articles. That and overwhelming pressure of my day job are making me long for the spring holidays. (Where I promise I am going to rest for a few days)

The most interesting thing to report is a few new OpenGLES3.0+ boards I've got hold of or are on the way thanks to generous donations from the makers.

I got a NanoPi Neo4 from the ever friendly FriendlyElec, and its just as nice as the T4, which I did eventually find a nice stable build to work on and it is a wonderful full professional board. The NEO4 has the same chip and less connections in a smaller board.

Its a fraction of the price of most other RK3399 Hexacore boards, and less ports might trouble some makers, but for me its fine, this is a beast, and looks super cool with its custom fitted heatsink



2 other RK3399 boards are on the way to me, thanks to the kind donations from the makers the RockPi4 which I've mentioned before but have had helluva time finding it in Europe at a decent price is on its way. As is the RockPro64 from Pine. I've never liked their kickstarter PineA64 board, but I've seen them grow and improve over the time they've been going so am quite excited to see their latest beast and hope that the software is up to it this time



All these lovely RK3399 boards really are opening up incredible new possibilities for graphics coders. Even though the gpu core size of most of them isn't much better (still MP4's) they are much faster bits of silicon and can push a lot more content if treated nicely with their OpenGLES3.0+ capabilities.

In other news, I finally fixed the "shader" issues with the UP^2 board, it was in fact a small maths issue in my code, bad programming, that didn't show up on ARM systems but did on intel.

Even though I only have the base model Celeron dual core system, what I do have is a (I think) 12 core, GPU capable of OpenGL 4.5 and I assume through some other wizardly full OpenGLES3.2 (at least it reports it ca).  Its a fantastically fast, powerful system, I know its pushing it to call it an SBC, its really a mini PC, but I like having something at the top end of the scale to play with and see how well things can scale back.
This is such a beast, check out this list of extensions, which is what the list extensions reports, but I suspect its all on board and no extension sneeded

/* UpSquared's extensions...wow mama
 *:GL_ANDROID_extension_pack_es31a
 *GL_ANGLE_texture_compression_dxt3
 *GL_ANGLE_texture_compression_dxt5
 *GL_APPLE_texture_max_level
 *GL_EXT_blend_func_extended
 *GL_EXT_blend_minmax
 *GL_EXT_buffer_storage
 *GL_EXT_clip_cull_distance
 *GL_EXT_color_buffer_float
 *GL_EXT_compressed_ETC1_RGB8_sub_texture
 *GL_EXT_copy_image
 *GL_EXT_discard_framebuffer
 *GL_EXT_disjoint_timer_query
 *GL_EXT_draw_buffers
 *GL_EXT_draw_buffers_indexed
 *GL_EXT_draw_elements_base_vertex
 *GL_EXT_frag_depth
 *GL_EXT_geometry_point_size
 *GL_EXT_geometry_shader
 *GL_EXT_gpu_shader5
 *GL_EXT_map_buffer_range
 *GL_EXT_multi_draw_arrays
 *GL_EXT_occlusion_query_boolean
 *GL_EXT_polygon_offset_clamp
 *GL_EXT_primitive_bounding_box
 *GL_EXT_read_format_bgra
 *GL_EXT_robustness
 *GL_EXT_separate_shader_objects
 *GL_EXT_shader_framebuffer_fetch
 *GL_EXT_shader_integer_mix
 *GL_EXT_shader_io_blocks
 *GL_EXT_shader_samples_identical
 *GL_EXT_tessellation_point_size
 *GL_EXT_tessellation_shader
 *GL_EXT_texture_border_clamp
 *GL_EXT_texture_buffer
 *GL_EXT_texture_compression_dxt1
 *GL_EXT_texture_cube_map_array
 *GL_EXT_texture_filter_anisotropic
 *GL_EXT_texture_format_BGRA8888
 *GL_EXT_texture_rg
 *GL_EXT_texture_sRGB_decode
 *GL_EXT_texture_type_2_10_10_10_REV
 *GL_EXT_unpack_subimage
 *GL_INTEL_conservative_rasterization
 *GL_INTEL_performance_query
 *GL_KHR_blend_equation_advanced
 *GL_KHR_blend_equation_advanced_coherent
 *GL_KHR_context_flush_control
 *GL_KHR_debug
 *GL_KHR_no_error
 *GL_KHR_robust_buffer_access_behavior
 *GL_KHR_robustness
 *GL_KHR_texture_compression_astc_hdr
 *GL_KHR_texture_compression_astc_ldr
 *GL_KHR_texture_compression_astc_sliced_3d
 *GL_MESA_shader_integer_functions
 *GL_NV_draw_buffers
 *GL_NV_fbo_color_attachments
 *GL_NV_image_formats
 *GL_NV_read_buffer
 *GL_NV_read_depth
 *GL_NV_read_depth_stencil
 *GL_NV_read_stencil
 *GL_OES_EGL_image
 *GL_OES_EGL_image_external
 *GL_OES_EGL_sync
 *GL_OES_compressed_ETC1_RGB8_texture
 *GL_OES_copy_image
 *GL_OES_depth24
 *GL_OES_depth_texture
 *GL_OES_depth_texture_cube_map
 *GL_OES_draw_buffers_indexed
 *GL_OES_draw_elements_base_vertex
 *GL_OES_element_index_uint
 *GL_OES_fbo_render_mipmap
 *GL_OES_geometry_point_size
 *GL_OES_geometry_shader
 *GL_OES_get_program_binary
 *GL_OES_gpu_shader5
 *GL_OES_mapbuffer
 *GL_OES_packed_depth_stencil
 *GL_OES_primitive_bounding_box
 *GL_OES_required_internalformat
 *GL_OES_rgb8_rgba8
 *GL_OES_sample_shading
 *GL_OES_sample_variables
 *GL_OES_shader_image_atomic
 *GL_OES_shader_io_blocks
 *GL_OES_shader_multisample_interpolation
 *GL_OES_standard_derivatives
 *GL_OES_stencil8
 *GL_OES_surfaceless_context
 *GL_OES_tessellation_point_size
 *GL_OES_tessellation_shader
 *GL_OES_texture_3D
 *GL_OES_texture_border_clamp
 *GL_OES_texture_buffer
 *GL_OES_texture_cube_map_array
 *GL_OES_texture_float
 *GL_OES_texture_float_linear
 *GL_OES_texture_half_float
 *GL_OES_texture_half_float_linear
 *GL_OES_texture_npot
 *GL_OES_texture_stencil8
 *GL_OES_texture_storage_multisample_2d_array
 *GL_OES_vertex_array_object
 *GL_OES_vertex_half_float
 *GL_OES_viewport_array
 *
*/


Sadly I never got anywhere with the UpCore Atom board, which should outperform the ^2 board, it's really not working no matter what I try,  and I'm trying to send it back for a replacement, but its proving to be quite a chore to get them to send RMA info. Frustrating as they are here in the Netherlands (I think in my home town as I saw their logo on a building here, but hard to verify that)

There's been a lot of new Orange and Banana boards, but I've resisted buying them, the software always lets them down, so am going to wait and see what people report before leaping in to add to the drawer of shame.

Thats it, I'll try to keep this blog updated a bit more, but if you are missing out on your fix of SBC for games/graphics, join the forums on my website, www.scratchpadgames.net

The what now Pi4?

While we all wait for the Raspberry Pi4 which, if it exists won't be announced until Pi Day   (14th March)
A possible contender for best SBC ever, has come up, and almost immediatly gone down in my estitmations.



the Rock Pi 4,  visible at  http://rockpi.org/

Looks like a total beast of a machine, a Raspberry config but based on a Rockchip 3399..... that's a beast...

At first glance I was salivating, I'm already falling in love with my T4 and Neo4 from Friendly arm, and a $39 RK3399 equiped chip with full ports is a bargain.
But nothing about the company behind the launch of this newcomer inspires me, its touted in the press releases as costing $39 up...nope, after a few days of being unable to find a retail supplier, it turns out the base price is closer to 68euros, exclusing postage, or heat sinks that almost certainly will be needed for an RK3399.

So its going to be around twice the price of a 3B+, but  you will get about twice the power in theory, the hexacore RK3999 is extremely fast and smooth to use, and the GPU is also wonderful, though I have fears about the drivers not being fully implimented yet.

In short this is a sexy beast, but it looks like they announced it a couple of weeks too early. The sites are woeful, the retail is non existant, and no idea what the final cost is going to be. And who knows how effective performace really is until we see an OS running.

Its locked itself into its own drawer of shame, but I'll check back in a month or so to see if they've got the price, the supply and most important the software under control

Using Code::Blocks libs

Here's a small screen shot for people having issues with MagPi lessons regarding library names

This shows the path name you need to enter under the linkers dirs

And this shows the names, even though they are listed as libGLESv2_static.xx, libEGL_static.xxx etc

they may be .a or .so files its not really important, it will include them as part of the project

Fixed the ubuntu issues

In the end it wasn't anything strange, I just never noticed I was not logging in on root, and the xserver was therefor restricted. log in as root, or add xhost+ and you can then get access.

Sadly however I was still unable to get the T4 to work, it refuses to update itself without error, meaning I don't have a full set of features to compile and run the demos. Upsetting but I'll just wait a  while for a new more effective OS to come out.

Edit... I reinstalled, and then instead of allowing the onboard updater to work, did my own upgrade-dist and got it to update and work fine,
I had to instal x11 as a dev lib but once up and running its all good.

Not so sure that the Mali GPU divers are fully hardware accelerated though, as I get the same GLMark2 mark with and with out VBO's which is not sensible....meaning it may be emulating a lot.

The CPU is blistering though...so once those drivers get a bit more uptodate, this will be an odroid beater.