• Locked Locked
  • Replies 18 replies
  • Subscribers 136 subscribers
  • Views 28817 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?
Parents
  • 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 ;)
Reply
  • 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 ;)
Children
No data