new (?) Rambus XDR memory and PlayStation 3 information

[DeanoC]

Here is a question. Would you rather have 256 MB of memory with ~ 50 GB/s bandwidth or 512 MB with ~ 25 GB/s bandwidth? I might have to go for the latter since eDRAM can do wonders for helping out in the most critical cases of bandwidth.

Great question
I'd have to look at the rest of the architecture, but (for arguments sake) assuming we get a TFLOP I'd vote 256Mb with 50GB/s, its a hard call but 25 GB/s is tight for roughly half a TFLOP. Even eDRAM only helps, just supplying the vertex/texture requirements of next-gen consoles is terrifying.

512 Gb would be great but if the arithmetic units are starved would good would it do. Better to have more bandwidth and use compression and procedural effects to fill in details IMHO.

As nAo says compression is the future in a big way. Lets hope Sony license S3TC this time (last generation they were the only ones who didn't support it).

 

[nAo]

As nAo says compression is the future in a big way. Lets hope Sony license S3TC this time (last generation they were the only ones who didn't support it).

S3TC is for loosers, real men use wavelets based compression schemes
8)

 

[j^aws]

As nAo says compression is the future in a big way. Lets hope Sony license S3TC this time (last generation they were the only ones who didn't support it).

S3TC is for loosers, real men use wavelets based compression schemes
8)

Sony hates licensing other techs if possible! It'll probably force ATRAC compression on us!

 

[ERP]

Here is a question. Would you rather have 256 MB of memory with ~ 50 GB/s bandwidth or 512 MB with ~ 25 GB/s bandwidth? I might have to go for the latter since eDRAM can do wonders for helping out in the most critical cases of bandwidth.

Great question
I'd have to look at the rest of the architecture, but (for arguments sake) assuming we get a TFLOP I'd vote 256Mb with 50GB/s, its a hard call but 25 GB/s is tight for roughly half a TFLOP. Even eDRAM only helps, just supplying the vertex/texture requirements of next-gen consoles is terrifying.

512 Gb would be great but if the arithmetic units are starved would good would it do. Better to have more bandwidth and use compression and procedural effects to fill in details IMHO.

As nAo says compression is the future in a big way. Lets hope Sony license S3TC this time (last generation they were the only ones who didn't support it).

Without more details it's a difficult call, personally I'd probably take the extra memory.

Realistically you need to know a lot of other things about the system before you can make the call. Latency is an issue as are the mechanisms available to hide it. Along with the intended use (by which I mean the interplay of the systems).

The system designer should have a pretty good idea of how the system will be used and what the cost (performance wise) of the reduced bandwidth will be, he's really the only one in a position to make the call until developers have actually used it.

At some levels the only real challenge in optimising performance of a system is managing bandwidth, however a system designer providing 2x bandwidth at point A does no one any good if the system is costrained at point C.

 

[DeanoC]

As nAo says compression is the future in a big way. Lets hope Sony license S3TC this time (last generation they were the only ones who didn't support it).

S3TC is for loosers, real men use wavelets based compression schemes
8)

So thats where a TFLOP is going, realtime on demand decompression of wavelets

Seriously no sane GPU this (or is it next, its quite confusing for me these days) will be using a variable texture decompression. BUT a CPU based texture cache system using wavelets is verylikely ;-)

 

[nAo]

So thats where a TFLOP is going, realtime on demand decompression of wavelets

Not if your wavelets scheme fits exactly/is merged into your mesh subdvision surface scheme..emh
OK..a little more FLOPs are needed anyway..

Seriously no sane GPU this (or is it next, its quite confusing for me these days) will be using a variable texture decompression.

Agreed. In fact I envisioned that on a CELL-like architecture where a lot of APUs are grouped and connetched to each other to form a custom pipeline.

BUT a CPU based texture cache system using wavelets is verylikely ;-)

I'm writing a function curves engine (to be used with basic SRT animations or skeletal animations) on that principle..

ciao,
Marco

 

[DeanoC]

Sony hates licensing other techs if possible! It'll probably force ATRAC compression on us!

Don't joke about these things, knowing Sony they will come up with a custom method that compresses blues and red really well but make green look crap.

We will spend all our time finding ways of producing nuggets of purest green.

