Demystifying Odroid N2 hardware acceleration

User avatar
memeka
Posts: 4420
Joined: Mon May 20, 2013 10:22 am
languages_spoken: english
ODROIDs: XU rev2 + eMMC + UART
U3 + eMMC + IO Shield + UART
Has thanked: 2 times
Been thanked: 57 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by memeka » Wed Nov 27, 2019 8:11 pm

The posts you linked are wayland in 4.9 kernel released by hk
My tests were mainline

odroidn2user
Posts: 108
Joined: Fri Oct 25, 2019 4:14 pm
languages_spoken: english
ODROIDs: N2
Has thanked: 24 times
Been thanked: 19 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by odroidn2user » Thu Nov 28, 2019 12:46 am

memeka wrote:
Wed Nov 27, 2019 8:11 pm
The posts you linked are wayland in 4.9 kernel released by hk
My tests were mainline
Oh, that doesn't give a high level of confidence that the Mali Wayland blobs would result in a wonderful experience when combined with the Meson DRM module.
Now it could well be that the Mali DRM module was just really bad and the Mali Wayland blobs were indeed wonderful.
Your experience seems to indicate that might be the case, and the Mali DRM module does indeed seem to be pretty bad when it comes to Wayland support, baed on reading some of the postings here.
But, as with much in life, we will have to wait and see.

P.S. I keep being amazed at how weird the software offerings from ARM/Mali are. They basically delivered pretty neat hardware, and then completely foul up the software side of things, while at the same time, with a straight face, saying they support Wayland? (Which they very clearly are not.) If they can't even get Wayland to go on their own DRM module...

ab1jx
Posts: 97
Joined: Wed Jul 10, 2019 8:25 am
languages_spoken: english
Has thanked: 8 times
Been thanked: 3 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by ab1jx » Thu Nov 28, 2019 9:41 am

I'm on an xorg mailing list and I just saw an answer from somebody at xorg saying that Redhat now ships with Wayland enabled by default although users can switch back. I've played with it a little, if you have xwayland installed you can run xorg programs under Wayland, sort of. It's a little slow like being on a fast VNC connection. I rarely watch video anyway. I had xorg Firefox running from within xwayland under Wayland, xwayland just comes up when it needs to. DRM/DRI would be good though, mutter also complains about that.

The standard Wayland terminal emulator isn't very good but I was somehow getting urxvt (with rounded corners) under Wayland. And Firefox running with rounded corners inside an xorg box with square corners. https://wayland.freedesktop.org/faq.html

User avatar
memeka
Posts: 4420
Joined: Mon May 20, 2013 10:22 am
languages_spoken: english
ODROIDs: XU rev2 + eMMC + UART
U3 + eMMC + IO Shield + UART
Has thanked: 2 times
Been thanked: 57 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by memeka » Thu Nov 28, 2019 10:35 am

@odroidn2user
there is no mali DRM module.
the DRM is specific to the SoC, not to mali.
So even if rockchip and amlogic both have exactly same Mali, they have different DRM hardware, one done by amlogc and one done by rockchip.

my experience with wayland on mainline with mainline meson drm was good.
very similar to the one on the XU4: https://www.youtube.com/watch?v=AkSgm4JF81U , https://www.youtube.com/watch?v=nT5XLdSAylU

ab1jx
Posts: 97
Joined: Wed Jul 10, 2019 8:25 am
languages_spoken: english
Has thanked: 8 times
Been thanked: 3 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by ab1jx » Fri Nov 29, 2019 12:33 am

Looking at my N2 (by ssh), in /dev I see 4 framebuffers and a /devmali0. Maybe I should move it upstairs for the winter as being more interesting than this Rock64. https://www.kernel.org/doc/html/latest/gpu/meson.html Meson is in the dmesg a bunch. But it has no man page. And the name is overused, this has nothing to do with the Meson build system.

I was getting a bunch of MySQL errors on this site that it was too busy yesterday.

ab1jx
Posts: 97
Joined: Wed Jul 10, 2019 8:25 am
languages_spoken: english
Has thanked: 8 times
Been thanked: 3 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by ab1jx » Fri Nov 29, 2019 8:59 am

Looking at my N2 (by ssh), in /dev I see 4 framebuffers and a /devmali0. Maybe I should move it upstairs for the winter as being more interesting than this Rock64. https://www.kernel.org/doc/html/latest/gpu/meson.html Meson is in the dmesg a bunch. But it has no man page. And the name is overused, this has nothing to do with the Meson build system.

I was getting a bunch of MySQL errors on this site that it was too busy yesterday.

odroidn2user
Posts: 108
Joined: Fri Oct 25, 2019 4:14 pm
languages_spoken: english
ODROIDs: N2
Has thanked: 24 times
Been thanked: 19 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by odroidn2user » Fri Nov 29, 2019 6:27 pm

memeka wrote:
Thu Nov 28, 2019 10:35 am
@odroidn2user
there is no mali DRM module.
the DRM is specific to the SoC, not to mali.
So even if rockchip and amlogic both have exactly same Mali, they have different DRM hardware, one done by amlogc and one done by rockchip.

my experience with wayland on mainline with mainline meson drm was good.
very similar to the one on the XU4: https://www.youtube.com/watch?v=AkSgm4JF81U , https://www.youtube.com/watch?v=nT5XLdSAylU
Interesting video's, the XU4 seems to be a pretty capable device as well! :)

Kernel 4.9 with ARM's proprietary Mali software bits appears to have a working DRM module? (There is acceleration, so there has to be a kernel driver somewhere.) I assume that DRM driver was created/modified/edited by Mali? And now the Meson project seems to be redo-ing the work in an Open / Free mainline package... So I kinda assumed there was a ARM Mali DRM driver and an Meson Mali DRM driver. And apparently, there is not. I am still grasping at the basics, it seems. Thanks.

I'm getting more and more enthusiastic about the near future of the Odroid N2 device! :)
With working GPU and VPU acceleration, this thing is a real game changer.

User avatar
memeka
Posts: 4420
Joined: Mon May 20, 2013 10:22 am
languages_spoken: english
ODROIDs: XU rev2 + eMMC + UART
U3 + eMMC + IO Shield + UART
Has thanked: 2 times
Been thanked: 57 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by memeka » Fri Nov 29, 2019 8:26 pm

No, DRM driver is not created or modified by mali.
it's a separate driver that needs to "talk" to mali but it's not done by ARM.

ab1jx
Posts: 97
Joined: Wed Jul 10, 2019 8:25 am
languages_spoken: english
Has thanked: 8 times
Been thanked: 3 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by ab1jx » Fri Nov 29, 2019 10:59 pm

Well, I built Panfrost and it does render, but it's at least partly software. In a sample that moves I can see it running in top, about 100% of 1 core. A page at freedesktop.org says to do glxinfo | grep render which looks like:

Code: Select all

direct rendering: Yes
    GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer, 
    GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, GLX_MESA_query_renderer, 
Extended renderer info (GLX_MESA_query_renderer):
OpenGL renderer string: softpipe
    GL_ARB_conditional_render_inverted, GL_ARB_conservative_depth, 
    GL_MESA_ycbcr_texture, GL_NV_conditional_render, GL_NV_depth_clamp, 
    GL_ARB_conditional_render_inverted, GL_ARB_conservative_depth, 
    GL_NV_conditional_render, GL_NV_depth_clamp, GL_NV_fog_distance, 
    GL_EXT_render_snorm, GL_EXT_sRGB_write_control, 
    GL_MESA_shader_integer_functions, GL_NV_conditional_render, 
    GL_OES_element_index_uint, GL_OES_fbo_render_mipmap, 
Panfrost came from https://gitlab.freedesktop.org/mesa/mesa and samples came from https://gitlab.freedesktop.org/mesa/demos. It was sort of a bear to build, lots of stuff to track down and install.
multisamp.png
multisamp.png (16.35 KiB) Viewed 2516 times

ab1jx
Posts: 97
Joined: Wed Jul 10, 2019 8:25 am
languages_spoken: english
Has thanked: 8 times
Been thanked: 3 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by ab1jx » Sat Nov 30, 2019 3:51 am

I'm getting a bunch of MySQL errors on the server which probably explains the double post. I thought it didn't post with the image so I did a version without. And I can't delete it, even though there's that option: I get a message saying I can't delete posts.

If you're going to fiddle with Panfrost, install current llvm and clang first so it can use them. The version in the debs is too old, I'm building llvm 9. Go to llvm.org

The "softpipe" should change to "llvmpipe" which is a little faster but I had the deb version of llvm/clang which isn't new enough to qualify.

ab1jx
Posts: 97
Joined: Wed Jul 10, 2019 8:25 am
languages_spoken: english
Has thanked: 8 times
Been thanked: 3 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by ab1jx » Sat Nov 30, 2019 9:19 am

Hmm, at https://panfrost.freedesktop.org/buildi ... -mesa.html it says:
"Use a mainline kernel version 5.2 or later with CONFIG_DRM_PANFROST enabled."

Maybe that's part of why I don't see a /dev/dri. I thought Panfrost was supposed to provide that. I don't suppose you can set that up as a module that you can insmod?

Interesting: https://www.collabora.com/news-and-blog ... st-driver/

ajcard
Posts: 59
Joined: Fri Jun 07, 2019 4:46 pm
languages_spoken: english
Has thanked: 0
Been thanked: 0
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by ajcard » Sat Nov 30, 2019 12:16 pm

ab1jx wrote:
Sat Nov 30, 2019 9:32 am
Hmm, at https://panfrost.freedesktop.org/buildi ... -mesa.html it says:
"Use a mainline kernel version 5.2 or later with CONFIG_DRM_PANFROST enabled."

Maybe that's part of why I don't see a /dev/dri. I thought Panfrost was supposed to provide that. I don't suppose you can set that up as a module that you can insmod? Maybe but not with this kernel version: https://en.opensuse.org/ARM_Mali_GPU The G52 isn't one of the supported Malis yet anyway.

Interesting: https://www.collabora.com/news-and-blog ... st-driver/
I've built this driver on kernel 5.4 according to your link #1, but I was not able to configure xorg in a way that the panfrost_dri driver
was used. Thanks for the other links, will try it.

User avatar
memeka
Posts: 4420
Joined: Mon May 20, 2013 10:22 am
languages_spoken: english
ODROIDs: XU rev2 + eMMC + UART
U3 + eMMC + IO Shield + UART
Has thanked: 2 times
Been thanked: 57 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by memeka » Sat Nov 30, 2019 12:39 pm

Panfrost is not compatible with Mali Gxx models yet
Afaik

ajcard
Posts: 59
Joined: Fri Jun 07, 2019 4:46 pm
languages_spoken: english
Has thanked: 0
Been thanked: 0
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by ajcard » Sat Nov 30, 2019 1:10 pm

memeka wrote:
Sat Nov 30, 2019 12:39 pm
Panfrost is not compatible with Mali Gxx models yet
Afaik
hmm, I can't remember exactly where I've read that it should work.
so I thought I would try it. Just to be prepared when the time comes ;)

And I've looked into the source panfrost_features.h , and there is:
#define hw_features_g52 (\
BIT_ULL(HW_FEATURE_JOBCHAIN_DISAMBIGUATION) | \
BIT_ULL(HW_FEATURE_PWRON_DURING_PWROFF_TRANS) | \
BIT_ULL(HW_FEATURE_XAFFINITY) | \
BIT_ULL(HW_FEATURE_WARPING) | \
BIT_ULL(HW_FEATURE_INTERPIPE_REG_ALIASING) | \
BIT_ULL(HW_FEATURE_32_BIT_UNIFORM_ADDRESS) | \
BIT_ULL(HW_FEATURE_ATTR_AUTO_TYPE_INFERRAL) | \
BIT_ULL(HW_FEATURE_BRNDOUT_CC) | \
BIT_ULL(HW_FEATURE_BRNDOUT_KILL) | \
BIT_ULL(HW_FEATURE_LD_ST_LEA_TEX) | \
BIT_ULL(HW_FEATURE_LD_ST_TILEBUFFER) | \
BIT_ULL(HW_FEATURE_LINEAR_FILTER_FLOAT) | \
BIT_ULL(HW_FEATURE_MRT) | \
BIT_ULL(HW_FEATURE_MSAA_16X) | \
BIT_ULL(HW_FEATURE_NEXT_INSTRUCTION_TYPE) | \
BIT_ULL(HW_FEATURE_OUT_OF_ORDER_EXEC) | \
BIT_ULL(HW_FEATURE_T7XX_PAIRING_RULES) | \
BIT_ULL(HW_FEATURE_TEST4_DATUM_MODE) | \
BIT_ULL(HW_FEATURE_THREAD_GROUP_SPLIT) | \
BIT_ULL(HW_FEATURE_FLUSH_REDUCTION) | \
BIT_ULL(HW_FEATURE_PROTECTED_MODE) | \
BIT_ULL(HW_FEATURE_PROTECTED_DEBUG_MODE) | \
BIT_ULL(HW_FEATURE_COHERENCY_REG))

So even if the accelaration does maybe not work yet, I tried build the driver and see how far I could get with x.

ab1jx
Posts: 97
Joined: Wed Jul 10, 2019 8:25 am
languages_spoken: english
Has thanked: 8 times
Been thanked: 3 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by ab1jx » Sat Nov 30, 2019 2:26 pm

What happened with me so far is that I don't get a /dev/dri, on my N2. I do on my Rock64 before I'd even done anything, but all the OpenGL ES samples I've tried run as softpipe. Didn't try building with a current llvm, working on building that on both.

I did see the G52 Mali listed somewhere under supported devices for Vulkan. I could never get that interested in OpenGL anyway. I just want to write to memory locations in the framebuffer, I'm not interested in the lighting and all that baggage of OpenGL.

The only thing I'm sure runs OpenGL ES with the GPU is my Raspberry Pis, even theoretically the $10 ZeroW since it has the same GPU.

ajcard
Posts: 59
Joined: Fri Jun 07, 2019 4:46 pm
languages_spoken: english
Has thanked: 0
Been thanked: 0
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by ajcard » Sat Nov 30, 2019 3:13 pm

my /dev/dri looks like this
/by-path
@platform-ff900000.vpu-card
-card0

but x uses llvmpipe as renderer

ab1jx
Posts: 97
Joined: Wed Jul 10, 2019 8:25 am
languages_spoken: english
Has thanked: 8 times
Been thanked: 3 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by ab1jx » Sat Nov 30, 2019 11:52 pm

Mine's too old-fashioned, locate shows no mention of anything with "vpu-card" in it. This is Debian or Ubuntu?
but x uses llvmpipe as renderer
That sounds very slow and like some percentage of your CPU would always be busy. Does
ps ax | grep llvm
show anything? I see no mention of llvm in my /var/log/Xorg.0.log either. (Debian, the image came from this thread: viewtopic.php?f=179&t=35658) Maybe it doesn't show because it's a system process.

Code: Select all

root@odroid:/dev# dpkg-query -l | grep llvm
ii  libllvm7:arm64                        1:7.0.1-8                           arm64        Modular compiler and toolchain technologies, runtime library
root@odroid:/dev# ps ax | grep llvm
21127 pts/15   S+     0:00 grep --color=auto llvm
Wayland OTOH can use OpenGL ES as part of it's output, which I suspect is why there's OpenGL ES for Wayland, because they had to set it up.

-----------
Oh, never mind, llvm is basically a C compiler, the program it compiled probably wouldn't have llvm in the name.
Last edited by ab1jx on Mon Dec 02, 2019 11:00 am, edited 1 time in total.

odroidn2user
Posts: 108
Joined: Fri Oct 25, 2019 4:14 pm
languages_spoken: english
ODROIDs: N2
Has thanked: 24 times
Been thanked: 19 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by odroidn2user » Sun Dec 01, 2019 4:47 am

