Tänk om - en kontrafaktisk spekulation kring konsolers historiska prestanda

Trädvy Permalänk
Medlem
Plats
Malmö
Registrerad
Dec 2004

Tänk om - en kontrafaktisk spekulation kring konsolers historiska prestanda

Goddag och välkommen!

Då och då ägnar jag mig åt det pikanta tidsfördrivet i att spekulera kring hur vissa konsoler och i slutändan konsolbranchen överlag hade tett sig som spelplattform (t ex under promenader). Nu har det gått så långt att jag bestämt mig för att göra en lång post här på Sweclockers och gotta och grotta mig i alla tekniska fantasier.

Moderator får gärna flytta tråden om denne misstycker med mitt forumavdelningsval. Diskussionen berör konsoler, men handlar inte direkt om spel, utan hårdvaran.

TL;DR i fetstil.

Mitt favoritobjekt är Playstation 3. Maskinen med skyhöga förväntningar och nästan lika stor potential. Vad som kom var… så dåligt relativt förväntningarna att det var svårt att ta in. Maskinen släpptes över ett år efter Xbox 360, var närapå dubbelt så dyr vid tillfället (6000 vs 3500) och hade dessutom marginellt sämre prestanda. Det var visserligen den billigaste blu-ray-spelaren i åratal, men för de som inte brydde sig om detta fanns inget annat att glädjas åt. Samma tråkikga DualShock-design med bristfälligt designade analoga axelknappar. Skakfunktionen var borta ur kontrollerna för att det inte gick ihop med gyro påstods det. Av allt snack om multitasking syntes inget. Gränssnittet och internettjänsterna lämnade en hel del övrigt att önska. Bakåtkompatibliteten var även den sämre.

Mycket rättades till efterhand, men dålig hårdvara går inte att rätta till med mindre än att göra en ny konsol.

Men tänk om de hade gjort nåt annat?
Det som blev var en Cell med 1PPE + 7SPE (den 8:e avstängd för bättre avkastning i produktionen) tillsammans med med 256MB RDRAM. Grafikchippet blev ett Nvidia G70 på 550MHz med 256MB GDDR3 på 650MHz, effektivt 1,3GHz. Samspelet mellan dessa var inte så värst bra heller vad jag förstått, så det var väldigt krångligt att få dem att samarbeta eller avlasta varandra.

Hur tänkte Sony med Cell egentligen? Menade de på fullt allvar att spelutvecklare skulle behöva vara datavetare för att få ut något vettigt ur den?
I en spelkonsol har det alltid lönat sig att ha en så enkel och lättarbetad design som möjligt. Exotiska eller krångliga lösningar brukar ofta straffa sig även om de kan ge mer prestanda (Sega Saturn, Nintendo 64). Spelutvecklare ska göra SPEL, inte ägna så åt forskning inom datavetande.
Det finns alltid de utvecklare som kan komma på trix för att få ut mer av hårdvaran, men de allra flesta får det som mainstreamvägen ger.

Givet att Sony slängt ut många miljarder på att utveckla Cell och nog tidigt bestämt sig för att stoppa in den i PS3an för att etablera processorn på marknaden (detta är förresten anledningen till att funktionen "Other OS" fanns: programmerare skulle få en chans att lära sig arbeta med Cell, och sprids kunskapen så ökar incitamenten för att en Cell ska användas i andra sammanhang, som t ex klusterdatorer) så får man anta att de inte ville ha någon annan CPU. Vid denna tiden var Sony fortfarande en hyfsat stor chipaktör, och Cell var väl ett försök att slåss med de stora elefanterna.

Om de bara kunde tweakat den lite? Vad sägs om att istället för 1PPE+7SPE stoppa in 2PPE:er och ditcha så många SPE:er som behövs för det. Och kanske istället gjort SPE:erna något kraftfullare. Läst nånstans att casheminnet till SPE:erna var väldigt litet, och överlag var de väldigt krångliga att få igång, men detta är över min kunskap. Då hade det varit mycket enklare att konvertera spel fram och tillbaka, och mycket enklare att få kraft ur PS3an utan att dilla med SPE:erna.
Tryck in mer minne också 512MB RDRAM. Det är väl en multitaskmaskin? Minnespriserna skönk väl ganska snabbt.