"can it be true? that I hold here, in my mortal hand, a nugget of purest green?" (name that classic British comedy )

 

[j^aws]

Sony hates licensing other techs if possible! It'll probably force ATRAC compression on us!

Don't joke about these things, knowing Sony they will come up with a custom method that compresses blues and red really well but make green look crap.

We will spend all our time finding ways of producing nuggets of purest green.

"can it be true? that I hold here, in my mortal hand, a nugget of purest green?" (name that classic British comedy )

Sir, I have a cunning plan! We can use a 1Tflop chip to render the purest precious 'green'!

 

[GwymWeepa]

As nAo says compression is the future in a big way. Lets hope Sony license S3TC this time (last generation they were the only ones who didn't support it).

S3TC is for loosers, real men use wavelets based compression schemes
8)

In a nutshell please explain that, I've heard that mentioned here and there on these forums.

 

[j^aws]

As nAo says compression is the future in a big way. Lets hope Sony license S3TC this time (last generation they were the only ones who didn't support it).

S3TC is for loosers, real men use wavelets based compression schemes
8)

In a nutshell please explain that, I've heard that mentioned here and there on these forums.

Try this link: Wavelet Compression

 

[DeanoC]

In a nutshell please explain that, I've heard that mentioned here and there on these forums.

Deep breath... (anybody feel free to correct me, this isn't a speciality).

Wavelets are a way of breaking a function into components, analogous to the fourier method (as used in compression system like MPEG2). Wavelets have some nice mathemical properties that make them handy for graphics compression.

The properties most interesting for compression is that you can throw large amounts of data away without the picture degrading that much. They don't produce block artifects as much as DCT (fourier) based compressions, the artifacts they produces are less noticeable in most real world images (its best described as a softening and ringing around high frequencies).

JPG2000 is based on wavelets rather than DCT. The general feeling among the image compression community is that DCT have outlived its usefulness and wavelets are the next generation of image compression algorithms.

They do take a large amount of CPU to decompress though, hence only just coming into use.

 

[nAo]

In a nutshell please explain that, I've heard that mentioned here and there on these forums.

Wavelets are a way to de-correlate a signal, to extract and split datas on different scales and resolutions. A signal (like a texture) represented trough wavelets can be quickly decomposed (this phase is called analysis) in a low resolution part and a detail part. Details can be easily removed from the final image, thus the texture can be compressed.
When one needs the decompressed data has to invert the analysis procedure (this phase is called synteshis), thus decompressing the data.
Synthesis may be very fast and easy to implement!

ciao,
Marco

 

[GwymWeepa]

Thanks folks!

 

[DeanoC]

I do find it reassuring that two developers (Marco and I) disagree on whats expensive or not ;-)

Developers never agree on anything, its the natural order of things we are like witches in that manor (ala Pratchett)

Of course I'm right

 

[j^aws]

Thanks folks!

I do think DeanoC's explanation could've been more compressed!

 

[ERP]

I do find it reassuring that two developers (Marco and I) disagree on whats expensive or not ;-)

Developers never agree on anything, its the natural order of things we are like witches in that manor (ala Pratchett)

Of course I'm right

Well technically your both right, just depends on the basis function and the number of taps it uses 8)

 

[nAo]

ahahaha
You're right Deano..synthesis can be very expensive, that's why I wrote synthesis may be easy to implement (and fast too..)
In the common case it's not..

 

[nAo]

Well technically your both right, just depends on the basis function and the number of taps it uses 8)

That's one point..the other one is how to cope in an efficient manner with zerotree decoding on a VS-like processor :?

ciao,
Marco

 

[MfA]

If you just take the outdated approach of counting arithmetic operations wavelets look great, so that is usually what its proponents do. The problem with on the fly methods is that they have to use fixed length coding ... as far as that is concerned, Sony would be better off licensing PVR-TC rather than S3TC

 

[Megadrive1988]

I been thinking about this for a while...I think the whole memory architectue needs to be taken as a whole. This includes the APU SRAM sizes/bandwidths, the PU cache size/bandwidth,

good points Jaws. I did not mention the APU SRAM size & bandwidth, the PU cache size & bandwidth, or the possibility of a harddrive, as well as other bandwidth conciderations. all important factors.