I've experimented a little (very little, but still) with Panfrost with KDE/X11 and Gnome/Wayland on the RockPro64 / RK3399, with kernel 5.4, mesa 19.2, using Manjaro ARM. Panfrost is surprisingly not fast. In fact, for normal video viewing en surfing, llvmpipe with fbdev/fbturbo was faster than full stack Panfrost.
A big difference is having vdec / vpu decoding support for video, which isn't the case on default Manjaro ARM. But full Panfrost on its own was not that wonderful. In fact, I went back to fbturbo.

The little outing around the RockPro64 made me appreciate Odroid N2 all the more. The other core layout and quicker core speeds really do seem to make a difference in responsiveness. The supported VPU and hardware acceleration (on kernel 4.4) make the RockPro64 a little quicker in the right conditions, but under most circumstances Odroid N2 is the better offering even now without the hardware acceleration. So HK not continuing the N1 route was probably with good reason. Also: the Odroid N2 costs less and it's easier to actually buy / get your hands on here in Europe.

Also, the Odroid N2 has a clearer output picture, somehow.

ab1jx
Posts: 97
Joined: Wed Jul 10, 2019 8:25 am
languages_spoken: english
Has thanked: 8 times
Been thanked: 3 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by ab1jx » Sun Dec 01, 2019 8:02 am

The g52 Mali is on the list of Vulkan Malis: https://developer.arm.com/solutions/gra ... pis/vulkan (So is the T860 in the Pinebook Pro.) You can get your very own copy of the SDK at https://vulkan.lunarg.com/sdk/home which is linked from the Khronos site so it's official. I wonder if they're shifting priority of driver development to Vulkan with later Malis.

Driver page: https://developer.arm.com/tools-and-sof ... user-space What I don't like is that they provide this stuff but they say you still need the DDK to use it. And the one time I looked it cost $6000 (per year) for the DDK. There's something about FOSS they just aren't getting.
Note that these components are not a complete driver stack. To build a functional OpenGL ES you need access to the full source code of the Mali GPU DDK, which is provided under the standard Arm commercial licence to all Mali GPU customers.
But
The open source drivers provided on this page are designed to run with a version-compatible release of the Mali GPU DDK. In functional and performance terms they are identical to the implementations provided under the commercial licence. By also releasing them under the GPLv2 licence we hope to make it easier to include Mali GPU drivers on any Linux or Android platform.
So I'm not sure where that leaves us but I'm still trying to find the g52 driver for Vulkan.

back2future
Posts: 271
Joined: Sun Jul 23, 2017 3:19 pm
languages_spoken: english
Has thanked: 12 times
Been thanked: 6 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by back2future » Sun Dec 01, 2019 10:37 pm

[ 1) first testing on x64 platform:

Code: Select all

vulkaninfo
===========
VULKAN INFO
===========

Vulkan Instance Version: 1.1.70

Cannot create Vulkan instance.
/build/vulkan-UL09PJ/vulkan-1.1.70+dfsg1/demos/vulkaninfo.c:768: failed with VK_ERROR_INCOMPATIBLE_DRIVER



2) testing on odroid bench for N2: -p 2227

Code: Select all

vulkaninfo
===========
VULKAN INFO
===========

Vulkan API Version: 1.0.39

INFO: [loader] Code 0 : Found ICD manifest file /usr/share/vulkan/icd.d/radeon_icd.aarch64.json, version "1.0.0"

Instance Extensions:
====================
Instance Extensions count = 5
VK_KHR_surface : extension revision 25
VK_KHR_xcb_surface : extension revision 6
VK_KHR_xlib_surface : extension revision 6
VK_KHR_wayland_surface : extension revision 5
VK_EXT_debug_report : extension revision 4
/build/vulkan-Lmcfe4/vulkan-1.0.39.0+dfsg1/demos/vulkaninfo.c:1485: failed with VK_ERROR_INITIALIZATION_FAILED
SIGGRAPH 2019: OpenXR Vulkan ]
Last edited by back2future on Mon Dec 02, 2019 12:38 pm, edited 1 time in total.

ab1jx
Posts: 97
Joined: Wed Jul 10, 2019 8:25 am
languages_spoken: english
Has thanked: 8 times
Been thanked: 3 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by ab1jx » Mon Dec 02, 2019 8:14 am

Why are you on an x64 platform? The ICD manifest is for a Radeon which is an ATI video card I think. But you also have aarch64 in the file name like it's for an ARM machine. And VK_ERROR_INCOMPATIBLE_DRIVER.

I haven't gotten as far as trying to run a demo, I'm still trying to track down drivers. There's a lot of noise out there, almost like one of those math exam questions where part of the object is to ignore what's irrelevant. I just built llvm9 on my Rock64, the N2 build is back around 80% done, still trying to link clang. And that's using gold instead of ld, ninja instead of make, about 10 GB of swap on both, both have 4 GB RAM.

back2future
Posts: 271
Joined: Sun Jul 23, 2017 3:19 pm
languages_spoken: english
Has thanked: 12 times
Been thanked: 6 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by back2future » Mon Dec 02, 2019 10:53 am

