Will It Be Fast Enough To Run Games At 800x480?

[Alex.]

Will the Pandora be able to render a few hundred sprites on a 16-bit 800x480 screen at 30fps? Some people said a while back that fast paced games will likely run at 400x240, and considering the pixels' extremely small physical size, that wouldn't be too bad at all. However, some graphics simply look better with more detail, so it would be nice to know how far we can go in this regard.

 

[skeezix]

Compare to other existing devices perhaps.

I'm running Civilization IV on a 1GHz machine with 1024x600, with a 3d GPU onboard..

jeff

 

[icurafu]

An interesting guy was talking about the GPU used in Menlow. It's basically the same as the Pandora, except it has DX9 hardware, OpenGL 2.0 hardware instead of OpenGL ES 2.0 and 200MHz instead of 120MHz.

He said this...

QUOTE
Some days before in another forum we have near the same problem.
Pipeline or not, every core is made for a maximal fillrate. All the traditional cores have ROPs to the end, so you can say this core can give out at max one pixel at ROP. If the core is "well balanced" you can get this one pixel per ROP per tact near the most time! So you have a score for this core.
If you have enough shaders for the core and also enough fixed function units for texturing and all the other stuff and if you can hold all this busy the whole time, your core will give you fillrate near the max fillrate.
PowerVR can do this, not ever but the most time. Till today they can do this better as all the other, so there cores are much more efficient.


So it seems likely that fillrate intensive actions can be done while making use of other GPU functions in an efficient manner.

But we will need to wait and see what dev box owners report back.

 

[Sphinxter]

800x480 is a lot of pixels even at 2 dimensions, I was wondering exactly how well too only on a thousand sprites. I'd be thrilled if I can paint the entire screen 8 times every 1/18 a second. Really only one way to find out how well the parts all line up. Once I discovered during the early runs of this prototype pad that every time it did a network read the whole desktop and apps just froze completely... and then fine. Never happened on paper or the reference board, had to get another guy on the team to write a driver to use dma transfer instead of port i/o to pull the whole thing out of the fire. God speed and good luck to them.

 

[icurafu]

276 Mpixels/s fillrate. 800x480x24x30.

on the SGX530, powervr states that at 200MHz you get 1200 MPixels/s and 13.5 million polygons.

It was stated before that only 120MHz will be used, but either way, you have enough fill to completely draw to the screen 30 times a second at 24-bit. (And 8 million polygons a second)

 

[Exophase]

It was stated before that only 120MHz will be used, but either way, you have enough fill to completely draw to the screen 30 times a second at 24-bit. (And 8 million polygons a second)

Where was this stated? Searching for 120MHz only comes up with your two posts in this thread. I can't search for "120."

 

[icurafu]

I can't seem to find on the interweb where I got it from.

That is, OMAP3430 GPU is clocked at 120MHz.

 

[Exophase]

I can't seem to find on the interweb where I got it from.

That is, OMAP3430 GPU is clocked at 120MHz.

While we're at it, how did you arrive at the 276 Mpixels/s required for an 800x480 framebuffer? A mpixel should be a pixel, not a bit. You can take that 24 out of the equation entirely (although stated fillrate might be at 16bpp, how much 24/32bpp framebuffers need over that is anyone's guess)

If PowerVR SGX530 really can peak out at 1200Mpixels/s at 200MHz, and we assume it scales down okay then that'd mean we get 720Mpixels/s at 120MHz - for what it's worth, this is a much higher figure than what I've been hearing for PSP, and would mean it can produce 6 pixels a clock. I don't know if it can really sustain this with DDR unless it's clocked much higher than the GPU (I do know that the tiled architecture means it can package entire tiles at a time and ship them off to RAM without having to worry about it again)

Ignore all that for now. At 800*480 you need to draw 384,000 pixels. At 30fps you need to draw 11.52 million a second. At 60fps 23.04 million a second. For a 2D game you shouldn't need an overdrawn level higher than 3, really less than 2 should be typical. Fortunately that won't matter too much since the architecture is tiled anyway. Let's say you might actually need around 30 million a second at the very most (32bpp). If Pandora can't deliver that then either there's a huge bottleneck in it or PowerVR is just lying with their marketing.

So no problem right?

PS1 could do pretty good 2D games, Pandora just needs to pull off 5x that.

 

[efegea]

But are we talking of 2D blitting or 2D sprites in opengl? If the last, there should be no problem. If the first, well, we'll see. The first is all the talk about the pixels, the fillrate and so.

PS1 did 2D games using the 3D hardware (as in "2D sprites in opengl")(I know there is not opengl in PS1 but you've understood me ), I mean, the sprites were polygons facing the camera, using orthogonal mode I think.

 

[Optimus]

I do wonder about software rendering and the memory bandwidth too. For this one I'll just have to wait until I get Pandora in my hands and try to code some soft plasmas =)))

But with the help of the GPU I guess there shouldn't be a problem at all

p.s. Also, I do wonder in which way the video buffer and the 3d accelerator will be unified. I mean, will it be possible to mix software rendering with hardware acceleration (like drawing a per pixel calculated effect as a background and then sending polygons in front) without much speed hit?

 

[Xmas]

p.s. Also, I do wonder in which way the video buffer and the 3d accelerator will be unified. I mean, will it be possible to mix software rendering with hardware acceleration (like drawing a per pixel calculated effect as a background and then sending polygons in front) without much speed hit?

An important part of hardware accelerated rendering is that GPU and CPU work in parallel. Mixing software and hardware rendering usually requires synchronization, i.e. one component waiting for the other. This will cause a big performance hit. If you want to calculate a background on the CPU your best option may be to make use of the display controller/overlay hardware. Otherwise you should upload it as a texture.

Luckily, with GPUs becoming more programmable there is less need for CPU based rendering anyway.

 

[fusion_power]

Will the Pandora be able to render a few hundred sprites on a 16-bit 800x480 screen at 30fps? Some people said a while back that fast paced games will likely run at 400x240, and considering the pixels' extremely small physical size, that wouldn't be too bad at all. However, some graphics simply look better with more detail, so it would be nice to know how far we can go in this regard.

Sounds like you are planing something specific...? Tell us more!

I also want to know, what the Pandora can do in 2D. And because of the really high DPI-Screen, 2D Games could be look great even 2X scaled from 400x240.

 

[ldesnogu]

An important part of hardware accelerated rendering is that GPU and CPU work in parallel. Mixing software and hardware rendering usually requires synchronization, i.e. one component waiting for the other. This will cause a big performance hit. If you want to calculate a background on the CPU your best option may be to make use of the display controller/overlay hardware. Otherwise you should upload it as a texture.

Luckily, with GPUs becoming more programmable there is less need for CPU based rendering anyway.

Another concern is that the GPU RAM is shared and so the IVA and the MPU subsystems will have to share the L3 interconnect bandwidth.