More Xenon rumors

[Panajev2001a]

does that mean the 10 MB is not embedded into Xenon's graphics processor?

Not in this diagram

it's 10MB of EDRAM (external) Not eDRAM

How misleading.

I still find it strange how 3dfx decided 4MB was the bare minimum a 3d accelerator needed to have to be useful, but nintendo got by on compression and transferring to main memory, and now xbox 2 is only going to have 10MB of dedicated ram? Come on, you can't even do 32bit color in that!

Tiling is a concept that you should seek help into .

 

[Vince]

Can someone whose informed be kind enough to explain what exactly this EDRAM is and what it's composed of? I, for one, assumed it was eDRAM (of the embedded kind of course) which seemed logical....

 

[Fox5]

does that mean the 10 MB is not embedded into Xenon's graphics processor?

Not in this diagram

it's 10MB of EDRAM (external) Not eDRAM

How misleading.

I still find it strange how 3dfx decided 4MB was the bare minimum a 3d accelerator needed to have to be useful, but nintendo got by on compression and transferring to main memory, and now xbox 2 is only going to have 10MB of dedicated ram? Come on, you can't even do 32bit color in that!

Tiling is a concept that you should seek help into .

So are you trying to say xbox2 will support tbdr like dreamcast, or that it supports tiling like all modern video cards which does something to help with memory?

 

[aaaaa00]

It says in that diagram that Z/Stencil tests, alpha blending and MSAA are done INSIDE the edram, so none of the bandwidth for that stuff has to leave the edram and go back to the GPU.

So you can knock that stuff off the memory bandwidth requirements as well.

*Assuming the diagram isn't BS, which it very well might be.

 

[aaaaa00]

So are you trying to say xbox2 will support tbdr like dreamcast, or that it supports tiling like all modern video cards which does something to help with memory?

In order to support HDTV resolutions, it will have to support something like dreamcast tiling.

The leaked document (which again, may be total BS) speaks of "hardware-accelerated partitioning and predicated rendering that has little cost other than additional vertex processing".

Sounds a bit like deferred rendering, plus binning and rendering the framebuffer in chunks to me...

You've got to remember, back in 1996 MS Graphics Research came up with a design for a layer composited, deferred, chunk based HW rendering engine called Talisman.

It was never really finished because the chip was too complex to fab and by that time IMRs like 3DFX had already pretty much taken over the market for PC 3D hardware.

 

[Panajev2001a]

So are you trying to say xbox2 will support tbdr like dreamcast, or that it supports tiling like all modern video cards which does something to help with memory?

Tiling does not have to mean deferred rendering.

It might mean it or not.

 

[aaaaa00]

Tiling does not have to mean deferred rendering.

It might mean it or not.

What do you think "predicated rendering" is?

Maybe you can delay actually rendering the actual object until after you can decide if its visible or not.

 

[Panajev2001a]

Tiling does not have to mean deferred rendering.

It might mean it or not.

What do you think "predicated rendering" is?

Maybe you can delay actually rendering the actual object until after you can decide if its visible or not.

Predicated... that the Hardware starts teaching you about the Bible ?

I dunno .

.

 

[Quaz51]

Can someone whose informed be kind enough to explain what exactly this EDRAM is and what it's composed of? I, for one, assumed it was eDRAM (of the embedded kind of course) which seemed logical....

EDRAM

EDRAM (enhanced dynamic random access memory) is dynamic random access memory (dynamic or power-refreshed RAM) that includes a small amount of static RAM (SRAM) inside a larger amount of DRAM so that many memory accesses will be to the faster SRAM. EDRAM is sometimes used as L1 and L2 memory and, together with Enhanced Synchronous Dynamic DRAM, is known as cached DRAM.
Data that has been loaded into the SRAM part of the EDRAM can be accessed by the microprocessor in 15 ns (nanoseconds). If data is not in the SRAM, it can be accessed in 35 ns from the DRAM part of the EDRAM.

 

[Panajev2001a]

16 ns... uhm... 500 MHz GPU = 2 ns for cycle time.

That is a latency of only 8 cycles: nice to see ATI going back to 1-T SRAM.

 

