What Kind Of Graphics Can We Expect?


>From 400X240 to 800X480? I believe it's 4 times

Yeah, but that's what's usually called pixel-doubling.. doubled vertically, doubled horizontally
 
mali said:
The LCD has got a hardware pixel-doubling mode. 400x240 is the way to go in games.
The display controller's video1 and video2 layers contain scaling logic which would allow both more flexible resolutions and better quality. For those cases where the shader load is too high to render 3D in WVGA at acceptable frame rates you could let the video1 layer scale the 3D output and use the video2 and graphics layers to display GUI elements at full resolution.

Some driver modifications may be necessary to allow this, though.
 
Last edited by a moderator:
Xmas said:
mali said:
The LCD has got a hardware pixel-doubling mode. 400x240 is the way to go in games.
The display controller's video1 and video2 layers contain scaling logic which would allow both more flexible resolutions and better quality. For those cases where the shader load is too high to render 3D in WVGA at acceptable frame rates you could let the video1 layer scale the 3D output and use the video2 and graphics layers to display GUI elements at full resolution.

Some driver modifications may be necessary to allow this, though.

any chance for this functionality to find its way into the OSS fb kernel driver?
 
Last edited by a moderator:
MDave said:
It's roughly 4 times more powerful then a psp, and it can do things the psp can only dream of doing ;) *cough* Shaders! *cough*

HOWEVER! Because it has double (or is that 4 times?) more pixels to render compared to the psp screen ... it could be hard to tell.

One thing's for sure, texture resolutions and quantity of textures are going to make a hell of a difference with 256 MB RAM compared to the psp's 32MB and 2MB VRAM used in commercial games ;) Difference will be night and day.

At 200Mhz the SGX 530 core would have 400Mpixel/s fillrate (two pipelines). That's enough pixel fillrate to paint an 800x480 screen over 1000 times per second.

while I doubt anything will ever get 1000fps on the pandora, you can be rest assured that the rate it can draw pixels (this is different from rendering pixels) will not be holding it back.

anyway, we have quake 3 on the pandora right? has anybody benchmarked it yet?
 
Last edited by a moderator:
Disclaimer: all information I'm sharing below is available on the web (particularly on Beyond3d forum). B)

Mr Poletski said:
At 200Mhz the SGX 530 core would have 400Mpixel/s fillrate (two pipelines). That's enough pixel fillrate to paint an 800x480 screen over 1000 times per second.
SGX in Pandora has 110MHz (when CPU is at 600MHz). It's clock is derived form CPU clock so when CPU clock gets bumped to 900MHz (which can be done) SGX will be at 166MHz. Default is 110MHz, though.

SGX@110MHz has fillrate of 220*mega [pixels/sec]. This allows filling 800x480 image 573 times/sec.

Mr Poletski said:
while I doubt anything will ever get 1000fps on the pandora, you can be rest assured that the rate it can draw pixels (this is different from rendering pixels) will not be holding it back.
Let's forget for a minute about fillrate, which itself is not very interesting (after all game that would only fill screen with color/single texture would have rather boring visuals...).
SGX has two "pipelines" that's true. But each of those pipelines is a restricted dual-issue, what means that each pipeline can do up to 2 ops/clock. So @110MHz it can do at most 110MHz*2[pipelines]*2[opcodes/pipeline] = 440*mega opcodes/sec.
For 25 frames/second this gives 440*mega[opcodes/sec]/25[frames/sec]/800[width]/480[height] = 45.83(3) opcode/pixel.
Each SGX register in 32-bit. If shader works on floats (like most of the do) - RGB color consumes three registers, and can be performed via 3 instruction executions.
This means that pixel shader can do 15.2(7) RGB-color operations per pixel.

Conclusions: You want full resolution shaders on Pandora ? Optimize your shaders (a lot). B)

Mr Poletski said:
anyway, we have quake 3 on the pandora right? has anybody benchmarked it yet?
I'd be very interested with benchmarks of OpenGL ES 2.0 Quake 3 port. It should be in 30+ fps range - after all Quake 3 uses very short shaders...
 
Last edited by a moderator:
Things like DMM and a robust physics engine also play a part. Capes moving realistically. Glass and trees breaking realistically. This type of stuff can be done on the DSP.

