Monthly Archives: October 2008

Why a good platform can’t be free

I sure am having fun thinking about OpenConsole, i.e., a Linux based set top box that plays in the same space as Microsoft and Sony and Nintendo, but is really an evolution of the Home Theater PC (HTPC) into gaming, but all using open licensing so you don’t have to pay the big boys to write applications for this platform. The underlying technologies are pretty cool as I play with adding OpenGL graphics to the qemu emulator. But the business side of it is interesting as well.

In particular, my thoughts turned to multimedia support on open platforms. This is where the insistence on Linux being free is really biting the hand that feeds you. Not all good software can be free. We do live in a world of patents and a lot of the key technology that goes into a multimedia system is protected by patents and require a license to legally distribution implementations of that technology.

You know, I have no problem with that. As I’ve stated in the past, complex algorithms are hard to get right and multimedia is complex to get good quality results. And I don’t blame the creators of this work wanting to get something out of it. If they didn’t, they probably wouldn’t have created it to begin with and we’d be waiting for some kind soul to donate this for free. Wishful thinking I’d think.

But you know, the costs aren’t that bad. One I was looking at was the DVD format licensing. There is a company in Japan that controls this and their pricing information is here. It’s about $5K for the book (under NDA), $15K for the license, then another $10K or so for verification. That’s not too bad if you’re selling thousands of units. But it’s also not zero. And the NDA also prevents the implementation from being open source to begin with anyway.

And there are similar fees for the very popular MP3, (minimum $15K). Blu-ray is similar. And some of these are yearly fees. So as you can see, if you want to produce a multimedia platform you can redistribute, the costs are non-zero. So why do people expect these platforms to cost zero…

BMW wants to go open

Ian Skerrett, our fine director of Marketing at the Eclipse Foundation, pointed out this article from BMW apparently is feeling out the market to see if there is an appetite by tier one manufacturers to work together on an open source stack for in-car infotainment systems.

The concept BMW has in mind reminds me a lot of Google’s Android who just recently released all the source to the Android platform for cell phones. Android is Google’s attempt to open up the software stack for much the same reason BMW wants it for automotive, to ensure leading edge software applications can be built for those platforms with minimal obstacles. We’ll see how well the master plan works, but I like the concept.

That would be quite a twist from the current proprietary mindset that these guys have today, and I’m not sure they are ready for the co-opetition this would take. Of course, we’re pretty used to it at Eclipse where platform vendors fighting in this space work together on open source tools. That’s fine, since that isn’t our core competency and we’re building a much better IDE together than we could independently. But that’s where we draw the line.

Ian concluded his blog entry by inviting BMW to the Automotive Symposium at Eclipse Summit Europe (I am looking forward to ESE as well!) But this brings up a sore point that we often talk about but one that seems impossible to solve. If they want the software stack to be completely open like Android, then they aren’t doing it at Eclipse. The Eclipse Board forbids GPL code within it’s walls. But I would think such a stack really could only be done on Linux and that’s a non starter. You could look at Symbian which will be EPL in the next few years, but I’m not sure Symbian is the right choice for this, especially if they want to link up with Android.

And this bugs me to no end. We are seeing some serious investment happening in open source platforms, the whole platform. The culture of commercial co-operation on open platforms at Eclipse makes it a natural to host such endeavors, which in turn would raise its profile immensely in the embedded and mobile community. Too bad the Eclipse Board shoots itself in the foot on this.

Fun with RSE

I love my home office setup. I still have an @work office that I go to, but with an Autistic son who’s home schooled, I never know when I need to work at home for a day or two so it’s good to have something setup so I can continue working when I do. In the office, I have a TV which I’m using to watch the great baseball playoffs happening right now and I’ll watch hockey whenever I get the chance too. And while doing that, I get to play on my laptop, like writing here in this blog.

At any rate, tonight I thought I’d try hooking together the virtual machines running in my Windows environment. One is qemu running my simulated OpenConsole thing to which I’ll be adding OpenGL support. The other is VirtualBox running a desktop version running the same distro, i.e. Debian, where I’ll be building the device driver and app prototypes. VirtualBox has nicer desktop control than plain qemu.