Apropå grafiken borde Sony väntat med lanseringen av maskinen lite och stoppat in ett Geforce 8800 GTS med de 320MB RAM. Väldigt tung satsning, men jag tror det hade lönat sig i längden. Då hade det varit klasskillnad. Geforce 8 var ett väldigt stort steg lite som med ATis Radeon 9700 Pro. DirectX10-motsvarande grafik som hade stått sig väl lång tid framåt. e hade fått deala en del med Nvidia för att få nåt bra. Kanske få lite rabatt om de sätter på ett klistermärke på PS3an som förkunnar "Graphics by Nvidia".

För att detta skulle hålla borde de designat PS3an mer som en reciever. Det går helt ihop med deras mediaspelarfilosofi kring PS3an, och då skulle det kunna ges rum för axialfläktar, gärna 92mm och kanske 2 stycken. Lägg moderkortet allra underst, och ha chippen uppåt för att inte stänga in värmen. Allt detta ger gott om utrymme till kylflänsar.
Överhettningsproblemet löst.
De skulle behållit denna design, givetvis då med full bakåtkompatibilitet, minneskortläsare och SACD-stöd, fram till typ 2010. Där kunde de släppa en slim och då, inte tidigare, skala bort bakåtkompatibiliteten, minneskortläsare och vissa funktioner. Det hade varit väldigt bra ur marknadsföringssynvinkel, väldigt tydligt för kunderna vad som funkar med vad.

Någon invänder kanske att det skulle varit för lång tid från Microsofts släpp av Xbox 360. Men de hade inget fast eget datum, utan hade som absolut mål att släppa sin maskin året innan Sony tänkte släppa sin PS3, oavsett vad. Då Sonys plan låg på 2006 så satte MS 2005. Hade Sony istället haft mål på 2007 hade MS kommit 2006. Detta hade varit fördelaktigt för alla, då bägge stora konsoler var framstressade. Och Sony tjänade ännu gott på Playstation 2. Etableringen av blu-ray hade riskerats, men jag tror det hade gått ändå.

TL;DR: Alltså:
Cell med 2PPE + ca 4-5 SPE med 512MB RDRAM.
Geforce 8800 GTS med 320MB RAM.
Fatmodell stor som en reciever för bättre kylning och mediespelarprofilering med alla features fram till 2010.

Väldigt tung investering i början, men maskinen hade hållit väl inpå 2014 och även stått sig väl mot de ännu ej uppkomna mobila enheterna.

---

En annan favorit är Gamecube. En överlag bra maskin på alla vis som mest torskade på en enda sak: minneskonfigurationen. Nintendo körde med 24MB "1T SRAM" vilket var billigt och bra. Detta kompletterades med 16MB billigt RAM som inte alls var så bra. Läs- och skrivhastigheten låg på runt 80MB/s. Detta gjorde att denna del av minnet många gånger var i praktiken värdelöst, och därmed blev GC konsolen med minst mängd minne.

Nintendo borde helt enkelt kört på 40MB 1T SRAM rakt igenom. Det hade blivit en större investering, men minnespriserna sjönk snabbt och det hela hade ordnat upp sig i längden.

Nintendo miste mycket tredjepartsstöd mot slutet av livscykeln på grund av det bristfälliga arbetsminnet. Burnout 3 släpptes inte till GC som en direkt följd av det, för Criterion kunde inte få det att köra helt enkelt.

Med 40MB 1T SRAM hade de även bäddat vägen för en lite mindre klen Wii, då vad som är känt är att Wii byggde vidare på exakt samma spec som Gameube, men de höjde bara frekvenserna på chipen och utökade minnet på den kassa delen, alltså 24+96MB.

---

En tredje favorit är Playstation Vita. Det bygger lite på att mitt scenario om PS3 blivit av. Vitan släpptes i nov/dec 2011 i Japan och början av 2012 i resten av världen. En väldigt fin maskin som kunde varit lite krämigare med tanke på vad som låg i utveckling.

