i cannot find out mali g72 driver
where is the driver?
it is very important to me.
please teach me. T T
i faced some problem maybe it is related to graphic driver…
There is currently no Mali G72 driver available.
I came across this on the smartfire website.
For the support of Mali G72, you can try to install opencl. The following links are for the Hikey 960 and Mali G71, but I feel it can be used on the 970: https://developer.arm.com/produc … -drivers/user-space .
Download mali-G71_r9p0-01rel0_linux_1fbdev.tar.gz, extract it to /opt, add the file opencl.cconf in the /etc/ld.so.conf.d/ directory, the content is /opt/fbdev, then run sudo ldconfig .
The possible problem is that there is no implementation for functions such as clCreateFromGL*.
This is the problem I posted on the arm forum, but no one answered at this time: https://community.arm.com/graphi … -hikey970-mali-g72#
http://smartfire.cn/forum-64-1.html
I will be trying to build the driver soon also.
I also remember reading somewhere that the Tensorflow Release of Debain from hikey includes the Mali driver. Maybe we can use that but i have to find it again.
Hi I really thank you for reply but i think my problem is releated to Opengl. T.T
it is related to “https://discuss.96boards.org/t/i-faced-some-gpu-problem-on-gaming/7201/3”
above link
so my question is… Do it related to my problem? i really have curiosity about this
Thank you for reading!
I did see your problem in a post before.
I thought you posted that using a 12v 3A power supply it solved your issue.
I don’t have any Idea what is causing you trouble. I would set up a serial console and look at the messages. I have had some thermal issues when running the board hard which is surprising to me because i have added extra heatsinks and 4 fans total.
I believe the heat problem may be due to the current heat-sink not sitting properly on the chips.
The chip that is not numbered next to the processor #10 is shorter than the Processor. So the flat heat-sink requires thicker Thermal Paste to allow the heat-sink to sit flat on the processor.
I am going to make a custom heat-sink that is stepped to match the height of the chips and also cover the wlan chip. I will post my design when i’m done.
Have you checked the temp of the processor during your hard runs?
Actually i didn’t
but i think it is not related to power resource problem and heat problem
and I already solved the issue
this issue is related to weird diagonals on display when i play game (maybe opengl 3.x issue with driver i have no confidence)
so i think it is not related heat problem.
so i really want to find out right driver…T.T
Here is the link to the Lebain that i believe has Tensorflow and opencl.
LeMaker has released a new Lebian that includes pre-installed tensorflow, which includes opencl
Http://mirror.lemaker.org/hikey970-lebian-9.tar.gz
Maybe you can use lebain-9. Other than that I think it is a matter of mounting the image in a Linux environment and copying out the driver. At any rate we can pull the kernel configuration, check for any related modules, and copy the userspace binary Mali driver. I have to look into it more.
It seems LeMaker had the source to build the Lebain-9 with Mali and opencl maybe we can send them a message and see if it is possible for LeMaker to share that source Code with us.
This is the EXACT place i found the image.
https://translate.google.com/translate?hl=en&sl=zh-CN&u=https://blog.csdn.net/bluewhalerobot/article/details/82343784&prev=search
In the lebian-9 tensorflow there is OpenCL which in turn loads libmali.so.
there is a possibility that this can be used for accelerated GLES under fbdev.
It’s been quite a while since the release of the Hikey970. No real support has been shown by neither hikey nor hisilicon. Apparently they leave the opensource community with an impossible task of getting drivers for the hardware inside the board. It is quite a dissapointment to spend money on a board and to intend to develop on it but to find out it has been yet another piece of abandonware.
Where are the days that companies took pride in making an effort to make things work.
The board in its current state is no more practical than an ordinary raspberry pi. It’s supposed to have great GPU and NPU but alas it’s inaccessable. Is this the way to treat your customers? promises but no real delivery? I am very disapponted. (and that is an understatement) When the board became available I ordered one immediately. It said ‘comes with Linux installed.’ But only at delivery it appeared that Android was running and no Linux available. After long waits a crippled Debian image is delivered that lacks drivers for the board. I had already installed debian on mine with the aarch64 repo from debian.org and hoped that the hikey970 debian image would be a serious upgrade. but no, it appears to be exactly the same, no drivers no nothing. If they can build an fbdev driver it means that they have the SDK up and running. They only need to re run a compile with the proper settings for X11 and release the binary to the public. But no, no developer shows up on the support forum nor any binary shows up. Is this plain disregard for the customers who put up their hard earned cash to buy the board? We really can’t tell but clearly they don’t care.
Dear Hikey and Hisilicon,
I would like to request some decent support on this board and a release of drivers for the hardware.
If you are not interested in giving support then please have the decency to reimburse my spending on the board and the time invested.
Best regards,
Jan Rinze.
The mali Driver is available.
It seems it will take a few of us to get everything running smoothly.
I am just a individual Learning what i can as i go.
If everything was done for us I don’t think I would enjoy it as much. I’m more than sure if you ask specific questions relating to specific problems someone will help.
I have a pretty big project started myself.
I am scripting the complete Ubuntu Bionic & Kernel & Drivers into a interactive builder that i am calling the Bionic Builder. Maybe once i have completed it you can test it out and see if you feel a little better.
If a few of us that are halfway knowledgeable got together as a group and worked through fixing issues we could accomplish a lot. I think part of the problem is that the information regarding many issues is scattered about. Answers are out there you just have to find them.
When i Initially purchased the hikey 970 I had hoped that the software and drivers were more mature. But when you buy a development board thats what you get A Dev Board made for developing.
When I get a little further along I will share my work with everyone.
I hope to have something good together within about a week.
Again though I am just a ordinary guy. So don’t expect miracles. But i have fixed some of the issues.
6.The latest Lebian from Lemaker has delivered userspace binary driver for G72. The binary library is /usr/lib/aarch64-linux-gnu/libmali.so. By installing the pocl, two OpenCL platforms can be found on Hikey 970. (Notice that Mali-G72 does not support cl_khr_fp64. )
./clinfo
Found 2 platform(s).
*******************0th platform******************************
platform[0xcd5c490]: profile: FULL_PROFILE
platform[0xcd5c490]: version: OpenCL 2.0 v1.r10p0-01rel0.e990c3e3ae25bde6c6a1b96097209d52
platform[0xcd5c490]: name: ARM Platform
platform[0xcd5c490]: vendor: ARM
platform[0xcd5c490]: extensions: cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_byte_addressable_store cl_khr_3d_image_writes cl_khr_int64_base_atomics cl_khr_int64_extended_atomics cl_khr_fp16 cl_khr_icd cl_khr_egl_image cl_khr_image2d_from_buffer cl_khr_depth_images cl_arm_core_id cl_arm_printf cl_arm_thread_limit_hint cl_arm_non_uniform_work_group_size cl_arm_import_memory cl_arm_shared_virtual_memory
platform[0xcd5c490]: Found 1 device(s).
------------------------0th device------------------------
device[0xcdbc7f0]: NAME: Mali-G72
device[0xcdbc7f0]: VENDOR: ARM
device[0xcdbc7f0]: PROFILE: FULL_PROFILE
device[0xcdbc7f0]: VERSION: OpenCL 2.0 v1.r10p0-01rel0.e990c3e3ae25bde6c6a1b96097209d52
device[0xcdbc7f0]: EXTENSIONS: cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_byte_addressable_store cl_khr_3d_image_writes cl_khr_int64_base_atomics cl_khr_int64_extended_atomics cl_khr_fp16 cl_khr_icd cl_khr_egl_image cl_khr_image2d_from_buffer cl_khr_depth_images cl_arm_core_id cl_arm_printf cl_arm_thread_limit_hint cl_arm_non_uniform_work_group_size cl_arm_import_memory cl_arm_shared_virtual_memory
device[0xcdbc7f0]: DRIVER_VERSION: 2.0
device[0xcdbc7f0]: Type: GPU
device[0xcdbc7f0]: EXECUTION_CAPABILITIES: Kernel
device[0xcdbc7f0]: GLOBAL_MEM_CACHE_TYPE: Read-Write (2)
device[0xcdbc7f0]: CL_DEVICE_LOCAL_MEM_TYPE: Global (2)
device[0xcdbc7f0]: SINGLE_FP_CONFIG: 0x3f
device[0xcdbc7f0]: QUEUE_PROPERTIES: 0x3
device[0xcdbc7f0]: VENDOR_ID: 1646329857
device[0xcdbc7f0]: MAX_COMPUTE_UNITS: 12
device[0xcdbc7f0]: MAX_WORK_ITEM_DIMENSIONS: 3
device[0xcdbc7f0]: MAX_WORK_GROUP_SIZE: 384
device[0xcdbc7f0]: PREFERRED_VECTOR_WIDTH_CHAR: 16
device[0xcdbc7f0]: PREFERRED_VECTOR_WIDTH_SHORT: 8
device[0xcdbc7f0]: PREFERRED_VECTOR_WIDTH_INT: 4
device[0xcdbc7f0]: PREFERRED_VECTOR_WIDTH_LONG: 2
device[0xcdbc7f0]: PREFERRED_VECTOR_WIDTH_FLOAT: 4
device[0xcdbc7f0]: PREFERRED_VECTOR_WIDTH_DOUBLE: 0
device[0xcdbc7f0]: MAX_CLOCK_FREQUENCY: 767
device[0xcdbc7f0]: ADDRESS_BITS: 64
device[0xcdbc7f0]: MAX_MEM_ALLOC_SIZE: 1073741824
device[0xcdbc7f0]: IMAGE_SUPPORT: 1
device[0xcdbc7f0]: MAX_READ_IMAGE_ARGS: 128
device[0xcdbc7f0]: MAX_WRITE_IMAGE_ARGS: 64
device[0xcdbc7f0]: IMAGE2D_MAX_WIDTH: 65536
device[0xcdbc7f0]: IMAGE2D_MAX_HEIGHT: 65536
device[0xcdbc7f0]: IMAGE3D_MAX_WIDTH: 65536
device[0xcdbc7f0]: IMAGE3D_MAX_HEIGHT: 65536
device[0xcdbc7f0]: IMAGE3D_MAX_DEPTH: 65536
device[0xcdbc7f0]: MAX_SAMPLERS: 16
device[0xcdbc7f0]: MAX_PARAMETER_SIZE: 1024
device[0xcdbc7f0]: MEM_BASE_ADDR_ALIGN: 1024
device[0xcdbc7f0]: MIN_DATA_TYPE_ALIGN_SIZE: 128
device[0xcdbc7f0]: GLOBAL_MEM_CACHELINE_SIZE: 64
device[0xcdbc7f0]: GLOBAL_MEM_CACHE_SIZE: 524288
device[0xcdbc7f0]: GLOBAL_MEM_SIZE: 4294967296
device[0xcdbc7f0]: MAX_CONSTANT_BUFFER_SIZE: 65536
device[0xcdbc7f0]: MAX_CONSTANT_ARGS: 8
device[0xcdbc7f0]: LOCAL_MEM_SIZE: 32768
device[0xcdbc7f0]: ERROR_CORRECTION_SUPPORT: 0
device[0xcdbc7f0]: PROFILING_TIMER_RESOLUTION: 1000
device[0xcdbc7f0]: ENDIAN_LITTLE: 1
device[0xcdbc7f0]: AVAILABLE: 1
device[0xcdbc7f0]: COMPILER_AVAILABLE: 1
*******************1th platform******************************
platform[0xffffaa0e7398]: profile: FULL_PROFILE
platform[0xffffaa0e7398]: version: OpenCL 1.2 pocl 1.2 RelWithDebInfo, LLVM 7.0.1, SLEEF, POCL_DEBUG, FP16
platform[0xffffaa0e7398]: name: Portable Computing Language
platform[0xffffaa0e7398]: vendor: The pocl project
platform[0xffffaa0e7398]: extensions: cl_khr_icd
platform[0xffffaa0e7398]: Found 1 device(s).
------------------------0th device------------------------
device[0xcdbcaf0]: NAME: pthread-cortex-a53
device[0xcdbcaf0]: VENDOR: ARM
device[0xcdbcaf0]: PROFILE: FULL_PROFILE
device[0xcdbcaf0]: VERSION: OpenCL 1.2 pocl HSTR: pthread-aarch64--linux-gnueabihf-cortex-a53
device[0xcdbcaf0]: EXTENSIONS: cl_khr_byte_addressable_store cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_3d_image_writes cl_khr_fp16 cl_khr_fp64
device[0xcdbcaf0]: DRIVER_VERSION: 1.2
device[0xcdbcaf0]: Type: CPU
device[0xcdbcaf0]: EXECUTION_CAPABILITIES: Kernel Native
device[0xcdbcaf0]: GLOBAL_MEM_CACHE_TYPE: Read-Write (2)
device[0xcdbcaf0]: CL_DEVICE_LOCAL_MEM_TYPE: Global (2)
device[0xcdbcaf0]: SINGLE_FP_CONFIG: 0x6
device[0xcdbcaf0]: QUEUE_PROPERTIES: 0x2
device[0xcdbcaf0]: VENDOR_ID: 5045
device[0xcdbcaf0]: MAX_COMPUTE_UNITS: 8
device[0xcdbcaf0]: MAX_WORK_ITEM_DIMENSIONS: 3
device[0xcdbcaf0]: MAX_WORK_GROUP_SIZE: 4096
device[0xcdbcaf0]: PREFERRED_VECTOR_WIDTH_CHAR: 16
device[0xcdbcaf0]: PREFERRED_VECTOR_WIDTH_SHORT: 8
device[0xcdbcaf0]: PREFERRED_VECTOR_WIDTH_INT: 4
device[0xcdbcaf0]: PREFERRED_VECTOR_WIDTH_LONG: 2
device[0xcdbcaf0]: PREFERRED_VECTOR_WIDTH_FLOAT: 4
device[0xcdbcaf0]: PREFERRED_VECTOR_WIDTH_DOUBLE: 2
device[0xcdbcaf0]: MAX_CLOCK_FREQUENCY: 1844
device[0xcdbcaf0]: ADDRESS_BITS: 64
device[0xcdbcaf0]: MAX_MEM_ALLOC_SIZE: 2147483648
device[0xcdbcaf0]: IMAGE_SUPPORT: 1
device[0xcdbcaf0]: MAX_READ_IMAGE_ARGS: 128
device[0xcdbcaf0]: MAX_WRITE_IMAGE_ARGS: 128
device[0xcdbcaf0]: IMAGE2D_MAX_WIDTH: 8192
device[0xcdbcaf0]: IMAGE2D_MAX_HEIGHT: 8192
device[0xcdbcaf0]: IMAGE3D_MAX_WIDTH: 2048
device[0xcdbcaf0]: IMAGE3D_MAX_HEIGHT: 2048
device[0xcdbcaf0]: IMAGE3D_MAX_DEPTH: 2048
device[0xcdbcaf0]: MAX_SAMPLERS: 16
device[0xcdbcaf0]: MAX_PARAMETER_SIZE: 1024
device[0xcdbcaf0]: MEM_BASE_ADDR_ALIGN: 1024
device[0xcdbcaf0]: MIN_DATA_TYPE_ALIGN_SIZE: 128
device[0xcdbcaf0]: GLOBAL_MEM_CACHELINE_SIZE: 64
device[0xcdbcaf0]: GLOBAL_MEM_CACHE_SIZE: 1048576
device[0xcdbcaf0]: GLOBAL_MEM_SIZE: 4534318080
device[0xcdbcaf0]: MAX_CONSTANT_BUFFER_SIZE: 524288
device[0xcdbcaf0]: MAX_CONSTANT_ARGS: 8
device[0xcdbcaf0]: LOCAL_MEM_SIZE: 524288
device[0xcdbcaf0]: ERROR_CORRECTION_SUPPORT: 0
device[0xcdbcaf0]: PROFILING_TIMER_RESOLUTION: 1
device[0xcdbcaf0]: ENDIAN_LITTLE: 1
device[0xcdbcaf0]: AVAILABLE: 1
device[0xcdbcaf0]: COMPILER_AVAILABLE: 1
The OpenCL driver for the mali G72 indeed is there but don’t you think it’s a bit under powered to do NPU tasks compared to the real NPU in the system?
Also the SDK from ARM to build the X11 drivers is only available to the vendors and not to opensource developers. Which implicitly means that there is no opportunity to do this work without these vendors. The availability of the OpenCL driver shows that the SDK is in use by those who released the driver and that they have not performed a build that supports X11.
In short: GPU and NPU are not accessible to developers that use Linux as their base platform.
To say that OpenCL is a viable solution feels like Lamborghini stating that being towed by a truck means that your sports car can do the distance. It simply defeats the purpose of having the hardware in the first place. There are plenty ARM boards available and those have similar specs for OpenCL and raw CPU power. It is the addition of the NPU and the Mali G72 OpenGLES that would actually distinguish this board from others. Unfortunately there is still no driver in sight but there are devices being sold at the moment which have the Kirin970 and those definitely shine in performance. So apparently the Hikey970 is being left out on all those. I really don’t see why this has to be the status quo. By the time that any open source developer has created anything close to a working driver for the fast hardware, the hardware will be obsolete in comparison with the newer offerings.
Technology is fast paced and Kirin980 is there already. It would be sad if this very capable board will go in history as a yet another abandoned development board.
The desktop X11 performance is really not on par even with a raspberry pi. The old Tegra K1 board that sits next to the Hikey970 is almost 100 times faster in graphics. That’s a 5 year old system with Cortex A15. NVidia actually has been releasing new drivers yearly for the graphics system. The latest GeForce RTX 2080 Ti appears to be ‘only’ 70 times faster in benchmarks than the K1. (Can’t check that but CUDA Benchmarks - Geekbench Browser seems to know.)
I really had hoped to do some comparison and testing on the Hikey970. (See Graphics Card Comparison - Head 2 Head)
Some older boards got support from hackers that found ways to extract drivers from commercial devices like phones and built wrappers to use those drivers under Linux. That’s not how this should be done. This board was designed and built by people who surely take pride in their work.
1 Like
I agree that the drivers should be available in some form or another.
Personally i have not worked with them yet although I plan to.
This document says that they are available.
It says that the User space Drivers are Dynamic Libraries.
ib(64)/libGLES_mali.so -->> OpenGL ES，Open CL ，Vulkan
ib(64)/libRSDriverArm.so -->> RenderScript
lib(64)/libmalicore.bc -->> RenderScript
lib64/libmalicore.bc -->> RenderScript
All of those libraries can be found in the AOSP source tree.
And there is the Kenel Driver.
The dts file path: arch/arm64/boot/dts/hisilicon/kirin970-gpu.dtsi
So I was under the impression that those were what we needed.
What are we missing?
As far as the NPU stuff It’s new to me so i have no Idea what you can even do with it.
The thing i am most interested in is using the M.2 Pcie and mini Pcie for expansion. After I get the Bionic-Builder completed I am going to work on the pcie.
I have several expansion Cards some that are for GPU Mining. I believe it may be possible to add a Graphics Card.
Have you sent any messages to hikey? Maybe they will build what you are looking for. I did send them a question about the pcie ports and they gave a decent response. I believe i used the support on the LeMaker Site.
AOSP source tree… Binary drivers for Android, not for Linux like Debian or Ubuntu.
The ones in Debian are not for X11 and unfortunately libhybris is 32 bit only so we cannot use the ones from AOSP in a wrapper.
On the site of Odroid they have the Odroid-N2 announcement that explains that there will not be any X11 drivers for the latest Mali GPUs because ARM has stopped supporting X11. If lucky there may be a Wayland driver for their GPU.
Apparently there won’t be future support for anything else but Android.
Would have been nice to know this beforehand.
So does that mean there is no way for us to port this.
I’m just wondering if there is a way we could compile the drive our self.
Also does that mean that LeMaker don’t have the src to build it.
Other than that I hope to be able to use a expansion card.
I bought a few of these.
They power the card with an external supply and may provide the ability to add in a seperate Graphics Card. Do you think it’s possible.
Using a different graphics card is certainly a possibility.
If the card comes with binary drivers for x86 that would not be a good idea.
To get the right graphics card it should be fully supported using open source drivers. The specific connector you showed is something I have been looking for too. Most important should be that the driver can be compiled on the hikey970 and that the PCI bus can properly communicate over that bus. Some mini PCI implementations have reduced the PCI memory window to something like 32MB or less and make it impossible to really use the graphics card over the external PCI.
So in short, it requires careful selection of the graphics card and there is no guarantee that the PCI bus can support the card.
I am willing to try the same here. Does the adapter fit on the hikey970?
Yes the Cards Do Fit. There are 2 types.
1 for Mini Pcie
1 for M.2 Key M Slot
The first one i think would be best for the GPU.
But i think the M.2 Key M slot has more channels than the Mini PCIe.
There is this card also that will allow us to expand further.
I think its going to come down to weather we can get the PCIE ports functioning correctly on the Hikey. But if we can do that I’m thinking we can add in any cards we want.
I wonder which one driver is these images, X11 or Wayland?
Its not X11 as noted above.
The lebain with tensorflow has the mali driver compiled in the kernel and one library file.
It then uses open cl to access the gpu.
Ive been working on a ubuntu 18 build and i havent figured out how to get the hdmi port working correctly yet.
Well, this is awful. Unless it’s possible to make Panfrost work on this board, lack of GPU acceleration makes is much less useful.
Was there some answer from company that produced board?
