http://msdn.microsoft.com/directx/presentations/
Interesting stuff. Props to Inane Dork.
Fairly broad, but still fun to poke through IMO.
Interesting stuff. Props to Inane Dork.
Fairly broad, but still fun to poke through IMO.
X360 GDC PPT presentations
- Thread starter superguy
- Start date
http://i1.tinypic.com/sf9z7n.jpg
I found this interesting.
What does "dedicated branch instruction execution" mean I wonder? They dont call it an ALU.
And I dont recall that being among Xenos's known features (could be wrong)?
I found this interesting.
What does "dedicated branch instruction execution" mean I wonder? They dont call it an ALU.
And I dont recall that being among Xenos's known features (could be wrong)?
Nice links. This one is nice too:
http://download.microsoft.com/downl...ab-df6c7a2580b9/Coding_for_Multiple_Cores.ppt
Shows some case studies in core-usage, Kameo and PGR3. Discusses some of the ways cores are being used, and of course, gives guidance on good multi-threading. I was surprised to see the resources that compression appears to be using.
http://download.microsoft.com/downl...ab-df6c7a2580b9/Coding_for_Multiple_Cores.ppt
Shows some case studies in core-usage, Kameo and PGR3. Discusses some of the ways cores are being used, and of course, gives guidance on good multi-threading. I was surprised to see the resources that compression appears to be using.
pc999 said:
You could link it to HD, in that higher resolutions may demand more complex and higher resolution assets, which without compression could ramp up load time. More directly, compression's would appear to be being used here to decrease load time, and to accomodate capacity constraints.
pc999 said:
Only if you're talking about something like a mpeg clip or something, for prerendered sequences.
I mean, really, there is no direct link between higher resolution and higher capacity requirements barring stuff like that. Just an indirect one, in that it encourages higher resolution assets (models, textures etc.).
Interesting tidbits
- File Decompression is "most common CPU heavy thread on the Xbox 360"
- Kameo Core Usage
C T Software Threads
0 0 Game Update
0 1 File IO
1 0 Rendering
1 1 ---
2 0 XAudio
2 1 File decompression
- PGR3 Core Usage
C T Software Threads
0 0 Update, physics, rendering, UI
0 1 Audio update, networking
1 0 Crowd update, texture decompression
1 1 Texture decompression
2 0 XAudio
2 1 ---
C = Core, T = (Hardware) Thread
Recommended use is one CPU intensive software thread per core, + many non-CPU intensive threads (e.g. blocking IO threads, intermittent tasks)
So much for the "early" titles only used a single core quib...
- File Decompression is "most common CPU heavy thread on the Xbox 360"
- Kameo Core Usage
C T Software Threads
0 0 Game Update
0 1 File IO
1 0 Rendering
1 1 ---
2 0 XAudio
2 1 File decompression
- PGR3 Core Usage
C T Software Threads
0 0 Update, physics, rendering, UI
0 1 Audio update, networking
1 0 Crowd update, texture decompression
1 1 Texture decompression
2 0 XAudio
2 1 ---
C = Core, T = (Hardware) Thread
Recommended use is one CPU intensive software thread per core, + many non-CPU intensive threads (e.g. blocking IO threads, intermittent tasks)
So much for the "early" titles only used a single core quib...
[maven] said:
Yeah, this is a great find, thanks Titanio and Xbot360. Can't tell you how many times this comes up where I hang out [no, I don't 'hang out' at GAF]. It's great that this presentation gives some good examples and has nice information that I can present to the more lay disposed without too much thought myself
Though I would imagine the more 'port' oriented games from third parties weren't extensively using SMT, probably just separating their main game thread to one core and doing some minor things on the other cores (i.e. more like single threaded SMP than SMT).
PowerPoint is to conference talks what Acrobat is to technical journals, so it's worth you getting just the viewer. Only a few megs.liolio said:
http://www.microsoft.com/downloads/details.aspx?FamilyID=428d5727-43ab-4f24-90b7-a94784af71a4&displaylang=en
Shifty Geezer said:
Thank you.
So for Xenon we have :
- Kameo Core Usage
C T Software Threads
0 0 Game Update
0 1 File IO
1 0 Rendering
1 1 ---
2 0 XAudio
2 1 File decompression
- PGR3 Core Usage
C T Software Threads
0 0 Update, physics, rendering, UI
0 1 Audio update, networking
1 0 Crowd update, texture decompression
1 1 Texture decompression
2 0 XAudio
2 1 ---
I try to dispatch that kind of work on cell (very trivial, but It is on purpose to have knowledgeable persons to go further)
PPE 1&2 Game update, file IO, networking, physic, os, control of spe threads.( i've tried to put all the "general purpose thread here and the helper or math heavy threads on the spe)(in regard with the xenon figure ppe should handle this task easily).
On Spe : math heavy task : some physics, decompression, audio, network code, rendering, os helper threads.
It seems that there is a lot more room on cell on that kind of dispatch.
Spe are decompression monsters(1 spe seems to be able to do as well as a xenon core), should be very good at audio too,
for physic It'll help but i don't know how much Math heavy are some work (i remenber A gubby test on the type of workload a cpu do while running an aegia demo, there is a lot of non math operations).
If somebody can go a lot more specific it should be a nice comparison between the two architectures on a technical side (not bias side
)
Last edited by a moderator:
I'm not sure if this is the decompression at work but, in PGR3 go into the photo mode and use the free roaming camera. Move the camera far away from the car say a few corners down the track and then switch back to the car view, you will quickly see all the textures draw back in as though they had been swapped out (except much quicker), switching between the car and free roam camera will always do this when moving far away. Could this be the texture decompression happening? As far as I know PGR3 doesn't stream any texture detail in.
How are the textures compressed? Are they 'JPEGd' and converted to DXTCs?