Vitan innehåller en fyrkärning ARM Cortex-A9 MPCore tillsammans med en fyrkärnig PowerVR SGX543MP4+. Arbetsminnet är på 512MB vanligt och 128MB för grafik. PowerVR 5-serien släpptes 2005 och är alltså väldigt gammal. 2012 släpptes PowerVR 6-serien som hade runt 10 gånger så hög prestanda och stöd för DirectX10-grafik! Man skulle alltså skjutit på releasen av Vitan med några månader och tryckt in med PVR6. I samma veva kanske man skulle trycka in lite mer minne, och eventuellt också någon bättre CPU som låg runt hörnet. I dagsläget känns det som att många pekplattor har parkerat på ungefär 1GB RAM och inte så värst mycket bättre CPU:er sedan 2012.

Jag är inte så haj på mobila chip och var TDP-gränserna ligger på, men jag tänker att alla nämnda är ämnade för mobila enheter, så de borde ju passa.

---

Playstation 4 och Xbox one har diskuterats till leda. Jag har kvar min uppfattning om att Sony borde släppt PS4an några månader senare för att trycka in en AMD Kaveri istället och därmed befäst prestandatronen och positionen som spelkonsol utifrån de ramar de hade.

---

Ett litet hedersomnämnade till Nintendo 64. Grafikcashen borde varit större så den inte cripplade maskinens grafiska kapacitet.

God jul!

500 watt räcker för en elementär dator oavsett grafikkort utan överklockning. Räkna ut annat på OuterVision Power Supply Calculator. Power. Performance. PRIME.
Elektrostatisk urladdning är ett verkligt problem.

"People who are serious about software should make their own hardware" – Alan Kay

Trädvy Permalänk
Datavetare
Plats
Stockholm
Registrerad
Jun 2011

Om ryktena stämmer så var ursprungstanken med Cell att man skulle ha två st och att majoriteten av grafik-pipelinen skulle utföras via SPE-enheterna. GPU-delen skulle i det läget i stort sätt bara bestå av en krets som utför ROP (Raster OPerations), d.v.s. konvertera 3D-space till 2D-space till en "frame-buffer". Frågan är hur korrekt detta rykte är, det som både stärker ryktet är att PS2 fungerade väldigt mycket på detta sätt. Men det är också något som gör ryktet lite svårbedömt då folk som visste hur PS2 fungerade enkelt skulle kunna gjort en egen teori om hur Sony _tänkte_ använda Cell.

I PS2 satt det en MIPS CPU som man kopplat två stycken vektor-enheter. VU0 var i stort sätt en "vanlig" flyttalsprocessor medan VU1 hade en direktkoppling till GS-kretsen (den som gjorde ROP) på ett sätt så VU1 kunde användas till enklare former av vad som senare kom att kallas "vertex-shaders".

Fortsättning på detta rykte är att Sony ganska sent insåg hur stort arbete man hade i att skapa en fungerade grafikstack ovanpå Cell så man fick i panik shoppa en "vanlig" GPU och kasta ut ena Cell-CPUn. I slutändan lärde sig ändå first-tier utvecklarna för PS3 hur en lång rad grafikeffekter och även logik effektivt kunde hanteras i SPE-enheterna, så den GPU-del som sitter i PS3 har i sina dar rendera grafik som den absolut inte är kapabel till utan Cell.

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Trädvy Permalänk
Testpilot, Geeks Gaming
David Kvist
Plats
Göteborg
Registrerad
Jun 2012

Du missar att en utvecklingcykel inte är så kort att man kan vänta tills lanseringsdatum av GPU X och få in den i maskinen på direkten och lansera konsollen.

Synpunkter på min moderering? Kontakt:
| PM:a mig | Maila mig | PM:a Moderatorerna | Kontaktformuläret |
Testpilot, Moderator & Geeks Gaming Huvudadmin
| Sweclockers Teamspeak |
Forumregler

Trädvy Permalänk
Medlem
Plats
Malmö
Registrerad
Dec 2004
Skrivet av Yoshman:

Om ryktena stämmer så var ursprungstanken med Cell att man skulle ha två st och att majoriteten av grafik-pipelinen skulle utföras via SPE-enheterna. GPU-delen skulle i det läget i stort sätt bara bestå av en krets som utför ROP (Raster OPerations), d.v.s. konvertera 3D-space till 2D-space till en "frame-buffer". Frågan är hur korrekt detta rykte är, det som både stärker ryktet är att PS2 fungerade väldigt mycket på detta sätt. Men det är också något som gör ryktet lite svårbedömt då folk som visste hur PS2 fungerade enkelt skulle kunna gjort en egen teori om hur Sony _tänkte_ använda Cell.

