• Locked Locked
  • Replies 18 replies
  • Subscribers 136 subscribers
  • Views 28819 views
  • Users 0 members are here
Options
Related
How was your experience today?
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 GPU development boards

guestposter guestposter
Note: This was originally posted on 12th October 2009 at http://forums.arm.com

While there are a variety of Mali GPU licensees currently designing Mali GPUs into their SoCs, there are not necessarily many development boards available to the general public.

In order to provide application developers on Mali GPU-based projects with the hardware they need to get their work done, we would like to gain a strong (and accurate) understanding of what needs to be made available. What are the things you look for in a development platform?
  • Note: This was originally posted on 21st October 2009 at http://forums.arm.com

    While there are a variety of Mali GPU licensees currently designing Mali GPUs into their SoCs, there are not necessarily many development boards available to the general public.

    In order to provide application developers on Mali GPU-based projects with the hardware they need to get their work done, we would like to gain a strong (and accurate) understanding of what needs to be made available. What are the things you look for in a development platform?


    I'd like to see HDMI, DVI, and VGA ports along with the option for a local 8"-10" diagonal LCD panel. For my purposes I'd like to see a Cortex A-9 MPCore  series processor (4 core), MALI GPU, 500 MB of Flash, 2 GB of RAM, and a Spartan 3AN FPGA.. USB and Ethernet ports for software development. That's about all for now... Still need to do some homework on the GPU...

    Dan Johnson
    [url="http://EpicenterTech.com"]http://EpicenterTech.com[/url]
    [url="http://vrmad.EpicenterTech.com"]http://vrmad.EpicenterTech.com[/url]
  • Note: This was originally posted on 23rd October 2009 at http://forums.arm.com

    While there are a variety of Mali GPU licensees currently designing Mali GPUs into their SoCs, there are not necessarily many development boards available to the general public.

    In order to provide application developers on Mali GPU-based projects with the hardware they need to get their work done, we would like to gain a strong (and accurate) understanding of what needs to be made available. What are the things you look for in a development platform?

    I'm really happy that ARM has their own GPU!

    IMHO, these are the next steps you should take:

    1) HW: Give to developers a low cost platform, like beagleboard, this was a boost for spread the ARM cores to new developers.
    2) SW: Simulators (you already have this!), Open source philosophy, OpenGL drivers for everybody. Don't do what IMGTEC have done.

    Cheers,

    Leandro
  • Note: This was originally posted on 26th October 2009 at http://forums.arm.com

    I'd like to see HDMI, DVI, and VGA ports along with the option for a local 8"-10" diagonal LCD panel. For my purposes I'd like to see a Cortex A-9 MPCore  series processor (4 core), MALI GPU, 500 MB of Flash, 2 GB of RAM, and a Spartan 3AN FPGA.. USB and Ethernet ports for software development. That's about all for now... Still need to do some homework on the GPU...

    Dan Johnson
    [url="http://EpicenterTech.com"]http://EpicenterTech.com[/url]
    [url="http://vrmad.EpicenterTech.com"]vrmad.EpicenterTech.com[/url]



    Thanks Dan for your useful input.

    Regarding (graphics) application development, what sort of environment do you normally work in - I presume you start by developing on PC and then port to embedded platforms. If so, how do you use the system memory (incl. VRAM on your graphics card)?

    Do you also plan on doing on-target compilation? (given 2GB of RAM is a non-negligible cost when targeting for a low-cost entry level embedded device, we need to weigh the actual memory requirements carefully) - so what I'm really saying is, how would 2GB RAM help you develop for this platform, where no less would do for instance and what type of applications do you develop.

    Also, it would be good to know what combination of OS and distribution you are targeting... 

    Cheers
    Saoud Moco/ARM
  • Note: This was originally posted on 30th October 2009 at http://forums.arm.com

    From my perspective I would like to see more openess of the drivers.
    Even if they can be released in binary format only,it would be nice to have them downloadable directly from here and even the beta status in case new functionality gets introduced, to get ahead with development.
    For example we are dealing with the Mali 200 dev board now,and we are told that the android bsp will be available to selected customers only initially.
    It would be nice if there wasn't this kind of discrimination but everyone,even a simple end users who just bought a device using mali and want to make his own app or port an existing one,can access to them.
  • Note: This was originally posted on 3rd November 2009 at http://forums.arm.com

    I have looked at the quick specs of mail, and it looks good, except the mystery of any open specs and/or drivers. I can't determine in detail if it is what I want. I have been bitten before by the "looks nice in the spec sheet" but "severely disappoints you when you actually find all the details, "gotchas" etc." department. I've been bitten by closed OpenGL-ES drivers before that have bugs that you can't verify or fix, or that simply lack the features you need (eg X11 flavor of EGL, TexturefromPixmap extensions etc.), and as your vendor also has restricted source access - they cannot provide the changes, nor can you "help yourself", as it's a closed blob. The Hardware is capable of it, just it has been artificially limited but API libraries on top that you cannot replace, modify or even inspect to see if the bug is yours, or the libraries'.

    I vote for at least open drivers, if not open drivers and specifications (enough specifications needed to modify, improve or fix the driver libraries). Right now such gfx units are in short supply on embedded devices, and I will lean to the open ones almost always as at least any hole I end up in, I can dig myself out of.
  • Note: This was originally posted on 20th July 2010 at http://forums.arm.com

    Hi Jarkko,

    The Linux BSP for ST-Ericsson's MOP-500 board will be available soon for download through a secure link for the people who have ordered the board. If you have done so then you'll be contacted shortly with download instructions.

    Cheers,
    Nizar


    When could I get Linux BSP for MOP500? Is it served yet?
  • Note: This was originally posted on 3rd December 2009 at http://forums.arm.com

    Thanks Dan for your useful input.

    Regarding (graphics) application development, what sort of environment do you normally work in - I presume you start by developing on PC and then port to embedded platforms. If so, how do you use the system memory (incl. VRAM on your graphics card)?

    Do you also plan on doing on-target compilation? (given 2GB of RAM is a non-negligible cost when targeting for a low-cost entry level embedded device, we need to weigh the actual memory requirements carefully) - so what I'm really saying is, how would 2GB RAM help you develop for this platform, where no less would do for instance and what type of applications do you develop.

    Also, it would be good to know what combination of OS and distribution you are targeting... 

    Cheers
    Saoud Moco/ARM


    Saoud,
          Sorry for the delay in getting back to you, haven't been back to the forums in a while. To answer your question about development platforms. I'm using Ubuntu Linux and Mac OS-X for cross-compiling activities using GNU compilers. At the present time I am deploying on BeagleBoards and SheevaPlugs to prototype my system (along with some Spartan 3AN Xilinx cards). The rest of the system is 100% Java based using processors from Imsys Technologies and aJile Systems. There is no OS in the traditional sense just thread pools executing tasks with master supervisors and state machines. It's an event driven system that spawns execution threads when needed. I started looking at the MALI GPU because I am interested in a non-PCI OpenGL-ES solution for my final product. The reason for the large memory space is that my product renders 3D scenes and objects in order to deliver multimedia content. This means I am dealing with 3D rendering, video, and audio all at the same time. The details of the device are at [url="http://vrmad.epicentertech.com"]http://vrmad.epicentertech.com[/url] although the documents there now are a bit out of date. There's enough there to give you the over-all concept though. I can implement the memory on a FPGA board if it makes your development board too expensive. The system basically divides up a 3D space in multiple regions that have their own mappings into video memory based on the viewer perspective. Basically, I'm looking at using the ARM processors to handle the rendering pipelines and video processing. In the future I will also be developing some derivative products using Google Android and Chrome OS.

    Dan
  • Note: This was originally posted on 26th April 2010 at http://forums.arm.com

    Opening up the DDK can be tricky to say the least [...]

    Hi Saoud,

    Is it possible for you two elaborate on this issue, on what the various obstacles are for you to be able to do this? I (and many others, I imagine) would be very interested in hearing about this.
    It seems a lot of people are seeking an open source 3D driver for the ARM platform. Ubuntu has been successfully ported to ARM, unfortunately without the 3D accelerated interface because of lacking open source graphics drivers. On Phoronix (a Linux-oriented news site with focus on graphics), people are also eager to know if any open source ARM-GPUs exist ([url="http://www.phoronix.com/forums/showthread.php?t=21341"]here[/url]), and people are even asking for ARM motherboards ([url="http://www.phoronix.com/forums/showthread.php?t=22630"]here[/url]).

    As I see it, ARM themselves delivering an open source graphics driver for their own architecture would overcome the main hurdle of the ARM-platform on Linux, and thus make it more popular amongst manufacturers, and amateurs as well, as also can be read by replies in this thread.

    How do you view this situation? Do you not think that an open source graphics driver would increase the use of the ARM-platform on Linux, or is ARM simply not too concerned with Linux-support, as Linux-users only make up a relatively small part of both PC and net book users?
    I'd love to hear your view on this as well.

    btw thanks to everyone who's been contributing to this forum - we're listening :(

    And thank you for entering into this discussion. It is truly wonderful to be able to talk about these things directly with the manufacturer, and not just speculate amongst ourselves about your motivations and lack thereof. :)
  • Note: This was originally posted on 5th May 2010 at http://forums.arm.com

    Hi RuneKS

    I'm not sure what you meant by open source GPU's - if you're referring to open architecture/design then we don't have any plans to so in the near future. However we're making available the MOP500 and TCC8900 boards via our developer portal. The former has our Mali-400 GPU and the latter our Mali-200 GPU in their chipsets respectively. We're also going to enable developers to use these GPU's by providing a Linux BSP with the Mali OpenGL ES drivers in binary, all downloadable from this site. We will put more information as and when they become available. Stay tuned :(

    S
  • Note: This was originally posted on 16th May 2010 at http://forums.arm.com

    Hi Saoud

    When I write open source GPU, I'm basically referring to a GPU for which documents are released, that enables software developers outside of ARM to develop an (open source) driver for the GPU in question.
    AMD and Intel have released such documents, which are available here:
    [url="http://www.x.org/docs/AMD/"]http://www.x.org/docs/AMD/[/url]
    [url="http://www.x.org/docs/intel/"]http://www.x.org/docs/intel/[/url]

    I'm very interested in what your thoughts (both yours personally, and ARM as a company) are on doing this, and if you can elaborate on your decision about doing it or not.

    Thanks for your time!

    -Rune Svendsen
  • Note: This was originally posted on 22nd June 2010 at http://forums.arm.com

    Hi RuneKS

    I'm not sure what you meant by open source GPU's - if you're referring to open architecture/design then we don't have any plans to so in the near future. However we're making available the MOP500 and TCC8900 boards via our developer portal. The former has our Mali-400 GPU and the latter our Mali-200 GPU in their chipsets respectively. We're also going to enable developers to use these GPU's by providing a Linux BSP with the Mali OpenGL ES drivers in binary, all downloadable from this site. We will put more information as and when they become available. Stay tuned B)

    S

    Where can I find Linux BSP for MOP500 and the MOP500 User Guide/Datasheet  ?
  • Note: This was originally posted on 25th June 2010 at http://forums.arm.com

    Where can I find Linux BSP for MOP500 and the MOP500 User Guide/Datasheet  ?


    Hi Jarkko,

    The Linux BSP for ST-Ericsson's MOP-500 board will be available soon for download through a secure link for the people who have ordered the board. If you have done so then you'll be contacted shortly with download instructions.

    Cheers,
    Nizar
  • Note: This was originally posted on 3rd November 2009 at http://forums.arm.com

    Hi!

    I can only second what other people have posted earlier in this thread.

    No matter how shiny and great the development board hardware is, this is only of so much significance.

    The software side matters much more.  Please carefully study by the nightmare that Imgtec has put it's customers (the SoC makers) into, and which even bigger nightmare those SoC makers then put the board-level product makers into.

    The Imgtec graphics stack is extremely closed.  The DDK (with source code) is only provided to the SoC makers, who in turn ship a DDK-generated SDK with binary drivers to their customers.

    The problem is that the SoC makers typically have only very limited understanding of Linux and the standard Linux graphics architecture beyond the framebuffer (e.g. DRI/DRI2/TTM/KMS, Xorg EXA/XAA/XRandR, Mesa, etc.).  Imgtec does not provide this as part of their DDK, and the SoC makers don't provide it either.  Now put yourself into the position of a company trying to build a MID or Netbook.  It's a nightmare.

    TI has struggled a lot, Intel (GMA500) has struggled a lot, and I am and have been working with other SoC makers who are still struggling a lot with the non-standard architecture of this graphics stack.

    ARM's Mali has the chance to not only offer an IP core with similar or better hardware performance.  It has the chance of being several orders of magnitude better when it comes to providing a "standard Linux graphics stack".  This means that
    * kernel framebuffer driver + DRI2 (or TTM/KMS), open source under GPL, actively contributed back to the mainline kernel
    * Xorg driver with EXA/XAA + Xvideo), open source under MIT license, against latest development version of Xorg
    * OpenGL driver (not only ES), preferrably open source. If it has to stay proprietary, keep the proprietary part as small as possible and make sure it only uses standardized DRI/DRM interface to the kernel

    If ARM can provide something along these lines, they will make it at least 10 times easier to build a Linux-based netbook or MID.  If they don't, it will not make a difference if you use Imgtec or Mali
  • Note: This was originally posted on 4th November 2009 at http://forums.arm.com

    From my perspective I would like to see more openess of the drivers.
    Even if they can be released in binary format only,it would be nice to have them downloadable directly from here and even the beta status in case new functionality gets introduced, to get ahead with development.
    For example we are dealing with the Mali 200 dev board now,and we are told that the android bsp will be available to selected customers only initially.
    It would be nice if there wasn't this kind of discrimination but everyone,even a simple end users who just bought a device using mali and want to make his own app or port an existing one,can access to them.


    Indeed the drivers will be provided in binary format directly from the Mali Developer Center. The aim is to provide developers all they need to get started in one place  ;)
    On your last note; it's more a question of availability - this is early stage hardware that is not manufactured in large volumes yet unfortunately. We therefore need to qualify these requests and use a queuing system. Have you requested a board btw?
  • Note: This was originally posted on 4th November 2009 at http://forums.arm.com

    Hi!

    I can only second what other people have posted earlier in this thread.

    No matter how shiny and great the development board hardware is, this is only of so much significance.

    The software side matters much more.  Please carefully study by the nightmare that Imgtec has put it's customers (the SoC makers) into, and which even bigger nightmare those SoC makers then put the board-level product makers into.

    The Imgtec graphics stack is extremely closed.  The DDK (with source code) is only provided to the SoC makers, who in turn ship a DDK-generated SDK with binary drivers to their customers.

    The problem is that the SoC makers typically have only very limited understanding of Linux and the standard Linux graphics architecture beyond the framebuffer (e.g. DRI/DRI2/TTM/KMS, Xorg EXA/XAA/XRandR, Mesa, etc.).  Imgtec does not provide this as part of their DDK, and the SoC makers don't provide it either.  Now put yourself into the position of a company trying to build a MID or Netbook.  It's a nightmare.

    TI has struggled a lot, Intel (GMA500) has struggled a lot, and I am and have been working with other SoC makers who are still struggling a lot with the non-standard architecture of this graphics stack.

    ARM's Mali has the chance to not only offer an IP core with similar or better hardware performance.  It has the chance of being several orders of magnitude better when it comes to providing a "standard Linux graphics stack".  This means that
    * kernel framebuffer driver + DRI2 (or TTM/KMS), open source under GPL, actively contributed back to the mainline kernel
    * Xorg driver with EXA/XAA + Xvideo), open source under MIT license, against latest development version of Xorg
    * OpenGL driver (not only ES), preferrably open source. If it has to stay proprietary, keep the proprietary part as small as possible and make sure it only uses standardized DRI/DRM interface to the kernel

    If ARM can provide something along these lines, they will make it at least 10 times easier to build a Linux-based netbook or MID.  If they don't, it will not make a difference if you use Imgtec or Mali


    Hey LaForge

    this is really valuable input for us. Opening up the DDK can be tricky to say the least, but some of your ideas about standardized interfaces is certainly interesting and worth investigating on our side. However, we're often dealing with Linux for embedded devices where for instance X11 isn't implemented - or their display system is proprietary. Generally for what sort of target devices do you develop applications?

    btw thanks to everyone who's been contributing to this forum - we're listening ;)