WANTED: PowerVR Video Card?


gamelaw

Still Fresh
Joined
Oct 29, 2010
Messages
10
We're not into either cross-dev or native-OpenPandora-dev options, and there IS a potential 3rd solution.


As a 3D MMORPG publisher, we're more concerned with fast native graphics first (Game code is mostly Python and any compiled code can be moved to native ARMv7 as a second pass). Anyone know of a PowerVR SGX 530 based machine we can use for development? The ideal would be a PowerVR SGX 530 w/ARMv7 laptop/netbook (OpenPandora II?). Similiar to how the Toshiba AC100 laptop has the Tegra 250 w/ARM Cortex-A9 MPCore.


At a minimum, cross-dev would really be optimized for us if anyone knows of a PowerVR SGX 530 PC card we can throw into a Ubuntu 10.4 machine. Anyone know of one?


Randel Reiss


Director Product Development


Prairie Games, Inc.


mailto:RandelR@PrairieGames.com


http://www.MinionsOfMirth.com
 
Isn't the beagle board a close enough match, hardware wise?


EDIT: Disregard that, it has only half the RAM and seems much harder to get started with than I remember.
 
Last edited by a moderator:
Intel's Z-series Atom SoCs have SGX 535s and you can find a few netbooks using it out in the wild. SGX 535 is SGX 530 but with two TMUs instead of one. That is of course x86.


Unfortunately, the Linux driver support for these chips is awful. Or at least that's what I last heard on the matter. The situation might be better in Windows.


I don't know of any ARM + SGX netbooks. The closest thing I'm aware of is iPad, but that's a tablet and it won't run anything but iOS. The Pegatron ARM netbook uses z430/Adreno 200, and while I expect there'll be netbooks using the Nufront Cortex-A9 chip those will be with Mali. There might be potential for an OMAP4 based solution.


You won't ever see anyone selling SGX as an add-on card for PC, or probably as a discrete solution for anything. The market for that sort of thing doesn't exist.


What should really be important to you is OpenGL ES 2 support, not SGX support, and AC100 can give you that. SGX doesn't have that many unique features that are currently exposed in anyone's drivers. nVidia is good about supporting extensions too. There's also OGL ES 2 emulators for PC, but those are buggy.
 
Isn't the beagle board a close enough match, hardware wise?


EDIT: Disregard that, it has only half the RAM and seems much harder to get started with than I remember.

FYI


Revision C which is the current version has the same amount of memory as the Pandora.. Older versions had half that. If your talking about NAND sure the pandora has double the beagleboard's, but that is only storage..


http://en.wikipedia.org/wiki/Beagle_Board


http://openpandora.org/index.php?option=com_content&view=article&id=91&Itemid=6&lang=en
 
Last edited by a moderator:
The PandaBoard has been released which is the big brother to the BeagleBoard.


Don't forget that several options to using OpenGL ES in software - ie Linux's Mesa drivers. Khronos.org will point you in the right direction.
 
If you need 512MB RAM, there's the touchbook from Always Innovating. If it doesn't have to be a laptop, you can use a Beagleboard-XM, which also has 512MB.
 
Thank you, everyone, for your responses.


Been researching all of your suggestions.


I think for a potential OpenPandora publisher like ourselves, we need to make OpenPandora development kits out of BeagleBoard-xM's - for graphics development - at least until OpenPandora hardware becomes more commonly obtainable. The faster processor will allow for debug versions of code. We'll also need the 512MB RAM as our current run-time footprint is around 380MB. Thanks Ari64, slaeshjag, and TrashyMG.


As to the perfect workstation, it sounds like it doesn't exist. We'll have to look into VMWare Player with a Ubuntu image, code/compile and send over to the BeagleBoard for graphics testing. Our hesitation here is that a number of folks reported their 64-bit Windows machines bricked from VMWare's Player.


The alternative for a workstation is to try and decipher Rockthesmruf's CodeSourcery for Windows setup instrcutions.


