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 kernelIf 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
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?
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 kernelIf 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
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.
Where can I find Linux BSP for MOP500 and the MOP500 User Guide/Datasheet ?
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
Opening up the DDK can be tricky to say the least [...]
btw thanks to everyone who's been contributing to this forum - we're listening
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... CheersSaoud Moco/ARM
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
View all questions in Graphics and Gaming forum