Beagle comments from James Trigg

These comments were incorrectly added by one of our readers to a wiki page. Placed into the forum:

This is what I am interested in. I would love to see Open GL ES working with the Beagle + Risc OS. as I have some games I would like to port from the iphone. I have just ordered Virtual Acorn for the mac. I am happy to give some money to anyone who gets a Beagle port running with Open GL. Thank’s for all your hard work. I have made a donation and there is more where that came from !!

Well, GCCSDK developers are actively working on trying to get Mesa (i.e. OSS OpenGL) into shape for RISC OS. One of the first steps is getting the Iyonix version fixed, and perhaps also a soft version:

http://www.riscos.info/cgi-bin/bugzilla3/show_bug.cgi?id=182

As for OpenGL ES, that may or may not be related work (I can only guess at the details). In practice, almost all the stuff using OpenGL that is of interest to RISC OS will be using Mesa (mostly various game ports). And porting from the iPhone is another topic again, and will depend upon a number of items.

Getting 3D acceleration working on the beagleboard/OMAP is certainly on my list of things to do. But it’s right at the bottom of the list, because the hardware docs are confidential and the Linux drivers are closed source. This means that (unless the driver source code gets released, or someone can convince PowerVR to start releasing RISC OS binaries) the only way we’re likely to get it working is if we can load the linux binary and use a wrapper layer to interface it with RISC OS. This would require an unknown amount of time to get working properly, which is why it’s going to stay at the bottom of my list until the more important stuff gets done first.

I’m especially interested in computer graphics and animation, so getting OpenGL ES to work on RISC OS is very high on my own list… However, I agree that as far as the porting efforts is concerned, much more fundamental issues should get priority first…

I still have an Iyonix, and I tried out IyonixMesa there a long time ago, but the problem was that it only worked for an older nVidia card, and not for the newer ones that was being shipped with newer Iyonixes (at the time)...

I didn’t want to write code for a card that nobody had, so I abandoned any more work on IyonixMesa at that time…

However, with the new crop of OMAP-based computers, this situation has changed again, making this a more interesting proposition, once again…

As long as the driver is closed source, it seems to me that most reasonable approach would be to try to wrap the Linux drivers, as you say.

Concerning 3D support, I would like to pose some (maybe obvious) questions:

• Did anybody ASK Imagination Technologies? / who volunteers? / has a contact?
• How could the effort for Imagination Technologies be minimised?
• How much overhead would a linux driver wrapper involve (runtime/development)
• What do we want in terms of interface?
• Is an NDA necessary / possible for a small group of riscos developers?

Did anybody ASK Imagination Technologies?

AFAIK nobody from the RISC OS community has asked them anything.

About the only thing that I do know is that around a year ago someone from the Pandora community asked Imagination Technologies about whether the drivers would be released as open source, and they were told that it wasn’t going to happen (or at least not yet). I’d be more specific, but I can’t find the relevant forum thread :(

How could the effort for Imagination Technologies be minimised?

The effort for them to port the driver? I guess sending them some up-to-date RISC OS documentation and a stable ROM build would help. Teaching them how to use the GCCSDK autobuilder might help too, as it might be easier for them to use their existing configure scripts/makefiles that way.

How much overhead would a linux driver wrapper involve (runtime/development)

The runtime overhead should be low, probably no worse than the overhead involved in a SWI call.

The development overhead is a bit trickier to gauge – if their driver uses one or more internal threads then that could be a major issue, as we’d have to find a sensible way of implementing that under RISC OS (although supporting threads would likely be a lot easier if we limited the driver for being used with unixlib)

What do we want in terms of interface?

Ideally something that will fit well with IyonixMesa, and the software Mesa implementation. Static linking with programs should be avoided, so that authors don’t have to worry about releasing multiple versions of their code, one for each platform. So this would come down to either releasing the drivers as modules (with either a SWI interface or a Shared C Library-style table of entry points), or, more likely, releasing them as shared libraries for use with GCC 4.

And the actual API used would obviously be OpenGL ES 2.0 :)

Is an NDA necessary / possible for a small group of riscos developers?

I have a feeling we’d have to wave around a large amount of cash in order to gain access to the driver source code/SGX technical docs.

Also it’s worth pointing out that there is an effort underway to produce a fully open-source driver by reverse-engineering the linux binary. But I don’t think they’ve got any code working yet, so it’s unlikely that their driver will be ready by the time that RISC OS is.

I have a feeling we’d have to wave around a large amount of cash in order to gain access to the driver source code/SGX technical docs.

Why do you think so? I suppose Imagination Technologies is interested in popularity/sales of their product and in protection of their IP. If it is easy and secure for them to access a wider range of machines or OS why should they ignore it? As a student I had to sign several NDA’s and felt obliged to follow it – so I see no problem there too. Maybe they even want to help us if it’s not too expensive for them :-)

I just read about the Barcelona Mobile World Congress. From the website:

Come visit Imagination at MWC 2010 in Barcelona, Feb 15-18, Hall 1 Stand 1E05.

anybody?

Why do you think so? I suppose Imagination Technologies is interested in popularity/sales of their product and in protection of their IP. If it is easy and secure for them to access a wider range of machines or OS why should they ignore it? As a student I had to sign several NDA’s and felt obliged to follow it – so I see no problem there too. Maybe they even want to help us if it’s not too expensive for them :-)

Generally speaking GPU manufacturers are very protective over their IP. If it was just a case of signing an NDA, Castle would have signed one with NVIDIA years ago and delivered a proper GeForce driver for RISC OS (e.g support for YUV overlays/hardware MPEG decoding). Although I’m willing to be proved wrong, I’d expect Imagination to be just as secretive about their tech as everyone else – especially since they seem to be the main player in the handheld GPU market at the moment.

Come visit Imagination at MWC 2010 in Barcelona, Feb 15-18, Hall 1 Stand 1E05.

I doubt I’d be able to get to Barcelona for next week – I don’t even have a passport! ;)

If it was just a case of signing an NDA, Castle would have signed one with NVIDIA years ago and delivered a proper GeForce driver for RISC OS

And if they had done so, they would have had a head start for the mobile device market today – so it was a mistake by NVIDIA.

P.S. My passport also expired last october ;-)

For anyone returning to this thread in the future, here are some additional pointers:

• TIB thread – Conversions (mostly games)
• Presumably the same James Trigg posting to the BeagleBoard mailing list
• open GL game programing

Did anybody ASK Imagination Technologies? / who volunteers? / has a contact?

• Imagination Technologies corporate contacts

For info, Imagination Technologies seem to have a PowerVR design job going.

"Memembership of the PowerVR Insider developer programme is free and open to all developers writing applications on PowerVR-enabled platforms. […] Once you’ve registered you are eligible for technical and co-marketing support […] will have access to our developer forums where you can post questions and browse and search for technical information from existing posts." Any good?

Nope.

Oh well… Could it be worth me trying to ask them a few things (a couple of years late)? (Wording can be clarified here/via email, as I’m not necessarily going to come up with the most pertinent points without guidance.)

Could it be worth me trying to ask them a few things

Unlikely!

Even if we did get access to the SGX docs or driver source, I’m tempted to say that our best bet for getting hardware acceleration working on RISC OS would be to concentrate on building a wrapper layer for the Linux drivers. The tools needed to build a wrapper for the SGX driver can easily be reused to build a wrapper for the VideoCore driver, or any of the Linux drivers that will be used by other future hardware targets.