Xenos and its special features: Educated expectations needed READ: post #126!

When your console already have an extra 32mb's of VRAM compared to it's competitor, I fnd it quite a stretch to refer to this as a 'problem'. A tradeoff is the proper term.
 
When your console already have an extra 32mb's of VRAM compared to it's competitor, I fnd it quite a stretch to refer to this as a 'problem'. A tradeoff is the proper term.
512MB (-32MB for OS) is already a very limited environment to work with (for HD resolutions) and duplicating some data makes it worse, so I understand why zeckensack called it a problem. Plus you have to bother about proper workflow (which is more complicated with tiling), what was discribed by Fran on previous page.
 
512MB (-32MB for OS) is already a very limited environment to work with (for HD resolutions) and duplicating some data makes it worse, so I understand why zeckensack called it a problem.

It's all relative imo, 360 has an extra 64mb of ram compared to it's competitor, so if you call the available memory very limited, then the PS3 is in an even worse position. It does not matter how 360 compared to high end PC's as it doesn't compete with high end PC's.

You do not have to use tiling at all on Xenos, if you do, you must sacrifice a small slice of memory, seems to me it's the definition of the word tradeoff.
 
When your console already have an extra 32mb's of VRAM compared to it's competitor, I fnd it quite a stretch to refer to this as a 'problem'. A tradeoff is the proper term.
You really don't need to get the competition involved when you can choose between tiled and non-tiled rendering on the very same device :rolleyes:

Going tiled is a net-cost, especially when you do procedurals, period. If it were any different, you bet PS3 developers would start using it, too (wha? yay! Pling, ploing), but they don't because it's a net cost.
I can certainly live with "workaround".
 
How many times do you need to hear that there is no problem with automatic tiling + memexport, outside the need to do the memexport calculations before the scene render?
Are you a mod?

Cause, I don't have to bear your critics...
I've red the post and Fran comment very quickly at job and, I post very quickly a day after, without thinking to much about it... just to thank him for his comments...
 
Last edited by a moderator:
It's all relative imo, 360 has an extra 64mb of ram compared to it's competitor, so if you call the available memory very limited, then the PS3 is in an even worse position. It does not matter how 360 compared to high end PC's as it doesn't compete with high end PC's.

You do not have to use tiling at all on Xenos, if you do, you must sacrifice a small slice of memory, seems to me it's the definition of the word tradeoff.
Bigger memory usage isn't unfortunately the only drawback of tiling, you have to care more about workflow. I'm not saying it's not worth it, AA really improves image quality and with optimizations it doesn't make an engine much slower.
BTW I thoght the thread was about Xenos and 360, not consoles in general.;)
 
I can't understand this memory stuff..
If the gpu works on some huge data set, storage outside of chip will be needed... (ie ram)
If the cpu works on a huge data set, storage outside the chip will be needed...

If the data fit "on chip" it's very likely that the memory space involved is insignificant.


Anyway I don't expect a lot of stuff from havoc, Ms would have to push them somewhat...
But, I'm sure that they could push something special with the right "motivation" lol.
 
i
Whereas if you have just a single "tile" (i.e. no tiles at all actually), you can "fire and forget" batches of geometry. You don't even need temporary buffers, as you can push them over the caches through the GPU directly into the final frame buffer. Even if you don't do that (shadow volume extrusion, fine-grained culling, yadda yadda), you can break the "we generate our procedurals here" sub-period of the frame into as many small chunks as you want, each time just working on small amounts of data (extrude one model, render shadow, then discard the extrusion to make room for the next -- that sort of thing). You cannot do any of that with data you want to feed into a tiled render. It needs to be saved for later.

That's not entirely true, you see: you can still "fire and forget" when tiling and you can still push geometry through the cache without saving it to memory. The point is if it's more efficient or not to do so, since you can potentially pay the cost of locking part of the cache and using up CPU cycles once per tile (depending on what you are trying to render). The GPU is often not the bottleneck that you want to offload work to the CPU.

I'm not entirely convinced XPS is a viable solution in many cases.

As always, the devil is in the details. I just find it pretty dishonest to claim that there are no problems coming from tiled rendering or even rebadging every solution to a problem as a "different way of doing things". Memory footprint for keeping procedurals is a cost, as resources are taken away from other tasks. That's just about the definition of "problem" no matter how you slice it.