The question comes: how do I get the stuff I’m building on the dev machine to the target. I thought of NFS, which is probably the best choice, but I’d need to spend time figuring out how to set up NFS for this. Instead, I thought I’d try an Eclipse solution, the Remote System Explorer, and hook up everything using SSH.

First, I had to redirect a port on my laptop towards the qemu SSH port 22. The qemu option ‘-redir tcp:2222::22’ did nicely there and I was able to use it to log into my qemu using PUTTY on my laptop. I also decided to forward another port, 2345 to the same port on qemu to allow gdb on my dev machine to talk to a gdbserver on the target using that port.

I then set up the SSH connection in RSE on the dev machine. I used the ‘router’ address so that the dev machine would connect to Windows on my laptop, which then forwarded the SSH connection to qemu. It was tricky to figure out how to set the port number to 2222 instead of 22, but I found it and it worked like a charm. I used the Terminal view to log into the qemu session from VirtualBox. Cool!

I then tried the C/C++ Remote Launch feature that uses the RSE connection to download and launch into the CDT debugger. When I first tried, the executable on the target didn’t have the execute permission set, but once I fixed that, the debugger launched fine. Very cool.

Apart from being fun and interesting, this OpenConsole thing is giving me some real experience on using Eclipse tools to do embedded development with Linux and exercise all that it offers. I am very pleased with it and I think we really need to get the word out how well it does, like a Webinar or something 🙂

BTW, Go Rays!

Open Console you say

Linux powers “cloud” gaming console.

More info here.

I hate the term cloud, but this is close to the internet appliance/open gaming console I have been thinking about. Specs are damn close too. Although I’m not sure the ATI HD 3200 class graphics (I assume it’s the 780G chipset) will do a good job at the games. But it’s good to see someone with money came up with a similar idea and has made this concept a reality, or at least is marketing it.


Looking closer to the EVO website, this thing isn’t as open as I was thinking. Game developers have to sign and NDA to get the SDK. Odd. They do mention proprietary features that are only in their version of the Linux. What I had more in mind was an open distro that ran on specific hardware specs, but was truly open. Looking at the games they have listed on their web site, they are all open as well that can run on any Linux distro that has OpenGL support and drivers. You don’t need to be proprietary…

Windows as a host for Linux development?

Here’s something I’m trying to decide as I work through the ultimate development environment for a Linux based “OpenConsole” (and to be clear, I’m talking about set top box class consoles, not mobile). As I mentioned in previous blog entries, I’ve figured out how to extend qemu to do OpenGL calls on the host and present a PCI interface to the guest to make those calls. All I need is a Linux driver and user space library to use that interface and present the OpenGL (or OpenGL ES) interface to applications that can do games, or what have you.

I figure Linux is a natural host development environment for the device driver. You need to reuse the kernel build system to build it and from what I understand, that build system doesn’t work on Windows, not even with Cygwin. So that’s a lock, and I can use the Linux version of CDT to build it.

But when it comes to applications, I am wondering how many developers would prefer to use Windows as their development host. From what I understand (again, and I keep guessing here), most game development is done on Windows, even when targeting the “closed” consoles. Actually, XBOX development is obviously done on Windows. But I believe the others have Windows hosted SDKs and tools as well.

However, as with device drivers, Linux should be an obvious choice for application development targeting Linux. This is especially true when targeting PC-type platforms since the host tool chain can actually be used to target the console, and even more true when you’re actually using the same run-time lineup.

I get the feeling that there’s more to life than writing your Linux targeted application. If, as the developer, you’re still relying on a lot of Windows tools or you just plain prefer Windows as a work environment, you would probably want to write your application on Windows as well.

It’s funny how we sometimes forget history and the fact that we abandoned our Unix environments for Windows because it had much better tools. And as I (and many others) have discussed, Linux hasn’t caught up yet to make us want to go back. So I firmly believe that Windows is an expected host development environment for Linux development, especially embedded. And with the help of gcc’s cross compilation abililty and the gcc support in the CDT, it’s shouldn’t be that hard to put together.

It’s all about the Stack

