Intel Gma 500 = Sgx 535

[ldesnogu]

Right now it renders at a very good frame rate: until id software releases the code, the Pandora only has a black screen to render

 

[darkblu]

doom3 was written for gf256/gf2 class hardware on the gpu side.

That was the case early in the development but it changed. And if you don't trust that here is the official page
http://www.idsoftware.com/games/doom/doom3..._section=sysreq

that does not really change the technological standing of doom3 - i.e. multi-pass shading and the stencil techniques employed.

the early shader gpu's on that list (gf3, ati8500 & co) do not provide much of a quality departure from their predecessors (pipeline-wise), so they'd still need to do pretty much the same as the gf2 would in doom3.

 

[kattle87]

Something's wrong... I see that GMA 500 has only 4 shader units, while the SGX 530 should have 8?!?!?

EDIT: My fault, was a misunderstanding already pointed out in another discussion

 

[Fishbong]

Anyone who thinks 3Dmark is an accurate measure of 3d performance, think again.

BTW, i once Benchmarked my onboard nForce 530 just for fun with the 06 version. It only got around 600 points, still it runs games such as UT2004 or Doom3 at fullspeed with high settings and a much higher resolution than the pandora will have.

So all these comparisons are irrelevant.

 

[Exophase]

I wonder how you guys can claim Doom3 would look as good on Pandora as it does on a desktop... On what basis can you say that ?

Anyway, this won't happen unless id open sources their id tech 4 engine.

I think they're saying this with the XBox version in mind.

 

[sindbad]

Since the screen is much smaller and has much higher DPI than your average monitor, it should look as good even when it's actually worse.

Also, once the id tech 4 gets open sourced, it can be customised for small devices. Many expensive operations can be replaced with cheaper ones if the difference in output is not too visible on a small screen.

 

[ldesnogu]

I think they're saying this with the XBox version in mind.

But the xbox GPU specs are not in the same league as Pandora's SGX :blink:

 

[nikkopt]

OMAP2 2420 (MBX core clocked at 50 mHz) runs 3DMark mobile ES 1.1 at ~38fps. Pic here.

There is also an OGL ES 2.0 version, pics here. which i think the omap 3 can run without a problem

Anyway, having the game source to lower texture resolution, reducing the poly count, shadow complexity, tweaking the shaders and some other stuff.. sure. Why not?

 

[Exophase]

I think they're saying this with the XBox version in mind.

But the xbox GPU specs are not in the same league as Pandora's SGX :blink:

No? How would you say the two compare?

 

[Elanzer]

If the AA is really "zero overhead", wouldn't 400x240 still look pretty decent? If the AA method is atleast equivalent of 2x MSAA, it shouldn't be -too- noticeably pixilated on that size of screen versus 800x480 without AA.

 

[joa]

Doom 3 was rubbish then, and it's rubbish now.

Bring on quake 3.

 

[ldesnogu]

I think they're saying this with the XBox version in mind.
But the xbox GPU specs are not in the same league as Pandora's SGX :blink:No? How would you say the two compare?
Well I'm unsure, that's the reason why I asked the question.
Here's an excerpt from Wikipedia:

QUOTE
# GPU and system chipset: 233 MHz "NV2A" ASIC. Co-developed by Microsoft and NVIDIA.

* Geometry engine: 115 million vertices/second, 125 million particles/second (peak)
* 4 pixel pipelines with 2 texture units each
* 932 megapixels/second (233 MHz x 4 pipelines), 1,864 megatexels/second (932 MP×2 texture units) (peak)
o Peak triangle performance (32pixel divided from filrate): 29,125,000 32-pixel triangles/sec raw or w. 2 textures and lit.
+ 485,416 triangles per frame at 60fps
+ 970,833 triangles per frame at 30fps
* 8 textures per pass, texture compression, full scene anti-aliasing (NV Quincunx, supersampling, multisampling)
* Bilinear, trilinear, and anisotropic texture filtering
* Similar to the GeForce 3 and GeForce 4 PC GPUs

Now if you think the SGX has the same level of performance, nice. But as long as I don't get any sort of demonstration, I won't believe a chip supposed to reach 14 M vertices/sec can equal that That doesn't mean some sort of stripped down can't run on Pandora, but that thinking that since it runs on an Xbox it can run on a Pandora (which was the original message I responded to) is probably very wrong.

 

[maciek_urbanski]

Let's be pessimistic about this and assume, that SGX is significantly slower in vertex processing and bandwidth departments...
I think we can all agree that in the same time it's more programmable.

Let's brainstorm what can we do about this...

Something from top-of-the-head:

• geometry processing done on NEON
  ...vertex shader, clipper and setup for sure, possibly functions of hull, domain and geometry shaders
• rendering to custom texture format (possibly 2-pass)
  ...YUV-alike, quincunx (checkerboard) luma subsampling, 1/8 chroma (4x less bandwidth)
• custom up-sizing via DSP
  ...edge-directed upsizer for luma and chroma to YUV422 (maybe something like this or this(IEEE subscription needed))