That is so very true. Tiling has a cost. memexport has a cost, XPS has a cost. Whether this cost is in terms of memory, bandwidth or CPU/GPU cycles or development time.

Fran in Rome
 
Fran and others please enlight me...

Which type of effect and technology is involved in this technique of this link for Global Illumination ?


http://news.teamxbox.com/xbox/12902/Geomerics-Announces-Enlighten-for-the-Xbox-360/

(some kind of precomputed radiance transfer ?)

Last I heard they are using a completely new form of computation for their rendering sub-systems which is based around something called Geometric algebra...

I read a little about their work a while back (Edge magazine) and tried to google for info on geometric algebra but came up a little short..

Here's some quotes from a press release on the website:-

Geomerics new solution to computing real time radiosity is demonstrated on their website: http://www.geomerics.com/lighting. The solution achieves frame rates of up to 100Hz on common graphics hardware, and allows for fully dynamic lighting including point spot-lights, area lights, texture-based lighting, glowing objects and the projection of video onto geometry. The full indirect lighting calculation includes the soft-shadows that characterize real-world scenes. Geomerics' technology also integrates smoothly with classic techniques such as normal and gloss mapping, and fully supports HDR (high dynamic range) lighting effects.
Wavelet PRT

Geomerics' second algorithm is a development from spherical harmonic PRT lighting.

In 2002 Peter-Pike Sloan et al. popularised a lighting technique based on pre-computed radiance transfer (PRT) known as Spherical Harmonic PRT. The kernel of the technique is pre-computing a visibility function for each point on a surface and store this in a suitably compressed format. If the lighting environment can be computed at run time in a similar basis to the visibility function, then the full lighting integral can be reduced to a dot product. Peter-Pike Sloan's original suggestion was to use spherical harmonics as the compression basis. These have the advantage that they can easily incorporate a diffuse BRDF. He found that impressively realistic effects could be generated with as little as 16 coefficients.

There are fundamental restrictions and problems with using spherical harmonics. Compressing the lighting environment down to 16 terms can generate some unrealistic 'side-lobes', giving the impression of light being present where it does not exist in the 'true' image. Furthermore, the technique is effectively restricted to a diffuse BRDF and cannot easily handle glossy surfaces. Any attempt to include more complex BRDFs takes the method from being O(n) to essentially O(n3).

In 2004, Ng, Ramamoorthi and Hanrahan introduced a new method for PRT based wavelets. Their key observation was that the full lighting integral, with an arbitrary BRDF, would remain O(n) if one works with a Haar wavelet basis.Their technique produced some stunning results, but was not suitable for real-time calculations.

At Geomerics we have applied our experience with spherical wavelets to extend the wavelet PRT idea to a method that is genuinely real-time (up to 300Hz). The method incorporates a glossy BRDF and allows objects to move around. It can be extended to allow for moving light sources, and is every bit as compact as spherical harmonic lighting.

Screenshots are available below. The artwork is borrowed directly from the DirectX SDK for ease of comparison with spherical harmonic PRT. A video of the technique will be available soon.

Source: http://www.geomerics.com/index.php?...icleid=19&cntnt01origid=15&cntnt01returnid=39

Seems to be some interesting math which provides meaning to things like "dividing by a circle" for example..

How it works is a mystery... :???:

Anyone go to their GDC presentation?
 
Last edited by a moderator:
Last I heard they are using a completely new form of computation for their rendering sub-systems which is based around something called Geometric algebra...

I read a little about their work a while back (Edge magazine) and tried to google for info on geometric algebra but came up a little short..
Geometric Algebra is pretty cute stuff, actually. Perhaps an easier source might be -- http://www3.telus.net/j_suter/paper/ga_primer.pdf -- it's pretty similar to the layout of the seminars I went to on the topic. The main value it has for rendering and physics and what not is giving you a theoretical ground for unifying a lot of vector and quaternion and tensor and spinor operations into a single system and it goes on into generalizing a lot of things that are normally thought of as strictly 3-dimensional (e.g. cross product) into higher dimensional systems. Yeah, and it does get into things that sound weird like dividing by a vector or multiplying a trivector by a cone and all that.

In and of itself, it doesn't do anything that was impossible otherwise, but the main thing is it just allows you to look at things differently and realize something that you might not have realized otherwise. So when they make a big deal of Geometric Algebra, I can only think that it was more of a tool that gave them some "Aha!" moments that made them realize, hey, I can do this, this, and this!

What they're doing is basically PRT in wavelet space, but my best guess they're just seeing something that enables them to think in terms of light volumes and visibility function sweeps which are convolved by a BRDF approximation and solving for degrees of intersection (presumably with everything represented in the same wavelet basis). Well, that's just a guess. Whatever they're doing, I don't see dynamic updates based on partial PRT as something that will scale up well to large scenes with many active dynamic lights.
 
Has any developer used already memexport ?

John Carmack started to use it but it seems he finished giving it up. Maybe Fable 2 will make use of any exhotic way of programming, Frank ;) ?
We use memexport extensively for the HD DVD player, but then we're not really using the GPU for any 3d rendering. We accelerate our video decode using the shaders and memexport.
 
We use memexport extensively for the HD DVD player, but then we're not really using the GPU for any 3d rendering. We accelerate our video decode using the shaders and memexport.

Cool stuff, did you guys at MS get this stuff from ATI or develop it yourselves?
 
Cool stuff, did you guys at MS get this stuff from ATI or develop it yourselves?
I'm not sure where we got the initial code, but all the shader work and performance improvements were done in house.
The original reference decoder was pretty awful. We were getting frame rates in the low single digits for H.264. Now we can decode two simultaneous H.264 streams at full frame rate. (Remember we also have audio decoding, mixing, and re-encoding, interactivity - which is essentially a javascript web-like browser with timing enhancements, AACS, and a bunch of other things going on at the same time.)
 
I'm not sure where we got the initial code, but all the shader work and performance improvements were done in house.
The original reference decoder was pretty awful. We were getting frame rates in the low single digits for H.264. Now we can decode two simultaneous H.264 streams at full frame rate. (Remember we also have audio decoding, mixing, and re-encoding, interactivity - which is essentially a javascript web-like browser with timing enhancements, AACS, and a bunch of other things going on at the same time.)

Nice work, thanks for the info.
 
According to a developer from geomerics here: http://filecoreinuse.livejournal.com/154268.html

At 720p they are geting frame rates higher than 60 fps on 360 by using their enlighten engine.

The video they refer are this one: http://www.youtube.com/watch?v=L1pfCUmEoCs

Where they claim the lighting is not pre baked, but instead computed in realtime (and on the video there are some scenes with a few source lights)...

Any one here was at their presentation at Gdc? Or know a bit more about what they are doing? (Iguess its not PRT because they already have an PRT engine too)
 
I do belive, RSX will have a BIG problem doing 4x AA @60fps, because its to low on bandwidth. (Forza 2, the first game that uses tiling on the X360, will do just this)

Interesting Point. In Theory, the Xenos is more poweful than the RSX. But in practise? In another (locked) thread, dantruon posted the following:

from what i gathered so far on many forums including this one i come to the conclusion that the Xenos beat the RSX hands down in theory but in practice the RSX whipped the Xenos's ass painfully.

http://forum.beyond3d.com/showthread.php?t=31917&page=4

What do you think of it?
 
Interesting Point. In Theory, the Xenos is more poweful than the RSX. But in practise? In another (locked) thread, dantruon posted the following:



http://forum.beyond3d.com/showthread.php?t=31917&page=4

What do you think of it?

Ninja Gaiden Sigma is 1080P 60FPS, selfshadowing and 2xAA... so I think it will depend on the engine. I don't imagine we will see these types of framerates and AA on top end FPShooters.

Here is something I would like to know... what is the bandwidth requirement (per second) for 720P 4xMSAA 60FPS?
 
Last edited by a moderator:
Interesting Point. In Theory, the Xenos is more poweful than the RSX. But in practise? In another (locked) thread, dantruon posted the following:



http://forum.beyond3d.com/showthread.php?t=31917&page=4

What do you think of it?


I am no expert but more powerfull really depends on what we are talking about. From everything I have read here xenos is monster at VS and leaves the RSX behind. Looking at sony's edge tools it seems to back that up with sony using up to 2/7 of the cell or 2 spu to cull triangles to help it catch xenos. If I am wrong I would love to be correct on that.
 
Back
Top