[ bay trail x64 example for vukaninfo

Code: Select all

==========
VULKANINFO
==========

Vulkan Instance Version: 1.1.97

INTEL-MESA: warning: Bay Trail Vulkan support is incomplete
INTEL-MESA: warning: ../src/intel/vulkan/anv_device.c:1242: FINISHME: Implement pop-free point clipping


Instance Extensions:
====================
Instance Extensions	count = 17
	VK_EXT_acquire_xlib_display         : extension revision  1
	VK_EXT_debug_report                 : extension revision  8
	VK_EXT_debug_utils                  : extension revision  1
	VK_EXT_direct_mode_display          : extension revision  1
	VK_EXT_display_surface_counter      : extension revision  1
	VK_KHR_device_group_creation        : extension revision  1
	VK_KHR_display                      : extension revision 23
	VK_KHR_external_fence_capabilities  : extension revision  1
	VK_KHR_external_memory_capabilities : extension revision  1
	VK_KHR_external_semaphore_capabilities: extension revision  1
	VK_KHR_get_display_properties2      : extension revision  1
	VK_KHR_get_physical_device_properties2: extension revision  1
	VK_KHR_get_surface_capabilities2    : extension revision  1
	VK_KHR_surface                      : extension revision 25
	VK_KHR_wayland_surface              : extension revision  6
	VK_KHR_xcb_surface                  : extension revision  6
	VK_KHR_xlib_surface                 : extension revision  6
Layers: count = 0
=======
Presentable Surfaces:
=====================
GPU id       : 0 (Intel(R) Bay Trail)
Surface type : VK_KHR_xcb_surface
Formats:		count = 2
	B8G8R8A8_SRGB
	B8G8R8A8_UNORM
Present Modes:		count = 3
	IMMEDIATE_KHR
	MAILBOX_KHR
	FIFO_KHR
VkSurfaceCapabilitiesKHR:
	minImageCount       = 2
	maxImageCount       = 0
	currentExtent:
		width       = 256
		height      = 256
	minImageExtent:
		width       = 256
		height      = 256
	maxImageExtent:
		width       = 256
		height      = 256
	maxImageArrayLayers = 1
	supportedTransform:
		VK_SURFACE_TRANSFORM_IDENTITY_BIT_KHR
	currentTransform:
		VK_SURFACE_TRANSFORM_IDENTITY_BIT_KHR
	supportedCompositeAlpha:
		VK_COMPOSITE_ALPHA_OPAQUE_BIT_KHR
		VK_COMPOSITE_ALPHA_INHERIT_BIT_KHR
	supportedUsageFlags:
		VK_IMAGE_USAGE_TRANSFER_SRC_BIT
		VK_IMAGE_USAGE_TRANSFER_DST_BIT
		VK_IMAGE_USAGE_SAMPLED_BIT
		VK_IMAGE_USAGE_STORAGE_BIT
		VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT
VkSurfaceCapabilities2EXT:
	supportedSurfaceCounters:
		None

GPU id       : 0 (Intel(R) Bay Trail)
Surface type : VK_KHR_xlib_surface
Formats:		count = 2
	B8G8R8A8_SRGB
	B8G8R8A8_UNORM
Present Modes:		count = 3
	IMMEDIATE_KHR
	MAILBOX_KHR
	FIFO_KHR
VkSurfaceCapabilitiesKHR:
	minImageCount       = 2
	maxImageCount       = 0
	currentExtent:
		width       = 256
		height      = 256
	minImageExtent:
		width       = 256
		height      = 256
	maxImageExtent:
		width       = 256
		height      = 256
	maxImageArrayLayers = 1
	supportedTransform:
		VK_SURFACE_TRANSFORM_IDENTITY_BIT_KHR
	currentTransform:
		VK_SURFACE_TRANSFORM_IDENTITY_BIT_KHR
	supportedCompositeAlpha:
		VK_COMPOSITE_ALPHA_OPAQUE_BIT_KHR
		VK_COMPOSITE_ALPHA_INHERIT_BIT_KHR
	supportedUsageFlags:
		VK_IMAGE_USAGE_TRANSFER_SRC_BIT
		VK_IMAGE_USAGE_TRANSFER_DST_BIT
		VK_IMAGE_USAGE_SAMPLED_BIT
		VK_IMAGE_USAGE_STORAGE_BIT
		VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT
VkSurfaceCapabilities2EXT:
	supportedSurfaceCounters:
		None


Groups :
========
	Device Group Properties (Group 0) :
		physicalDeviceCount = 1

			Intel(R) Bay Trail (ID: 0)

		subsetAllocation = 0

	Device Group Present Capabilities (Group 0) :

		Intel(R) Bay Trail (ID: 0)
		Can present images from the following devices:
			Intel(R) Bay Trail (ID: 0)

		Present modes:
			VK_DEVICE_GROUP_PRESENT_MODE_LOCAL_BIT_KHR



Device Properties and Extensions :
==================================
GPU0
VkPhysicalDeviceProperties:
===========================
	apiVersion     = 0x401060  (1.1.96)
	driverVersion  = 79691778 (0x4c00002)
	vendorID       = 0x8086
	deviceID       = 0x0f31
	deviceType     = INTEGRATED_GPU
	deviceName     = Intel(R) Bay Trail
	VkPhysicalDeviceLimits:
	-----------------------
		maxImageDimension1D                     = 16384
		maxImageDimension2D                     = 16384
		maxImageDimension3D                     = 2048
		maxImageDimensionCube                   = 16384
		maxImageArrayLayers                     = 2048
		maxTexelBufferElements                  = 0x8000000
		maxUniformBufferRange                   = 0x8000000
		maxStorageBufferRange                   = 0x40000000
		maxPushConstantsSize                    = 128
		maxMemoryAllocationCount                = 4294967295
		maxSamplerAllocationCount               = 65536
		bufferImageGranularity                  = 0x40
		sparseAddressSpaceSize                  = 0x0
		maxBoundDescriptorSets                  = 8
		maxPerStageDescriptorSamplers           = 16
		maxPerStageDescriptorUniformBuffers     = 64
		maxPerStageDescriptorStorageBuffers     = 64
		maxPerStageDescriptorSampledImages      = 16
		maxPerStageDescriptorStorageImages      = 8
		maxPerStageDescriptorInputAttachments   = 64
		maxPerStageResources                    = 250
		maxDescriptorSetSamplers                = 96
		maxDescriptorSetUniformBuffers          = 384
		maxDescriptorSetUniformBuffersDynamic   = 8
		maxDescriptorSetStorageBuffers          = 384
		maxDescriptorSetStorageBuffersDynamic   = 8
		maxDescriptorSetSampledImages           = 96
		maxDescriptorSetStorageImages           = 48
		maxDescriptorSetInputAttachments        = 256
		maxVertexInputAttributes                = 28
		maxVertexInputBindings                  = 28
		maxVertexInputAttributeOffset           = 0x7ff
		maxVertexInputBindingStride             = 0x800
		maxVertexOutputComponents               = 128
		maxTessellationGenerationLevel          = 64
		maxTessellationPatchSize                        = 32
		maxTessellationControlPerVertexInputComponents  = 128
		maxTessellationControlPerVertexOutputComponents = 128
		maxTessellationControlPerPatchOutputComponents  = 128
		maxTessellationControlTotalOutputComponents     = 2048
		maxTessellationEvaluationInputComponents        = 128
		maxTessellationEvaluationOutputComponents       = 128
		maxGeometryShaderInvocations            = 32
		maxGeometryInputComponents              = 64
		maxGeometryOutputComponents             = 128
		maxGeometryOutputVertices               = 256
		maxGeometryTotalOutputComponents        = 1024
		maxFragmentInputComponents              = 112
		maxFragmentOutputAttachments            = 8
		maxFragmentDualSrcAttachments           = 1
		maxFragmentCombinedOutputResources      = 8
		maxComputeSharedMemorySize              = 0x8000
		maxComputeWorkGroupCount[0]             = 65535
		maxComputeWorkGroupCount[1]             = 65535
		maxComputeWorkGroupCount[2]             = 65535
		maxComputeWorkGroupInvocations          = 512
		maxComputeWorkGroupSize[0]              = 512
		maxComputeWorkGroupSize[1]              = 512
		maxComputeWorkGroupSize[2]              = 512
		subPixelPrecisionBits                   = 8
		subTexelPrecisionBits                   = 4
		mipmapPrecisionBits                     = 4
		maxDrawIndexedIndexValue                = 4294967295
		maxDrawIndirectCount                    = 4294967295
		maxSamplerLodBias                       = 16.000000
		maxSamplerAnisotropy                    = 16.000000
		maxViewports                            = 16
		maxViewportDimensions[0]                = 16384
		maxViewportDimensions[1]                = 16384
		viewportBoundsRange[0]                  = -32768.000000
		viewportBoundsRange[1]                  =  32767.000000
		viewportSubPixelBits                    = 13
		minMemoryMapAlignment                   = 4096
		minTexelBufferOffsetAlignment           = 0x1
		minUniformBufferOffsetAlignment         = 0x20
		minStorageBufferOffsetAlignment         = 0x4
		minTexelOffset                          =  -8
		maxTexelOffset                          =   7
		minTexelGatherOffset                    = -32
		maxTexelGatherOffset                    =  31
		minInterpolationOffset                  = -0.500000
		maxInterpolationOffset                  =  0.437500
		subPixelInterpolationOffsetBits         = 4
		maxFramebufferWidth                     = 16384
		maxFramebufferHeight                    = 16384
		maxFramebufferLayers                    = 2048
		framebufferColorSampleCounts            = 13
		framebufferDepthSampleCounts            = 13
		framebufferStencilSampleCounts          = 13
		framebufferNoAttachmentsSampleCounts    = 13
		maxColorAttachments                     = 8
		sampledImageColorSampleCounts           = 13
		sampledImageDepthSampleCounts           = 13
		sampledImageStencilSampleCounts         = 13
		sampledImageIntegerSampleCounts         = 1
		storageImageSampleCounts                = 1
		maxSampleMaskWords                      = 1
		timestampComputeAndGraphics             = 0
		timestampPeriod                         = 80.000000
		maxClipDistances                        = 8
		maxCullDistances                        = 8
		maxCombinedClipAndCullDistances         = 8
		discreteQueuePriorities                 = 2
		pointSizeRange[0]                       = 0.125000
		pointSizeRange[1]                       = 255.875000
		lineWidthRange[0]                       = 0.000000
		lineWidthRange[1]                       = 7.992188
		pointSizeGranularity                    = 0.125000
		lineWidthGranularity                    = 0.007812
		strictLines                             = 0
		standardSampleLocations                 = 1
		optimalBufferCopyOffsetAlignment        = 0x80
		optimalBufferCopyRowPitchAlignment      = 0x80
		nonCoherentAtomSize                     = 0x40
	VkPhysicalDeviceSparseProperties:
	---------------------------------
		residencyStandard2DBlockShape            = 0
		residencyStandard2DMultisampleBlockShape = 0
		residencyStandard3DBlockShape            = 0
		residencyAlignedMipSize                  = 0
		residencyNonResidentStrict               = 0

VkPhysicalDevicePointClippingProperties:
========================================
	pointClippingBehavior               = 0

VkPhysicalDevicePushDescriptorProperties:
=========================================
	maxPushDescriptors               = 32

VkPhysicalDeviceMultiviewProperties:
====================================
	maxMultiviewViewCount     = 16
	maxMultiviewInstanceIndex = 268435455

VkPhysicalDeviceMaintenance3Properties:
=======================================
	maxPerSetDescriptors    = 1024
	maxMemoryAllocationSize = 2147483648

VkPhysicalDeviceIDProperties:
=========================================
	deviceUUID      = ????????-5ad8-87e1-829c-0faaea22e811
	driverUUID      = 168e9065-7969-3606-c3fb-f2bb6aee9292
	deviceLUIDValid = false

VkPhysicalDeviceDriverProperties:
=================================
	driverID   = 6
	driverName = Intel open-source Mesa driver
	driverInfo = Mesa 19.0.2
	conformanceVersion:
		major    = 1
		minor    = 1
		subminor = 2
		patch    = 0

VkPhysicalDevicePCIBusInfoProperties
====================================
	pciDomain   = 0
	pciBus      = 0
	pciDevice   = 2
	pciFunction = 0

VkPhysicalDeviceTransformFeedbackProperties
===========================================
	maxTransformFeedbackStreams                = 4
	maxTransformFeedbackBuffers                = 4
	maxTransformFeedbackBufferSize             = 4294967296
	maxTransformFeedbackStreamDataSize         = 512
	maxTransformFeedbackBufferDataSize         = 512
	maxTransformFeedbackBufferDataStride       = 2048
	transformFeedbackQueries                   = 1
	transformFeedbackStreamsLinesTriangles     = 0
	transformFeedbackRasterizationStreamSelect = 0
	transformFeedbackDraw                      = 1

Device Extensions	count = 39
	VK_EXT_calibrated_timestamps        : extension revision  1
	VK_EXT_display_control              : extension revision  1
	VK_EXT_external_memory_dma_buf      : extension revision  1
	VK_EXT_pci_bus_info                 : extension revision  2
	VK_EXT_scalar_block_layout          : extension revision  1
	VK_EXT_shader_viewport_index_layer  : extension revision  1
	VK_EXT_transform_feedback           : extension revision  1
	VK_EXT_vertex_attribute_divisor     : extension revision  3
	VK_GOOGLE_decorate_string           : extension revision  1
	VK_GOOGLE_hlsl_functionality1       : extension revision  1
	VK_KHR_bind_memory2                 : extension revision  1
	VK_KHR_create_renderpass2           : extension revision  1
	VK_KHR_dedicated_allocation         : extension revision  1
	VK_KHR_depth_stencil_resolve        : extension revision  1
	VK_KHR_descriptor_update_template   : extension revision  1
	VK_KHR_device_group                 : extension revision  1
	VK_KHR_draw_indirect_count          : extension revision  1
	VK_KHR_driver_properties            : extension revision  1
	VK_KHR_external_fence               : extension revision  1
	VK_KHR_external_fence_fd            : extension revision  1
	VK_KHR_external_memory              : extension revision  1
	VK_KHR_external_memory_fd           : extension revision  1
	VK_KHR_external_semaphore           : extension revision  1
	VK_KHR_external_semaphore_fd        : extension revision  1
	VK_KHR_get_memory_requirements2     : extension revision  1
	VK_KHR_image_format_list            : extension revision  1
	VK_KHR_incremental_present          : extension revision  1
	VK_KHR_maintenance1                 : extension revision  1
	VK_KHR_maintenance2                 : extension revision  1
	VK_KHR_maintenance3                 : extension revision  1
	VK_KHR_multiview                    : extension revision  1
	VK_KHR_push_descriptor              : extension revision  1
	VK_KHR_relaxed_block_layout         : extension revision  1
	VK_KHR_sampler_mirror_clamp_to_edge : extension revision  1
	VK_KHR_sampler_ycbcr_conversion     : extension revision  1
	VK_KHR_shader_draw_parameters       : extension revision  1
	VK_KHR_storage_buffer_storage_class : extension revision  1
	VK_KHR_swapchain                    : extension revision 68
	VK_KHR_variable_pointers            : extension revision  1

VkQueueFamilyProperties[0]:
===========================
	queueFlags         = GRAPHICS | COMPUTE | TRANSFER
	queueCount         = 1
	timestampValidBits = 36
	minImageTransferGranularity = (1, 1, 1)

VkPhysicalDeviceMemoryProperties:
=================================
	memoryHeapCount       = 1
	memoryHeaps[0] :
		size          = 1008332800 (0x3c19f000) (961.62 MiB)
		flags:
			VK_MEMORY_HEAP_DEVICE_LOCAL_BIT
	memoryTypeCount       = 2
	memoryTypes[0] :
		heapIndex     = 0
		propertyFlags = 0x7:
			VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT
			VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT
			VK_MEMORY_PROPERTY_HOST_COHERENT_BIT
	memoryTypes[1] :
		heapIndex     = 0
		propertyFlags = 0xb:
			VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT
			VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT
			VK_MEMORY_PROPERTY_HOST_CACHED_BIT

VkPhysicalDeviceFeatures:
=========================
	robustBufferAccess                      = 1
	fullDrawIndexUint32                     = 1
	imageCubeArray                          = 1
	independentBlend                        = 1
	geometryShader                          = 1
	tessellationShader                      = 1
	sampleRateShading                       = 1
	dualSrcBlend                            = 1
	logicOp                                 = 1
	multiDrawIndirect                       = 1
	drawIndirectFirstInstance               = 1
	depthClamp                              = 1
	depthBiasClamp                          = 1
	fillModeNonSolid                        = 1
	depthBounds                             = 0
	wideLines                               = 1
	largePoints                             = 1
	alphaToOne                              = 1
	multiViewport                           = 1
	samplerAnisotropy                       = 1
	textureCompressionETC2                  = 1
	textureCompressionASTC_LDR              = 0
	textureCompressionBC                    = 1
	occlusionQueryPrecise                   = 1
	pipelineStatisticsQuery                 = 1
	vertexPipelineStoresAndAtomics          = 0
	fragmentStoresAndAtomics                = 1
	shaderTessellationAndGeometryPointSize  = 1
	shaderImageGatherExtended               = 1
	shaderStorageImageExtendedFormats       = 1
	shaderStorageImageMultisample           = 0
	shaderStorageImageReadWithoutFormat     = 0
	shaderStorageImageWriteWithoutFormat    = 1
	shaderUniformBufferArrayDynamicIndexing = 1
	shaderSampledImageArrayDynamicIndexing  = 1
	shaderStorageBufferArrayDynamicIndexing = 1
	shaderStorageImageArrayDynamicIndexing  = 1
	shaderClipDistance                      = 1
	shaderCullDistance                      = 1
	shaderFloat64                           = 0
	shaderInt64                             = 0
	shaderInt16                             = 0
	shaderResourceResidency                 = 0
	shaderResourceMinLod                    = 0
	sparseBinding                           = 0
	sparseResidencyBuffer                   = 0
	sparseResidencyImage2D                  = 0
	sparseResidencyImage3D                  = 0
	sparseResidency2Samples                 = 0
	sparseResidency4Samples                 = 0
	sparseResidency8Samples                 = 0
	sparseResidency16Samples                = 0
	sparseResidencyAliased                  = 0
	variableMultisampleRate                 = 1
	inheritedQueries                        = 1

VkPhysicalDeviceSamplerYcbcrConversionFeatures:
===============================================
	samplerYcbcrConversion = 1

VkPhysicalDeviceVariablePointerFeatures:
========================================
	variablePointersStorageBuffer = 1
	variablePointers              = 1

VkPhysicalDeviceMultiviewFeatures:
==================================
	multiview                   = 1
	multiviewGeometryShader     = 1
	multiviewTessellationShader = 1

VkPhysicalDeviceTransformFeedbackFeatures:
==========================================
	transformFeedback = 1
	geometryStreams   = 1

VkPhysicalDeviceScalarBlockLayoutFeatures:
==========================================
	scalarBlockLayout = 1

Format Properties:
==================

FORMAT_B4G4R4A4_UNORM_PACK16,
FORMAT_BC1_RGB_UNORM_BLOCK,
FORMAT_BC1_RGB_SRGB_BLOCK,
FORMAT_BC1_RGBA_UNORM_BLOCK,
FORMAT_BC1_RGBA_SRGB_BLOCK,
FORMAT_BC2_UNORM_BLOCK,
FORMAT_BC2_SRGB_BLOCK,
FORMAT_BC3_UNORM_BLOCK,
FORMAT_BC3_SRGB_BLOCK,
FORMAT_BC4_UNORM_BLOCK,
FORMAT_BC4_SNORM_BLOCK,
FORMAT_BC5_UNORM_BLOCK,
FORMAT_BC5_SNORM_BLOCK,
FORMAT_BC6H_UFLOAT_BLOCK,
FORMAT_BC6H_SFLOAT_BLOCK,
FORMAT_BC7_UNORM_BLOCK,
FORMAT_BC7_SRGB_BLOCK,
FORMAT_ETC2_R8G8B8_UNORM_BLOCK,
FORMAT_ETC2_R8G8B8_SRGB_BLOCK,
FORMAT_ETC2_R8G8B8A1_UNORM_BLOCK,
FORMAT_ETC2_R8G8B8A1_SRGB_BLOCK,
FORMAT_ETC2_R8G8B8A8_UNORM_BLOCK,
FORMAT_ETC2_R8G8B8A8_SRGB_BLOCK,
FORMAT_EAC_R11_UNORM_BLOCK,
FORMAT_EAC_R11_SNORM_BLOCK,
FORMAT_EAC_R11G11_UNORM_BLOCK,
FORMAT_EAC_R11G11_SNORM_BLOCK:
	linearTiling   FormatFeatureFlags:
		VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT
		VK_FORMAT_FEATURE_BLIT_SRC_BIT
		VK_FORMAT_FEATURE_BLIT_DST_BIT
		VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT
		VK_FORMAT_FEATURE_TRANSFER_SRC_BIT_KHR
		VK_FORMAT_FEATURE_TRANSFER_DST_BIT_KHR

	optimalTiling  FormatFeatureFlags:
		VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT
		VK_FORMAT_FEATURE_BLIT_SRC_BIT
		VK_FORMAT_FEATURE_BLIT_DST_BIT
		VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT
		VK_FORMAT_FEATURE_TRANSFER_SRC_BIT_KHR
		VK_FORMAT_FEATURE_TRANSFER_DST_BIT_KHR

	bufferFeatures FormatFeatureFlags:
		None

FORMAT_R5G6B5_UNORM_PACK16,
FORMAT_B5G6R5_UNORM_PACK16,
FORMAT_A1R5G5B5_UNORM_PACK16,
FORMAT_R8G8B8A8_SRGB,
FORMAT_B8G8R8A8_SRGB,
FORMAT_A8B8G8R8_SRGB_PACK32:
	linearTiling   FormatFeatureFlags:
		VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT
		VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BIT
		VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BLEND_BIT
		VK_FORMAT_FEATURE_BLIT_SRC_BIT
		VK_FORMAT_FEATURE_BLIT_DST_BIT
		VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT
		VK_FORMAT_FEATURE_TRANSFER_SRC_BIT_KHR
		VK_FORMAT_FEATURE_TRANSFER_DST_BIT_KHR

	optimalTiling  FormatFeatureFlags:
		VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT
		VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BIT
		VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BLEND_BIT
		VK_FORMAT_FEATURE_BLIT_SRC_BIT
		VK_FORMAT_FEATURE_BLIT_DST_BIT
		VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT
		VK_FORMAT_FEATURE_TRANSFER_SRC_BIT_KHR
		VK_FORMAT_FEATURE_TRANSFER_DST_BIT_KHR

	bufferFeatures FormatFeatureFlags:
		VK_FORMAT_FEATURE_UNIFORM_TEXEL_BUFFER_BIT

FORMAT_R8_UNORM,
FORMAT_R8_SNORM,
FORMAT_R8G8_UNORM,
FORMAT_R8G8_SNORM,
FORMAT_R8G8B8A8_UNORM,
FORMAT_R8G8B8A8_SNORM,
FORMAT_A8B8G8R8_UNORM_PACK32,
FORMAT_A8B8G8R8_SNORM_PACK32,
FORMAT_A2B10G10R10_UNORM_PACK32,
FORMAT_R16_UNORM,
FORMAT_R16_SNORM,
FORMAT_R16_SFLOAT,
FORMAT_R16G16_UNORM,
FORMAT_R16G16_SNORM,
FORMAT_R16G16_SFLOAT,
FORMAT_R16G16B16A16_UNORM,
FORMAT_R16G16B16A16_SNORM,
FORMAT_R16G16B16A16_SFLOAT,
FORMAT_R32_SFLOAT,
FORMAT_R32G32_SFLOAT,
FORMAT_R32G32B32A32_SFLOAT,
FORMAT_B10G11R11_UFLOAT_PACK32:
	linearTiling   FormatFeatureFlags:
		VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT
		VK_FORMAT_FEATURE_STORAGE_IMAGE_BIT
		VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BIT
		VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BLEND_BIT
		VK_FORMAT_FEATURE_BLIT_SRC_BIT
		VK_FORMAT_FEATURE_BLIT_DST_BIT
		VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT
		VK_FORMAT_FEATURE_TRANSFER_SRC_BIT_KHR
		VK_FORMAT_FEATURE_TRANSFER_DST_BIT_KHR

	optimalTiling  FormatFeatureFlags:
		VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT
		VK_FORMAT_FEATURE_STORAGE_IMAGE_BIT
		VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BIT
		VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BLEND_BIT
		VK_FORMAT_FEATURE_BLIT_SRC_BIT
		VK_FORMAT_FEATURE_BLIT_DST_BIT
		VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT
		VK_FORMAT_FEATURE_TRANSFER_SRC_BIT_KHR
		VK_FORMAT_FEATURE_TRANSFER_DST_BIT_KHR

	bufferFeatures FormatFeatureFlags:
		VK_FORMAT_FEATURE_UNIFORM_TEXEL_BUFFER_BIT
		VK_FORMAT_FEATURE_STORAGE_TEXEL_BUFFER_BIT
		VK_FORMAT_FEATURE_VERTEX_BUFFER_BIT

FORMAT_R8_USCALED,
FORMAT_R8_SSCALED,
FORMAT_R8G8_USCALED,
FORMAT_R8G8_SSCALED,
FORMAT_R8G8B8_USCALED,
FORMAT_R8G8B8_SSCALED,
FORMAT_R8G8B8A8_USCALED,
FORMAT_R8G8B8A8_SSCALED,
FORMAT_A8B8G8R8_USCALED_PACK32,
FORMAT_A8B8G8R8_SSCALED_PACK32,
FORMAT_A2R10G10B10_SNORM_PACK32,
FORMAT_A2R10G10B10_USCALED_PACK32,
FORMAT_A2R10G10B10_SSCALED_PACK32,
FORMAT_A2R10G10B10_UINT_PACK32,
FORMAT_A2R10G10B10_SINT_PACK32,
FORMAT_A2B10G10R10_SNORM_PACK32,
FORMAT_A2B10G10R10_USCALED_PACK32,
FORMAT_A2B10G10R10_SSCALED_PACK32,
FORMAT_A2B10G10R10_SINT_PACK32,
FORMAT_R16_USCALED,
FORMAT_R16_SSCALED,
FORMAT_R16G16_USCALED,
FORMAT_R16G16_SSCALED,
FORMAT_R16G16B16_USCALED,
FORMAT_R16G16B16_SSCALED,
FORMAT_R16G16B16A16_USCALED,
FORMAT_R16G16B16A16_SSCALED:
	linearTiling   FormatFeatureFlags:
		None

	optimalTiling  FormatFeatureFlags:
		None

	bufferFeatures FormatFeatureFlags:
		VK_FORMAT_FEATURE_VERTEX_BUFFER_BIT

FORMAT_R8_UINT,
FORMAT_R8_SINT,
FORMAT_R8G8_UINT,
FORMAT_R8G8_SINT,
FORMAT_R8G8B8A8_UINT,
FORMAT_R8G8B8A8_SINT,
FORMAT_A8B8G8R8_UINT_PACK32,
FORMAT_A8B8G8R8_SINT_PACK32,
FORMAT_A2B10G10R10_UINT_PACK32,
FORMAT_R16_UINT,
FORMAT_R16_SINT,
FORMAT_R16G16_UINT,
FORMAT_R16G16_SINT,
FORMAT_R16G16B16A16_UINT,
FORMAT_R16G16B16A16_SINT,
FORMAT_R32G32_UINT,
FORMAT_R32G32_SINT,
FORMAT_R32G32B32A32_UINT,
FORMAT_R32G32B32A32_SINT:
	linearTiling   FormatFeatureFlags:
		VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT
		VK_FORMAT_FEATURE_STORAGE_IMAGE_BIT
		VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BIT
		VK_FORMAT_FEATURE_BLIT_SRC_BIT
		VK_FORMAT_FEATURE_BLIT_DST_BIT
		VK_FORMAT_FEATURE_TRANSFER_SRC_BIT_KHR
		VK_FORMAT_FEATURE_TRANSFER_DST_BIT_KHR

	optimalTiling  FormatFeatureFlags:
		VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT
		VK_FORMAT_FEATURE_STORAGE_IMAGE_BIT
		VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BIT
		VK_FORMAT_FEATURE_BLIT_SRC_BIT
		VK_FORMAT_FEATURE_BLIT_DST_BIT
		VK_FORMAT_FEATURE_TRANSFER_SRC_BIT_KHR
		VK_FORMAT_FEATURE_TRANSFER_DST_BIT_KHR

	bufferFeatures FormatFeatureFlags:
		VK_FORMAT_FEATURE_UNIFORM_TEXEL_BUFFER_BIT
		VK_FORMAT_FEATURE_STORAGE_TEXEL_BUFFER_BIT
		VK_FORMAT_FEATURE_VERTEX_BUFFER_BIT

FORMAT_R8_SRGB,
FORMAT_E5B9G9R9_UFLOAT_PACK32:
	linearTiling   FormatFeatureFlags:
		VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT
		VK_FORMAT_FEATURE_BLIT_SRC_BIT
		VK_FORMAT_FEATURE_BLIT_DST_BIT
		VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT
		VK_FORMAT_FEATURE_TRANSFER_SRC_BIT_KHR
		VK_FORMAT_FEATURE_TRANSFER_DST_BIT_KHR

	optimalTiling  FormatFeatureFlags:
		VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT
		VK_FORMAT_FEATURE_BLIT_SRC_BIT
		VK_FORMAT_FEATURE_BLIT_DST_BIT
		VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT
		VK_FORMAT_FEATURE_TRANSFER_SRC_BIT_KHR
		VK_FORMAT_FEATURE_TRANSFER_DST_BIT_KHR

	bufferFeatures FormatFeatureFlags:
		VK_FORMAT_FEATURE_UNIFORM_TEXEL_BUFFER_BIT

FORMAT_R8G8B8_UNORM,
FORMAT_R16G16B16_UNORM:
	linearTiling   FormatFeatureFlags:
		None

	optimalTiling  FormatFeatureFlags:
		VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT
		VK_FORMAT_FEATURE_BLIT_SRC_BIT
		VK_FORMAT_FEATURE_BLIT_DST_BIT
		VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT
		VK_FORMAT_FEATURE_TRANSFER_SRC_BIT_KHR
		VK_FORMAT_FEATURE_TRANSFER_DST_BIT_KHR

	bufferFeatures FormatFeatureFlags:
		VK_FORMAT_FEATURE_VERTEX_BUFFER_BIT

FORMAT_R8G8B8_SNORM,
FORMAT_R16G16B16_SNORM:
	linearTiling   FormatFeatureFlags:
		None

	optimalTiling  FormatFeatureFlags:
		VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT
		VK_FORMAT_FEATURE_BLIT_SRC_BIT
		VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT
		VK_FORMAT_FEATURE_TRANSFER_SRC_BIT_KHR
		VK_FORMAT_FEATURE_TRANSFER_DST_BIT_KHR

	bufferFeatures FormatFeatureFlags:
		VK_FORMAT_FEATURE_VERTEX_BUFFER_BIT

FORMAT_R8G8B8_UINT,
FORMAT_R8G8B8_SINT,
FORMAT_R16G16B16_UINT,
FORMAT_R16G16B16_SINT:
	linearTiling   FormatFeatureFlags:
		None

	optimalTiling  FormatFeatureFlags:
		VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT
		VK_FORMAT_FEATURE_BLIT_SRC_BIT
		VK_FORMAT_FEATURE_TRANSFER_SRC_BIT_KHR
		VK_FORMAT_FEATURE_TRANSFER_DST_BIT_KHR

	bufferFeatures FormatFeatureFlags:
		VK_FORMAT_FEATURE_VERTEX_BUFFER_BIT

FORMAT_R8G8B8_SRGB:
	linearTiling   FormatFeatureFlags:
		None

	optimalTiling  FormatFeatureFlags:
		VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT
		VK_FORMAT_FEATURE_BLIT_SRC_BIT
		VK_FORMAT_FEATURE_BLIT_DST_BIT
		VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT
		VK_FORMAT_FEATURE_TRANSFER_SRC_BIT_KHR
		VK_FORMAT_FEATURE_TRANSFER_DST_BIT_KHR

	bufferFeatures FormatFeatureFlags:
		None

FORMAT_B8G8R8A8_UNORM,
FORMAT_A2R10G10B10_UNORM_PACK32:
	linearTiling   FormatFeatureFlags:
		VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT
		VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BIT
		VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BLEND_BIT
		VK_FORMAT_FEATURE_BLIT_SRC_BIT
		VK_FORMAT_FEATURE_BLIT_DST_BIT
		VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT
		VK_FORMAT_FEATURE_TRANSFER_SRC_BIT_KHR
		VK_FORMAT_FEATURE_TRANSFER_DST_BIT_KHR

	optimalTiling  FormatFeatureFlags:
		VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT
		VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BIT
		VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BLEND_BIT
		VK_FORMAT_FEATURE_BLIT_SRC_BIT
		VK_FORMAT_FEATURE_BLIT_DST_BIT
		VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT
		VK_FORMAT_FEATURE_TRANSFER_SRC_BIT_KHR
		VK_FORMAT_FEATURE_TRANSFER_DST_BIT_KHR

	bufferFeatures FormatFeatureFlags:
		VK_FORMAT_FEATURE_UNIFORM_TEXEL_BUFFER_BIT
		VK_FORMAT_FEATURE_VERTEX_BUFFER_BIT

FORMAT_R16G16B16_SFLOAT,
FORMAT_R32G32B32_SFLOAT:
	linearTiling   FormatFeatureFlags:
		VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT
		VK_FORMAT_FEATURE_BLIT_SRC_BIT
		VK_FORMAT_FEATURE_BLIT_DST_BIT
		VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT
		VK_FORMAT_FEATURE_TRANSFER_SRC_BIT_KHR
		VK_FORMAT_FEATURE_TRANSFER_DST_BIT_KHR

	optimalTiling  FormatFeatureFlags:
		VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT
		VK_FORMAT_FEATURE_BLIT_SRC_BIT
		VK_FORMAT_FEATURE_BLIT_DST_BIT
		VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT
		VK_FORMAT_FEATURE_TRANSFER_SRC_BIT_KHR
		VK_FORMAT_FEATURE_TRANSFER_DST_BIT_KHR

	bufferFeatures FormatFeatureFlags:
		VK_FORMAT_FEATURE_UNIFORM_TEXEL_BUFFER_BIT
		VK_FORMAT_FEATURE_VERTEX_BUFFER_BIT

FORMAT_R32_UINT,
FORMAT_R32_SINT:
	linearTiling   FormatFeatureFlags:
		VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT
		VK_FORMAT_FEATURE_STORAGE_IMAGE_BIT
		VK_FORMAT_FEATURE_STORAGE_IMAGE_ATOMIC_BIT
		VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BIT
		VK_FORMAT_FEATURE_BLIT_SRC_BIT
		VK_FORMAT_FEATURE_BLIT_DST_BIT
		VK_FORMAT_FEATURE_TRANSFER_SRC_BIT_KHR
		VK_FORMAT_FEATURE_TRANSFER_DST_BIT_KHR

	optimalTiling  FormatFeatureFlags:
		VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT
		VK_FORMAT_FEATURE_STORAGE_IMAGE_BIT
		VK_FORMAT_FEATURE_STORAGE_IMAGE_ATOMIC_BIT
		VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BIT
		VK_FORMAT_FEATURE_BLIT_SRC_BIT
		VK_FORMAT_FEATURE_BLIT_DST_BIT
		VK_FORMAT_FEATURE_TRANSFER_SRC_BIT_KHR
		VK_FORMAT_FEATURE_TRANSFER_DST_BIT_KHR

	bufferFeatures FormatFeatureFlags:
		VK_FORMAT_FEATURE_UNIFORM_TEXEL_BUFFER_BIT
		VK_FORMAT_FEATURE_STORAGE_TEXEL_BUFFER_BIT
		VK_FORMAT_FEATURE_STORAGE_TEXEL_BUFFER_ATOMIC_BIT
		VK_FORMAT_FEATURE_VERTEX_BUFFER_BIT

FORMAT_R32G32B32_UINT,
FORMAT_R32G32B32_SINT:
	linearTiling   FormatFeatureFlags:
		VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT
		VK_FORMAT_FEATURE_BLIT_SRC_BIT
		VK_FORMAT_FEATURE_BLIT_DST_BIT
		VK_FORMAT_FEATURE_TRANSFER_SRC_BIT_KHR
		VK_FORMAT_FEATURE_TRANSFER_DST_BIT_KHR

	optimalTiling  FormatFeatureFlags:
		VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT
		VK_FORMAT_FEATURE_BLIT_SRC_BIT
		VK_FORMAT_FEATURE_TRANSFER_SRC_BIT_KHR
		VK_FORMAT_FEATURE_TRANSFER_DST_BIT_KHR

	bufferFeatures FormatFeatureFlags:
		VK_FORMAT_FEATURE_UNIFORM_TEXEL_BUFFER_BIT
		VK_FORMAT_FEATURE_VERTEX_BUFFER_BIT

FORMAT_D16_UNORM,
FORMAT_X8_D24_UNORM_PACK32,
FORMAT_D32_SFLOAT:
	linearTiling   FormatFeatureFlags:
		None

	optimalTiling  FormatFeatureFlags:
		VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT
		VK_FORMAT_FEATURE_DEPTH_STENCIL_ATTACHMENT_BIT
		VK_FORMAT_FEATURE_BLIT_SRC_BIT
		VK_FORMAT_FEATURE_BLIT_DST_BIT
		VK_FORMAT_FEATURE_TRANSFER_SRC_BIT_KHR
		VK_FORMAT_FEATURE_TRANSFER_DST_BIT_KHR

	bufferFeatures FormatFeatureFlags:
		None

FORMAT_S8_UINT,
FORMAT_D24_UNORM_S8_UINT,
FORMAT_D32_SFLOAT_S8_UINT:
	linearTiling   FormatFeatureFlags:
		None

	optimalTiling  FormatFeatureFlags:
		VK_FORMAT_FEATURE_DEPTH_STENCIL_ATTACHMENT_BIT
		VK_FORMAT_FEATURE_BLIT_SRC_BIT
		VK_FORMAT_FEATURE_BLIT_DST_BIT
		VK_FORMAT_FEATURE_TRANSFER_SRC_BIT_KHR
		VK_FORMAT_FEATURE_TRANSFER_DST_BIT_KHR

	bufferFeatures FormatFeatureFlags:
		None

FORMAT_G8B8G8R8_422_UNORM,
FORMAT_B8G8R8G8_422_UNORM:
	linearTiling   FormatFeatureFlags:
		VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT
		VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT
		VK_FORMAT_FEATURE_TRANSFER_SRC_BIT_KHR
		VK_FORMAT_FEATURE_TRANSFER_DST_BIT_KHR

	optimalTiling  FormatFeatureFlags:
		VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT
		VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT
		VK_FORMAT_FEATURE_TRANSFER_SRC_BIT_KHR
		VK_FORMAT_FEATURE_TRANSFER_DST_BIT_KHR

	bufferFeatures FormatFeatureFlags:
		None

FORMAT_G8_B8_R8_3PLANE_420_UNORM,
FORMAT_G8_B8R8_2PLANE_420_UNORM,
FORMAT_G8_B8_R8_3PLANE_422_UNORM,
FORMAT_G8_B8R8_2PLANE_422_UNORM,
FORMAT_G16_B16_R16_3PLANE_420_UNORM,
FORMAT_G16_B16R16_2PLANE_420_UNORM,
FORMAT_G16_B16_R16_3PLANE_422_UNORM,
FORMAT_G16_B16R16_2PLANE_422_UNORM:
	linearTiling   FormatFeatureFlags:
		VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT
		VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT
		VK_FORMAT_FEATURE_TRANSFER_SRC_BIT_KHR
		VK_FORMAT_FEATURE_TRANSFER_DST_BIT_KHR

	optimalTiling  FormatFeatureFlags:
		VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT
		VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT
		VK_FORMAT_FEATURE_TRANSFER_SRC_BIT_KHR
		VK_FORMAT_FEATURE_TRANSFER_DST_BIT_KHR

	bufferFeatures FormatFeatureFlags:
		None

FORMAT_G8_B8_R8_3PLANE_444_UNORM,
FORMAT_G16_B16_R16_3PLANE_444_UNORM:
	linearTiling   FormatFeatureFlags:
		VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT
		VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT
		VK_FORMAT_FEATURE_TRANSFER_SRC_BIT_KHR
		VK_FORMAT_FEATURE_TRANSFER_DST_BIT_KHR

	optimalTiling  FormatFeatureFlags:
		VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT
		VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT
		VK_FORMAT_FEATURE_TRANSFER_SRC_BIT_KHR
		VK_FORMAT_FEATURE_TRANSFER_DST_BIT_KHR

	bufferFeatures FormatFeatureFlags:
		None

Unsupported formats:
FORMAT_UNDEFINED
FORMAT_R4G4_UNORM_PACK8
FORMAT_R4G4B4A4_UNORM_PACK16
FORMAT_R5G5B5A1_UNORM_PACK16
FORMAT_B5G5R5A1_UNORM_PACK16
FORMAT_R8G8_SRGB
FORMAT_B8G8R8_UNORM
FORMAT_B8G8R8_SNORM
FORMAT_B8G8R8_USCALED
FORMAT_B8G8R8_SSCALED
FORMAT_B8G8R8_UINT
FORMAT_B8G8R8_SINT
FORMAT_B8G8R8_SRGB
FORMAT_B8G8R8A8_SNORM
FORMAT_B8G8R8A8_USCALED
FORMAT_B8G8R8A8_SSCALED
FORMAT_B8G8R8A8_UINT
FORMAT_B8G8R8A8_SINT
FORMAT_R64_UINT
FORMAT_R64_SINT
FORMAT_R64_SFLOAT
FORMAT_R64G64_UINT
FORMAT_R64G64_SINT
FORMAT_R64G64_SFLOAT
FORMAT_R64G64B64_UINT
FORMAT_R64G64B64_SINT
FORMAT_R64G64B64_SFLOAT
FORMAT_R64G64B64A64_UINT
FORMAT_R64G64B64A64_SINT
FORMAT_R64G64B64A64_SFLOAT
FORMAT_D16_UNORM_S8_UINT
FORMAT_ASTC_4x4_UNORM_BLOCK
FORMAT_ASTC_4x4_SRGB_BLOCK
FORMAT_ASTC_5x4_UNORM_BLOCK
FORMAT_ASTC_5x4_SRGB_BLOCK
FORMAT_ASTC_5x5_UNORM_BLOCK
FORMAT_ASTC_5x5_SRGB_BLOCK
FORMAT_ASTC_6x5_UNORM_BLOCK
FORMAT_ASTC_6x5_SRGB_BLOCK
FORMAT_ASTC_6x6_UNORM_BLOCK
FORMAT_ASTC_6x6_SRGB_BLOCK
FORMAT_ASTC_8x5_UNORM_BLOCK
FORMAT_ASTC_8x5_SRGB_BLOCK
FORMAT_ASTC_8x6_UNORM_BLOCK
FORMAT_ASTC_8x6_SRGB_BLOCK
FORMAT_ASTC_8x8_UNORM_BLOCK
FORMAT_ASTC_8x8_SRGB_BLOCK
FORMAT_ASTC_10x5_UNORM_BLOCK
FORMAT_ASTC_10x5_SRGB_BLOCK
FORMAT_ASTC_10x6_UNORM_BLOCK
FORMAT_ASTC_10x6_SRGB_BLOCK
FORMAT_ASTC_10x8_UNORM_BLOCK
FORMAT_ASTC_10x8_SRGB_BLOCK
FORMAT_ASTC_10x10_UNORM_BLOCK
FORMAT_ASTC_10x10_SRGB_BLOCK
FORMAT_ASTC_12x10_UNORM_BLOCK
FORMAT_ASTC_12x10_SRGB_BLOCK
FORMAT_ASTC_12x12_UNORM_BLOCK
FORMAT_ASTC_12x12_SRGB_BLOCK
FORMAT_R10X6_UNORM_PACK16
FORMAT_R10X6G10X6_UNORM_2PACK16
FORMAT_R10X6G10X6B10X6A10X6_UNORM_4PACK16
FORMAT_G10X6B10X6G10X6R10X6_422_UNORM_4PACK16
FORMAT_B10X6G10X6R10X6G10X6_422_UNORM_4PACK16
FORMAT_G10X6_B10X6_R10X6_3PLANE_420_UNORM_3PACK16
FORMAT_G10X6_B10X6R10X6_2PLANE_420_UNORM_3PACK16
FORMAT_G10X6_B10X6_R10X6_3PLANE_422_UNORM_3PACK16
FORMAT_G10X6_B10X6R10X6_2PLANE_422_UNORM_3PACK16
FORMAT_G10X6_B10X6_R10X6_3PLANE_444_UNORM_3PACK16
FORMAT_R12X4_UNORM_PACK16
FORMAT_R12X4G12X4_UNORM_2PACK16
FORMAT_R12X4G12X4B12X4A12X4_UNORM_4PACK16
FORMAT_G12X4B12X4G12X4R12X4_422_UNORM_4PACK16
FORMAT_B12X4G12X4R12X4G12X4_422_UNORM_4PACK16
FORMAT_G12X4_B12X4_R12X4_3PLANE_420_UNORM_3PACK16
FORMAT_G12X4_B12X4R12X4_2PLANE_420_UNORM_3PACK16
FORMAT_G12X4_B12X4_R12X4_3PLANE_422_UNORM_3PACK16
FORMAT_G12X4_B12X4R12X4_2PLANE_422_UNORM_3PACK16
FORMAT_G12X4_B12X4_R12X4_3PLANE_444_UNORM_3PACK16
FORMAT_G16B16G16R16_422_UNORM
FORMAT_B16G16R16G16_422_UNORM
]
Last edited by back2future on Fri Dec 06, 2019 5:36 pm, edited 1 time in total.