Besides just GPU power to draw a world, the more realistic the world animates also is very important to visuals.
 
maciek_urbanski said:
If shader works on floats (like most of the do)

I don't think this is a valid assumption for shaders written specifically for GLSL ES. For ports that will of course be true.

While I can't comment on your calculation in detail, I agree with the recommendation: optimize your shaders. After all, even if your app is running fast enough you can still save power by reducing the shader load.
 
Last edited by a moderator:
Mr Poletski said:
At 200Mhz the SGX 530 core would have 400Mpixel/s fillrate (two pipelines). That's enough pixel fillrate to paint an 800x480 screen over 1000 times per second.

while I doubt anything will ever get 1000fps on the pandora, you can be rest assured that the rate it can draw pixels (this is different from rendering pixels) will not be holding it back.
i woudn't be that optimistic. a 0-overdraw scenario is utopian; even though TBDR does help with drawing translucencies, it does not eliminate them.

and in general, as long as we hold the pandora in the group of last (or even current) generation of consoles, we'll need to consider that:

pandora does not shine with max fillrate (important for drawing high-overdraw, low pixel complexity stuff like particles, volumetric effects, etc) and it does not shine at runnig huge shaders either (ie. it can handle arbitrary complex shaders, but its shader-processing rate is not that high for the resolutions it will be running at), so in order for pandora to be able to reach and even outdo its bigger console brethren we will have to use its flexible shader architecture (where pandora actually shines) and on-board frame (tile) buffer efficiently. or put in other words, we'll have to be smart about what shaders we produce, and in what scenes we use those for maximum impact.

the reason i'm saying all that is that one of the most stupid ways to spoil the fun for outselves is to build wrong expectations (as in: unrealistically high) of an otherwise outstanding device.

ps: for reference, quake 3 is not exactly modern day technology - even a dreamcast could handle it without sweat. i, for one, expect much more impressive things from the pandora ; )
 
Last edited by a moderator:
mali said:
The LCD has got a hardware pixel-doubling mode. 400x240 is the way to go in games.

Unless you want a 400x240 game screen with an 800x480 GUI on top. :p

Also if the Pandora gets anything that looks as good as say Crisis Core I'm going to eat my hat. Well, go buy a hat, then eat it.
 
Last edited by a moderator:
Eniko said:
mali said:
The LCD has got a hardware pixel-doubling mode. 400x240 is the way to go in games.

Unless you want a 400x240 game screen with an 800x480 GUI on top. :p

Also if the Pandora gets anything that looks as good as say Crisis Core I'm going to eat my hat. Well, go buy a hat, then eat it.

If Pandora gets anything that looks as good as Crisis Core, I'll buy you a hat, just so you can eat it :D A real fancy one, too. A lesson learned early in the restaurant industry: presentation is more important than flavour.
 
Last edited by a moderator:
WizardStan said:
If Pandora gets anything that looks as good as Crisis Core, I'll buy you a hat, just so you can eat it :D A real fancy one, too. A lesson learned early in the restaurant industry: presentation is more important than flavour.
Heh... Wouldn't know if we get that far, but I'm saving up money so I can pitch in on that... ;)
 
Last edited by a moderator:
QUOTE
For 25 frames/second this gives 440*mega[opcodes/sec]/25[frames/sec]/800[width]/480[height] = 45.83(3) opcode/pixel.
Each SGX register in 32-bit. If shader works on floats (like most of the do) - RGB color consumes three registers, and can be performed via 3 instruction executions.
This means that pixel shader can do 15.2(7) RGB-color operations per pixel.
As Xmas hinted at, Isn't each unit SIMD for smaller data types? In GLSL ES you usually hold colour as a lowp 10bit fixed point vec4, which i hope under most operations executes in a single clock.
 
So I guess we could expect very good graphics from homebrew games that pay attention to optimization, but not that great graphics if you want to port a heavy game like doom 3 (because it'll be harder to optimize it properly). right?
 
Aretha Franklin hat? I think they are sold out...


@jakewastaken acutally at least initially it is more likely to be Ports > Native > Emulation IMO
 
Back
Top