Xbox 2 hardware overview leaked?

[Fafalada]

Of course, it means one more ball to juggle for programmers, possibly leading to mental meltdown for those less talented, unless schemes such as these can be easily/transparently managed through devkit or middleware.

It's not "that" bad - we've used something along this lines for IPU textures - and frankly having a 'decompression unit' that you program yourself would make things easier. As it is, the way IPU is implemented forces me to use more CPU interaction than I would like, which consequently limits the scale of application for the scheme.

Also, how much performance would have to be devoted to this scheme to make it useable? IE to have all textures uncompressed & ready to use when they're needed.

There's a lot of things that you'd need to answer first - what kind of compression algorythm, do you compress every texture this way or just certain subset(s), do you always uncompress on the fly or use a level of caching... etc.

 

[Farid]

edit: however it looks like I missed something else too

Each of these pixels can be expanded through multisampling to
4 samples, for up to 32 multisampled pixel samples per clock cycle.
With alpha blending, z-test, and z-write enabled, this is equivalent
to having 256 GB/sec of effective bandwidth! The important thing is
that frame buffer bandwidth will never slow down the Xenon GPU.

equivalent to 256 GB/sec of effective bandwidth.

<feeling better now>

It's more a PR "best case scenario" than anything else, IMHO.

Each of these pixels can be expanded through multisampling to
4 samples, for up to 32 multisampled pixel samples per clock cycle.
With alpha blending, z-test, and z-write enabled, this is equivalent
to having 256 GB/sec of effective bandwidth! The important thing is
that frame buffer bandwidth will never slow down the Xenon GPU.

It's not really panacea, actually...

For my my part, what intrigues me is that 10Mo (Yes, octets! ) EDram...
What will it be used for? like 991060 said 1280x720p (since its looks like being Next-gen "base" Resolution) buffers will just fit on those 10Mo,... Without any AA.

 

[AlNom]

is 720p < 480p w/AA? (eDram or image quality)

 

[jvd]

is 720p < 480p w/AA? (eDram or image quality)

the higher the res the more it naturaly smooths the lines .

SO i would say 720p is better than 480p with 2x aa but they may be equal if 480p has 4x aa .

I think we are going to see the ati chip in this running with 32 megs of on board ram. Which shoudl be enough for 720p with 6x fsaa.

Also doesn't the r3x0 and r42x compress the framebuffer while using aa ?

 

[jvd]

here is what i'm talking about

Another element to HYPER Z III is loss-less Z compression. This results in no image issues but can compress the Z buffer, reducing the bandwidth needed for Z buffer reads or writes. ATI claim a minimum of a 2:1 compression ratio and a best case of 4:1 during normal rendering. However, when FSAA is enabled the compression ratios will nearly scale linearly with the FSAA sample number, so, for instance, with 6X FSAA applied the best compression ratio achieved will be 24:1. Including this for FSAA operations can significantly reduce the overhead for FSAA processing.

Alongside Z buffer compression, R300 also feature colour compression when FSAA is enabled. Because of the way multisampling operates much of the subsamples contain the same colour data, its only at polygon intersections are there ever more than one colour value over all the subsamples. R300 is able to compress the colour samples and achieve a very high compression ratio with mulitsampling.

Finally HYPER Z III also features Fast Z Clear. Between each rendered frame the Z buffer needs to be reset, which means the values of the z buffer have to be cleared. If the display resolution is set to 1600x1200 roughly 7.7MB of data must be cleared and if this is being done on an individual basis this can both take time and bandwidth. HYPER Z III clears the Z buffer in blocks which requires only 1/64 of the amount of data to be passed

 

[AlNom]

this is what I could find....

Another element to HYPER Z III is loss-less Z compression. This results in no image issues but can compress the Z buffer, reducing the bandwidth needed for Z buffer reads or writes. ATI claim a minimum of a 2:1 compression ratio and a best case of 4:1 during normal rendering. However, when FSAA is enabled the compression ratios will nearly scale linearly with the FSAA sample number, so, for instance, with 6X FSAA applied the best compression ratio achieved will be 24:1. Including this for FSAA operations can significantly reduce the overhead for FSAA processing.

Alongside Z buffer compression, R300 also feature colour compression when FSAA is enabled. Because of the way multisampling operates much of the subsamples contain the same colour data, its only at polygon intersections are there ever more than one colour value over all the subsamples. R300 is able to compress the colour samples and achieve a very high compression ratio with mulitsampling.

don't know if this is what you're referring to...



edit: aha.....whoops, missed your post as I was reading

 

[jvd]

yes part of it. I posted the rest above u

How does that affect what can be done with the 10megs .

 

[jvd]

from the x800 review

