02-28-2019, 06:24 PM
(This post was last modified: 03-01-2019, 11:01 AM by Brian Beuken.)
First looks, as I don't have time to really play...
Nice, I have a 2GB version with onboard eMMC which has Android on it, but burning Debian to SD card makes it boot from that without issue
GLmark2 is frame locked, but running it offscreen gives a score of 249. Hmm not outstanding but workable
It needed an apt-get update before it would install Bullet, as well as apt-get install build-essential as well as apt-get install gdb
This really is a slim image but these things are easy to install, and after the keyboard hack is also entered into the terminal
sudo chmod a+r /dev/input/*
Maze project builds fine.
Not exactly blinding speed, on a par with a Raspberry,doing mostly 60fps, with some slow downs. But do remember that the Maze project is seriously badly done and with optimisation and some OpenGLES3.2 featrues can easily get 3-4 times faster Also I don't currently know how to set the framebuffer on standard Linux systems to less than full screen, on Raspberry I tend to run a half screen size framebuffer.
Its interesting to note that the NanoPi RK3399 boards reported a much faster GLMark2, but were rather sluggish running the demo, averaging 30fps.. Not sure why the RockPi is making a better attempt at keeping up the frame rate.. would like to find out. I thought GLMark2 was supposed to be the premium test project?? I guess Im not using some features that are poorly implmented.
Oh yes, did I mention, OpenGLES3.2 Mali-T860Mp4
This is nice.....this is very nice, I'm sure there are issues with it, it does get hot which must have an impact on its speed, but for the moment I'm very pleased.I'll stress it out a bit soon as my code reviews are done and try to put together something in OpenGLES3.2 to really show it off.
I have to say my initial negativity was misplaced, Tom Cubie was very kind to respond to my mail and provide a test unit and give a little insight into future plans which is very encouraging. I hope they get it out to the market place in numbers soon. This board will certainly give the RPi a run for its money.
It does seem to have hardware drivers though, which is nice to see. Here's its list of 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
Nice, I have a 2GB version with onboard eMMC which has Android on it, but burning Debian to SD card makes it boot from that without issue
GLmark2 is frame locked, but running it offscreen gives a score of 249. Hmm not outstanding but workable
It needed an apt-get update before it would install Bullet, as well as apt-get install build-essential as well as apt-get install gdb
This really is a slim image but these things are easy to install, and after the keyboard hack is also entered into the terminal
sudo chmod a+r /dev/input/*
Maze project builds fine.
Not exactly blinding speed, on a par with a Raspberry,doing mostly 60fps, with some slow downs. But do remember that the Maze project is seriously badly done and with optimisation and some OpenGLES3.2 featrues can easily get 3-4 times faster Also I don't currently know how to set the framebuffer on standard Linux systems to less than full screen, on Raspberry I tend to run a half screen size framebuffer.
Its interesting to note that the NanoPi RK3399 boards reported a much faster GLMark2, but were rather sluggish running the demo, averaging 30fps.. Not sure why the RockPi is making a better attempt at keeping up the frame rate.. would like to find out. I thought GLMark2 was supposed to be the premium test project?? I guess Im not using some features that are poorly implmented.
Oh yes, did I mention, OpenGLES3.2 Mali-T860Mp4
This is nice.....this is very nice, I'm sure there are issues with it, it does get hot which must have an impact on its speed, but for the moment I'm very pleased.I'll stress it out a bit soon as my code reviews are done and try to put together something in OpenGLES3.2 to really show it off.
I have to say my initial negativity was misplaced, Tom Cubie was very kind to respond to my mail and provide a test unit and give a little insight into future plans which is very encouraging. I hope they get it out to the market place in numbers soon. This board will certainly give the RPi a run for its money.
It does seem to have hardware drivers though, which is nice to see. Here's its list of 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
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