This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Mali-400 functioning with software stack running on Cortex-A53 AARCH64 Linux OS.

Dear ARM Forum,


I am working for a ARM Cortex-A53 + Mali based SOC. I am preparing a demo plan for my platform to show Mali-400 functioning with  software stack running on Cortex-A53 AARCH64 Linux OS.

Thanks in advance, I hope your Expertise and Experience provides some great details on my queries.

Demo : “A simple 3D rotating object to display on Linux running  platform”.
Project:  Run OpenGLES application directly on display driver (fbdev).

For This above demo I am expecting the below software stack is required.

   Graphics Stack

OpenGLES application

MALI OpenGLES library                   

MALI Common User Library

MALI Kernel driver


Display Stack

Mali EGL (MESA driver for handling Interrupts from Mali and communicating with fbdev ?)

Fbdev           

Custom Display Driver

Please let me know

1. Is the above stack is good enough for my demo ? Please add/correct the missing components. If possible please give the components names, provides and its interactions with in the stack.

    Please suggest if any other alternatives.

2. Can I get any open source for the OpenGLES2.0 3d applications, OpenGLES Library, MALI user and kernel graphics stack ?

3. Does ARM has these components ported and working for AARCH64, can that available for developer community under opensource or Licenses ?

4. ARM AARCH64 bit porting guidelines for Linux OS based applications and drivers.
   Please add your observations, issues, tools chains and their issues etc,..
5. Please provide  Linux Graphics and Display stack that is there today? and each component's interfaces that is provides below and above stack.
   My interest is to understand how user level graphics or windowing application achieve their data rendering. Please provide links if you have any which explains more.

Regards,

Are

Parents
  • Hi Are,

    1.

    Yes, the Graphics stack as you mentioned is approximately what you need as a minimum. Note, that generally speaking we build our driver monolithic-ally, and as such, the 'MALI Common User Library' and 'MALI OpenGLES library' would be the same file, potentially with symlinks or stubs for the GLES part linking to the common part.

    I believe the Display stack is also correct for fbdev at least, however I am not an expert on the Display side.

    2.

    There are many Open Source OpenGLES2.0 3D applications you can use... for example we provide our own in the Mali GLES SDK.

    There are no known Khronos Compliant Open Source Mali Driver Libraries available. We do Open Source the Kernel side as it is GPL. Mali Drivers

    For the Userspace components, you need to contact the device manufacturer to be provided with the correct binaries for your device and BSP.

    There is MESA which provides OpenGLES support, but this is software driven and thus will not be accelerated using the Mali GPU.

    3.

    Both our Midgard and Utgard range of GPU's fully support Aarch64. Again, the userspace sourcecode is proprietary and only available to partners and customers under legal agreement. For binaries, you need to contact your SoC vendor, and ask them to build and release you the libraries needed.

    We do have some prebuilt binary userspace libraries on our website for the community to use for a select few development devices and boards, however to date, these are all ARMv7 architecture (not ARMv8 as you requested), and are for the Midgard GPUs. Eventually we do plan to add Utgard versions, as well as ARMv8 versions, but cannot give an estimate on when this will be made public. For reference: Mali GPU User-Space Binary Drivers

    4.

    There is a lot of general advice already on this website regarding porting to Aarch64, for example: Porting to ARM 64-bit

    This isn't specific to graphics however, but should still be relevant.

    5.

    This is a very general question. For interfaces, the application will utilise the OpenGL ES API. Please refer to the khronos website for more details on this. The interface between our kernel and user side drivers is not public.

    I hope this helps,

    Kind Regards,

    Michael McGeagh

Reply
  • Hi Are,

    1.

    Yes, the Graphics stack as you mentioned is approximately what you need as a minimum. Note, that generally speaking we build our driver monolithic-ally, and as such, the 'MALI Common User Library' and 'MALI OpenGLES library' would be the same file, potentially with symlinks or stubs for the GLES part linking to the common part.

    I believe the Display stack is also correct for fbdev at least, however I am not an expert on the Display side.

    2.

    There are many Open Source OpenGLES2.0 3D applications you can use... for example we provide our own in the Mali GLES SDK.

    There are no known Khronos Compliant Open Source Mali Driver Libraries available. We do Open Source the Kernel side as it is GPL. Mali Drivers

    For the Userspace components, you need to contact the device manufacturer to be provided with the correct binaries for your device and BSP.

    There is MESA which provides OpenGLES support, but this is software driven and thus will not be accelerated using the Mali GPU.

    3.

    Both our Midgard and Utgard range of GPU's fully support Aarch64. Again, the userspace sourcecode is proprietary and only available to partners and customers under legal agreement. For binaries, you need to contact your SoC vendor, and ask them to build and release you the libraries needed.

    We do have some prebuilt binary userspace libraries on our website for the community to use for a select few development devices and boards, however to date, these are all ARMv7 architecture (not ARMv8 as you requested), and are for the Midgard GPUs. Eventually we do plan to add Utgard versions, as well as ARMv8 versions, but cannot give an estimate on when this will be made public. For reference: Mali GPU User-Space Binary Drivers

    4.

    There is a lot of general advice already on this website regarding porting to Aarch64, for example: Porting to ARM 64-bit

    This isn't specific to graphics however, but should still be relevant.

    5.

    This is a very general question. For interfaces, the application will utilise the OpenGL ES API. Please refer to the khronos website for more details on this. The interface between our kernel and user side drivers is not public.

    I hope this helps,

    Kind Regards,

    Michael McGeagh

Children