• final YUV->RGB conversion via overlay

This could give us a full 800x480 with good quality of luma (most visual information is there) and still acceptable quality of chroma at 1/4 of bandwidth cost of full rendering. Not sure about 'setup time' though...
I think I'll do some crude upsampling experiments in the weekend. B)

Other ideas ?

 

[mali]

Scratch 800x480. 400x240 is enough. Better use the additional recources freed by lowering the resolution for other visual enhancements. Using the native resolution in fast paced games makes no sense IMO.

 

[fusion_power]

Scratch 800x480. 400x240 is enough. Better use the additional recources freed by lowering the resolution for other visual enhancements. Using the native resolution in fast paced games makes no sense IMO.

Yupp, with 400x240 we still have the Pixel-Size of the GP2X screen (Pandora 2x the DPI of the GP2X). I think 3D Games still look amazing in 400x240 and someone mentioned, that things like Anti Aliasing are nearly "for free" with the OMAP so we could compense the lower res with such effects, of course I have no proof of this. ^_^

 

[darkblu]

Well I'm unsure, that's the reason why I asked the question.
Here's an excerpt from Wikipedia:
<snip>


on xbox doom3 does multipass shading, of the form (likely worst-case scenario, see footnotes):

* one pass for scene depth and ambience
* two passes for all stencil shadow volumes (i don't think nv2a does two-sided stencils)
* one pass for each individual light's diffuse contribution, combined with surface texturing, carried versus shadow volumes (1)
* one pass for each individual light's specular contribution, carried versus shadow volumes (1)

(1) potentially xbox may be able to do two lights per pass here, depending on its pixel shader limits.


so doom3 on xbox would total to 5 passes per scene with one light, adding two more passes for each new light! also, a non-negligible fact is that all shading passes after the first one are of the read-modify-write type - and xbox is notorious for its framebuffer access latencies (framebuffer in uma - just genius).

now, considering that each pass consumes both transform- and fill-rate, i guess you can see how an architecture with half-to-quarter of the fillrate and a fraction of the transform rate can achieve the same, given that it can:

* perform the above shading in two passes - one for producing the depth texture (per light), and one for all the shading of the scene.
* the stencil shadow volume algo is dropped for a more efficient one (i.e. depth buffer shadows)

and this is before we consider fill-rate savers like res doubling, etc.

 

[ldesnogu]

@darkblu That's a very interesting post, thanks
This raises two questions:
- SGX is uma too Even if it's tile based this will have an impact. (And for those who think Omap3 has a nice memory bandwidth, no it hasn't.)
- who will implement the rewrite of id tech 3? That looks like a big task according to your description.

 

[mali]

- who will implement the rewrite of id tech 3? That looks like a big task according to your description.

There is so much prestige to gain, that most certainly someone will be willing to try it, when/if the source is released

 

[darkblu]

This raises two questions:
- SGX is uma too Even if it's tile based this will have an impact. (And for those who think Omap3 has a nice memory bandwidth, no it hasn't.)
- who will implement the rewrite of id tech 3? That looks like a big task according to your description.

- you're right that omap3's bandwidth can be a reason for concern (bandwidht always is), but the platform's uma limitations would affect SGX's geometry binning performance, not the framebuffer one - the latter is as optimal as it gets - massive bandwidth to tile, everything framebuffer-related goes to uma only as highly-efficient (tile-chunked) burst-transfers.

- well, anybody with sufficient understanding of shaders, a bit of understanding of game engines, and some will. i suspect there are at least several local dwellers who'd immediately qualify, that last will part non-withstanding ; )

 

[Exophase]

Let's be pessimistic about this and assume, that SGX is significantly slower in vertex processing and bandwidth departments...
I think we can all agree that in the same time it's more programmable.

Let's brainstorm what can we do about this...

Something from top-of-the-head:

• geometry processing done on NEON
  ...vertex shader, clipper and setup for sure, possibly functions of hull, domain and geometry shaders
• rendering to custom texture format (possibly 2-pass)
  ...YUV-alike, quincunx (checkerboard) luma subsampling, 1/8 chroma (4x less bandwidth)
• custom up-sizing via DSP
  ...edge-directed upsizer for luma and chroma to YUV422 (maybe something like this or this(IEEE subscription needed))
• final YUV->RGB conversion via overlay

This could give us a full 800x480 with good quality of luma (most visual information is there) and still acceptable quality of chroma at 1/4 of bandwidth cost of full rendering. Not sure about 'setup time' though...
I think I'll do some crude upsampling experiments in the weekend. B)

Other ideas ?



I don't know what the CPU requirements of Doom 3 are like, or what they can be made to be like, but if the Cortex-A8's full integer performance is needed to run the game logic then it'll be difficult or even impossible to run NEON geometry code at the same time.

The up-sampling and color conversion sounds cool but I would say getting something at 400x240 would be an important enough first step. It's a neat idea in general though, but I was wondering how much support in hardware SGX has for YUV, or how much is necessary (for instance for alpha blending, correct me if this can be done blindly as if they were RGB textures)