Someone recently pointed me to a presentation that Tim Sweeney (Mr. Unreal engine) from Epic Games gave at POPL (Principles of Programming Languages) 2006. The focus of the presentation was on “The Next Mainstream Programming Language” where he discussed the challenges game developers have with performance and quality and what the next generation language needs to have to help with their problems. I truly believe game developers are at the forefront of software engineering and have the heaviest requirement set for IDEs. And that’s why I’m trying to figure out how they work.

Tim’s slides talk about the technologies that went into the game “Gears of War” and it’s a very interesting mix. While the bulk of the code is C++, there is extensive use of scripting languages as well. And, of course, most modern games make extensive use of Shading languages to manipulate vertices and pixels using the almost teraflop class GPUs we have today. So they could really benefit from an IDE that did more than just C++ or more than just scripting while integrating shader development into the fold.

The other interesting point I got out of Tim’s slides was the breadth of software libraries that they were using – DirectX for 3D graphics, OpenAL for sound, Ogg Vorbis for music, wxWidgets for 2D widgets, Zlib for compression, and the list goes on. Apparently they used a mix of 20 libraries to build Gears of War. And it only makes sense as the quality of the software components out there removes any need to build the same functionality yourself.

And I think this is another area where IDEs could improve on, integration of SDKs and automatic setup of build and indexing environments. We do a bit of that in the CDT, at least on the indexing front. And it is something we’ve talked about on the Build side but we’ve never really come up with a generic mechanism that would allow you to add SDKs to a project.

Building an IDE to help game developers be more productive would be beneficial to all users of the IDE as I think all developers run into these issues. Maybe not to the same scale but I can see how everyone would benefit from multi-language and software component management support. And, of course, I can’t see a better platform to build this other than Eclipse. If we look hard, we’ll see that we have lot of this already.

On the Future of C++

There’s been talk for a number of years now on the decline of C++ and the rise of virtual machine and scripting language. But certainly from where I sit, the C/C++ community is still very strong. In fact, I still see many more C applications than C++, especially in the Linux and embedded worlds. Though, everyone agrees, for large applications, doing them in C++ instead of C makes sense.

But I have to admit, for desktop applications, I’m not sure C++ is the right answer like it was in the 1990’s. We’re certainly seeing Java, with the help of Eclipse, and C# on the .Net side, take a much bigger chunk of the pie chart. And I think that’s the right approach. The richness of these environments naturally enables a developer to be much more productive than in the C++ world, especially when dealing with the user via graphical interfaces. I’m pretty much ready to concede this space to those languages. Sad, but true.

But there are a few areas where I don’t think C or C++ will every go away. And that’s the areas where the developer has the need for speed and where they want to work close to and take advantage of the native processing hardware underneath their application. I often hear from people who would know, that modern Java VMs can actually do better than C/C++ in performance, thanks to run-time optimizations. But projects like LLVM which provides similar optimizations to native applications, may balance the scale there. And at any rate, out of the box, native applications will start with the better performance.

When your writing a high performance application, like 3D gaming, or scientific simulations, or if your working on mobile applications where you need to balance CPU cycles versus battery life, C/C++ will always be the obvious choice. There may be exceptions to the rule, and Microsoft with .Net Compact and OSGi for Java are trying to make a splash, but C/C++ will be difficult to replace.

OpenGL 3.0 or OpenGL ES 2.0?

First, I have to admit, I’m a newbie at this whole 3D programming world. I watch from a far with a lot of interest but no real experience working in that world. So I apologize ahead of time if this is a stupid question. But I know a lot of CDT users are using the CDT to work with 3D graphic APIs and game engines so I thought I’d bounce this off you.

It was interesting to watch the response to the release of the latest major version of the OpenGL spec. The reception from the game development community was especially interesting. They were furious, at least according to Slashdot. But I can see disappointment in other articles I’ve read. The question came up: do we declare Microsoft the victor in the OpenGL versus DirectX wars? To which I add, does this spell the end of the dream of gaming on Linux?