ab1jx
Posts: 97
Joined: Wed Jul 10, 2019 8:25 am
languages_spoken: english
Has thanked: 8 times
Been thanked: 3 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by ab1jx » Mon Dec 02, 2019 2:04 pm

I see, there's very little mention of Mali or ARM in that. From the Vulkan-Guide dir:

Code: Select all

 grep -ir " mali " .
./chapters/development_tools.md:- [Arm PerfDoc layer](https://github.com/ARM-software/perfdoc) - Checks Vulkan applications for best practices on Arm Mali devices.

root@rock64:/usr/src/misc/vulkan/vulkan_guide/Vulkan-Guide# grep -ir " arm " .
./chapters/development_tools.md:- [Arm PerfDoc layer](https://github.com/ARM-software/perfdoc) - Checks Vulkan applications for best practices on Arm Mali devices.
./chapters/development_tools.md:- [Arm Streamline Performance Analyzer](https://developer.arm.com/tools-and-software/graphics-and-gaming/arm-mobile-studio/components/streamline-performance-analyzer) - Visualize the performance of mobile games and applications for a broad range of devices, using Arm Mobile Studio.
platforms_overview.png
platforms_overview.png (36.14 KiB) Viewed 2112 times
Maybe ARM wishes they had better support than they do but they're only taken seriously for games on phones. I've been using ARM machines as my main computers for a couple years. When I go to a web site, at least in Firefox, I usually get the mobile version of the site because some test only sees the ARM. And it's very common so it must be written into some Javascipt library. They didn't even make it into the picture here.

Drivers at https://developer.arm.com/tools-and-sof ... user-space maybe, but for Odroid I only see the xu3. There seem to be drivers for x11 and fbdev, I grabbed a couple to look at and inside they have this directory structure. The libmali.so file is a slightly different size between the two.

Code: Select all

lrwxrwxrwx 1 16580 16580       10 Jan 21  2015 libEGL.so -> libmali.so
lrwxrwxrwx 1 16580 16580       10 Jan 21  2015 libGLESv1_CM.so -> libmali.so
lrwxrwxrwx 1 16580 16580       10 Jan 21  2015 libGLESv2.so -> libmali.so
-rwxr-x--- 1 16580 16580 22239915 Jan 21  2015 libmali.so
lrwxrwxrwx 1 16580 16580       10 Jan 21  2015 libOpenCL.so -> libmali.so
Now is this really a Vulkan driver or is it more universal than that? It's from the list at the bottom of https://developer.arm.com/tools-and-sof ... user-space The nm output is about 2.7 mb, too big for my new free account on pastebin.com. I see function names that look like they belong to different Khronos languages like OpenCL, OpenGL ES 1, OpenGL ES 2. Maybe they're objects rather than functions, I see like

Code: Select all

01c5aec T glScalef
001c5b3c T glScalex
001c5b74 T glScalexOES
001c38f8 T glScissor
001c5bac T glShadeModel
001c8c30 T glShaderBinary
001c8c74 T glShaderSource001e1698 t gles_texturep_slave_delete
and
001e1550 t gles_texturep_slave_delete_internal
001e23c0 t gles_texturep_slave_disable_afbc_if_too_small
001e1a5c t gles_texturep_slave_find_and_release_pbuffer_to_egl
001e0af0 t gles_texturep_slave_force_sync
001e2460 t gles_texturep_slave_get_crop_rectangle_size
001e12d4 t gles_texturep_slave_get_image
and
001ed90c t gles1_vertex_point_size_pointer_oes
001ec010 t gles1_vertex_set_constant_point_size
001ed65c t gles1_vertex_state_init
001ed89c t gles1_vertex_tex_coord_pointer
001ed780 t gles1_vertex_vertex_pointer
001ed954 t gles1_vertex_weight_pointer_oes
01088c60 d gles1_vtable
001c147c t gles2_buffer_atomic_counter_buffer_unbind_all
001c1344 t gles2_buffer_begin_transform_feedback
001c1188 t gles2_buffer_bind_buffer_base
001c1144 t gles2_buffer_bind_buffer_range
001c1330 t gles2_buffer_bind_transform_feedback
001be904 t gles2_buffer_copy_buffer_sub_data
and
000f6564 T egl_color_buffer_get_early_display
000f65bc T egl_color_buffer_get_fence
000f4d68 T egl_color_buffer_get_format
000f4d70 T egl_color_buffer_get_format_info
000f4d64 T egl_color_buffer_get_height
000f56e0 T egl_color_buffer_get_line_stride
000f56ec T egl_color_buffer_get_mapped_address
I don't know the best way to explore what's in there. Somewhere there are matching header files with those function names.

IgaBiva
Posts: 56
Joined: Tue May 07, 2019 4:00 pm
languages_spoken: english, deutsch, srpski
ODROIDs: N2
Has thanked: 0
Been thanked: 6 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by IgaBiva » Mon Dec 02, 2019 7:05 pm

Vulkan is suported on N2 but only on Android 64bit.

ab1jx
Posts: 97
Joined: Wed Jul 10, 2019 8:25 am
languages_spoken: english
Has thanked: 8 times
Been thanked: 3 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by ab1jx » Tue Dec 03, 2019 12:08 am

Hmm, that driver is 32-bit:

Code: Select all

file libmali.so
libmali.so: ELF 32-bit LSB pie executable, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=0b02aa0dab352c61344762b3299efc8e2fc3cc87, not stripped
I wanted to play with compiling and linking one of the Vulkan drivers from https://developer.arm.com/tools-and-sof ... user-space using an OpenGL ES 2 source (es2gears.c) from https://gitlab.freedesktop.org/mesa/demos But ld kicks it out as incompatible because I'm on an aarch64 machine, so I ran file on it. I'm not sure if there's a way to link to 32-bit libraries or not. And maybe they aren't all 32-bit, could be just the one I grabbed at random. Both the x11 and fbdev versions are 32-bit.

The file names are

Code: Select all

malit62xr5p006rel0linux1fbdevtar.gz
malit62xr5p006rel0linux1x11tar.gz
malit62xr4p100rel0linux1fbdevtar.gz
malit62xr4p100rel0linux1x11tar.gz
malit62xr4p002rel0linux1fbdevtar.gz
malit62xr4p002rel0linux1x11tar.gz 
so I grabbed the top ones (I think) and tried an x11 and a fbdev.

No, you can't really use a 32-bit library: https://stackoverflow.com/questions/194 ... it-program

BTW the SOC (Amlogic S922x) was built as a media player SOC https://en.wikipedia.org/wiki/Amlogic so why is it so hard to get video under Linux? Can we steal the Android drivers? Or maybe there's too much Java crap in them.

Oh, woops, read the page, dummy: "These drivers can be used along with the Mali Open Source Kernel Space Device Drivers to create a complete driver stack and run applications using standard APIs such as; [OpenGL ES 1 - 3, OpenCL 1.1 - 2, Vulkan]. Will they get acceleration? Don't know.

Sav
Posts: 128
Joined: Mon Sep 02, 2019 2:33 am
languages_spoken: english
ODROIDs: odroid-n2
Has thanked: 28 times
Been thanked: 9 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by Sav » Tue Dec 03, 2019 3:15 am

IgaBiva wrote:
Mon Dec 02, 2019 7:05 pm
Vulkan is suported on N2 but only on Android 64bit.
Vulkan is supported by lineage os 32 bit: viewtopic.php?f=178&t=35690&p=270206&hi ... an#p270206

ab1jx
Posts: 97
Joined: Wed Jul 10, 2019 8:25 am
languages_spoken: english
Has thanked: 8 times
Been thanked: 3 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by ab1jx » Tue Dec 03, 2019 4:05 am

Yeah, armv7, missed that https://developer.arm.com/-/media/Files ... e664620842 The HiKey 960 Linux for fbdev looks better. Still mostly libmali inside but 64 bit.

Code: Select all

gcc es2gears.c eglut.c -o eg2g -L/usr/programs/c/egles_test -lmali
/usr/bin/ld: /tmp/cc0qx4oP.o: undefined reference to symbol 'sincos@@GLIBC_2.17'
/usr/bin/ld: //lib/aarch64-linux-gnu/libm.so.6: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make: *** [Makefile:2: eg2g] Error 1
I'm not linking against the stuff in the kernel because I don't know how yet. Actually I'm on my Rock64 but they aren't that different. My N2 finally finished building llvm9 after 2 days. This is probably not in the kernel I'm using: https://developer.arm.com/tools-and-sof ... ard-kernel

There's where the undefined reference comes from, in libmali. I thought sincos might mean "since os" but probably not. OK it's not exactly the right one but it probably has to do with sin cos OpenGL involves scary amounts of trigonometry which I've forgotten.
undefined_sincos.gif
undefined_sincos.gif (9.97 KiB) Viewed 1958 times

User avatar
meveric
Posts: 10725
Joined: Mon Feb 25, 2013 2:41 pm
languages_spoken: german, english
ODROIDs: X2, U2, U3, XU-Lite, XU3, XU3-Lite, C1, XU4, C2, C1+, XU4Q, HC1, N1, Go, H2 (N4100), N2, H2 (J4105)
Has thanked: 28 times
Been thanked: 236 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by meveric » Tue Dec 03, 2019 6:45 pm

ab1jx wrote:
Tue Dec 03, 2019 12:08 am

Code: Select all

malit62xr5p006rel0linux1fbdevtar.gz
malit62xr5p006rel0linux1x11tar.gz
malit62xr4p100rel0linux1fbdevtar.gz
malit62xr4p100rel0linux1x11tar.gz
malit62xr4p002rel0linux1fbdevtar.gz
malit62xr4p002rel0linux1x11tar.gz 
You can't just pick random drivers and expect them to work.
The ODROID N2 is a Mali G52 so called "Bifrost" GPU.
The Mali T62x is a completely different GPU architecture called "Midgard".

So obviously drivers for Midgard GPUs won't run on Bifrost GPUs just cause you put them into the folder.
Donate to support my work on the ODROID GameStation Turbo Image for U2/U3 XU3/XU4 X2 X C1 as well as many other releases.
Check out the Games and Emulators section to find some of my work or check the files in my repository to find the software i build for ODROIDs.
If you want to add my repository to your image read my HOWTO integrate my repo into your image.

back2future
Posts: 271
Joined: Sun Jul 23, 2017 3:19 pm
languages_spoken: english
Has thanked: 12 times
Been thanked: 6 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by back2future » Fri Dec 06, 2019 5:30 pm

Code: Select all

gcc es2gears.c eglut.c -o eg2g -L/usr/programs/c/egles_test -lmali
/usr/bin/ld: /tmp/cc0qx4oP.o: undefined reference to symbol 'sincos@@GLIBC_2.17'
/usr/bin/ld: //lib/aarch64-linux-gnu/libm.so.6: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make: *** [Makefile:2: eg2g] Error 1
adding mathematics library libm.so might solve this dependency error


chromium browser

Code: Select all

chrome://gpu/
nicely lists overview information about gpu capabilities and @themoment supported features

ab1jx
Posts: 97
Joined: Wed Jul 10, 2019 8:25 am
languages_spoken: english
Has thanked: 8 times
Been thanked: 3 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by ab1jx » Sat Dec 07, 2019 12:05 am

That would be doing math on the CPU I think and not the GPU. I'm trying to look into Vulkan but not getting much farther.

I don't have Chromium but glxinfo tells me:

Code: Select all

libGL error: unable to load driver: rockchip_dri.so
libGL error: driver pointer missing
libGL error: failed to load driver: rockchip
name of display: :0.0
display: :0  screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.4
server glx extensions:
    GLX_ARB_context_flush_control, GLX_ARB_create_context, 
    GLX_ARB_create_context_no_error, GLX_ARB_create_context_profile, 
    GLX_ARB_fbconfig_float, GLX_ARB_framebuffer_sRGB, GLX_ARB_multisample, 
    GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile, 
    GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB, 
    GLX_EXT_import_context, GLX_EXT_libglvnd, GLX_EXT_no_config_context, 
    GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, 
    GLX_MESA_copy_sub_buffer, GLX_OML_swap_method, GLX_SGIS_multisample, 
    GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, 
    GLX_SGI_make_current_read
client glx vendor string: Mesa Project and SGI
client glx version string: 1.4
client glx extensions:
    GLX_ARB_context_flush_control, GLX_ARB_create_context, 
    GLX_ARB_create_context_profile, GLX_ARB_create_context_robustness, 
    GLX_ARB_fbconfig_float, GLX_ARB_framebuffer_sRGB, 
    GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_buffer_age, 
    GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile, 
    GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB, 
    GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, 
    GLX_EXT_visual_rating, GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, 
    GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer, 
    GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control, 
    GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, 
    GLX_SGIX_visual_select_group, GLX_SGI_make_current_read, 
    GLX_SGI_swap_control, GLX_SGI_video_sync
GLX version: 1.4
GLX extensions:
    GLX_ARB_context_flush_control, GLX_ARB_create_context, 
    GLX_ARB_create_context_profile, GLX_ARB_fbconfig_float, 
    GLX_ARB_framebuffer_sRGB, GLX_ARB_get_proc_address, GLX_ARB_multisample, 
    GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile, 
    GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB, 
    GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, 
    GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, GLX_MESA_query_renderer, 
    GLX_OML_swap_method, GLX_SGIS_multisample, GLX_SGIX_fbconfig, 
    GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_SGI_make_current_read
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: VMware, Inc. (0xffffffff)
    Device: llvmpipe (LLVM 7.0, 128 bits) (0xffffffff)
    Version: 18.3.6
    Accelerated: no
    Video memory: 3986MB
    Unified memory: no
    Preferred profile: core (0x1)
    Max core profile version: 3.3
    Max compat profile version: 3.1
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.0
OpenGL vendor string: VMware, Inc.
OpenGL renderer string: llvmpipe (LLVM 7.0, 128 bits)
OpenGL core profile version string: 3.3 (Core Profile) Mesa 18.3.6
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
    GL_AMD_conservative_depth, GL_AMD_draw_buffers_blend, 
    GL_AMD_gpu_shader_int64, GL_AMD_multi_draw_indirect, 
    GL_AMD_seamless_cubemap_per_texture, GL_AMD_shader_stencil_export, 
    GL_AMD_shader_trinary_minmax, GL_AMD_vertex_shader_layer, 
    GL_AMD_vertex_shader_viewport_index, GL_ANGLE_texture_compression_dxt3, 
    GL_ANGLE_texture_compression_dxt5, GL_ARB_ES2_compatibility, 
    GL_ARB_ES3_compatibility, GL_ARB_arrays_of_arrays, GL_ARB_base_instance, 
    GL_ARB_blend_func_extended, GL_ARB_buffer_storage, 
    GL_ARB_clear_buffer_object, GL_ARB_clear_texture, GL_ARB_clip_control, 
    GL_ARB_compressed_texture_pixel_storage, 
    GL_ARB_conditional_render_inverted, GL_ARB_conservative_depth, 
    GL_ARB_copy_buffer, GL_ARB_copy_image, GL_ARB_cull_distance, 
    GL_ARB_debug_output, GL_ARB_depth_buffer_float, GL_ARB_depth_clamp, 
    GL_ARB_direct_state_access, GL_ARB_draw_buffers, 
    GL_ARB_draw_buffers_blend, GL_ARB_draw_elements_base_vertex, 
    GL_ARB_draw_indirect, GL_ARB_draw_instanced, GL_ARB_enhanced_layouts, 
    GL_ARB_explicit_attrib_location, GL_ARB_explicit_uniform_location, 
    GL_ARB_fragment_coord_conventions, GL_ARB_fragment_layer_viewport, 
    GL_ARB_fragment_shader, GL_ARB_framebuffer_object, 
    GL_ARB_framebuffer_sRGB, GL_ARB_get_program_binary, 
    GL_ARB_get_texture_sub_image, GL_ARB_gpu_shader_fp64, 
    GL_ARB_gpu_shader_int64, GL_ARB_half_float_pixel, 
    GL_ARB_half_float_vertex, GL_ARB_instanced_arrays, 
    GL_ARB_internalformat_query, GL_ARB_internalformat_query2, 
    GL_ARB_invalidate_subdata, GL_ARB_map_buffer_alignment, 
    GL_ARB_map_buffer_range, GL_ARB_multi_bind, GL_ARB_multi_draw_indirect, 
    GL_ARB_occlusion_query2, GL_ARB_pipeline_statistics_query, 
    GL_ARB_pixel_buffer_object, GL_ARB_point_sprite, 
    GL_ARB_polygon_offset_clamp, GL_ARB_program_interface_query, 
    GL_ARB_provoking_vertex, GL_ARB_robustness, GL_ARB_sampler_objects, 
    GL_ARB_seamless_cube_map, GL_ARB_seamless_cubemap_per_texture, 
    GL_ARB_separate_shader_objects, GL_ARB_shader_bit_encoding, 
    GL_ARB_shader_objects, GL_ARB_shader_stencil_export, 
    GL_ARB_shader_subroutine, GL_ARB_shader_texture_lod, 
    GL_ARB_shading_language_420pack, GL_ARB_shading_language_packing, 
    GL_ARB_stencil_texturing, GL_ARB_sync, GL_ARB_texture_buffer_object, 
    GL_ARB_texture_buffer_object_rgb32, GL_ARB_texture_buffer_range, 
    GL_ARB_texture_compression_bptc, GL_ARB_texture_compression_rgtc, 
    GL_ARB_texture_cube_map_array, GL_ARB_texture_float, 
    GL_ARB_texture_gather, GL_ARB_texture_mirror_clamp_to_edge, 
    GL_ARB_texture_multisample, GL_ARB_texture_non_power_of_two, 
    GL_ARB_texture_query_levels, GL_ARB_texture_query_lod, 
    GL_ARB_texture_rectangle, GL_ARB_texture_rg, GL_ARB_texture_rgb10_a2ui, 
    GL_ARB_texture_stencil8, GL_ARB_texture_storage, 
    GL_ARB_texture_storage_multisample, GL_ARB_texture_swizzle, 
    GL_ARB_texture_view, GL_ARB_timer_query, GL_ARB_transform_feedback2, 
    GL_ARB_transform_feedback3, GL_ARB_transform_feedback_instanced, 
    GL_ARB_transform_feedback_overflow_query, GL_ARB_uniform_buffer_object, 
    GL_ARB_vertex_array_bgra, GL_ARB_vertex_array_object, 
    GL_ARB_vertex_attrib_64bit, GL_ARB_vertex_attrib_binding, 
    GL_ARB_vertex_buffer_object, GL_ARB_vertex_shader, 
    GL_ARB_vertex_type_10f_11f_11f_rev, GL_ARB_vertex_type_2_10_10_10_rev, 
    GL_ARB_viewport_array, GL_ATI_blend_equation_separate, 
    GL_ATI_texture_float, GL_ATI_texture_mirror_once, GL_EXT_abgr, 
    GL_EXT_blend_equation_separate, GL_EXT_draw_buffers2, 
    GL_EXT_draw_instanced, GL_EXT_framebuffer_blit, 
    GL_EXT_framebuffer_multisample, GL_EXT_framebuffer_multisample_blit_scaled, 
    GL_EXT_framebuffer_object, GL_EXT_framebuffer_sRGB, 
    GL_EXT_packed_depth_stencil, GL_EXT_packed_float, 
    GL_EXT_pixel_buffer_object, GL_EXT_polygon_offset_clamp, 
    GL_EXT_provoking_vertex, GL_EXT_shader_integer_mix, GL_EXT_texture_array, 
    GL_EXT_texture_compression_dxt1, GL_EXT_texture_compression_rgtc, 
    GL_EXT_texture_compression_s3tc, GL_EXT_texture_integer, 
    GL_EXT_texture_mirror_clamp, GL_EXT_texture_sRGB, 
    GL_EXT_texture_sRGB_decode, GL_EXT_texture_shared_exponent, 
    GL_EXT_texture_snorm, GL_EXT_texture_swizzle, GL_EXT_timer_query, 
    GL_EXT_transform_feedback, GL_EXT_vertex_array_bgra, 
    GL_EXT_vertex_attrib_64bit, GL_IBM_multimode_draw_arrays, 
    GL_KHR_context_flush_control, GL_KHR_debug, GL_KHR_no_error, 
    GL_KHR_texture_compression_astc_ldr, 
    GL_KHR_texture_compression_astc_sliced_3d, GL_MESA_pack_invert, 
    GL_MESA_shader_integer_functions, GL_MESA_texture_signed_rgba, 
    GL_MESA_ycbcr_texture, GL_NV_conditional_render, GL_NV_depth_clamp, 
    GL_NV_packed_depth_stencil, GL_OES_EGL_image, GL_S3_s3tc

OpenGL version string: 3.1 Mesa 18.3.6
OpenGL shading language version string: 1.40
OpenGL context flags: (none)
OpenGL extensions:
    GL_AMD_conservative_depth, GL_AMD_draw_buffers_blend, 
    GL_AMD_multi_draw_indirect, GL_AMD_seamless_cubemap_per_texture, 
    GL_AMD_shader_stencil_export, GL_AMD_shader_trinary_minmax, 
    GL_ANGLE_texture_compression_dxt3, GL_ANGLE_texture_compression_dxt5, 
    GL_APPLE_packed_pixels, GL_ARB_ES2_compatibility, 
    GL_ARB_ES3_compatibility, GL_ARB_arrays_of_arrays, GL_ARB_base_instance, 
    GL_ARB_blend_func_extended, GL_ARB_buffer_storage, 
    GL_ARB_clear_buffer_object, GL_ARB_clear_texture, GL_ARB_clip_control, 
    GL_ARB_color_buffer_float, GL_ARB_compatibility, 
    GL_ARB_compressed_texture_pixel_storage, 
    GL_ARB_conditional_render_inverted, GL_ARB_conservative_depth, 
    GL_ARB_copy_buffer, GL_ARB_copy_image, GL_ARB_cull_distance, 
    GL_ARB_debug_output, GL_ARB_depth_buffer_float, GL_ARB_depth_clamp, 
    GL_ARB_depth_texture, GL_ARB_direct_state_access, GL_ARB_draw_buffers, 
    GL_ARB_draw_buffers_blend, GL_ARB_draw_elements_base_vertex, 
    GL_ARB_draw_indirect, GL_ARB_draw_instanced, GL_ARB_enhanced_layouts, 
    GL_ARB_explicit_attrib_location, GL_ARB_explicit_uniform_location, 
    GL_ARB_fragment_coord_conventions, GL_ARB_fragment_layer_viewport, 
    GL_ARB_fragment_program, GL_ARB_fragment_program_shadow, 
    GL_ARB_fragment_shader, GL_ARB_framebuffer_object, 
    GL_ARB_framebuffer_sRGB, GL_ARB_get_program_binary, 
    GL_ARB_get_texture_sub_image, GL_ARB_half_float_pixel, 
    GL_ARB_half_float_vertex, GL_ARB_instanced_arrays, 
    GL_ARB_internalformat_query, GL_ARB_internalformat_query2, 
    GL_ARB_invalidate_subdata, GL_ARB_map_buffer_alignment, 
    GL_ARB_map_buffer_range, GL_ARB_multi_bind, GL_ARB_multi_draw_indirect, 
    GL_ARB_multisample, GL_ARB_multitexture, GL_ARB_occlusion_query, 
    GL_ARB_occlusion_query2, GL_ARB_pipeline_statistics_query, 
    GL_ARB_pixel_buffer_object, GL_ARB_point_parameters, GL_ARB_point_sprite, 
    GL_ARB_polygon_offset_clamp, GL_ARB_program_interface_query, 
    GL_ARB_provoking_vertex, GL_ARB_robustness, GL_ARB_sampler_objects, 
    GL_ARB_seamless_cube_map, GL_ARB_seamless_cubemap_per_texture, 
    GL_ARB_separate_shader_objects, GL_ARB_shader_bit_encoding, 
    GL_ARB_shader_objects, GL_ARB_shader_stencil_export, 
    GL_ARB_shader_subroutine, GL_ARB_shader_texture_lod, 
    GL_ARB_shading_language_100, GL_ARB_shading_language_420pack, 
    GL_ARB_shading_language_packing, GL_ARB_shadow, GL_ARB_stencil_texturing, 
    GL_ARB_sync, GL_ARB_texture_border_clamp, GL_ARB_texture_buffer_object, 
    GL_ARB_texture_buffer_object_rgb32, GL_ARB_texture_buffer_range, 
    GL_ARB_texture_compression, GL_ARB_texture_compression_bptc, 
    GL_ARB_texture_compression_rgtc, GL_ARB_texture_cube_map, 
    GL_ARB_texture_cube_map_array, GL_ARB_texture_env_add, 
    GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar, 
    GL_ARB_texture_env_dot3, GL_ARB_texture_float, GL_ARB_texture_gather, 
    GL_ARB_texture_mirror_clamp_to_edge, GL_ARB_texture_mirrored_repeat, 
    GL_ARB_texture_multisample, GL_ARB_texture_non_power_of_two, 
    GL_ARB_texture_query_levels, GL_ARB_texture_query_lod, 
    GL_ARB_texture_rectangle, GL_ARB_texture_rg, GL_ARB_texture_rgb10_a2ui, 
    GL_ARB_texture_stencil8, GL_ARB_texture_storage, 
    GL_ARB_texture_storage_multisample, GL_ARB_texture_swizzle, 
    GL_ARB_texture_view, GL_ARB_timer_query, GL_ARB_transform_feedback2, 
    GL_ARB_transform_feedback3, GL_ARB_transform_feedback_instanced, 
    GL_ARB_transform_feedback_overflow_query, GL_ARB_transpose_matrix, 
    GL_ARB_uniform_buffer_object, GL_ARB_vertex_array_bgra, 
    GL_ARB_vertex_array_object, GL_ARB_vertex_attrib_binding, 
    GL_ARB_vertex_buffer_object, GL_ARB_vertex_program, GL_ARB_vertex_shader, 
    GL_ARB_vertex_type_10f_11f_11f_rev, GL_ARB_vertex_type_2_10_10_10_rev, 
    GL_ARB_viewport_array, GL_ARB_window_pos, GL_ATI_blend_equation_separate, 
    GL_ATI_draw_buffers, GL_ATI_fragment_shader, GL_ATI_separate_stencil, 
    GL_ATI_texture_compression_3dc, GL_ATI_texture_env_combine3, 
    GL_ATI_texture_float, GL_ATI_texture_mirror_once, GL_EXT_abgr, 
    GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_equation_separate, 
    GL_EXT_blend_func_separate, GL_EXT_blend_minmax, GL_EXT_blend_subtract, 
    GL_EXT_compiled_vertex_array, GL_EXT_copy_texture, GL_EXT_draw_buffers2, 
    GL_EXT_draw_instanced, GL_EXT_draw_range_elements, GL_EXT_fog_coord, 
    GL_EXT_framebuffer_blit, GL_EXT_framebuffer_multisample, 
    GL_EXT_framebuffer_multisample_blit_scaled, GL_EXT_framebuffer_object, 
    GL_EXT_framebuffer_sRGB, GL_EXT_gpu_program_parameters, 
    GL_EXT_multi_draw_arrays, GL_EXT_packed_depth_stencil, 
    GL_EXT_packed_float, GL_EXT_packed_pixels, GL_EXT_pixel_buffer_object, 
    GL_EXT_point_parameters, GL_EXT_polygon_offset_clamp, 
    GL_EXT_provoking_vertex, GL_EXT_rescale_normal, GL_EXT_secondary_color, 
    GL_EXT_separate_specular_color, GL_EXT_shader_integer_mix, 
    GL_EXT_shadow_funcs, GL_EXT_stencil_two_side, GL_EXT_stencil_wrap, 
    GL_EXT_subtexture, GL_EXT_texture, GL_EXT_texture3D, 
    GL_EXT_texture_array, GL_EXT_texture_compression_dxt1, 
    GL_EXT_texture_compression_latc, GL_EXT_texture_compression_rgtc, 
    GL_EXT_texture_compression_s3tc, GL_EXT_texture_cube_map, 
    GL_EXT_texture_edge_clamp, GL_EXT_texture_env_add, 
    GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, 
    GL_EXT_texture_integer, GL_EXT_texture_lod_bias, 
    GL_EXT_texture_mirror_clamp, GL_EXT_texture_object, 
    GL_EXT_texture_rectangle, GL_EXT_texture_sRGB, GL_EXT_texture_sRGB_decode, 
    GL_EXT_texture_shared_exponent, GL_EXT_texture_snorm, 
    GL_EXT_texture_swizzle, GL_EXT_timer_query, GL_EXT_transform_feedback, 
    GL_EXT_vertex_array, GL_EXT_vertex_array_bgra, 
    GL_IBM_multimode_draw_arrays, GL_IBM_rasterpos_clip, 
    GL_IBM_texture_mirrored_repeat, GL_INGR_blend_func_separate, 
    GL_KHR_context_flush_control, GL_KHR_debug, GL_KHR_no_error, 
    GL_KHR_texture_compression_astc_ldr, 
    GL_KHR_texture_compression_astc_sliced_3d, GL_MESA_pack_invert, 
    GL_MESA_shader_integer_functions, GL_MESA_texture_signed_rgba, 
    GL_MESA_window_pos, GL_MESA_ycbcr_texture, GL_NV_blend_square, 
    GL_NV_conditional_render, GL_NV_depth_clamp, GL_NV_fog_distance, 
    GL_NV_light_max_exponent, GL_NV_packed_depth_stencil, 
    GL_NV_primitive_restart, GL_NV_texgen_reflection, 
    GL_NV_texture_env_combine4, GL_NV_texture_rectangle, GL_OES_EGL_image, 
    GL_OES_read_format, GL_S3_s3tc, GL_SGIS_generate_mipmap, 
    GL_SGIS_texture_border_clamp, GL_SGIS_texture_edge_clamp, 
    GL_SGIS_texture_lod, GL_SUN_multi_draw_arrays

OpenGL ES profile version string: OpenGL ES 3.0 Mesa 18.3.6
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00
OpenGL ES profile extensions:
    GL_ANGLE_texture_compression_dxt3, GL_ANGLE_texture_compression_dxt5, 
    GL_APPLE_texture_max_level, GL_EXT_base_instance, 
    GL_EXT_blend_func_extended, GL_EXT_blend_minmax, 
    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_map_buffer_range, GL_EXT_multi_draw_arrays, 
    GL_EXT_occlusion_query_boolean, GL_EXT_polygon_offset_clamp, 
    GL_EXT_read_format_bgra, GL_EXT_separate_shader_objects, 
    GL_EXT_shader_integer_mix, GL_EXT_texture_border_clamp, 
    GL_EXT_texture_compression_dxt1, GL_EXT_texture_compression_s3tc, 
    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_KHR_context_flush_control, GL_KHR_debug, 
    GL_KHR_no_error, 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_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_image_external_essl3, 
    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_get_program_binary, GL_OES_mapbuffer, GL_OES_packed_depth_stencil, 
    GL_OES_required_internalformat, GL_OES_rgb8_rgba8, 
    GL_OES_standard_derivatives, GL_OES_stencil8, GL_OES_surfaceless_context, 
    GL_OES_texture_3D, GL_OES_texture_border_clamp, 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_vertex_array_object, 
    GL_OES_vertex_half_float

270 GLX Visuals
Which with my luck is based on software rendering. Using llvmpipe isn't good. Mesa I think is sometimes hardware but mostly software, I think it just tries to get the job done however it has to do it. If it can find hardware and drivers it uses them.

back2future
Posts: 271
Joined: Sun Jul 23, 2017 3:19 pm
languages_spoken: english
Has thanked: 12 times
Been thanked: 6 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by back2future » Sat Dec 07, 2019 1:54 am

What is found with linux-vdso.so.#
"The "vDSO" (virtual dynamic shared object) is a small shared library
that the kernel automatically maps into the address space of all
user-space applications. Applications usually do not need to concern
themselves with these details as the vDSO is most commonly called by
the C library. This way you can code in the normal way using
standard functions and the C library will take care of using any
functionality that is available via the vDSO.

etc."

If libm.so is included in ldd output for a graphics driver library it's a pointer to higher shares of cpu side/"software" rendering?

Chromium chrome://gpu/ x64 example

Code: Select all

Graphics Feature Status
Canvas: Hardware accelerated
Flash: Hardware accelerated
Flash Stage3D: Hardware accelerated
Flash Stage3D Baseline profile: Hardware accelerated
Compositing: Hardware accelerated
Metal: Disabled
Multiple Raster Threads: Enabled
Out-of-process Rasterization: Disabled
Hardware Protected Video Decode: Unavailable
Rasterization: Software only. Hardware acceleration disabled
Skia Renderer: Disabled
Surface Control: Disabled
Surface Synchronization: Enabled
Video Decode: Unavailable
Viz Service Display Compositor: Enabled
Viz Hit-test Surface Layer: Disabled
WebGL: Hardware accelerated
WebGL2: Hardware accelerated
edit: Wayland (gpu drivers -> vendor-independent API) vs. 30 yrs. X11
Are developers disappointed?
[Trackers consume attention and rise energy demand?]
Last edited by back2future on Sat Dec 07, 2019 9:29 pm, edited 5 times in total.

glenswada
Posts: 10
Joined: Sun Sep 01, 2019 3:19 pm
languages_spoken: english
ODROIDs: Odroid N2
Has thanked: 2 times
Been thanked: 1 time
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by glenswada » Sat Dec 07, 2019 11:24 am

Nice writeup odroidn2user, thanks for breakdown. Yes agree Odroid N2 is a powerhouse. The N2 makes a very good server (nginx, dbms using MariaDB etc) and as a personal desktop, they not too bad at all. I have been developing on a N2 as my mainstream desktop for last few months (rarely turning on my I7-3770) and its performed great. Its value for performance is simply unmatched.

But I can also understand why some people need gpu performance in linux desktop and getting impatient waiting for something to happen. Perhaps people need accept that if ARM as a private company don't want to support linux with X11 drivers. Thats the end of the story. The reverse engineered drivers, if they ever appear, are not guaranteed to perform, to anyones expectations.

For this and other reasons I feel open source risc-v will eventually dominate the RISC market. By the time ARM management realize their lost opportunities, it will be far too late. Hopefully alibaba's new RISC-V, the 16 core Xuantie 910 (said to be open-sourced to global developers) will soon enter production. If its priced right, why would anyone want an ARM with its ever silent gpu.

I love the value that harkenel provides to their customors. If they can get on the risc-v bandwagon. I will definately be one to join crowdfunding etc. to help make it a reality.

User avatar
rooted
Posts: 7259
Joined: Fri Dec 19, 2014 9:12 am
languages_spoken: english
Location: Gulf of Mexico, US
Has thanked: 452 times
Been thanked: 127 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by rooted » Sat Dec 07, 2019 11:36 am

The XU4 is a better desktop device overall, just that it's limited to 2GB of RAM.

odroidn2user
Posts: 108
Joined: Fri Oct 25, 2019 4:14 pm
languages_spoken: english
ODROIDs: N2
Has thanked: 24 times
Been thanked: 19 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by odroidn2user » Sat Dec 07, 2019 8:29 pm

glenswada wrote:
Sat Dec 07, 2019 11:24 am
Nice writeup odroidn2user, thanks for breakdown. Yes agree Odroid N2 is a powerhouse. The N2 makes a very good server (nginx, dbms using MariaDB etc) and as a personal desktop, they not too bad at all. I have been developing on a N2 as my mainstream desktop for last few months (rarely turning on my I7-3770) and its performed great. Its value for performance is simply unmatched.
Indeed, it is a powerhouse, just not for desktops. If you want a desktop, at the moment you still have to look elsewhere. And as you, i've been trying to get the work done on the N2 instead of an I5, and it's do-able, just don't watch video and don't do any graphics.
glenswada wrote:
Sat Dec 07, 2019 11:24 am
But I can also understand why some people need gpu performance in linux desktop and getting impatient waiting for something to happen. Perhaps people need accept that if ARM as a private company don't want to support linux with X11 drivers. Thats the end of the story. The reverse engineered drivers, if they ever appear, are not guaranteed to perform, to anyones expectations.
Well, that if is not an if. That has already happened. ARM does not and will not support X11 on the Bifrost line. They made clear they just don't support Linux desktop use anymore. The money is in Android, not Linux desktops, so there. They have made a clear choice.

But: They do have a 'vision', and that is Wayland. The thing is, even after all those years, it just doesn't quite seem to come together in a smoothly working way. There is the Fedora 31 Wayland thing, where their ARM desktop seems completely based on Wayland, which gives us some hope for N2. Now, Fedora 31 doesn't work on N2, from what I understand, but at least that route seems a good plan for us on the N2 as ARM does do Wayland drivers.

The problem is, 'we' are continually shooting ourselves in the foot, here. Just when we get near to a real alternative, we shift gears and put 'ourselves' years and years back. We get to desktop level performance, but then we pull software support. Then when software support almost arrives, we focus on RISC. Thereby we keep prolonging the reliance on Wintel for decades, we should have had all this years and years ago. But no.

It's Linux as well, though, let's overhaul the complete audio-stack so no-one will have good working audio for years, good idea! Let's overhaul the complete init deamon so boot-up gets broken everywhere, good idea! Let's overhaul the V4L interfaces so no-one will be playing video for years, good idea!
glenswada wrote:
Sat Dec 07, 2019 11:24 am
For this and other reasons I feel open source risc-v will eventually dominate the RISC market. By the time ARM management realize their lost opportunities, it will be far too late. Hopefully alibaba's new RISC-V, the 16 core Xuantie 910 (said to be open-sourced to global developers) will soon enter production. If its priced right, why would anyone want an ARM with its ever silent gpu.
Look, I like what I hear about RISC-V. Sounds wonderful, excellent proposition for the future. The problem is, last time I checked, it's years away for a cheap Linux workstation a la the N2 without all the "US agencies" in it at both the hardware level and the software level. Whereas we could easily have had a semi-powerful Linux workstation with the Odroid based on ARM right now. But no, and instead of getting the shit sorted out and actually getting what we want as a community, we have to drop Linux support and start over again. And then we have to pivot to RISC and start from scratch all over again. That is a losing deal, plain and simple, it's just busywork, getting us nowhere fast and keeping us firmly in the US Wintel playing arena. And I fully trust Alibaba to substitute "US Agencies" in the hardware and software stack with "Chinese and US agencies" in the hardware and software stack, so not sure how that is progress.
glenswada wrote:
Sat Dec 07, 2019 11:24 am
I love the value that harkenel provides to their customors. If they can get on the risc-v bandwagon. I will definately be one to join crowdfunding etc. to help make it a reality.
Indeed, I love what hardkernel is doing as well, excellent hardware. But software wise, they are dropping the ball on this. Perhaps that software ball is just too heavy to lift, could well be, but they are just not delivering a working Linux environment for their device. They have all kinds of promises about the hardware, but not delivering on it.

Because, it seems to me we could well have a working Wayland image for N2 for months, but for reasons unknown (very likely it's just available man-hours) it is just not materializing. The reliance on individuals spending their spare time getting something going is just not a way to go, that's good for select enthusiasts but not a way forward. Hardkernel probably does what it can, and that *is* much appreciated, but that doesn't bring the potential of the N2 to customers.

I see the same with the RockPro64 from Pine64. So, it's probably not Hardkernel or Pine64 specifically, but it's just devices that don't function up to their potential. Pine64 has some hardware acceleration, but it's by volunteer effort and effectively broken. So, ARM *really* doesn't want Linux on their hardware, not really. We read that loud and clear.

Now, largely from the Arch / Manjaro ARM community, as far as I can see, we are still getting somewhere near something that should function at some point, for enthusiasts. But if and when and how that'll work... As you say: "The reverse engineered drivers, if they ever appear, are not guaranteed to perform, to anyones expectations." Indeed, and that seems to be the case. And: That is a lousy bet for the future. However, given ARMs excellent ability to break software support for their own hardware, it's probably all we are going to get. But: given the expertise of all the other people contributing to the Meson and Panfrost drivers, I certainly am still hopeful!

But... yeah, in the mean time we keep shooting ourselves in the foot and HardKernel just isn't delivering any real Linux support for the N2 device they are selling as of yet. But who knows what Ubuntu 20.04 will bring. We can always be hopeful. It's been awfully quiet though from official channels and new images and previews just aren't showing.
These users thanked the author odroidn2user for the post:
glenswada (Sun Dec 08, 2019 5:18 am)

odroidn2user
Posts: 108
Joined: Fri Oct 25, 2019 4:14 pm
languages_spoken: english
ODROIDs: N2
Has thanked: 24 times
Been thanked: 19 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by odroidn2user » Sat Dec 07, 2019 8:47 pm

rooted wrote:
Sat Dec 07, 2019 11:36 am
The XU4 is a better desktop device overall, just that it's limited to 2GB of RAM.
2GB does not a working desktop make, even 4GB just barely. And besides that, the average smartphone these days has more memory and processor and graphics power than the XU4 and N2 combined.

back2future
Posts: 271
Joined: Sun Jul 23, 2017 3:19 pm
languages_spoken: english
Has thanked: 12 times
Been thanked: 6 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by back2future » Sat Dec 07, 2019 9:43 pm

It is interesting looking at Fedora's Rockchip support:
https://fedoraproject.org/wiki/Architec ... hromebooks

[ Many people are clueless, that ARM (Acorn,Apple,VLSI Tech,Nippon Invest and Finanance->2016: Softbank) is a company defining their mobile SoCs and even less interested what's ARM's software roadmap.
They like apps and that's Android (Google).
"it has over two billion monthly active users", "In the third quarter of 2016, Android's share of the global smartphone shipment market was 87.5%"
"The main benefits of using Bionic instead of the GNU C Library (glibc) or uClibc are its smaller runtime footprint, and optimization for low-frequency CPUs. At the same time, Bionic is licensed under the terms of the BSD licence, which Google finds more suitable for the Android's overall licensing model." ]
Last edited by back2future on Sun Dec 08, 2019 6:16 am, edited 2 times in total.

ab1jx
Posts: 97
Joined: Wed Jul 10, 2019 8:25 am
languages_spoken: english
Has thanked: 8 times
Been thanked: 3 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by ab1jx » Sat Dec 07, 2019 11:29 pm

I think it's time to boycott ARM and look elsewhere. Unfortunately you can't just unplug the Mali and plug in a different GPU. TI for one has some stuff, haven't considered them in a while. And what would be wrong with putting an SODIMM socket or two on the board maybe in addition to 4 GB in the SOC?

RISC, didn't we do that 20 years ago? I remember setting up a Windows NT webserver for somebody on a RISC machine. It was the up and coming thing then but it never amounted to anything.

Maybe it's time for phone CPU/GPUs and desktop CPU/GPUs to walk 2 different paths again. Cell phones with millions of them sold is a formidable amount of buying power, but I'm not going to let ARM cram Wayland down my throat before it's ready. I like the 40 years of history behind X11. Yes, there's a lot than can be left out like colormaps and stippled backgrounds but I think the structure is flexible enough to allow for that. And in 10 or 20 years maybe Wayland will be useful.

User avatar
mad_ady
Posts: 7347
Joined: Wed Jul 15, 2015 5:00 pm
languages_spoken: english
ODROIDs: XU4, C1+, C2, N1, H2, N2, Go, Go Advance
Location: Bucharest, Romania
Has thanked: 350 times
Been thanked: 252 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by mad_ady » Sun Dec 08, 2019 1:27 am

RISC, didn't we do that 20 years ago?
ARM processors are also RISC.

Tvan
Posts: 15
Joined: Sun Jul 21, 2019 8:35 am
languages_spoken: english
ODROIDs: xu4,hc2,n2
Has thanked: 0
Been thanked: 4 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by Tvan » Sun Dec 08, 2019 1:53 am

Wayland is the new X. And not just for the arm platform.

odroidn2user
Posts: 108
Joined: Fri Oct 25, 2019 4:14 pm
languages_spoken: english
ODROIDs: N2
Has thanked: 24 times
Been thanked: 19 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by odroidn2user » Sun Dec 08, 2019 5:06 am

ab1jx wrote:
Sat Dec 07, 2019 11:29 pm
I think it's time to boycott ARM and look elsewhere. Unfortunately you can't just unplug the Mali and plug in a different GPU.
Well, boycotting is the negative approach, doesn't do anything for anyone, so that's almost never a good solution. Looking for better alternatives and weighing options is always good.
ab1jx wrote:
Sat Dec 07, 2019 11:29 pm
TI for one has some stuff, haven't considered them in a while. And what would be wrong with putting an SODIMM socket or two on the board maybe in addition to 4 GB in the SOC?

RISC, didn't we do that 20 years ago? I remember setting up a Windows NT webserver for somebody on a RISC machine. It was the up and coming thing then but it never amounted to anything.
Well, RISC itself is OK and clearly winning compared to the CISC alternatives. And RISC-V as a platform has a nice future, but is not currently a viable alternative. And I really don't know what TI is bringing to the table currently (note to self: research) Instead of boycotting, let's just look at alternatives and weigh options. I don't really see a whole lot better for my goals than Odroid N2 currently. Especially if they can get the graphics and video side sorted, this thing is indeed a powerhouse and might even be an industry game changer - as someone else explained on this forum very eloquently.
ab1jx wrote:
Sat Dec 07, 2019 11:29 pm
Maybe it's time for phone CPU/GPUs and desktop CPU/GPUs to walk 2 different paths again. Cell phones with millions of them sold is a formidable amount of buying power, but I'm not going to let ARM cram Wayland down my throat before it's ready. I like the 40 years of history behind X11. Yes, there's a lot than can be left out like colormaps and stippled backgrounds but I think the structure is flexible enough to allow for that. And in 10 or 20 years maybe Wayland will be useful.
Well, Fedora has been shipping a very nicely working Wayland for years now. And Mutter/Gnome3 based on Wayland really does seems to be quite OK. Clearly there are issues that are really tricky to sort out, but it's definitely a workable solution. Yes X11 has some nice history, but there are clear reasons why they started working the Wayland route. And indeed, sad to say: it does have a nice 'shooting ourselves in the foot' vibe going. ARM really sabotaged desktop Linux by pulling their X11 support. It seems they don't want to see Desktop Linux happening any time soon. But Fedora shows Wayland can be made to work.

Also, there might be technical reasons why phone CPU/GPU's can't work as desktops, there are some clearly different goals for phones compared to workstations. But I don't really think there are technical reasons stopping desktop use of phone hardware. It really is not that different, computing is computing, there are some different connectors and such, but based on recent examples (such as Chromebooks and even the Odroid N2) it is clearly possible. And even stronger than that: both Apple and Microsoft are now preparing/going for RISC processors in desktop-like products. CISC based Intel and AMD's are quickly losing ground. Apple is building their own ARMs for near-future macOS products and Microsoft really pushes for Qualcomm ARM laptops now.

There are software challenges due to the way GNU/Linux works, but really that doesn't mean phone hardware isn't capable of being used as a desktop. Look at Dex, for example. It's just getting the software going, and it really is not that tricky. But if you don't have any company investing in Desktop Linux on ARM ... well, then it isn't happening.

But we do have Collabora with Panfrost, the Meson contributors are hard at work, and Hardkernel is working on things as well, no doubt, and who knows what ARM might still pull out of their hat with Wayland. Let's just wait and see what happens with the Meson DRM, Wayland drivers and Wayland. We should be able to put together a really nice image, the puzzle pieces seem to be ready. It's really now just a question of time and effort. It really is nearly there.

glenswada
Posts: 10
Joined: Sun Sep 01, 2019 3:19 pm
languages_spoken: english
ODROIDs: Odroid N2
Has thanked: 2 times
Been thanked: 1 time
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by glenswada » Sun Dec 08, 2019 9:48 am

odroidn2user wrote:
Sat Dec 07, 2019 8:29 pm
glenswada wrote:
Sat Dec 07, 2019 11:24 am
Indeed, I love what hardkernel is doing as well, excellent hardware. But software wise, they are dropping the ball on this. Perhaps that software ball is just too heavy to lift, could well be, but they are just not delivering a working Linux environment for their device. They have all kinds of promises about the hardware, but not delivering on it.
Personally I dont believe hardkernel should have anything to do with gpu drivers. All the sbc vendors would end up expend money duplicating each others work. Result in much higher end cost to the buyer. The responsibility for writing drivers should remain with the cpu manufacturer. With cost shared by all the vendors equally from buying slightly more expensive cpu's. You wouldn't want see MS writing NVIdia drivers would you? Neither would NVIdia, funny enough!
Look, I like what I hear about RISC-V. Sounds wonderful, excellent proposition for the future. The problem is, last time I checked, it's years away for a cheap Linux workstation a la the N2
Agree. But creating linux graphic drivers for arm might also drag into years. When you have companies like Think Silicon demonstating the performance of their risc-v gpu next week ... https://think-silicon.com/2019/12/02/th ... -v-summit/ with support for OpenGL, ES and Vulkan, The linux community could become very enthusiastic with the opensource nature of risc-v.

The thing is ARM is making over a billion dollars each year in profits. Yet can't employ a few software engineers to develop gpu drivers for linux. Perhaps as a community we should write a letter to each of the board members of ARM explaining why its in their best interest to do so.

User avatar
rooted
Posts: 7259
Joined: Fri Dec 19, 2014 9:12 am
languages_spoken: english
Location: Gulf of Mexico, US
Has thanked: 452 times
Been thanked: 127 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by rooted » Sun Dec 08, 2019 10:06 am

A true desktop ARM device is coming from Huawei:

https://wccftech.com/huawei-preps-deskt ... m-v8-cpus/

stmicro
Posts: 251
Joined: Tue Apr 28, 2015 4:23 pm
languages_spoken: english, chinese
ODROIDs: Many Odroids and Rpis.
Location: shenzhen china
Has thanked: 0
Been thanked: 1 time
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by stmicro » Sun Dec 08, 2019 11:31 am

I don't think ARM platforms can do that in near future.
My oDroid H2 runs well Vulkan GPU driver on Wayland with Kernel 5.4 smoothly. If H2 price is $100 including 4GB RAM+32GB eMMC, it will be a nice SBC you guys are looking for. But I spent near $200 for H2 + 8GB RAM + Case2 + 256GB NVMe + Shipping.

odroidn2user
Posts: 108
Joined: Fri Oct 25, 2019 4:14 pm
languages_spoken: english
ODROIDs: N2
Has thanked: 24 times
Been thanked: 19 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by odroidn2user » Sun Dec 08, 2019 5:40 pm

stmicro wrote:
Sun Dec 08, 2019 11:31 am
I don't think ARM platforms can do that in near future.
My oDroid H2 runs well Vulkan GPU driver on Wayland with Kernel 5.4 smoothly. If H2 price is $100 including 4GB RAM+32GB eMMC, it will be a nice SBC you guys are looking for. But I spent near $200 for H2 + 8GB RAM + Case2 + 256GB NVMe + Shipping.
I think a lot of people (including me) would rather leave the intel/amd companies behind, at this point, for all kinds of valid reasons. Technically, x86 is nearing its end. It has some future like high end gaming equipment, but RISC/ARM is to be taking over for all the rest. And it shows, with hardware and software vulnerabilities (largely by design) now showing left and right. So x86 is perhaps not wanted.

Huawei has some potential and some awesome products, but internationally they have a hard time convincing we aren't exchanging US agencies with Chinese *and* US agencies (government, intelligence and linked organisations) baked inside the products. So, not sure how well Chinese government (linked) organisations like Huawei will be a solution for people wanting some normal privacy back on their own computers...

So, I'm done with all that. I choose not to choose that, I choose something else. And it looks like SBCs like the Odroids might just be the thing, but not when they add Intel(ligence) x86 technology into it. So: no thanks to the H2. I like me some ownership and privacy.
Last edited by odroidn2user on Sun Dec 08, 2019 8:06 pm, edited 10 times in total.

odroidn2user
Posts: 108
Joined: Fri Oct 25, 2019 4:14 pm
languages_spoken: english
ODROIDs: N2
Has thanked: 24 times
Been thanked: 19 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by odroidn2user » Sun Dec 08, 2019 6:03 pm

glenswada wrote:
Sun Dec 08, 2019 9:48 am
Personally I dont believe hardkernel should have anything to do with gpu drivers. All the sbc vendors would end up expend money duplicating each others work. Result in much higher end cost to the buyer. The responsibility for writing drivers should remain with the cpu manufacturer. With cost shared by all the vendors equally from buying slightly more expensive cpu's. You wouldn't want see MS writing NVIdia drivers would you? Neither would NVIdia, funny enough!
Hmm, good point. Hardkernel shouldn't have to. They should however supply a driver with the hardware to use the hardware. And there is, and they are, it's just not working right. You can't expect the user to fix it for themselves, so they have a shared responsibility to at least deliver the driver with a platform where the hardware they sell actually works. All these SBC-boards are different, so, it isn't like Windows and Nvidia where you download the drivers from the Nvidia site and off you go.
glenswada wrote:
Sun Dec 08, 2019 9:48 am
But creating linux graphic drivers for arm might also drag into years. When you have companies like Think Silicon demonstating the performance of their risc-v gpu next week ... https://think-silicon.com/2019/12/02/th ... -v-summit/ with support for OpenGL, ES and Vulkan, The linux community could become very enthusiastic with the opensource nature of risc-v.
Yeah, RISC-V has plenty potential. And will check out the link and demonstration for sure. And this ARM graphic thing might indeed, drag into years. We're well underway. That said, it doesn't have to, it looks to me like we have (almost) all the pieces available here. There is a VPU with CoreElec, there is GPU graphics acceleration using the 4.9 kernel, there is Wayland drivers, there is now with 5.4 mainline kernel DRM support for almost everything... It's just fitting them together right. And I'm afraid that's beyond my level of knowledge and available spare time as an enthusiast. But that should not be beyond the level of knowledge of Hardkernel. But I fully imagine they don't have time available for this either.

So, yeah, who knows. Perhaps RISC-V is a quicker solution in the end :) That said, RISC-V is a new platform, so we're very likely further back than with the N2. With Manjaro ARM, to me: this thing is all kinds of awesome already! And it can be even better, and that's just .... so close!
glenswada wrote:
Sun Dec 08, 2019 9:48 am
The thing is ARM is making over a billion dollars each year in profits. Yet can't employ a few software engineers to develop gpu drivers for linux. Perhaps as a community we should write a letter to each of the board members of ARM explaining why its in their best interest to do so.
Yeah, they just don't want to support Linux on the Desktop, for some reason. And I can think of some good reasons for why the IT industry does not want a real good Linux desktop alternative. In fact, I see billions of reasons as to why this isn't materializing into something fully awesome.

But then they do deliver a Wayland driver and... that's proven useless for the past (3/4 of a) year. I mean: ARM should do it not at all (scrap the Wayland modules and call it quits for Linux in general) or deliver something that actually works. And we don't get something that works. So, why pretend? I still see it as Hardkernel's responsibility to deliver something with a working Wayland driver. Then enthusiasts can work with that and improve on it. But in absence of Hardkernel showing that their N2 board works with Wayland, they are leaving it up to Manjaro / Arch / Armbian to basically do the heavy lifting for them.

Look, I like hardkernel and I like the odroid N2. It is an awesome product, well thought out, well built, and it shows lots of potential, just finish the finishing touches! And it seems to me that tobetter and memeka and others here are doing just that! It's just waiting for things is never that much fun :)
These users thanked the author odroidn2user for the post:
glenswada (Mon Dec 09, 2019 8:46 am)

Nuems
Posts: 134
Joined: Thu Sep 19, 2013 3:50 am
languages_spoken: english, german
ODROIDs: xu, c1
Has thanked: 0
Been thanked: 2 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by Nuems » Mon Dec 09, 2019 3:09 am

ARM won't call it quits for Linux as long as Android uses a Linux kernel. And as a rule, graphics and media drivers for Android work well - but they aren't necessarily mainline and might include proprietary binary blobs. It boils down the simple truth that there are a few thousand customers for a particular SBC, but possibly millions for smartphones and tablets.

User avatar
mad_ady
Posts: 7347
Joined: Wed Jul 15, 2015 5:00 pm
languages_spoken: english
ODROIDs: XU4, C1+, C2, N1, H2, N2, Go, Go Advance
Location: Bucharest, Romania
Has thanked: 350 times
Been thanked: 252 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by mad_ady » Mon Dec 09, 2019 4:57 am

Why isn' the other way around fesable? Running the android graphical stack on linux and writing a translation layer between X11 and the framebuffer, or whatever android uses? Too much overhead and too little performance?

User avatar
rooted
Posts: 7259
Joined: Fri Dec 19, 2014 9:12 am
languages_spoken: english
Location: Gulf of Mexico, US
Has thanked: 452 times
Been thanked: 127 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by rooted » Mon Dec 09, 2019 5:14 am

mad_ady wrote:Why isn' the other way around fesable? Running the android graphical stack on linux and writing a translation layer between X11 and the framebuffer, or whatever android uses? Too much overhead and too little performance?
I think this has been done before but I can't remember what it's called.

crashoverride
Posts: 4716
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1
Has thanked: 0
Been thanked: 191 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by crashoverride » Mon Dec 09, 2019 9:17 am

rooted wrote:
Mon Dec 09, 2019 5:14 am
I think this has been done before but I can't remember what it's called.
https://en.wikipedia.org/wiki/Hybris_(software)
Hybris or libhybris is a compatibility layer for computers running Linux distributions based on the GNU C library or Musl,[3] intended for using software written for Bionic-based Linux systems, which mainly includes Android libraries and device drivers.
These users thanked the author crashoverride for the post (total 2):
rooted (Mon Dec 09, 2019 11:10 am) • mad_ady (Mon Dec 09, 2019 3:15 pm)

User avatar
rooted
Posts: 7259
Joined: Fri Dec 19, 2014 9:12 am
languages_spoken: english
Location: Gulf of Mexico, US
Has thanked: 452 times
Been thanked: 127 times
Contact:

Re: Demystifying Odroid N2 hardware acceleration

Unread post by rooted » Mon Dec 09, 2019 11:10 am

crashoverride wrote:
rooted wrote:
Mon Dec 09, 2019 5:14 am
I think this has been done before but I can't remember what it's called.
https://en.wikipedia.org/wiki/Hybris_(software)
Hybris or libhybris is a compatibility layer for computers running Linux distributions based on the GNU C library or Musl,[3] intended for using software written for Bionic-based Linux systems, which mainly includes Android libraries and device drivers.
That's the one, thank you.

Oddly enough I was about to PM you and see how you are and what have you been up to, your knowledge and rare snark is missed.

Post Reply

Return to “General Topics”

Who is online

Users browsing this forum: No registered users and 0 guests