BILDER AV XBOX 360 LEKKET UT PÅ NETTET

VG Blog rapporterer som vanlig, og selv om artikkelen er god nok, så er kommentarene enda bedre. Her har vi folk som kommer med innlegg med høyt faglig og saklig nivå. Nå vet jeg altså at jeg må droppe denne xbox'en og heller satse på pc fordi jeg ALLEREDE NÅ får kjøpt pcer med enda bedre maskinvare!!!

idioter.
 

SHDR

Gullmedlem
Ja, faen, så mye spennende spill som det kommer på PC om dagen fatter jeg ikke at jeg sitter og spiller innovative konsollspill. Fuck it, CS er veien!

Tja sånn rent i utgangspunktet så er jo spesifikasjonene veldig fine, for en spill konsoll.. Grafikk messig vil nok en konsoll være underlegen en PC så lenge en ikke kan kjøre spill på høyere oppløsninger.. jeg blir til tider dårlig av spill på konsoller.. pga farger og dårlig oppløsning..

Aha. Den kjører 1080p som standard, med full anti-aliasing, og på et grafikkort som ikke finnes til PC enda, som neppe slippes til forbrukervennlige priser på enda MINST seks måneder til. Og når så noen sist en forbruker tabletop med tri-core 3.2GHz G5-prosessorer? You go!

Jeg leser resten nå. Provoserende hvor mye folk tror de kan.
 

Kilik

Lokal moderator
Opprinnelig skrevet av Shadar@10.05.2005, 13.32
Det var også noe spennende i Edge denne måneden; en dev-kar som mente at prosessorene i Xbox 360 og PS3 var in-order-CPU-er som kjørte low-level assembly veldig bra, og som var jævler på tallknusing og svære likninger, men at de kjørte "dynamisk" kode, som for eksempel interaksjonssystemer, dårligere enn dagens prosessorer, som kjører out-of-order kode nesten like bra som algoritmisk low-level kode, altså in-order. Bahhh ... for å summe opp litt: de nye prosessorene er ganske enkelt ikke så gode på objektorientert kode som de er på algoritmisk kode. Kanskje vi får se folk skrive spill i C igjen?
Ja, kommentarene etter GDC var ikke bare av det hyggelige slaget når det gjelder in-order (det er forresten for lengst bekreftet at Cell er in-order):

Eric Zimmerman: Thank you Brenda. Our final rant--Chris Hecker. Chris Hecker is the quintessential indie game designer/developer. Chris is responsible for the Indie Game Jam, helps engineer their experimental gameplay workshop every year. And is an important pundit, gadfly and generally dissatisfied citizen of the game industry. Ladies and gentlemen, Chris Hecker!

Chris Hecker: It pains me to [speak] after that introduction. I recently actually took a job at EA.

[laughter, heckling]

However, I work for Will on the game you just saw, so it's not [indiscernible]. All right, here we go. "How Sony and Microsoft are about to screw your game design." These are games in the good old days. We didn't exactly have the best physique, but we were at least a balanced individual, you walk out on the beach, and you were like, you know, pathetic. But you know, you looked like a normal person. These are games today. We've been working really hard--I mean, you can maybe make the argument that this is the game--these are games today. I gotta little more work on that left arm to do, it's going to be as big as our graphics arm soon. This is kind of lame. We really want to be this guy don't we?

Unknown Speaker: No!

[laughter]

Chris Hecker: OK, he was the best guy I could find in like, three seconds in the WiFi network out in the lobby. All right. But how do we get there? Well, I'm going to take a little diversion here. I'm a programmer, so, I have two technical slides, really one technical slide. And that's about it. All right, ready? So there are two kinds of code in a game basically. There's gameplay code and engine code. Engine code, like graphics and physics, takes really giant data structures of homogenous data. I mean, it's all the same, like a lot of vertices are all a big matrix, or whatever, but usually floating point data structures these days. And you have a single small, relatively small hour that grinds away on that. This code is like, wow, it has a lot of math in it, it has to be optimized for super scalar, blah, blah, blah. It's just not actually that hard to write, right? It's pretty well defined what this code does.