I PS2 satt det en MIPS CPU som man kopplat två stycken vektor-enheter. VU0 var i stort sätt en "vanlig" flyttalsprocessor medan VU1 hade en direktkoppling till GS-kretsen (den som gjorde ROP) på ett sätt så VU1 kunde användas till enklare former av vad som senare kom att kallas "vertex-shaders".

Fortsättning på detta rykte är att Sony ganska sent insåg hur stort arbete man hade i att skapa en fungerade grafikstack ovanpå Cell så man fick i panik shoppa en "vanlig" GPU och kasta ut ena Cell-CPUn. I slutändan lärde sig ändå first-tier utvecklarna för PS3 hur en lång rad grafikeffekter och även logik effektivt kunde hanteras i SPE-enheterna, så den GPU-del som sitter i PS3 har i sina dar rendera grafik som den absolut inte är kapabel till utan Cell.

Dold text

Jag är rätt säker på att det stämmer. Ryktet har jag läst på ett flertal sajter, och jag har även läst en djupgående artikel om hur Sony kontaktade Nvidia för att lösa deras problem, men Nvidia tog väldigt bra betalt och var överlag inte så väldans tillmötesgående, så Sony kände sig inte så värst nöjda med samarbetet. Det var ju förstås ett tag sedan, så den kanske inte är helt trovärdig, men samtidigt ändå, då det ju var ett tag innan PS4 var i ropet.

Skrivet av DavidtheDoom:

Du missar att en utvecklingcykel inte är så kort att man kan vänta tills lanseringsdatum av GPU X och få in den i maskinen på direkten och lansera konsollen.