[AlNom]

My friend has a 1.4GHz Tualatin in his and a 120GB 7200rpm HDD...

how's that working? better framerates?

You can put in all those things. Fastest and still compatible cpu available is a normal pentium 3.(there's also a 1.4ghz celeron, p4 based maybe? but it breaks compatibility with many games) You can't put in faster ram(where would you buy it, and how would the motherboard recognize it?) you can double the ram as well, and you can replace the harddrive completely, as well as add in an 80 pin cable(instead of 40) to speed up load times.

I don't get how you say that you can't put in faster ram, but you can double the ram and....still recognize

*daydreams about faster load times*

 

[aaaaa00]

Can someone whose informed be kind enough to explain what exactly this EDRAM is and what it's composed of? I, for one, assumed it was eDRAM (of the embedded kind of course) which seemed logical....

EDRAM

EDRAM (enhanced dynamic random access memory) is dynamic random access memory (dynamic or power-refreshed RAM) that includes a small amount of static RAM (SRAM) inside a larger amount of DRAM so that many memory accesses will be to the faster SRAM. EDRAM is sometimes used as L1 and L2 memory and, together with Enhanced Synchronous Dynamic DRAM, is known as cached DRAM.
Data that has been loaded into the SRAM part of the EDRAM can be accessed by the microprocessor in 15 ns (nanoseconds). If data is not in the SRAM, it can be accessed in 35 ns from the DRAM part of the EDRAM.

I suppose that means eDRAM can be made from EDRAM. ;-)

 

[Guden Oden]

In order to support HDTV resolutions, it will have to support something like dreamcast tiling.

I'd say it is more likely it supports something like GC tiling instead, which is exactly what the document alludes to when it states 'little cost other than additional vertex processing'. That is exactly what happens in GC when you do antialiasing. It transforms data, sends it to Flipper which draws half the screen and dumps it to main RAM, then re-sends geometry and draws the remaining lines.

You've got to remember, back in 1996 MS Graphics Research came up with a design for a layer composited, deferred, chunk based HW rendering engine called Talisman.

From what I have been able to glean about talisman, it's that like everybody HATED that concept, and that it was impractical and stupid and that's why it never took off. Not that it was too complex to be manufactured. It was simply a design taken in the wrong direction, and over-engineered to boot. Typical MS brainchild in other words.

 

[aaaaa00]

In order to support HDTV resolutions, it will have to support something like dreamcast tiling.

I'd say it is more likely it supports something like GC tiling instead, which is exactly what the document alludes to when it states 'little cost other than additional vertex processing'. That is exactly what happens in GC when you do antialiasing. It transforms data, sends it to Flipper which draws half the screen and dumps it to main RAM, then re-sends geometry and draws the remaining lines.

So what's the big difference between PVR-tiling and GC-tiling?