From what I gather, there were a couple of issues with the OpenGL 3.0 release. One, the group writing the spec disappeared behind closed doors and sprung it on the world when they were done without really getting the ordinary game developer’s input. And in the end, it appears a lot of compromises were made to keep the non-game developer, the big CAD companies from what I hear, happy. So despite discussion of big architectural changes to compete with DirectX, it ends up not even worthy of the major version number.

It highlights the problem of trying to be everything for everyone and how that is impossible in many situations. Maybe the game developers need a special version of OpenGL spec’ed out just for them. If not, they’re all jumping on the DirectX bandwagon and see you later.

But that got me taking another look at OpenGL ES, the OpenGL APIs reduced for embedded applications and gaining wide acceptance in the smartphone market. It was interesting to see that the Playstation 3 uses ES as one of it’s available 3D APIs. And reading a few forums I’ve seen comments from experts who think OpenGL ES, at least the 2.0 version centralized around shaders, is OpenGL done right. The drivers are a lot easier to write and the API cuts out almost all the duplication and focuses on efficiency. It does make one think.

For the future of Linux gaming then, should we be looking to OpenGL ES? I don’t know how many OpenGL experts read this blog but I’d be interested to hear your comments on this. I recently bought a book on OpenGL ES programming to see what it was all about and it started to make sense to me that maybe this is the right direction. Heck, it almost seems like Khronos’s master plan…

What would I do without CDT

While waiting for my VOBs to sync from Salburg to Ottawa, I thought I’d poke around qemu to figure out exactly what I would need to do to add a PCI device. Apparently, there’s very little, if any, documentation on how to do that. And I even saw one response to a similar query that told the guy to go look at the source. So I did.

I started by grabing the source for the latest qemu release 0.9.1. I created a CDT Makefile project and untared the release into the project directory. I created an External Tool to run configure with the options I wanted and then I did a project build which ran the resulting makefiles. So far so good. Looking at the Includes folder on the project, I see it caught the mingw gcc standard headers as well as my project as an include path.

So off I went. First I looked for things beginning with pc_ in the Open Element dialog (Shift-Ctrl-t). There I found the pc init code and went looking there for PCI devices. I found the LSI SCSI device init and hit F3 to go look at the implementation. There I started seeing some generic PCI type things. To see what other PCI devices I could look at, I selected the call to register a PCI I/O region and did a search for references. In the Search results view I quickly saw other PCI devices – VGA displays, the IDE device, some networking things, USB. All good examples.

It wasn’t long before I figured out what I needed to do. It got me thinking. How did I ever do this before the CDT and how are the poor guys still stuck in the command line world doing stuff like this. I guess I used to do the same thing but used grep which does simple text searches. But there’s no way I could do the same navigation with the same speed. And things like Alt left and right arrow to go back and forth along my path doesn’t happen in that environment.

No, CDT rocks. I hear a lot lately about how there are still many people hesitant to leave the safety and comfort of the command line world. I think that’s too bad. They’re missing out on some real productivity gains.

QEMU Manager

Shh, I’m supposed to be working, don’t tell my boss 😉

I wrote in a previous entry about the VirtualBox SDK, and the potential for using that SDK to add 3d graphics support. I was pretty excited. All I needed to do was create a DLL that could be loaded into the VirtualBox I used for running Linux on my Windows laptop. Well, I tried a simple example, but could never get the DLL to load. Looking at the source code for VirtualBox, I noticed that there’s a “hardened” mode for building it. For security, it prevents rogue DLLs from getting loaded. I guess my DLL looked pretty rogue :(. And the complexity of building VirtualBox myself scared me off.

I’ve also been a pretty big fan of the Qemu emulator, especially for emulating mobile devices. But you can use it for emulating a PC and there is an accelerator driver that apparently makes it fast. So I guess I could give that a try. I’ve mucked around in the qemu source in the past and I have an idea on how to add a device. It’s not as clean as the VirtualBox SDK promised, but it could be done.

Along the way, I found Qemu Manager, a nice GUI that manages virtual machines and launching them on Windows. Very cool. And it’s extensible so that if a new version, or a cleverly hacked version, of qemu comes out, you can have it manage launches for them as well.

So this weeks “Open Source Tools Kudos” go to David Reynolds for building the Qemu Manager. Very cool and thanks!