Intel Gma 500 = Sgx 535

[AireTamStorm]

says they benched the Dell Mini 12 with a 697 score on 3D mark 2001!

3D Mark 2001 isn't a very good demo, as it only benchmarks the "raw" performance of modern cards. In other words, clock rate is more important than feature set. The SGX has much more advanced shaders than what was around in 3DMark 2001's era.

Doom 3 is most likely doable at the Pandora's resolution thanks to its advanced, highly efficient shaders.* The OMAP hardware smokes any other handheld out in the mass market, is that not enough for you all? :lol:



*All other factors ignored.

 

[darkblu]

Something from top-of-the-head:

• <snip>
• 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 ?


well, everything you say above pertains 100% to the ps3 ; )

let me throw in a common point of consideration:

just like every compression scheme, the YUV rendition is a neat bandwidth solution when you have fat pixels to write, and shader rate to burn. like on ps3's shader-capable, bandwidth-limited RSX, where there's at least one commercial project doing multi-sampled HDR rendition like this (heavenly sword - see below).

on the panda's SGX, we're not exactly in this situation - while we don't have any bandwidth (outside of the direct link to our tile buffer) we also don't have shader rate to burn. and the tile buffer, low and behold, cannot output below 16bpp, to the best of my knowledge. so it does not matter if you do fancy YUV rendition or plain 16bpp RGB - you would not save youself one bit of bandwidth.

so, what's left? i'd say a brute-force approach like compressing the bejesus out of your static textures, includingly those you'd not normally compress (at least not with the given schemes), would be the way to allow yourself some bandwidth headroom.

as for render-target textures, well, choose your pixel format wisely, and most importantly, don't go overboard with resolutions.

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)

IIRC, lerping in YUV does not give you exactly alpha-blending, but it's not that much different either. for the interested, check out Marco Salvi's (AKA nAo@B3D) accounts on what he did in heavenly sword (i.e. NAO32 pixel format) to save fp framebuffer bandwidth and allow hw fsaa on the RSX. basically, he implemented logarithmic luma for their HDR rendering.

http://forum.beyond3d.com/showthread.php?t=42689
http://pixelstoomany.wordpress.com/2008/07...for-the-future/

 

[ldesnogu]

http://forum.beyond3d.com/showthread.php?t=42689

Now I know why your login name sounded familiar

 

[maciek_urbanski]

just like every compression scheme, the YUV rendition is a neat bandwidth solution when you have fat pixels to write, and shader rate to burn. like on ps3's shader-capable, bandwidth-limited RSX, where there's at least one commercial project doing multi-sampled HDR rendition like this (heavenly sword - see below).

Yes, but YUV is not for compression here.

It's just a bit-by-bit linear transform fo color space and I'm suggesting it only, because since human visual system has so much lower perception to chrominance that it can be sub-sampled spatially.
At the same time luminance carries most visual stimuli - so we shouldn't sub-sample it too much.
Essentially we create two separate images, one 1 component/pixel (luma) and other 2 components/pixel (chroma). To do this we need (probably) two-pass rendering.

Spatially when those two images would be interleaved samples would look like this:
CODE

Y Y
vYuY
Y Y
vYuY



So instead of rendering 3 components/pixel shaders would only do 12/16 components/pixel (4x less). That's essentially 4x less shader invocations, on 4x more shader instructions at fixed fame rate...

Luma interpolation on quincunx grid is well researched problem (it's done in every camera with Bayer filter for green channel). The same goes for luma-directed chroma upsampling, so I'm suggesting reconstruct this data to YUV422 image (or even RGB) from this two images non-linearly using DSP.

so, what's left? i'd say a brute-force approach like compressing the bejesus out of your static textures, includingly those you'd not normally compress (at least not with the given schemes), would be the way to allow yourself some bandwidth headroom.

I have strong hunch, that texture bandwidth will be not too big issue, but I'm worried about shader length for given frame rate... Limiting shader invocation count will essentially give us ability to write longer shaders.

IIRC, lerping in YUV does not give you exactly alpha-blending, but it's not that much different either. for the interested, check out Marco Salvi's (AKA nAo@B3D) accounts on what he did in heavenly sword (i.e. NAO32 pixel format) to save fp framebuffer bandwidth and allow hw fsaa on the RSX. basically, he implemented logarithmic luma for their HDR rendering.

http://forum.beyond3d.com/showthread.php?t=42689
http://pixelstoomany.wordpress.com/2008/07...for-the-future/


That's nice trick to create HDR. Others abuse sRGB textures/render targets for it (Source Engine can do it and it's a pain in the butt for some architectures).
I'd have to experiment to create reconstruction kernels that perform good in log-space, but I definitely will keep this in mind. B)

 

[darkblu]

Yes, but YUV is not for compression here.

bah. sorry, maciek, for blatantly missing your original point. i should have realised i was on the wrong track the moment i rigorously reached the conclusion we could not go below 16bbp out of the tile buffer :lol:

of course you're right - a sparse chroma scheme can be used as a fillrate saver too. don't mind me next time ; )

http://forum.beyond3d.com/showthread.php?t=42689

Now I know why your login name sounded familiar

darn. i blew my cover.