PVR-tiling (correct me if I'm wrong) you have a small fast on-chip buffer, you bin the triangles first, resolve Z (on-chip), then only render the visible polygons (on-chip), then you copy the on-chip buffer out to main memory...

My guess is on xenon, you have a large fast EDRAM (on-chip?) buffer, you have hardware accelerated "binning" ("hardware accelerated partitioning"), you can render a z-only pass to resolve visibility (z-only is apparently much faster), then run your expensive pixel shaders on only the visible ones ("predicated rendering?"), then copy out the framebuffer out to main memory...

Am I wrong? What's the real difference between this and PVR tiling, other than the size of the on-chip "tile" you're rendering?

You've got to remember, back in 1996 MS Graphics Research came up with a design for a layer composited, deferred, chunk based HW rendering engine called Talisman.

From what I have been able to glean about talisman, it's that like everybody HATED that concept, and that it was impractical and stupid and that's why it never took off. Not that it was too complex to be manufactured. It was simply a design taken in the wrong direction, and over-engineered to boot. Typical MS brainchild in other words.

It had several problems:

It was something like a 3 chip design, and this made it too expensive to build. One chip designs won. Two chip designs (like Voodoo 1) were niche.

It was completely oriented towards saving memory. Which became obsolete as memory prices suddenly plummeted.

And the layer composition thing ended up being a bad idea.

However, it was a full chunking and on-chip Z tiling architecture. (Which was another thing a bunch of people hated at the time.)

 

[Gubbi]

In order to support HDTV resolutions, it will have to support something like dreamcast tiling.

I'd say it is more likely it supports something like GC tiling instead, which is exactly what the document alludes to when it states 'little cost other than additional vertex processing'. That is exactly what happens in GC when you do antialiasing. It transforms data, sends it to Flipper which draws half the screen and dumps it to main RAM, then re-sends geometry and draws the remaining lines.

So what's the big difference between PVR-tiling and GC-tiling?

PVR-tiling (correct me if I'm wrong) you have a small fast on-chip buffer, you bin the triangles first, resolve Z (on-chip), then only render the visible polygons (on-chip), then you copy the on-chip buffer out to main memory...

My guess is on xenon, you have a large fast EDRAM (on-chip?) buffer, you have hardware accelerated "binning" ("hardware accelerated partitioning"), you can render a z-only pass to resolve visibility (z-only is apparently much faster), then run your expensive pixel shaders on only the visible ones ("predicated rendering?"), then copy out the framebuffer out to main memory...

Am I wrong? What's the real difference between this and PVR tiling, other than the size of the on-chip "tile" you're rendering?

Two things. You're pushing geometry through your GPU twice, once to render Z and once to test-and-draw.

And you actually "draw" (store) Z-values for all pixels in all polygons. Whereas in a PVR deferred renderer you process each pixel to its completion at a time, - by resolving visibility of all polygons (lots of Z-comparators) in a tile. If there are more polygons in a tile than there are >-comparators (I believe there were 32 comparators in Kyro) it has to use multiple passes (and hence multiple cycles)

In a PVR deferred renderer tiles serves two purposes: 1.) The reduced number of pixels means that on-die buffers can hold Z, colour etc. 2.) reduces polygon complexity in a tile, lowering the average amount of Z-comparators needed.

Cheers
Gubbi

 

[Fafalada]

So what's the big difference between PVR-tiling and GC-tiling?

One is hardware accelerated, the other is not.

 

[PiNkY]

Remotely related:

http://www.semiconductor.com/resources/press_releases/2004_06_28_1.asp?c=11627

seems IBM already laid the foundation for a 3 core Power4/5 based CPU considering their impressive size reduction of ppc 970fx.

 

[aaaaa00]

In a PVR deferred renderer tiles serves two purposes: 1.) The reduced number of pixels means that on-die buffers can hold Z, colour etc. 2.) reduces polygon complexity in a tile, lowering the average amount of Z-comparators needed.

Purpose 1 sounds like a minimal advantage if you have on-chip/fast EDRAM.

I'm not sure how purpose 2 relates.

I guess the only thing that might really hurt you is the double traversal of the polygon list.

??

 

[Gubbi]

In a PVR deferred renderer tiles serves two purposes: 1.) The reduced number of pixels means that on-die buffers can hold Z, colour etc. 2.) reduces polygon complexity in a tile, lowering the average amount of Z-comparators needed.

Purpose 1 sounds like a minimal advantage if you have on-chip/fast EDRAM.

I'm not sure how purpose 2 relates.

ad. 1: Consider doing 6x MSAA (or better) on a 1600x1200 buffer. You'll need 8 MB (or 6MB for 24bit Z) for the primary Z-buffer and a good chunk of sidebuffer to store the extra compressed Z-samples in. You'll need massive amounts of on die eDRAM. With the TBDR approach you can do massive MSAA with relatively little extra cost (a little more SRAM and more comparators.)

ad. 2: Doesn't relate to IMRs, but since a TBDR has to check all polygons against all other polygons in a tile for visibility, reducing the number of polygons per tile is paramount.

Cheers
Gubbi

 

[Simon F]

ad. 2: Doesn't relate to IMRs, but since a TBDR has to check all polygons against all other polygons in a tile for visibility, reducing the number of polygons per tile is paramount.

That'd be an O(N^2) algorithm which'd be insane. No-one in their right mind would do that. Visibility testing is O(N) just as it is for an IMR.