SMOOTHVISION HD
3Dc Normal Map Compression
High quality 4:1 Normal Map Compression
Works with any two-channel data format
2x/4x/6x Multi-Sampling full scene Anti-Aliasing modes, adaptive algorithm with programmable sample patterns and colour buffer compression
Temporal Anti-Aliasing
Lossless Color Compression (up to 6:1)at all resolutions, including widescreen HDTV resolutions
2x/4x/8x/16x anisotropic filtering modes
HYPER Z HD
3-level Hierarchical Z-Buffer with early Z test
Lossless Z-Buffer compression (up to 48:1)
Fast Z-Buffer Clear
Z Cache Optimisations for shadow rendering
Optimized for performance at high display resolutions, including widescreen HDTV resolutions

So it apears they are slowly getting better at the compresion.

 

[Thowllly]

yes part of it. I posted the rest above u

How does that affect what can be done with the 10megs .

I doesn't affect it all. Since it's lossless compression, no level of compression can be guarantied. Therefore a full size buffer has to be allocated. It only saves bandwidth, not memory.

 

[AlNom]

alrighty... who's with me and wants to raid MS and force them to give us 64MB of eDram for Xenon?

 

[jvd]

yes part of it. I posted the rest above u

How does that affect what can be done with the 10megs .

I doesn't affect it all. Since it's lossless compression, no level of compression can be guarantied. Therefore a full size buffer has to be allocated. It only saves bandwidth, not memory.

well at least the meager bandwidth isn't a big deal

 

[Megadrive1988]

if you recall, back in 1999, the Flipper was reportedly getting 8 to 16 MB of on-chip / embedded 1T-SRAM, before the GameCube got unvieled with only 3+ MB of on-chip 1T-SRAM.

Xenon's 10 MB of on-chip GPU memory is on the low side of what was, at first, expected for the previous generation Dolphin/GameCube.

I do hope the Xenon document and block diagram are grossly outdated if they are in fact legit. 32 MB of on-chip GPU memory would indeed be nice, jvd. that is the same amount of memory as the I-32 version of GS used in GSCube.


32 MB would allow for 720p or 1080i and plenty of AA would it not?

 

[psurge]

Wasn't the EDRAM on that block diagram off-chip?

 

[Squeak]

Of course, it means one more ball to juggle for programmers, possibly leading to mental meltdown for those less talented, unless schemes such as these can be easily/transparently managed through devkit or middleware.

It's not "that" bad - we've used something along this lines for IPU textures - and frankly having a 'decompression unit' that you program yourself would make things easier. As it is, the way IPU is implemented forces me to use more CPU interaction than I would like, which consequently limits the scale of application for the scheme.

So you did get IPU decompression of textures to work? I just remember you, or someone else saying something along the lines of, “that it is a nice feature to have, but not very useful or practical in a real gameâ€￾?
Maybe you found a way to compress and decompress swizzled 4bit textures?

But back on topic. I think real time decompression (as opposed to pre-decompression of data and storing them in intermediate buffer), with the assistance of supplied libraries or proprietary software, on the VPU, is the way forward. Not only for textures but also for geometry and sound.
With the sheer amount of computational power that is going to be available next gen, having dedicated hardware for “smallâ€￾ tasks like sound, IO and decompression ,is simply a waste of die space, better used for general power.

 

[Megadrive1988]

Wasn't the EDRAM on that block diagram off-chip?

I could be mistaken, but I thought EDRAM implies embedded memory. embedded onto the chip itself.

 

[Squeak]

Wasn't the EDRAM on that block diagram off-chip?

I could be mistaken, but I thought EDRAM implies embedded memory. embedded onto the chip itself.

Actually it's enhanced DRAM. The enhanced part being that it has a SRAM cache imbedded on the die.

 

[hey69]

OT :isn't Panajev posting here anymore?

 

[Guden Oden]

having dedicated hardware for “smallâ€￾ tasks like sound, IO and decompression ,is simply a waste of die space, better used for general power.

Well, you can't generalize away the I/O functions. CPUs don't interface directly with twisted-wire ethernet interfaces or DVDROMs or joypad ports and such.

Decompression might not be such a small task either, look at the hardware demands for HDTV-res WM9 video codec for example. P4 @ 2+ GHz, blecccchhhh...

 

[DeanoC]

edit: the calculation of required framebuffer size is based on no AA situation. when using 4xAA, the number will grow up to 30MB??!! :?

No it wouldn't if its MSAA, a 1280x720 4xMSAA (32bit colour and depth) would take 18Mb.

A 1280x720 2xMSAA would take 11Mb.

 

[jvd]

edit: the calculation of required framebuffer size is based on no AA situation. when using 4xAA, the number will grow up to 30MB??!! :?

No it wouldn't if its MSAA, a 1280x720 4xMSAA (32bit colour and depth) would take 18Mb.

A 1280x720 2xMSAA would take 11Mb.

How about 6x deanoc ?

Anyway they can allways use temporal aa . If any of u have a r3x0 or r42x use rad linker and force it on. IT works very well and with a 60hz refresh rate they should haven o problems running it