The second kind of code we have is AI and gameplay code. Lots of little exceptions. Even if you're doing a simulation-y kind of game, there's tons of tunable parameters, [it's got a lot of interactions], it's a mess. I mean, this code--you look at the gameplay code in the game, and it's crap. Compared to like, my elegant physics simulator or whatever. But this is a code that actually makes the game feel different. This is the kind of code we want to be easy to write and so we can do more experimental stuff. Here is the terrifying realization about the next generation of consoles. I'm about to break about a zillion NDAs, but I didn't sign any NDAs so that's totally cool!

I'm actually a pretty good programmer and mathematician but my real talent is getting people to tell me stuff that they're not supposed to tell me. There we go. Gameplay code will get slower and harder to write on the next generation of consoles. Why is this? Here's our technical slide. Modern CPUs, like the Intel Pentium 4, blah, blah, blah, Pentium [indiscernible] or laptop, whatever is in your desktop, and all the modern power PCs, use what's called 'out of order' execution. Basically, out of order execution is there to make really crappy code run fast.

So, they basically--when out of order execution came out on the P6, the Pentium 6 [indiscernible] the Pentium 5, the original Pentium and the one after that. The Pentium Pro I think they called it, it basically annoyed a whole bunch of low level ASCII coders, because now all of a sudden, like, the crappiest-ass C code, that like, Joe junior programmer could write, is running as fast as their Assembly, and there's nothing they can do about it. Because the CPU behind their back, is like, reordering that guy's crappy ass C code, to run really well and utilize all the parts of the processor. While this annoyed a whole bunch of people in Scandinavia, it actually…

[laughter]

And this is a great change in the bad old days of 'in order execution,' where you had to be an Assembly language wizard to actually get your CPU to do anything. You were always stalling in the cache, you needed to like--it was crazy. It was a lot of fun to write that code. It wasn't exactly the most productive way of doing experimental programming.

The Xenon and the cell are both in order chips. What does this mean? The reason they did this, is it's cheaper for them to do this. They can drop a lot of core--you know--one out of order core is about the size of three to four in order cores. So, they can make a lot of in order cores and drop them on a chip, and keep the power down, and sell it for cheap--what does this do to our code?

Well, it makes--it's totally fine for grinding like, symmetric algorithms out of floating point numbers, but for lots of 'if' statements in directions, it totally sucks. How do we quantify 'totally sucks?' "Rumors" which happen to be from people who are actually working on these chips, is that straight line gameplay code runs at 1/3 to 1/10 the speed at the same clock rate on an in order core as an out of order core.

This means that your new fancy 2 plus gigahertz CPU, and its Xenon, is going to run code as slow or slower than the 733 megahertz CPU in the Xbox 1. The PS3 will be even worse.

This sucks!

[laughter]

GDC rant
-----------------------------------------

Uh, fordi som ikke vet hva in-order her, så kommer her en liten "dodgy" forklaring:

Et problem blir med parallellprosessering er jo avhengigheter og Cell er intet unntak. Kjører man to instruksjoner samtidig som benytter samme variabel, oppstår det som fort komplikasjoner.


Et typisk Assembly-eksempel er:


1) LOAD R1
2) ADD R0, R1, R2

Her brukes altså verdien fra linje 1 i linje 2. Hvis linje 2 kjøres før linje 1 forandres hele meningen med programmet.

Derfor bruker Cell in-order arkitektur som ja, holder orden på rekkefølgen. Alle instruksjoner blir eksekvert i samme rekkefølgen som når de kom inn i prosessoren. Som de fleste designvalg har dette sine fordeler og ulemper. Fordelen er selvsagt at man slipper avhengighetsproblemet, men Cell har ikke mulighet til å re-arrangere instruksjonskøen til en rekkefølge som er mer optimal. En out-of-order CPU er smartere i det at den sjekker hvilke instruksjoner som er avhengighetsbærende. Tenk f.eks. om det prosessoren skal ha ikke finnes i cache og man må kaster bort masse sykler på å hente fra RAM. Der en out-of-order prosessor kan kjøre uavhengige prosesser i mens, må en in-order vente. En annen ting er at kompabilitet med x86 (som da ikke er in-order) blir kastet ut av vinduet. Men det er også flere fordeler: En mye enklere arkitektur og kortere pipeline gjør at chip'en blir mindre kompleks og mindre strømforbruk. Enklere å "pumpe" opp GHz altså, som vi alle vet er bra i markedsføringsøyemed...
 

SHDR

Gullmedlem
Der har vi mannen jeg snakker om! Glad for at Edge gjorde en del redigeringsarbeide på den der, for fyren er tydeligvis ikke særlig velartikulert. Leser resten av GDC-niggeriet nå.

Dette, damer og herrer, er hva hype-maskinen EGENTLIG handler om. Dette er grunnen til at jeg ikke liker Sonys måte å gjøre ting på, dette er grunnen til at jeg blir litt glad når jeg ser spill som transcenderer sin tekniske side og blir gøy på grunnlag av input heller enn output.