[vrmad1]

ElanLennard, on Oct 12 2009, 11:22 AM, said:

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
http://EpicenterTech.com
http://vrmad.EpicenterTech.com

[DrOctavius]

ElanLennard, on Oct 12 2009, 04:22 PM, said:

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

[ChristianBrandoni]

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.

This post has been edited by ChristianBrandoni: 30 October 2009 - 01:44 PM

[Raster]

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.

[LaForge]

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

[ChristianBrandoni]

Saoud Moco, on Nov 4 2009, 04:31 PM, said:

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?

Glad to hear that To tell you the truth we are not just developers but we plan to make a device based on TCC8900,but since we wanted an open platform it's good we have to add less abstraction since the drivers will be freely available(otherwise we would had to create an intermediate library).

As for the last note,I was talking of the android bsp only.The dev board and the linux bsp aren't a problem,but android support is limited to key customer at the moment.Yes,we ordered the board,just in the middle of the various negotiations and NDA.
I think this platform is way ahead of the competitions and the drivers organizations is really good,making use of standard frameworks like gstreamer,openmax,openvg,etc.

[DrOctavius]

LaForge, on Nov 3 2009, 04:54 AM, said:

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

This makes the difference, not if the GPU has 5MPoly/sec more or less.
Anyways, the core business of ARM is the processor architecture, I would do a long term strategy, giving and doing what all the other companies like IMGTEC didn't (source code, helping the open source community, etc), low license prices for the GPU that will supplement the next CortexA8-A9 licenses (the collateral effect is most important: makes stronger the Core business). This is the right moment and a chance that ARM cannot waste.

[Raster]

Saoud Moco, on Nov 4 2009, 04:49 PM, said:

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

Saoud Moco, on Nov 4 2009, 04:49 PM, said:

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

I'll answer for laforge here. first - I am currently working on several generations of SoC and OS that all use X11 as their windowing system - on mobile phone devices. Look at the Nokia N900 for starters. The Samsung 360 H1 - x11+OpenGL-ES. It is a growing reality that there WILL need to be both FB and X11 support for OpenGL-ES (not to mention those other proprietary windowing systems too). In fact I know that I, and the engineers I work with will kick up a big stink about any SoC that makes this hard to implement, and isn't already there with full X11 support (proper buffers swaps with page flipping even if windowed - eg copy non-window regions from front to back buffer, have single shared backbuffer, then flip, or flip if window is fullscreen + unobscured, drop to copies if not, texture-from-pixmap extensions, the ability to force double buffering vs triple buffering globally, or the ability to even drop all buffers and re-alloc them on the fly for multiple windows and compositing).

As ARM may not have interests in implementing every windowing system and his dog out there, or not maintain X11 compatibility (DRI, DRI2, DRM, etc. etc.) then an open driver is an obvious choice.

I know it may be tricky legally, politically (especially) etc., but please, make an effort. It makes a HUGE difference to your indirect customers (the people working on the software that runs on the SoC's that license your GPU engine). Those that don't care or need them to be open, are unaffected. Those that do will seriously evaluate any alternative that makes their lives easier. If it is things like not wanting to give away the shader compiler code you worked hard on, then look at mesa. Have an open DDK that is built with mesa and use the shader compiler there. Keep your non-open DDK for those that don't care about open, much like gcc vs ARM's own C/C++ compiler - yours may produce better shader code, but for many the mesa one may be good enough, and with enough work may even match yours for the uses it is put to.

So just to summarise - X11 is definitely used. Used for devices from netbooks to mobile phones. Yes - it really is used in the R&D labs building next-gen OS's. Look at maemo for the N900, Limo, Ubuntu based netbooks using ARM SoC's and more. You may not see X11 much now, but... it's marching into your room and making noise as we speak. (X11 gives you wins in terms of ease of development, portability and abstraction layers, re-use of existing code and toolkits, less or no porting work etc. etc. - it has big wins for devices that intend to have 3rd party software, and even if not, it wins in giving easier development and re-use of existing libraries, toolkits and apps).

Making it open means you either only do the base porting work to X11 and then leave it up to the community+clients to improve it, or it means you can farm it off totally to your customers+development community. It also makes you differentiate compared to your current competition (imgtec). Right now I see no difference, and thus I see no benefits to the mali400 vs the SGX. Better the devil I know (SGX) than the devil I don't (mali400). Give us a reason to go "oooh aaah! awesome! we want this one!" and that pressure will soon enough be felt by the SoC designers and thus influence their decisions. Not to mention it will influence which SoC is chosen for products too. I've recently had more bad experiences thanks to closed drivers and I pay attention to avoiding them in the future, and now those that didn't realize the pain they can cause, have realized as they got burned too. I'd rather be in the position of "well it doesn't support our particular featureset... BUT we can freely add them and work with others to share and support them, improve them and so on". at least there is a solution - it just requires work. If they are closed, we are pot-out-of-luck on solutions (well not within engineering we have to put things up the legal chain and support chain rather than just get on with work).

[vrmad1]

Saoud Moco, on Oct 26 2009, 09:10 AM, said:

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 http://vrmad.epicentertech.com 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

[RuneKS]

Saoud Moco, on Nov 4 2009, 04:49 PM, said:

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 (here), and people are even asking for ARM motherboards (here).

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.

Saoud Moco, on Nov 4 2009, 04:49 PM, said:

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.

This post has been edited by RuneKS: 16 May 2010 - 09:50 PM

[RuneKS]

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:
http://www.x.org/docs/AMD/
http://www.x.org/docs/intel/

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

This post has been edited by RuneKS: 16 May 2010 - 09:52 PM

[Jarkko]

Saoud Moco, on May 5 2010, 02:11 PM, said:

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

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

[Nizar Romdan]

Jarkko, on Jun 22 2010, 07:52 AM, said:

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

[Jin]

Nizar Romdan, on Jun 25 2010, 12:23 PM, said:

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?