360 Xenos (Memexport?) use similar memory controller methods as X18k?

jpr27

Regular
Please lock this thread and direct me to topic if this has been answered. I was reading about the Memory Controller in the high end X1800 and was wondering if the Xbox 360 used a similar controller (Memexport use any of the new release methods?). I know that the 360 memory is shared but is there any aspect of the new controller that is used and do we now have all the information pertaining to the 360's memory controller? Or is Memexport an entirely different ?

Again please lock and point me to topic if discussed. Otherwise I would like to know any similarities / differences between the two.

Thanks
 
Not quite sure what you are asking... but...

The programmable memory controller that is present in the x1800 series is also present in the x1300 and x1600 versions. Even the x800 (R4xx) series GPUs have a programmable memory controller, though to a lesser degree. The "Ring" memory bus is a new concept for the GPUs and is somewhat similar to the EIB bus that is present in the Cell CPU. That said... XENOS uses a more conventional memory interface, but is also programmable much like the r4xx/r5xx series GPUs. The Ring memory bus on the Radeon x1000 series GPUs should help it with high resolutions and high levels of FSAA, but as the resolutions on a console are more fixed and the daughter module on XENOS handles the FSAA with the eDRAM it is less necessary.

MEMEXPORT is a different feature that is unique to XENOS. It is also important to note that XENOS acts as the north bridge (memory controller) for the CPU (XENON).
 
I guess Im referring to programability (subsystem memory mapping?) of it. As you mentioned it is unique to the 360 but the memory controller in the X16k & X18k (which I believe differs from the X13k) and Xenos use the mentioned "ring bus". I guess Im asking if it shares similar aspects to X18k memory controller but is used in a unified Memory architecture (acts as a northbridge as you mentioned as well). I took this information from Daves article and maybe will help clarify what I'm getting at.

From Dave's article:

"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."

Some recent forum posts have noted the flexability of the X18k memory controller (one mentioning gains in OGL performance through optimizations and subsystem memory mapping in the new memory controller. I was just wondering if the 360 Memexport shared some of these "subsystem memory mapping optimising ability?" feature so developers might be able to increase performance in their graphics engine or other aspect of game development. Or is this not needed due to the daughter die logic?

The thread I was referring to is: Recent Radeon X1K Memory Controller Improvements in OpenGL with AA (bah cant get the link function to work sorry :( )

Forgive me I know I probably hav'nt clarified this in the best way... its late :)
 
jpr27 said:
I guess Im asking if it shares similar aspects to X18k memory controller but is used in a unified Memory architecture (acts as a northbridge as you mentioned as well).
My own personal guess is, no. The x1800 has eight 32-bit memory interfaces sitting on that ring bus, and the ring bus likely being there in the first place because of the (assumed, but likely) difficulty of physically fitting so many interfaces with their corresponding pins to a chip die. Xenos on the other hand only has two 64-bit interfaces, how would you create a ring bus between just two parties, and what would be the point of it?
 
Back
Top