Sonys samarbete med Nvidia till PS3 började åtminstonne 2004 (http://www.ign.com/articles/2004/12/08/nvidia-sony-and-playst...), och de tog fram flera prototyper med bättre specifikationer allt eftersom tiden gick, och den som lanserades var den femte av dem. Tror den första innehöll någon Geforce 5 bara för att få ett hum om saker och ting, sedan körde de med Geforce 6 länge innan de smällde in en G70 i slutet. Så helt hux flux var det inte. Om IBM kunde ta fram en CPU-derivata av Cell på mindre än ett år åt Microsoft som blev rätt bra så tror jag definitivt det hade gått att få in ett Geforce 8-chip i PS3.

500 watt räcker för en elementär dator oavsett grafikkort utan överklockning. Räkna ut annat på OuterVision Power Supply Calculator. Power. Performance. PRIME.
Elektrostatisk urladdning är ett verkligt problem.

"People who are serious about software should make their own hardware" – Alan Kay

Trädvy Permalänk
Datavetare
Plats
Stockholm
Registrerad
Jun 2011
Skrivet av DavidtheDoom:

Du missar att en utvecklingcykel inte är så kort att man kan vänta tills lanseringsdatum av GPU X och få in den i maskinen på direkten och lansera konsollen.

GPU-delen i PS3 är inte speciellt integrerad i resten, så det borde ha varit en rätt smal sak att stoppa in den kretsen väldigt sent i processen. PS3 har ju separat GPU-minne som inte verkar vara snabbare att läsa/skriva till än vad man kunde förvänta sig om den satt på PCIe- (eller på den tiden AGP-) buss, GPU-kretsen är separat från resten.

Men det är inget jättejobb att stoppa in ett CPU- och/eller GPU-block heller, enda undantagen är Intel och AMDs tidigare (då de fortfarande hade egen tillverkning) "big-core" designer då dessa CPU-designer är så pass specialiserade att de kräver att man även utvecklar specifika fabriker för dem. Nvidia och ATI-delen av AMD har aldrig haft egen tillverkning, så deras designer har alltid varit anpassade för att tillverkas av 3:e-part.

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Trädvy Permalänk
Testpilot, Geeks Gaming
David Kvist
Plats
Göteborg
Registrerad
Jun 2012
Skrivet av Yoshman:

GPU-delen i PS3 är inte speciellt integrerad i resten, så det borde ha varit en rätt smal sak att stoppa in den kretsen väldigt sent i processen. PS3 har ju separat GPU-minne som inte verkar vara snabbare att läsa/skriva till än vad man kunde förvänta sig om den satt på PCIe- (eller på den tiden AGP-) buss, GPU-kretsen är separat från resten.

Men det är inget jättejobb att stoppa in ett CPU- och/eller GPU-block heller, enda undantagen är Intel och AMDs tidigare (då de fortfarande hade egen tillverkning) "big-core" designer då dessa CPU-designer är så pass specialiserade att de kräver att man även utvecklar specifika fabriker för dem. Nvidia och ATI-delen av AMD har aldrig haft egen tillverkning, så deras designer har alltid varit anpassade för att tillverkas av 3:e-part.

Den biten ifrågasätter jag inte men jag ifrågasätter det naiva tankesättet att tro att man kan vänta fram till lanseringsdag för ett grafikkort och dagen efter lansera konsolen. Lär vara bra mycket mer jobb att få in en krets, och då inte hårdvarumässigt utan framförallt ekonomiskt och logistiskt.

Synpunkter på min moderering? Kontakt:
| PM:a mig | Maila mig | PM:a Moderatorerna | Kontaktformuläret |
Testpilot, Moderator & Geeks Gaming Huvudadmin
| Sweclockers Teamspeak |
Forumregler

Trädvy Permalänk
Medlem
Plats
Malmö
Registrerad
Dec 2004
Skrivet av DavidtheDoom:

Den biten ifrågasätter jag inte men jag ifrågasätter det naiva tankesättet att tro att man kan vänta fram till lanseringsdag för ett grafikkort och dagen efter lansera konsolen. Lär vara bra mycket mer jobb att få in en krets, och då inte hårdvarumässigt utan framförallt ekonomiskt och logistiskt.

Samarbetet inleds förstås i god tid så att allting hinner bli uppstyrt tills chipet är färdigt. Och lanseringen av retailprodukter sker ju ett ganska bratag efter att designen slagits fast, och några månader efter tester och annat är färdigt.

Som sagt, om IBM kan ta fram en CPU åt Microsoft på mindre än 1 år tror jag definitivt att det skulle gå att stoppa in en G80 i PS3an med lansering samma år om viljan hade funnits. Nvidias samarbete med Sony kring PS3 sträckte sig rätt långt tillbaka ändå.

500 watt räcker för en elementär dator oavsett grafikkort utan överklockning. Räkna ut annat på OuterVision Power Supply Calculator. Power. Performance. PRIME.
Elektrostatisk urladdning är ett verkligt problem.

"People who are serious about software should make their own hardware" – Alan Kay

Trädvy Permalänk
Medlem
Plats
Malmö
Registrerad
Dec 2004

Titta vad jag hittade @Yoshman
http://forums.xbox-scene.com/index.php?/topic/231928-xenon-ha...
Läckt internt dokument om Xbox 360 från någonstans innan juni 2004.

Source: Unknown

QUOTE
Xenon Hardware Overview

By Pete Isensee, Development Lead, Xbox Advanced Technology Group

This documentation is an early release of the final documentation, which may be changed substantially prior to final commercial release, and is confidential and proprietary information of MS Corporation. It is disclosed pursuant to a nondisclosure agreement between the recipient and MS.
“Xenon” is the code name for the successor to the Xbox® game console from MS. Xenon is expected to launch in 2005. This white paper is designed to provide a brief overview of the primary hardware features of the console from a game developer’s standpoint.

Caveats
In some cases, sizes, speeds, and other details of the Xenon console have not been finalized. Values not yet finalized are identified with a “+” sign, indicating that the numbers may be larger than indicated here. At the time of this writing, the final console is many months from entering production. Based on our experience with Xbox, it’s likely that some of this information will change slightly for the final console.

For additional information on various hardware components, see the other relevant white papers.

Hardware Goals
Xenon was designed with the following goals in mind:

•Focus on innovation in silicon, particularly features that game developers need. Although all Xenon hardware components are technologically advanced, the hardware engineering effort has concentrated on digital performance in the CPU and GPU.

•Maximize general purpose processing performance rather than fixed-function hardware. This focus on general purpose processing puts the power into the Xenon software libraries and tools. Rather than being hamstrung by particular hardware designs, software libraries can support the latest and most efficient techniques.

•Eliminate the performance issues of the past. On Xbox, the primary bottlenecks were memory and CPU bandwidth. Xenon does not have these limitations.

Basic Hardware Specifications

Xenon is powered by a 3.5+ GHz IBM PowerPC processor and a 500+ MHz ATI graphics processor. Xenon has 256+ MB of unified memory. Xenon runs a custom operating system based on MS® Windows NT®, similar to the Xbox operating system. The graphics interface is a superset of MS® Direct3D® version 9.0.
CPU

The Xenon CPU is a custom processor based on PowerPC technology. The CPU includes three independent processors (cores) on a single die. Each core runs at 3.5+ GHz. The Xenon CPU can issue two instructions per clock cycle per core. At peak performance, Xenon can issue 21 billion instructions per second.

The Xenon CPU was designed by IBM in close consultation with the Xbox team, leading to a number of revolutionary additions, including a dot product instruction for extremely fast vector math and custom security features built directly into the silicon to prevent piracy and hacking.

Each core has two symmetric hardware threads (SMT), for a total of six hardware threads available to games. Not only does the Xenon CPU include the standard set of PowerPC integer and floating-point registers (one set per hardware thread), the Xenon CPU also includes 128 vector (VMX) registers per hardware thread. This astounding number of registers can drastically improve the speed of common mathematical operations.

Each of the three cores includes a 32-KB L1 instruction cache and a 32-KB L1 data cache. The three cores share a 1-MB L2 cache. The L2 cache can be locked down in segments to improve performance. The L2 cache also has the very unusual feature of being directly readable from the GPU, which allows the GPU to consume geometry and texture data from L2 and main memory simultaneously.
Xenon CPU instructions are exposed to games through compiler intrinsics, allowing developers to access the power of the chip using C language notation.
GPU

The Xenon GPU is a custom 500+ MHz graphics processor from ATI. The shader core has 48 Arithmetic Logic Units (ALUs) that can execute 64 simultaneous threads on groups of 64 vertices or pixels. ALUs are automatically and dynamically assigned to either pixel or vertex processing depending on load. The ALUs can each perform one vector and one scalar operation per clock cycle, for a total of 96 shader operations per clock cycle. Texture loads can be done in parallel to ALU operations. At peak performance, the GPU can issue 48 billion shader operations per second.

The GPU has a peak pixel fill rate of 4+ gigapixels/sec (16 gigasamples/sec with 4× antialiasing). The peak vertex rate is 500+ million vertices/sec. The peak triangle rate is 500+ million triangles/sec. The interesting point about all of these values is that they’re not just theoretical—they are attainable with nontrivial shaders.

Xenon is designed for high-definition output. Included directly on the GPU die is 10+ MB of fast embedded dynamic RAM (EDRAM). A 720p frame buffer fits very nicely here. Larger frame buffers are also possible because of hardware-accelerated partitioning and predicated rendering that has little cost other than additional vertex processing. Along with the extremely fast EDRAM, the GPU also includes hardware instructions for alpha blending, z-test, and antialiasing.

The Xenon graphics architecture is a unique design that implements a superset of Direct3D version 9.0. It includes a number of important extensions, including additional compressed texture formats and a flexible tessellation engine. Xenon not only supports high-level shading language (HLSL) model 3.0 for vertex and pixel shaders but also includes advanced shader features well beyond model 3.0. For instance, shaders use 32-bit IEEE floating-point math throughout. Vertex shaders can fetch from textures, and pixel shaders can fetch from vertex streams. Xenon shaders also have the unique ability to directly access main memory, allowing techniques that have never before been possible.

As with Xbox, Xenon will support precompiled push buffers (“command buffers” in Xenon terminology), but to a much greater extent than the Xbox console does. The Xbox team is exposing and documenting the command buffer format so that games are able to harness the GPU much more effectively.

In addition to an extremely powerful GPU, Xenon also includes a very high-quality resize filter. This filter allows consumers to choose whatever output mode they desire. Xenon automatically scales the game’s output buffer to the consumer-chosen resolution.

Memory and Bandwidth
Xenon has 256+ MB of unified memory, equally accessible to both the GPU and CPU. The main memory controller resides on the GPU (the same as in the Xbox architecture). It has 22.4+ GB/sec aggregate bandwidth to RAM, distributed between reads and writes. Aggregate means that the bandwidth may be used for all reading or all writing or any combination of the two. Translated into game performance, the GPU can consume a 512×512×32-bpp texture in only 47 microseconds.

The front side bus (FSB) bandwidth peak is 10.8 GB/sec for reads and 10.8 GB/sec for writes, over 20 times faster than for Xbox. Note that the 22.4+ GB/sec main memory bandwidth is shared between the CPU and GPU. If, for example, the CPU is using 2 GB/sec for reading and 1 GB/sec for writing on the FSB, the GPU has 19.4+ GB/sec available for accessing RAM.

Eight pixels (where each pixel is color plus z = 8 bytes) can be sent to the EDRAM every GPU clock cycle, for an EDRAM write bandwidth of 32 GB/sec. Each of these pixels can be expanded through multisampling to 4 samples, for up to 32 multisampled pixel samples per clock cycle. With alpha blending, z-test, and z-write enabled, this is equivalent to having 256 GB/sec of effective bandwidth! The important thing is that frame buffer bandwidth will never slow down the Xenon GPU.

Audio
The Xenon CPU is a superb processor for audio, particularly with its massive mathematical horsepower and vector register set. The Xenon CPU can process and encode hundreds of audio channels with sophisticated per-voice and global effects, all while using a fraction of the power of a single CPU core.

The Xenon system south bridge also contains a key hardware component for audio—XMA decompression. XMA is the native Xenon compressed audio format, based on the WMA Pro architecture. XMA provides sound quality higher than ADPCM at even better compression ratios, typically 6:1–12:1. The south bridge contains a full silicon implementation of the XMA decompression algorithm, including support for multichannel XMA sources. XMA is processed by the south bridge into standard PCM format in RAM. All other sound processing (sample rate conversion, filtering, effects, mixing, and multispeaker encoding) happens on the Xenon CPU.

The lowest-level Xenon audio software layer is XAudio, a new API designed for optimal digital signal processing. The Xbox Audio Creation Tool (XACT) API from Xbox is also supported, along with new features such as conditional events, improved parameter control, and a more flexible 3D audio model.

Input/Output
As with Xbox, Xenon is designed to be a multiplayer console. It has built-in networking support including an Ethernet 10/100-BaseT port. It supports up to four controllers. From an audio/video standpoint, Xenon will support all the same formats as Xbox, including multiple high-definition formats up through 1080i, plus VGA output.

In order to provide greater flexibility and support a wider variety of attached devices, the Xenon console includes standard USB 2.0 ports. This feature allows the console to potentially host storage devices, cameras, microphones, and other devices.

Storage
The Xenon console is designed around a larger world view of storage than Xbox was. Games will have access to a variety of storage devices, including connected devices (memory units, USB storage) and remote devices (networked PCs, Xbox Live™). At the time of this writing, the decision to include a built-in hard disk in every Xenon console has not been made. If a hard disk is not included in every console, it will certainly be available as an integrated add-on component.

Xenon supports up to two attached memory units (MUs). MUs are connected directly to the console, not to controllers as on Xbox. The initial size of the MUs is 64 MB, although larger MUs may be available in the future. MU throughput is expected to be around 8 MB/sec for reads and 1 MB/sec for writes.

The Xenon game disc drive is a 12× DVD, with an expected outer edge throughput of 16+ MB/sec. Latency is expected to be in the neighborhood of 100 ms. The media format will be similar to Xbox, with approximately 6 GB of usable space on the disk. As on Xbox, media will be stored on a single side in two 3 GB layers.

Industrial Design
The Xenon industrial design process is well under way, but the final look of the box has not been determined. The Xenon console will be smaller than the Xbox console.
The standard Xenon controller will have a look and feel similar to the Xbox controller. The primary changes are the removal of the Black and White buttons and the addition of shoulder buttons. The triggers, thumbsticks, D-pad, and primary buttons are essentially unchanged. The controller will support vibration.

Xenon Development Kit
The Xenon development environment follows the same model as for Xbox. Game development occurs on the PC. The resulting executable image is loaded by the Xenon development kit and remotely debugged on the PC. MS® Visual Studio® version 7.1 continues as the development environment for Xenon.

The Xenon compiler is based on a custom PowerPC back end and the latest MS® Visual C++® front end. The back end uses technology developed at MS for Windows NT on PowerPC. The Xenon software group includes a dedicated team of compiler engineers updating the compiler to support Xenon-specific CPU extensions. This team is also heavily focused on optimization work.
The Xenon development kit will include accurate DVD emulation technology to allow developers to very precisely gauge the effects of the retail console disc drive.

Miscellaneous Xenon Hardware Notes

Some additional notes:
•Xenon is a big-endian system. Both the CPU and GPU process memory in big-endian mode. Games ported from little-endian systems such as the Xbox or PC need to account for this in their game asset pipeline.

•Tapping into the power of the CPU is a daunting task. Writing multithreaded game engines is not trivial. Xenon system software is designed to take advantage of this processing power wherever possible. The Xbox Advanced Technology Group (ATG) is also exploring a variety of techniques for offloading graphics work to the CPU.

•People often ask if Xenon can be backward compatible with Xbox. Although the architecture of the two consoles is quite different, Xenon has the processing power to emulate Xbox. Whether Xenon will be backward compatible involves a variety of factors, not the least of which is the massive development and testing effort required to allow Xbox games run on Xenon.

Dold text

Kort och spontant känns det som att folket på Microsoft hade rakt motsatt tänk gentemot sina kolleger på Sony.
Tänker framför allt på detta:
•Maximize general purpose processing performance rather than fixed-function hardware. This focus on general purpose processing puts the power into the Xenon software libraries and tools. Rather than being hamstrung by particular hardware designs, software libraries can support the latest and most efficient techniques.

500 watt räcker för en elementär dator oavsett grafikkort utan överklockning. Räkna ut annat på OuterVision Power Supply Calculator. Power. Performance. PRIME.
Elektrostatisk urladdning är ett verkligt problem.

"People who are serious about software should make their own hardware" – Alan Kay

Trädvy Permalänk
Testpilot, Geeks Gaming
David Kvist
Plats
Göteborg
Registrerad
Jun 2012

@Gibbe: Mycket intressant dokument!
Behöver sätta mig in i ämnet igen innan jag kan intellektuell kommentera på innehållet.

Synpunkter på min moderering? Kontakt:
| PM:a mig | Maila mig | PM:a Moderatorerna | Kontaktformuläret |
Testpilot, Moderator & Geeks Gaming Huvudadmin
| Sweclockers Teamspeak |
Forumregler

Trädvy Permalänk
Datavetare
Plats
Stockholm
Registrerad
Jun 2011

@Gibbe: väldigt intressant information!

Och till stor del vad Xenon en långt bättre design än Cell som TV-spel. På pappret var ju PS3 långt kraftigare, men det var kraftig på ett sätt som var extremt svårt att utnyttja i spel. När man väl lärde sig tygla "power of the Cell" så var det bara att konstatera att det endast var möjligt för de exklusiva titlar då en sådan motor och ett sådant spel var tvunget att designas helt kring de styrkor som faktiskt fanns.

Xbox360 var betydligt närmare PC i sin design, det enda som låg den i fatet var att det har tagit till ungefär nu för speltillverkarna att lära sig designa spelmotorer som kan använda 3 CPU-kärnor / 6 CPU-trådar. Vet att Carmack var väldigt avigt inställd till både PS3 och 360, han ansåg (helt korrekt så här med facit i hand) att spelbranschen inte var mogen för HW där multicoreprogrammering var ett krav och på den nivån som PS3/360 krävde det (360 6 trådar, PS3 2 trådar + 6 SPEer).

Rent CPU-mässigt är det faktiskt inte jättestor skillnad mellan 360 och PS4/XBO, de senare är mycket mer förlåtande mot ej optimerad kod. Men skriver man "snäll" kod så är CPU-kraften i 360 inte speciellt långt efter, vilket jag tycker är lite trist då denna generation kommer tyvärr blir lite samma som förra fast med bättre grafik. I.o.f.s. mycket mer RAM som ger en hel del flexibilitet.

Carmack ansåg att man borde kört en generation till med single core eller i alla fall inte mer än dual core.

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer