Is this an example of Xbox 360 being future proof

seeing that ATI have said the visual quality on the Xenos will be on par with the R600 which will be the first directx10 card, is it true that directx 10 shaders are already implemented in the Xenos card and will be 'enabled' when the developers get the updated API of Directx containing version 10 to use these features? Its interesting because ATI has said that unified shaders will be the future of their PC designs as well and that wil start with R600. Now Nvidia has also come out and said thier Directx10 designed graphics card will use unified architecture as well.

You should note that to use directx you just would need to use the API and the features would be in the graphics card. Maybe MS designed directx 10 and experimented it with the Xbox 360 GPU but doesnt want to announce it because just like HD-DVD some gamers will say they will wait until Dx10 Games on Xbox 360 before they announce it. Also the fact that Microsoft has said this again and again that Xbox 360 is future proof. Could this be the "future proof"?
 
onetimeposter said:
seeing that ATI have said the visual quality on the Xenos will be on par with the R600 which will be the first directx10 card, is it true that directx 10 shaders are already implemented in the Xenos card and will be 'enabled' when the developers get the updated API of Directx containing version 10 to use these features?

No. There will be no enabling. Xenos has what it has (48 ALUs capable of either pixel or vertex work, with 32bit pixel shader percision versus the 24bit found in ATIs DX9 hardware).

Also, Xbox 360 has its own DX API version. The API is "thin" and it exposes all the features on Xenos. There is no need to wait. As for features, Xenos has some DX10 features (unified shaders, geometry tesselation) but not others (geometry shaders; although MEMEXPORT and CPU streaming make it kind of redundant in some ways). It is similar, but different.

Also, unified shaders are not going to change the IQ necessarily. They are a different approach to accomplishing the same task. Think of it as the difference between eating pudding with a spoon or fork. Both get the job done, just in a different way.

You should note that to use directx you just would need to use the API and the features would be in the graphics card. Maybe MS designed directx 10 and experimented it with the Xbox 360 GPU but doesnt want to announce it because just like HD-DVD some gamers will say they will wait until Dx10 Games on Xbox 360 before they announce it. Also the fact that Microsoft has said this again and again that Xbox 360 is future proof. Could this be the "future proof"?

Your not making much sense with the connect the dots.

Xbox 360 will be similar to the DX10 standard it seems, but Xenos featureset = DX10. Xenos was designed around the concerns of a console environment (e.g. fillrate, eDRAM, no geometry shader). Obviously MS will want to leverage the 360 to provide a stream of Vista games, so seeing that Xenos has a lot of DX10 features is not surprising. But in the end they stand on their own and Xenos was designed to be a console part, not a desktop part..
 
MEMEXPORT is discussed in Dave's XENOS article...
In addition to its other capabilities Xenos has a special instruction which is presently unique to this graphics processor and may not necessarily even be available in WGF2.0 and this is the MEMEXPORT function. In simple terms the MEMEXPORT function is a method by which Xenos can push and pull vectorised data directly to and from system RAM. This becomes very useful with vertex shader programs as with the capabilities to scatter and gather to and from system RAM the graphics processor suddenly becomes a very wide processor for general purpose floating point operations. For instance, if a shader operation could be run with the results passed out to memory and then another shader can be performed on the output of the first shader with the first shader's results becoming the input to the subsequent shader.

MEMEXPORT expands the graphics pipeline further forward and in a general purpose and programmable way. For instance, one example of its operation could be to tessellate an object as well as to skin it by applying a shader to a vertex buffer, writing the results to memory as another vertex buffer, then using that buffer run a tessellation render, then run another vertex shader on that for skinning. MEMEXPORT could potentially be used to provide input to the tessellation unit itself by running a shader that calculates the tessellation factor by transforming the edges to screen space and then calculates the tessellation factor on each of the edges dependant on its screen space and feeds those results into the tessellation unit, resulting in a dynamic, screen space based tessellation routine. Other examples for its use could be to provide image based operations such as compositing, animating particles, or even operations that can alternate between the CPU and graphics processor.

With the capability to fetch from anywhere in memory, perform arbitrary ALU operations and write the results back to memory, in conjunction with the raw floating point performance of the large shader ALU array, the MEMEXPORT facility does have the capability to achieve a wide range of fairly complex and general purpose operations; basically any operation that can be mapped to a wide SIMD array can be fairly efficiently achieved and in comparison to previous graphics pipelines it is achieved in fewer cycles and with lower latencies. For instance, this is probably the first time that general purpose physics calculation would be achievable, with a reasonable degree of success, on a graphics processor and is a big step towards the graphics processor becoming much more like a vector co-processor to the CPU.

Seeing as MEMEXPORT operates over the unified shader array the capability is also available to pixel shader programs, however the data would be represented without colour or Z information which is likely to limit its usefulness.

ATI indicate that MEMEXPORT functions can still operate in parallel with both vertex fetch and filtered texture operations.

MEMEXPORT basically allows the GPU to export and import data from memory and generally this can be used to circumvent limitations that may be present... but more than that it will also allow for some interesting implementations as you could theoretically use the GPU ALUs for things other than graphics or allow the CPU and GPU to share certain workloads. It is quite interesting... and certainly seems to have a lot of potential there.

CPU Streaming/Slaving is a particular feature on XENOS that is not present on ANY other processor where the GPU can actually SLAVE one or more of XENON's (The Xbox360 TriCore CPU) cores and have the CPU perform certain tasks and stream that data directly to the GPU. This will be important for Microsoft's procedural technologies implementation.
 
I meant, how do memexport and cpu streaming make geometry shaders "kind of redundant"?


Note: I clearly don't have an advanced understanding of the above implications. ;)
 
Last edited by a moderator:
Alstrong said:
I meant, how do memexport and cpu streaming make geometry shaders "kind of redundant"?

Possibly because the information could be exported to the CPU and the CPU could act as a programmable geometry shader and then export it back to the GPU?
 
is it possible to have the following configuration

1 Core for Physics
1 Core for Graphics (Slaved by the GPU)
75% of 1 core for A.I and 25% for OS Sound Live

?
 
oh....

well, I wasn't too sure what a geo shader does exactly.

geometry shaders are run before rendering begins. They create geometry procedurally by using a function call library that closely follows the .mi2 scene description language.

I found this definition, but I guess it's starting to make sense.

sorry for the newb questions. :)
 
onetimeposter said:
is it possible to have the following configuration

1 Core for Physics
1 Core for Graphics (Slaved by the GPU)
75% of 1 core for A.I and 25% for OS Sound Live

?

Theoretically... yes.

The better way to put this would be...

1st Core > Game Code + Audio + AI
2nd Core > Physics
3rd Core > Slaved to GPU for "XBox Procedural Synthesis" or other related functions

Of course it really depends on the application we are talking about as some games don't need certain elements that other games would need. There is a good deal of flexibility in how you can use those three cores on XENON.
 
No such thing as future proof

The hardware capability wont change but you will see developers use the hardware more effectively. The PS2 is a perfect example of this. Ironically, it will probably be the same issue that will limit performance of many early games ... CPU utilization.
 
You can add RAM to that too. You just know that, give or take 6 months, developers will start nagging about not having enough RAM. They always do.
 
Back
Top