Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Asus Tinkerboard
#1
I soooo want to love the Tinkerboard, I really do, and I suspect I will, but I need to wait just a little bit longer for the software to be just right. But for sure its been improving with each release, its almost at this point usable.

It does have graphics, now (it didn't when it was first released) it does have X11 video GL2.0 and GL3.0 drivers, and therefore it will build the current maze demo, but the GPU does not yet seem to be accelerated, so for the moment at least it chugs like me in a 10m sprint to the donut counter, ie it does the job, but not fast. 

It has the potential to be a monster machine with ES3.1 (maybe 3.2) and it does report that 3.1 is possible, so it may be we can play with some 3.1 shaders, but until the acceleration is switched on, its not going to be quite good enough.

Soon though, very soon.
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 



Reply
#2
Its been a while, so I've come back to look at the Tinkerboard. Its nice to see a new version S on the market but it only offers eMMC memory which for me isn't important so not going to invest in that.
But what is good to see is a much more active community and with it a lot more OS's now available. I'll try a simple update/upgrade 1st to see if it does the trick, other wise I'll download the latest version of the TinkerOS (Debian Stretch) and create a new SD.
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 



Reply
#3
I am having some issues with the X11 display, I managed to work out how to allow access but in the process I have ended up with a blank screen...it may be some fix I had before to resolve the screen data, but I'll find out soon.
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 



Reply
#4
Now that I have resolved the X11 display, I can report the Tinkerboard demo is up and running, but it does seem to have a bit of an issue with glitching, also three's some occasional slow downs which seem to be related to allocation of GPU memory (it tends to slow down as new images are created)

Overall though, its fast, and effective, I'll try to see if the glitching is something I can control and fix (perhaps a frame sync issue)
The system reports ES3.1 on board, so I'll have a crack at making some 3.1 shaers working on it and see what impact has on performance.
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 



Reply
#5
And in my search for a reliable system to test out some 3.0 and 3.1 code, I've come back again to this and still finding it its glitching for some reason, full update and dist-upgrade later and no real improvement in the flicker, but I am not going to assume its the drivers fault as I made such an assumption with the Up^2 board. I'll continue to use it for now with flicker and hopefully the issue will become clear and give me another of my things to watch out for in specific SBC's

Aside from the flicker, its performing pretty well though I think it should be performing a lot better. It seems to be marginally more powerful than a Raspberry in terms of CPU but lacking a little in real usage terms on the GPU. GLMark2-es2 reports a healthy score of around 470, way in excess of a Raspberry but in practice I'm not seeing it consistently hitting the 60fps is should be able to do with that kind of power.
Oh and if you want a nice heatsink shaped brand on your fingers...this is the puppy for you, this is one hot system. Which could be why its performing below the level I expect.

I'll start working on some ES3.0 and ES3.1 demos soon using this.
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 



Reply
#6
I've seen these on the shelf at Fry's and have been waiting for them to discount further since they do not seem to be moving much. The do seem like nice boards and the GPIO pins should be similar to the Raspberry Pi mapping.

Have you seen this?
https://www.geeks3d.com/20180110/discove...y-pi-3/#_4
Reply
#7
Its a nice board, I don't think the software is quite there yet though, I havn't found the cause of the flickering yet but apart from that its running most demo's at 1080p at close to 60fps on totally unoptomised render draws, its only on the more intense multi model demo's that its not quite making it, but that can be fixed, so its a pretty hot machine.

Not seen the article, just read it, it fits with my findings.
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 



Reply
#8
After reading that article, I realised I had not updated the Tinkerboard OS from the forums for quite some time, relying only on an apt-get update/upgrade cycle which isn't always going to be 100%.
So I decided to download the newest version, it wasn't perfect though it needed an update/upgrade after install to get it working, it had some network issues but the update fixed that, but the main reason for the update was the promise of new Mali drivers, and sure enough I got the latest Mali libs and an interesting print out of the capabilities...

This GPU supplied by  :ARM
This GPU supports     :OpenGL ES 3.2 v1.r13p0-00rel0-git(a4271c9).40dbad8455f8b43d1f8fbb5a1fe733e6
This GPU Renders with :Mali-T760
This GPU supports     :OpenGL ES GLSL ES 3.20
This GPU supports these extensions      :GL_ARM_rgba8 GL_ARM_mali_shader_binary GL_OES_depth24 GL_OES_depth_texture GL_OES_depth_texture_cube_map GL_OES_packed_depth_stencil GL_OES_rgb8_rgba8 GL_EXT_read_format_bgra GL_OES_compressed_paletted_texture GL_OES_compressed_ETC1_RGB8_texture GL_OES_standard_derivatives GL_OES_EGL_image GL_OES_EGL_image_external GL_OES_EGL_image_external_essl3 GL_OES_EGL_sync GL_OES_texture_npot GL_OES_vertex_half_float GL_OES_required_internalformat GL_OES_vertex_array_object GL_OES_mapbuffer GL_EXT_texture_format_BGRA8888 GL_EXT_texture_rg GL_EXT_texture_type_2_10_10_10_REV GL_OES_fbo_render_mipmap GL_OES_element_index_uint GL_EXT_shadow_samplers GL_OES_texture_compression_astc GL_KHR_texture_compression_astc_ldr GL_KHR_texture_compression_astc_hdr GL_KHR_texture_compression_astc_sliced_3d GL_KHR_debug GL_EXT_occlusion_query_boolean GL_EXT_disjoint_timer_query GL_EXT_blend_minmax GL_EXT_discard_framebuffer GL_OES_get_program_binary GL_OES_texture_3D GL_EXT_texture_storage GL_EXT_multisampled_render_to_texture GL_OES_surfaceless_context GL_OES_texture_stencil8 GL_EXT_shader_pixel_local_storage GL_ARM_shader_framebuffer_fetch GL_ARM_shader_framebuffer_fetch_depth_stencil GL_ARM_mali_program_binary GL_EXT_sRGB GL_EXT_sRGB_write_control GL_EXT_texture_sRGB_decode GL_KHR_blend_equation_advanced GL_KHR_blend_equation_advanced_coherent GL_OES_texture_storage_multisample_2d_array GL_OES_shader_image_atomic GL_EXT_robustness GL_EXT_draw_buffers_indexed GL_OES_draw_buffers_indexed GL_EXT_texture_border_clamp GL_OES_texture_border_clamp GL_EXT_texture_cube_map_array GL_OES_texture_cube_map_array GL_OES_sample_variables GL_OES_sample_shading GL_OES_shader_multisample_interpolation GL_EXT_shader_io_blocks GL_OES_shader_io_blocks GL_EXT_tessellation_shader GL_OES_tessellation_shader GL_EXT_primitive_bounding_box GL_OES_primitive_bounding_box GL_EXT_geometry_shader GL_OES_geometry_shader GL_ANDROID_extension_pack_es31a GL_EXT_gpu_shader5 GL_OES_gpu_shader5 GL_EXT_texture_buffer GL_OES_texture_buffer GL_EXT_copy_image GL_OES_copy_image GL_EXT_color_buffer_half_float GL_EXT_color_buffer_float GL_EXT_YUV_target GL_OVR_multiview GL_OVR_multiview2 GL_OVR_multiview_multisampled_render_to_texture GL_KHR_robustness GL_KHR_robust_buffer_access_behavior GL_EXT_draw_elements_base_vertex GL_OES_draw_elements_base_vertex

The interesting bit aside from all those extensions, is OpenGLES3.2 Big Grin So far the Tinkerboard has been limited to 3.1 even thought the Rockchip's Mali 764 GPU is rated as an OpenGLES3.2 and Vulkan 1.0 gpu.

Not tried to do any 3.2 on it but I will.. Sadly I still have my flickering issue, but I don't honestly think thats the board, it's something I'm doing wrong am sure.. I'll find it in due course it did however keep the frame rate up into the 60's except when there were a lot of models on screen at once which is quite good.

Building GLmark2 on it as described here
https://www.pcsuggest.com/install-glmark2-debian/
(don't use gl flavours, use this ./waf configure --with-flavors=x11-glesv2, and remember you will build glmark2-es2 not glmark2)

GLmark2 returns the same info as my demo code, ie, OpenGLES3.2 and libs r13 and running it off screen gives a score of.
395..hmmm that's a bit of a drop from the 470 I was getting before.

One small issue though, the board seems to be pulling a lot more power, I had to hook up a 5a unit to it, the normal 2.5a caused the screen to vanish at times it may also be the cause of the score drop, the Tinker board has always been a bit susceptible to power outages, which can come in many forms, including a screen blank and a general slow down, so of course I ran it again with a 5a unit and the score was.
403 hmmm ok well that's not really getting back my 70 points but..oh well, its running OpenGLES3.2 Big Grin and maybe we have to accept the new drivers are a bit slower.
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 



Reply
#9
I also added a small fan to try to keep it cool, maybe its throttling due to overheating..but nope, 398, its pretty much averaging GLMark2 scores of 400 with extra power and cooling.
Still waaaay faster than a Raspberry, and if coded properly with optimised rendering should be a great system.
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 



Reply
#10
Interesting to note that when I run my standard demo on a couple of other ES3.2 rated systems, in ES2.0 mode,  I get flickering models..this further supports my theory that I've done somthing slightly wrong.. I'll keep checking, the more ES3.0+ things I do the sooner I'll stumble on it. But google isn't showing any thing that gives me a lot of clues yet.
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 



Reply


Forum Jump:


Users browsing this thread: 2 Guest(s)