Trish
18th October 2006, 14:15
Sembra che Microsoft stia per spedire un aggiornamento all'SDK della 360 per gli sviluppatori consentirà di aprire ai programmatori la VERA potenza grafica della GPU, dandogli accesso diretto alla scheda per sfruttarne quelle caratteristiche promesse fin dall'inizio ma mai utilizzate:
La notizia sta facendo il giro dei forum: http://forum.teamxbox.com/showthread.php?t=477218
Citazione:
"Okay I went up there directly left of the sony booth you had the Microsoft one which had games for windows running crysis and many other things such as flight simulator X (which looked like crap and had terrible fps) and further down there were some 360s which had fear and stuff like that, but I wasn't concerned with all of that. I asked the Microsoft employee if anything at this event had directx 10 even installed on it and he said no none of it. I asked him about unified shaders with the 360's gpu he says a lot of people asked him the very same question all of the days he's been at the event, but all he could say on the subject is that there will be a VERY important update going out to developers relating to the 360's videocard which developers have been asking for since launch he couldn't give a date on this. He says long story short developers have the 360 gpu, but they don't REALLY have access it until these updates go through"
Hardware related
a) New DirectX-360 version (360 port of Pc's Dx-10)
b ) Better GPU Threads handling
c) Better Auto-Balance for shaders ( Pixel <-> Vertex commuting)
d) Auto-Tiling (finally real free 4x AA + HDR + Blending )
e) Support for Mem-Export functions (Geometry Tessellator, Geo Shader via cache-lock and core-lock)
f) Direct support for procedural textures
g) unlock 1080p as native resolution
Software Related:
a) New Blade for HD Cinema
b ) Users can join in groups (Clan managment)
c) Video Streaming possible with Win XP
Insomma, sembra che non abbiamo visto ancora niente..
altre conferme arrivano da uno sviluppatore 360 su Beyond3D ha detto tempo fa che gli SDK della 360 erano incompleti e che i programmatori potevano "vedere ma non toccare" certe opzioni fondamentali, come gli shader unificati!
Citazione:
Xenos ALUs can stall when you have very short loops (say 2 instructions), or when you don't have enough ALU code to hide TEX latency.
One solution is to re-sequence your code. e.g. unroll loops or pre-fetch textures.
The sequencer in Xenos is programmable, allowing devs to fine-tune the coherency of code execution. That is, to define thread-switching points in their code, rather than allowing Xenos to apply its default behaviour. This means Xenos will run with less thread-switches (in total), where every thread-switch costs time through latency (if the latency can't otherwise be hidden).
Xenos's default behaviour is to thread-switch whenever it sees a latency-inducing instruction (e.g. TEX or BR). So, by lumping TEX operations together and then saying "now you can switch threads", Xenos can reduce the 2 or 3 separate thread-switches to a single thread-switch. That reduces the total number of ALU instructions that are required to hide these TEX instructions.
The first task for devs is to tweak data formats (stored as textures or vertex streams) so that access patterns are efficient. i.e. the minimum number of fetches are performed. Additionally, since Xenos offers a choice of access techniques, the dev has to evaluate them.
In a unified architecture, you can't evaluate the performance of a shader in isolation. You can't write a shader and say "TEX ops take this long, ALU ops this long and branches this long, so the total time is xxx, so we can get X fps". You can only say that's the minimum time they'll take. When the pipelines are doing a mix of work (for other pixels, say, or for vertices as well as pixels) then bandwidth limits or full buffers will cause blips. Ultimately the programmer is exposed to concurrency issues.
Another way of putting it is that the programmer has better control of concurrency issues in Xenos - in traditional GPUs, when resource limits are reached, the dev has to tackle the problem indirectly, rewriting code in the hope that the new usage pattern will eke-out better performance. In theory Xenos provides direct control and more options to control execution and resource usage.
Since the SDK for Xenos is still not complete, devs are currently in see-but-can't-touch hell...
infatti ricordo ke Sakaguchi al TGS affermo' ke LO ancora sfruttasse un solo Core della console... e ke aspettava le SDK nuove ... a quanto pare è vera
La notizia sta facendo il giro dei forum: http://forum.teamxbox.com/showthread.php?t=477218
Citazione:
"Okay I went up there directly left of the sony booth you had the Microsoft one which had games for windows running crysis and many other things such as flight simulator X (which looked like crap and had terrible fps) and further down there were some 360s which had fear and stuff like that, but I wasn't concerned with all of that. I asked the Microsoft employee if anything at this event had directx 10 even installed on it and he said no none of it. I asked him about unified shaders with the 360's gpu he says a lot of people asked him the very same question all of the days he's been at the event, but all he could say on the subject is that there will be a VERY important update going out to developers relating to the 360's videocard which developers have been asking for since launch he couldn't give a date on this. He says long story short developers have the 360 gpu, but they don't REALLY have access it until these updates go through"
Hardware related
a) New DirectX-360 version (360 port of Pc's Dx-10)
b ) Better GPU Threads handling
c) Better Auto-Balance for shaders ( Pixel <-> Vertex commuting)
d) Auto-Tiling (finally real free 4x AA + HDR + Blending )
e) Support for Mem-Export functions (Geometry Tessellator, Geo Shader via cache-lock and core-lock)
f) Direct support for procedural textures
g) unlock 1080p as native resolution
Software Related:
a) New Blade for HD Cinema
b ) Users can join in groups (Clan managment)
c) Video Streaming possible with Win XP
Insomma, sembra che non abbiamo visto ancora niente..
altre conferme arrivano da uno sviluppatore 360 su Beyond3D ha detto tempo fa che gli SDK della 360 erano incompleti e che i programmatori potevano "vedere ma non toccare" certe opzioni fondamentali, come gli shader unificati!
Citazione:
Xenos ALUs can stall when you have very short loops (say 2 instructions), or when you don't have enough ALU code to hide TEX latency.
One solution is to re-sequence your code. e.g. unroll loops or pre-fetch textures.
The sequencer in Xenos is programmable, allowing devs to fine-tune the coherency of code execution. That is, to define thread-switching points in their code, rather than allowing Xenos to apply its default behaviour. This means Xenos will run with less thread-switches (in total), where every thread-switch costs time through latency (if the latency can't otherwise be hidden).
Xenos's default behaviour is to thread-switch whenever it sees a latency-inducing instruction (e.g. TEX or BR). So, by lumping TEX operations together and then saying "now you can switch threads", Xenos can reduce the 2 or 3 separate thread-switches to a single thread-switch. That reduces the total number of ALU instructions that are required to hide these TEX instructions.
The first task for devs is to tweak data formats (stored as textures or vertex streams) so that access patterns are efficient. i.e. the minimum number of fetches are performed. Additionally, since Xenos offers a choice of access techniques, the dev has to evaluate them.
In a unified architecture, you can't evaluate the performance of a shader in isolation. You can't write a shader and say "TEX ops take this long, ALU ops this long and branches this long, so the total time is xxx, so we can get X fps". You can only say that's the minimum time they'll take. When the pipelines are doing a mix of work (for other pixels, say, or for vertices as well as pixels) then bandwidth limits or full buffers will cause blips. Ultimately the programmer is exposed to concurrency issues.
Another way of putting it is that the programmer has better control of concurrency issues in Xenos - in traditional GPUs, when resource limits are reached, the dev has to tackle the problem indirectly, rewriting code in the hope that the new usage pattern will eke-out better performance. In theory Xenos provides direct control and more options to control execution and resource usage.
Since the SDK for Xenos is still not complete, devs are currently in see-but-can't-touch hell...
infatti ricordo ke Sakaguchi al TGS affermo' ke LO ancora sfruttasse un solo Core della console... e ke aspettava le SDK nuove ... a quanto pare è vera