I know Linux fans would probably tell us to use Linux workstations. But usually any computer with a graphics acceleration card in it has more horsepower than Linux needs and therefor is wasted if it's not running Windows.


Randel Reiss


Director Product Development


Prairie Games, Inc.


mailto:RandelR@PrairieGames.com


http://www.MinionsOfMirth.com
 
Last edited by a moderator:
Sorry for the bump, had the tab opened for some days but lost track of it after some time.

I think for a potential OpenPandora publisher like ourselves, we need to make OpenPandora development kits out of BeagleBoard-xM's - for graphics development - at least until OpenPandora hardware becomes more commonly obtainable.
No, just a GLES2 support layer is enough. If you have a modern system with GL4 drivers you most likely have something compatible. Probably even with hardware debug and profiling registers.


If you don't chances are that a wrapper to Desktop GL2 exists which is usually enough. There is even one by PowerVR - and it's also for Windows.

The faster processor will allow for debug versions of code. We'll also need the 512MB RAM as our current run-time footprint is around 380MB. Thanks Ari64, slaeshjag, and TrashyMG.
Why do you even worry about graphics if you have such a large footprint?

As to the perfect workstation, it sounds like it doesn't exist. We'll have to look into VMWare Player with a Ubuntu image, code/compile and send over to the BeagleBoard for graphics testing.
What the fuck.. You can just compile through / for cygwin. It should be all you need for now. Games usually don't depend too much on the OS anyway (usually no GUI, only threading, timing, etc. necessary). So maybe you can (or already have) your own wrapper for the system calls. Running a VM is overkill imho.


A BeagleBoard is not necessary for the reasons I mentioned above. It's only necessary if you need a lot of extensions and the same precision as the Pandoras SGX provides.


However, for a company this is not a wise decision as you want your code to be portable. Hence you wouldn't want to add bit fiddling hacks on the GPU side.

Our hesitation here is that a number of folks reported their 64-bit Windows machines bricked from VMWare's Player.
- No comment -

I know Linux fans would probably tell us to use Linux workstations. But usually any computer with a graphics acceleration card in it has more horsepower than Linux needs and therefor is wasted if it's not running Windows.
Sorry?! Recently those "GPU powered low-cost super computers" have been showing up a lot as projects at Universitys etc. Most of them run Linux because they need fine control over the HW - something which is harder to do with Windows. Your argument is only true when talking about ATI hardware as their driver support for Linux sucks. Furthermore a dual-boot (possibly even from USB) is not hard to set up. Wether it's necessary or not is another point. I still think Cygwin or something similar is by far enough. Porting well-structured code is a matter of minutes anyway.

Randel Reiss


Director Product Development


Prairie Games, Inc.


mailto:RandelR@PrairieGames.com


http://www.MinionsOfMirth.com
There is a feature on the forum called "Signature", start using it.


BTW: If the graphics quality from the video on http://www.minionsofmirth.com/ is your set goal, you should consider using GLES1 anyway.


Probably adds a lot of platforms to the possible userbase and at the same times simplifies the code. You would depend on the drivers then as most just wrap around GLES2 (or something equivalent), but the shown graphics seem so simple, that even old chips should handle them fine if your renderer isn't a complete mess.


But in any case, the video doesn't give me the impression that anything even has to be optimized. It's neither showing complex scenes, nor complex shading. - There shouldn't be much room for improvement besides the typical optimizations which you'd also do on desktops. So why do you even want a dev system for the port? Just use a GLES 1 / 2 support layer.. Maybe it would already be enough to use a GL to GLES wrapper. It would certainly cut development cost.
 
.. I'm not trying to troll here, but using the onboard compiler of the Pandora for development and directly testing on the Pandora is a great solution. I have my Pandora SD cards mounted over the 'net to my local Linux box, where I edit, save, and press "Make" (I have a make script that executes make on the Pandora target) - this all works very well. The Pandora is more than enough machine to build most projects, and I doubt you'll need the horsepower once you get into a serious make->test cycle on the real hardware.
 
If it were me I would get an nvidia card as the linux driver supports opengl4 which requires opengl-es 2.0


For testing on a arm platform I would go for the pandaboard or equivalent, since those are available.


Also the memory requirements are a concern, is it 380 mb just for the application or does this include gpu memory too? Pandora has 256 mb which is shared with the sgx. Either way the current consumption is way over what the pandora can provide. (If the 380 doesnt include gpu then its even worse)
 
VMWare, IIRC, cannot emulate ARM, and so compile in Ubuntu x86 with VMWare will get you nowhere. Cross compile (from Windows? What do you run?) instead.


If your memory consumption is 380MB, you might need to reconsider a Pandora release - the Pandora only has 256MB, and unless you're willing to write your own game-specific miniOS (think like a standard game console) you're gonna have to share, maybe, a hundred meg with the OS (not actually sure how much the Pandora uses, don't quote me here-I don't has a pandora yet but i'm used to running stuff like Xubuntu). That or try and 'trim the fat' from your game - there are valid reasons for (comparatively) high memory usage - don't get me wrong - but go over your design and see if there are possible optimisations before worrying too much about the Pandora.


Good Luck!
 
I really doubt the OS is reserving 100/256MB for itself. If it is something is seriously wrong with the design.
 
No, just a GLES2 support layer is enough. If you have a modern system with GL4 drivers you most likely have something compatible. Probably even with hardware debug and profiling registers.
If you don't chances are that a wrapper to Desktop GL2 exists which is usually enough. There is even one by PowerVR - and it's also for Windows.
Every graphics chipset has different performance limitations and driver bugs. It doesn't matter what you use for development, if your intent is to make a cross-platform game, you have to test on a wide variety of hardware.
 
I really doubt the OS is reserving 100/256MB for itself. If it is something is seriously wrong with the design.
Well good design would be to assume that the OS takes about 100M. I just booted my pandora to X, opened a terminal and said free -m. It says 46M in use (w/o buffers&cache). So in my case this assumption leaves some 54M for disk cache and backgrounded applications that the user chooses to run before your app. IMO Its already a tight fit.
 
The alternative for a workstation is to try and decipher Rockthesmruf's CodeSourcery for Windows setup instrcutions.

Hi Randel,


Sorry my instructions were a bit of a nightmare, despite how complicated I made it all sound, it isn't really that bad. I am happy to help you out (I have only just seen this post, as I normally only go to the GP32X forums). There isn't really any reason why we couldn't just have a zip file that you extract to a folder on your Windows PC, set an environment variable to said directory, and then be able to cross compile to Pandora. That is more or less what I've done. I'm not sure if there are any limitations imposed from the Codesourcery guys about releasing zip files that contain their tool chain.


If you need any help you can drop me a message on here (I assume that'll send me an email), and we can take it from there.


In terms of debugging, I do not have a good solution, but in terms of actually taking code and making an exe, I believe this is very usable on Windows.


Steve
 
Well good design would be to assume that the OS takes about 100M. I just booted my pandora to X, opened a terminal and said free -m. It says 46M in use (w/o buffers&cache). So in my case this assumption leaves some 54M for disk cache and backgrounded applications that the user chooses to run before your app. IMO Its already a tight fit.

Disk cache is free to be discarded whenever something else needs the space. 54MB is a lot to spend for other background programs. Why assume the user is running that and not running 200MB of background stuff? It's still not stuff taken by the OS..


IMO 46MB is already too much and should be pared down.
 
Disk cache is free to be discarded whenever something else needs the space. 54MB is a lot to spend for other background programs. Why assume the user is running that and not running 200MB of background stuff? It's still not stuff taken by the OS..


IMO 46MB is already too much and should be pared down.

I doubt it's possible to go much lower with xorg.
 
Back
Top