Intels Haswell-processors gaan DirectX 11.1 ondersteunen

Intels Haswell-cpu's, die in 2013 moeten verschijnen, krijgen ondersteuning voor het nog onaangekondigde Microsoft DirectX 11.1. Daarnaast moet de nieuwe grafische chip overweg kunnen met versie 3.2 van de OpenGL-api.

Dat blijkt uit een uitgelekte roadmap, die is gericht op de ingebouwde grafische chips van Intels processors en de applicaties waarvoor ze gecertificeerd zijn. Van Intels Ivy Bridge-cpu's, die in 2012 uitkomt, was al bekend dat de igp's ondersteuning voor DirectX 11 krijgen. De huidige Sandy Bridge-chips komen niet verder dan versie 10.1 van DirectX.

Intels Hasswell-processors zouden nog verder gaan dan Ivy Bridge door ook versie 11.1 van DirectX te ondersteunen. Dit zou ook de eerste igp zijn waarmee het bedrijf compleet op Windows 8 mikt. Het is daarom aannemelijk dat DirectX 11.1 de versie is die samen met Windows 8 wordt geleverd.

Mocht Windows 8 met DirectX 11.1 worden geleverd, dan zou dat de frequentie waarmee Microsoft nieuwe DirectX-versies aflevert verlagen. Windows Vista en Windows 7 werden met respectievelijk DirectX 10 en 11 geleverd. Tussen Windows 7 en 8 zou dan enkel een point release van DirectX zitten. Of de verschillen tussen DirectX 11 en 11.1 zo klein zijn als de versienummers suggereren, is nog niet bekend.

Reacties (82)

[Verwijderd]

Opmerkelijk genoeg gaat deze roadmap alleen over software ondersteuning en niet over de mate waarin deze Gfx onderdelen veel krachtiger worden dan dat ze nu zijn.

Dat is een beetje vreemd aangezien Intel toch wel een behoorlijke inhaalslag nodig heeft om AMD bij te kunnen benen op grafisch gebied.........

[Dreamvoid]

De achterstand van Intel is juist de software kant, aan de hardware kant doet Intel het door hun sterke produktietechnologie helemaal niet zo beroerd. De HD 3000 op de Sandy Bridge is weliswaar 2x langzamer dan de Llano's, maar Intel heeft dan ook half zo weinig oppervlak (transistors) voor het gpu gedeelte gebruikt. In principe is het toevoegen van meer shaders en hogere klok niet heel moeilijk voor een ervaren chipbakker als Intel, het gaat alleen binnen 1 cpu/gpu package van je speelruimte voor het cpu deel af. nVidia en AMD lopen met name voor op het gebied van features en software: OpenCL/CUDA/etc.

[Reactie gewijzigd door Dreamvoid op 22 juli 2024 21:33]

[Verwijderd]

nVidia en AMD lopen met name voor op het gebied van features en software: OpenCL/CUDA/etc.

Die voorsprong zal van korte duur zijn. Haswell's AVX2 ondersteuning biedt 'gather' instructies, FMA, 256-bit integer vectors, en nog meer van dat moois.

Daarmee wordt de CPU net zo goed in 'throughput computing' als de GPU. Beter nog, door ook een hoge sequentiele snelheid en ongelimiteerde ondersteuning voor zaken zoals functie-recursie met een grote stack, zullen complexe applicaties heel wat sneller draaien op een CPU dan op een GPU.

Uiteindelijk zullen de CPU cores ook de grafische taken voor hun rekening kunnen nemen. De IGP zal dus verdwijnen en met CPUs met zeer veel cores zal ook de discrete GPU-kaart moeten wijken. Graphics wordt steeds meer programmeerbaar en de CPU krijgt erg krachtige vectorinstructies, dus heeft het geen zin meer om die berekeningen decentraal uit te voeren.

[dmantione]

Door alleen al te kijken naar de grote geheugenbandreedtes (kijk maar eens op de specsheets van een videokaart: 256 bit bus, 4000MHz effectief) benodigd voor GPU's kun je beredeneren dat dit onzin is.

Ook blijft gelden dat specialistische hardware efficiënt is in wat het doet. Je zou gelijk kunnen hebben als warmteproduktie en chipoppervlak geen beperkingen waren, maar helaas, dat zijn ze wel. Als je grote hoeveelheden gigaflopsen hebt te berekenen, dan is een GPU-architectuur daarom de aangewezen weg.

Overigens weet Intel dat prima, ze ontwikkelen niet voor niets hun Knights Ferry, het is alleen de vraag of ze daarmee ooit met GPU's kunnen concurreren.

[Verwijderd]

Door alleen al te kijken naar de grote geheugenbandreedtes (kijk maar eens op de specsheets van een videokaart: 256 bit bus, 4000MHz effectief) benodigd voor GPU's kun je beredeneren dat dit onzin is.

De CPU en IGP delen dezelfde socket, en dus is er ook geen verschil in beschikbare geheugenbandbreedte. En er staat geen limiet op. Sandy Bridge-E krijgt reeds vier geheugenkanalen, in totaal 256-bit dus. DDR4 zal ook heel ver doorschalen. Dus er is geen reden waarom de CPU de taak van een discrete GPU niet kan overnemen.

Ook blijft gelden dat specialistische hardware efficiënt is in wat het doet. Je zou gelijk kunnen hebben als warmteproduktie en chipoppervlak geen beperkingen waren, maar helaas, dat zijn ze wel. Als je grote hoeveelheden gigaflopsen hebt te berekenen, dan is een GPU-architectuur daarom de aangewezen weg.

Niks belet de CPU om dezelfde efficiëntie te behalen. Intel heeft reeds vermeld dat AVX uitgebreid kan worden naar 1024-bit. Net zoals bij een GPU hoeven die brede vectoren echter niet in één klockcyclus verwerkt te worden. Door AVX-1024 instructies in vier cycli op de bestaande 256-bit verwerkingseenheden uit te voeren, onstaat een grote opportuniteit om zwaar te gaan clock-gaten. De front-end hoeft slechts 1/4 van de instructieverwerking te voorzien -zonder aan effectieve rekenkracht in te boeten- waardoor de chip heel wat minder stroom verbruikt.

GPUs bevatten steeds minder gespecialiseerde hardware. Micro-polygonen en ray-tracing vragen om programmeerbare rasterisatie, en ook texturen filteren wordt steeds vaker aan de programmeerbare cores overgelaten. GPUs zelve evoluren dus steeds meer richting de volledige programmeerbaarheid van de CPU.

Ook de toevoeging van F16C aan AVX verwijst sterk naar grafische verwerking. En niks belet CPU-designers van nog meer instructies toe te voegen die voornamelijk (maar niet exclusief) nuttig zijn voor grafische taken.

[SG]

Het gebruik van 256bit tot 1024bit FP of integer is nihil en extreme aps gebruiken die dingen. dus denk ik eerder dat single instructie multiple date het meeste wordt gebruikt.
4 64bit fp bundelen. Wel een GPU gebruikt daar 8 stream procesors voor als ze 64fp generfd hebben. Zo niet 4 stream procs die double aankunnen.

Daarnaast verbeterd intel hun cores maar GPU boeren doen dat ook. SM4.1 zitten we nu en elke gen is weer flexible en uitgebreider dan de vorige.
Dus wat brengt de next cuda cores en AMD stream cores.
Daarnaast ben je met die AVx en ander SSE instructie extenties zwaar afhankelijk van gebruik van iNtels plugin compiler. terwijl het gross standaard compiler van hun ontwikkel omgeving toepassen die intel en AMD cpu evenredig of de meest gemene deler ondersteunen.

Bij GPU krijg CUDA 3.3 opvolhger en OpenCL 1.1 opvolging.

Dat iNtel Grafisch ondersteunenede instructies set introduceerd is goed mogelijk. Want dat hadden ze al voor de Larabee cores klaar gestoomd. dus hebben ze al klaar liggen voor gebruik in andere cores. Wetende dat de zwaar geinvesteerde LRB een flop geworden is. Maakt CPU nog geen GPU killer.
GFX is een zeer goed en onafhankelijke fine grain parraleliseerbare vererking toepassing. Wat zich extreem uitleend voor concurent prosessing.

Ik zie eerder dat nextgen CPU het veel beter kunnen dan vorige gen. Maar nog niet kunnen tippen aan GPU.

[Verwijderd]

Het gebruik van 256bit tot 1024bit FP of integer is nihil en extreme aps gebruiken die dingen.

Nonsens. GPUs werken met vectoren van wel 2048-bit.

Wel een GPU gebruikt daar 8 stream procesors voor als ze 64fp generfd hebben. Zo niet 4 stream procs die double aankunnen.

SIMD op een CPU is compleet hetzelfde als SIMD op een GPU.

Daarnaast verbeterd intel hun cores maar GPU boeren doen dat ook. SM4.1 zitten we nu en elke gen is weer flexible en uitgebreider dan de vorige.

Inderdaad, maar als we de vooruitgang in de halfgeleidertechnologie in acht nemen, daalt de rekenkracht van de GPU met elke nieuwe generatie. Ze investeren immers steeds meer transistors in hogere flexibiliteit. De CPU heeft reeds ultieme flexibiliteit, maar maken een inhaalbeweging qua rekenkracht met brederer vectoren en FMA. Dus ze convergeren naar elkaar toe.

Daarnaast ben je met die AVx en ander SSE instructie extenties zwaar afhankelijk van gebruik van iNtels plugin compiler.

Nog meer nonsens. Ook Microsoft's compilers en GCC ondersteunen AVX. En LLVM kan gebruikt worden om dynamisch AVX code te genereren. Zo wordt OpenCL bijvoorbeeld gecompileerd naar heel efficiente code, en met AVX2 wordt dat nog een heel pak sneller (voornamelijk dankzij gather instructies).

[ferdinand]

Daarmee wordt de CPU net zo goed in 'throughput computing' als de GPU. Beter nog, door ook een hoge sequentiele snelheid en ongelimiteerde ondersteuning voor zaken zoals functie-recursie met een grote stack, zullen complexe applicaties heel wat sneller draaien op een CPU dan op een GPU.

[sarcasm]
Yup Intel gaat ervoor zorgen dat 1 cpu core zoveel paralelle rekenkracht heeft dat 500+ cores van Nvidia het niet meer kunnen bijbenen. Dit is mogelijk door nieuwe magische instructies die 1000 instructies kunnen converteren naar 1 instructie die de cpu razendsnel kan uitvoeren.
[/sarcasm]

[Verwijderd]

Geen van NVIDIA's GPUs heeft 500+ cores. Ze hebben tot 4 cores, met elk 4 vectoreenheden van 32 elementen. Da's een totaal van 512 ALUs, niet cores.

Mainstream CPUs hebben momenteel tot 4 cores, met elk 2 vectoreenheden, van 8 elementen. Da's 64 ALUs. En ze zijn twee keer zo snel geklokt, en de CPU cores zijn een heel pak kleiner.

Niks weerhoud Intel van een 8-core Haswell CPU 1 TFLOP te doen behalen, en da's aardig in de buurt van NVIDIA's topmodel, met een kleinere en zuinigere chip...

Je mag in het vervolg je sarcasme dus achterwege laten. Er is niks magisch nodig om een CPU uit te rusten met vergelijkbare rekenkracht.

[Devpartner]

Als je cpu cores kleiner noemt ....

Afgezien van de power and process node heeft fermi een 3keer hogere densiteit voor zijn 'alu's' dan de intel core serie.

[Verwijderd]

Afgezien van de power and process node heeft fermi een 3keer hogere densiteit voor zijn 'alu's' dan de intel core serie.

Ben je niet vergeten om de kloksnelheid mee te rekenen en de IGP uit de berekening te laten?

Bemerkt verder dat de GPU waardeloos is zonder CPU. Je moet dus eigenlijk een stuk CPU meerekenen om objectief de mogelijkheden te vergelijken.

[MSalters]

Hoe kom je aan 16 vectorelementen per core? SSE heeft 4 SP units (4x32=128 bits). AVX heeft er 8, maar ik zie geen CPU met 2 AVX units per core.

[Verwijderd]

Zowel poort 0, 1 en 5 kunnen AVX-instructies uitvoeren, simultaan. Maar doorgaans telt men enkel optellingen en vermenigvuldigingen. De verwachting is dat Haswell twee FMA-instructies per klokcyclus kan uitvoeren.

[Devpartner]

Hasswel = 2013. Software support ~ 2014.
Als je denkt dat AMD en Nvidia 3jaar gaan stilstaan dan ben je toch grondig mis hoor.

Bij AMD en Nvidia spreken tegen die tijd echt niet meer over GFlops hoor.

De rekenkracht waar jij over spreekt (waar je het ook maar vandaan haalt) wordt in pure nummers al gehaald met trinity die over minder dan 6-8 maand komt.

AMD is ook bezig met hun gpu architectuur om te schakelen naar meer gpgpu orriented, net zoals nvidia... Dus ik zie bijlange niet in hoe intel alles voorbij gaat steken met AVX2... we zullen zien over 3jaar..

[Verwijderd]

Hasswel = 2013. Software support ~ 2014.

In 2014 hebben we alweer de volgende process shrink...

Als je denkt dat AMD en Nvidia 3jaar gaan stilstaan dan ben je toch grondig mis hoor.

Neen, tegen dan heeft AMD bijvoobeeld 'Graphics Core Next'. En daarvan is reeds duidelijk dat de hogere flexibiliteit een lagere rekendensiteit zal betekenen.

De rekenkracht waar jij over spreekt (waar je het ook maar vandaan haalt) wordt in pure nummers al gehaald met trinity die over minder dan 6-8 maand komt.

Theoretisch misschien, maar in de praktijk haalt een GPU doorgaans slechts een fractie van z'n rekenkracht bij generieke taken. En tenzij Trinity aanzienlijk hogere RAM-bandbreedte heeft, ingebouwde eDRAM, of een grote L3 cache, komt er van het verwezenlijken van meer effectieve rekenkracht niks van in huis. En al die zaken zorgen voor een aanzienlijke meerkost. Llano is al een behoorlijk grote chip, en AMD zal in 8 maanden nog steeds op 32 nm zitten.

AMD is ook bezig met hun gpu architectuur om te schakelen naar meer gpgpu orriented, net zoals nvidia...

Inderdaad, en die omschakeling kost transistors! De ruwe rekenkracht per transistor gaat omlaag en de architectuur komt steeds dichter bij die van een CPU aanleunen. Er is niks dat deze convergentie stopt, dus vroeg of laat zijn ze zodanig gelijkaardig dat men beter één type core overhoudt dat zowel efficient sequentiële als parallele taken kan uitvoeren. Hetzelfde is reeds gebeurd met 'unified' vertex- en pixel-verwerking.

[PjotterP]

Is dat zo? Voor de meeste gebruikers is iets meer power misschien welkom maar de huidige intel IGP's hebben al een niveau bereikt dat voor het merendeel van toepassingen voldoende is en bovendien energiezuinig. Mensen die behoefte aan 'echte' grafische power kiezen toch eerder voor een discrete oplossing

[vayana]

Wat ik me nou afvraag is of die ondersteuning ook iets positiefs gaat betekenen voor games met DX11 (.1) Ik bedoel, kan de processor dan ook daadwerkelijk de losse videokaart helpen met sommige processen, of is het óf de losse videokaart óf de igp?

In dat opzicht heb ik meer vertrouwen op de weg die AMD inslaat met fusion.

[Verwijderd]

Het lijkt erop dat je een paar begrippen door elkaar haalt.

De IGP was voorheen de geïntegreerde videokaart op het moederbord.
Deze voormalige igp is nu onderdeel van de APU, namelijk het GPU gedeelte.
Zowel Intel als AMD hebben gecombineerde GPU/CPU processors.

Bij AMD kon je voorheen de IGP laten samenwerken met een losse grafische kaart.
_{(Dat heette dacht ik Crossfire-X)}
In hoeverre het nog steeds mogelijk is bij AMD om een losse grafische kaart te laten samenwerken met het GPU gedeelte van de APU weet ik niet.

Er is hier vast wel iemand die dat wel weet.......

[Majin Buu]

Hybrid Crossfire

Link naar T.net review

[Reactie gewijzigd door Majin Buu op 22 juli 2024 21:33]

[humbug]

Wat alleen nauwelijk nut lijkt te hebben. Zelfs met een lowend discrete gpu voegt de APU vrijwel niets toe. Ik zie dan ook meer voordeel in het feit dat je de discrete GPU kan uitzetten op het moment dat je hem niet nodig hebt om zo energie te besparen. Dit kan zowel met AMD als Intel.

[Knobby]

je kan je geintegreerde (amd) gpu laten crossfire-en met een losse (amd) videokaart
hoe het zit met intel weet ik niet

[Dylan93]

Ja dit kan AMD Dual Graphics is de oplossing.

[Verwijderd]

Er bestaat nu al een soort van crossfire-x opstelling voor een APU en losse GPU hier een item erover : http://www.youtube.com/wa...U&feature=player_embedded

[Reactie gewijzigd door Verwijderd op 22 juli 2024 21:33]

[Verwijderd]

Nice, al zijn die nieuwe gpu's natuurlijk onbetaalbaar(voor mijn budget) op de releasedate?
Heb namelijk net 2x een 6970 aangeschaft...

[humbug]

IGPs zijn natuurlijk niet de meest krachtige chips. Dat zal je probleem niet zijn. Wat wel kan is dat directX 11.1 efficiënter is en nieuwe effecten mogelijk maakt waardoor kaarten met directX 11.1 duidelijk betere plaatjes kunnen neerzetten dan kaarten zonder. Daar is op dit moment eigenlijk weinig over te zeggen. Maar als je nu 2x een 6970 hebt zal een IGP over twee jaar niet voldoen en zal je eerder een nieuwe setup van discrete GPUs neerzetten. Ga er maar vanuit dat je huidige setup tzt verouderd is.

[SG]

Bij iNtel zijn igp in verleden zeer zwak ook mede het driver team. waar performance niet het streven was.
Maar AMD pakt het anders aan. Mogelijk omdat ze op CPU vlak niet goed meekomen.
Stoppen ze voor IGP diespace normn een relatief grote GPU deel in de APU.

Dus Igp is clasiek low budged. Maar bij AMD zit het dicht bij midrange. En dat met de driver support.
houd in dat IGP een grote sprong voorwaarts maakt.

[nr12]

Wees maar niet bang, deze CPU (met gpu ingebouwd) zal echt niet betere preformence bieden dan 2 x 6970. Jou setup is way sterker dan een onboard gpu van over 2 jaar.

[Verwijderd]

Oow, was al bang dat dx 11.1 het nieuwe dx12 was..
Thanks for the update.

[Ackermans1973]

Per saldo kan een DX-11 kaart uiteindelijk NIET DX-11.1 doen. Dus ja, ligt eraan hoe je het bekijkt, maar DX-11.1 kaarten en CPU's kunnen dus straks wel meer. Op brute kracht misschien gelijk maar er zullen punten zijn die ze wel kunnen uitvoeren en de 6970 niet.

[SG]

Nou dat is deels het geval. Vaak is het meer van een hogere DX kan bepaalde features efficenter doen. Maar ook van meer complexere gebruik ervan.
Omdat Nextgen vaak mee lifd op moderne procede komt er ook brute rauwe performance sprong. Simpel door meer reken eennheden en hogere klok.

[Madje]

Onboard gpu is vooral voor tablets en laptops interessant. Je zit dus nog wel goed met je gfx monsters

[Ackermans1973]

Is in principe onzin, want dat is puur uitgaand van rekenkracht. DX-11.1 zal nieuwe features hebben, dus, "meer" kunnen dan de huidige DX-11 kaarten.

[TetPr87]

Ja? Dus je blijft strax op een onboard gpu omdat het "meer" kan. Vooral doen.

[Verwijderd]

Theoretisch gezien heeft een één-chip CPU+GPU+MMU potentiële snelheidsvoordelen t.o.v. een externe GPU, om de simpele reden dat je ze beter kan integreren en sneller kan koppelen. In de praktijk zal dat echter nog wel even duren, o.a. ten gevolge van de toenemende complexiteit van zo'n oplossing, en het feit dat de meeste geïntegreerde oplossingen voor massaproductie bedoeld zijn ("one size fits all"), en niet voor (relatieve) niche-markten zoals gaming-PC's en grafische werkstations die uitzonderlijke eisen hebben.

[boelensman1]

Even voor de duidelijkheid, met DX11.1 is niet meer mogelijk dan met DX 11. Het is alleen wat makkelijker te programeren. Net zoals dat alle DX11 effecten ook in DX 9 mogelijk zijn, alleen kost het wat meer programeer-werk.

[Reactie gewijzigd door boelensman1 op 22 juli 2024 21:33]

[et36s]

Ik begrijp het nut nooit van DirectX 11.1 op een IGP. Een IGP kan amper de effecten van DirectX 9.0 aan. Mijn GTX460 is amper krachtig genoeg voor DirectX 11

[Reactie gewijzigd door et36s op 22 juli 2024 21:33]

[Dreamvoid]

DirectX 11 heeft ook allerlei features die niet met graphics en games van doen hebben, DirectCompute bijvoorbeeld. Het gebruik van shaders voor non-graphics toepassingen. Betere ondersteuning voor video decoding/encoding op de gpu, etc.

[Reactie gewijzigd door Dreamvoid op 22 juli 2024 21:33]

[Verwijderd]

DirectCompute op een IGP heeft geen enkele zin. Sandy Bridge 's CPU cores leveren ruwweg twee keer zo veel floating-point rekenkracht als de IGP. Die kloof wordt nog groter met AVX2.

Er zijn zelfs indicaties dat Intel de CPU cores gebruikt voor een deel van de geometrische berekeningen. Het lijkt erop dat steeds meer taken naar de CPU zullen verhuizen want die is veel flexibeler en springt efficiënter om met geheugenbandbreedte. Zo hoeft men ook helemaal niet gelimiteerd te zijn door DirectX of andere beperkende API's.

[Dreamvoid]

Die IGP heeft *extra* shader units bovenop de bestaande (AVX/AVX2/etc) SIMD units die de cpu al heeft. Het blijft altijd zonde om hele lappen silicon niets te laten doen.

[Reactie gewijzigd door Dreamvoid op 22 juli 2024 21:33]

[SG]

Het is dat gross van de dev dus juist niet gelimiteerd zijn, maar eerder aan tijd gebrek en budged. Deze voldoende feature rijke en generieke API standaarden voorgames voldoen zelfs niet. Te low level. Dus de industrie is groten deels gedreven door code reuse. Voor korte game productie schema. onvermijdbaar.
En nemen een nog beperkende lic3enceerbare game engine.
De kern is time to market. Daarom doen de vele middleware oplossing het goed.

Als je de innovatieveling wild uithangen en een Raytraced race game wilt opzetten. Dan voldoet de huidige defacto standaard api niet.
Maar zou je met CuDa en OpenCL en directcompute toch de GPU kunnen gebruiken voor alternatieve render methoden.
Maar dit houd in jaren R&D voordat je aan game productie kan beginnen. En heb je dus veel tijd en budged nodig. Als heel veel van de grond af moet opzetten.

Zo staat er in mijn Cuda boek een simpele raytrace example in.

En het wiel opnieuw uitvinden brengt niet veel meerwaarde voor games.
Voorbeeld het einde van red fraction serie. Of!
Het sucses dat sommige Total Conversion mods halen.

Als je game visie hebt en sterk leund op iets unieks en niet beschikbaar in bestaande game engine. Dan moet je dat deel zelf implementeren.
De feasability en risko gaat daarmee omhoog plus de expertise benodig moet je hebben of binnen halen. En de meer tijd en budged moet dat dekken.

[humbug]

In 2013 zullen de IGPs vast ook wel wat krachtiger zijn zodat directX 11 wel degelijk zin heeft.

[maarten12100]

Dus de gewone gebruiker heeft hier geen enkel voordeel bij.
Ik zie eigenlijk pas voordelen vanaf ivybridge processors (after effects )

[flippy]

je orginele standpunt blijft dus staan: de gewone gebruiker heeft er niks aan

[Verwijderd]

Haswell zal AVX2 ondersteunen, met "gather" en FMA instructies. Daarmee kunnen de CPU cores de programmeerbare grafische taken (shaders) efficient uitvoeren. Een 8-core Haswell haalt mogelijks 1 TFLOP...

[Dreamvoid]

AVX2 worden toch extra SIMD units op het CPU deel, niet op het GPU deel? Al vervaagt dat onderscheid naar de toekomst toe wel steeds meer natuurlijk.

[Reactie gewijzigd door Dreamvoid op 22 juli 2024 21:33]

[Verwijderd]

Vroeger gebeurde de vertex-verwerking op de CPU. Naarmate GPUs steeds meer cores, bredere vectoreenheden, fused multiply-add en gather ondersteuning kregen, werd ook die taak aan de GPU overgelaten...

Maar nu worden de rollen weer omgedraaid. We hebben CPUs met meer cores dan wat de doorsnee applicatie benut, AVX heeft de vectorbreedte verdubbeld, en AVX2 zal FMA en gather ondersteuning toevoegen.

Tegenwoordig is niet enkel de vertex-verwerking programmeerbaar, maar zowat elke stap in de grafische verwerking. Door de CPU en GPU te versmelten tot een homogene architectuur zouden de mogelijkheden onbeperkt worden. DirectX 12 ondersteuning wordt dan simpelweg een kwestie van een nieuwe driver te downloaden.

[SG]

Dat denk ik niet.
Cpu en gpu verschil kwa smp is nu factor 100 of meer.
Bijvoorbeeld quad core vs 448 shaders.

six core vs 512 en bij AMD nog meer.

Dus GPU doen het goed op sofware taken die heel fijn deelbaar zijn en onafhankelijk mogelijk parrallel verwerkt kan worden. Nu is het dat niet elk software probleem hier aan voldoet. Maar varieerd gradiaal van zeer slecht tot extreem goed en de bulk ligd verspreid in het midden.
Als het straks 50 vs 5000 wordt dan wordt het opschalen kwa performance van meer serieele dus afhankelijke code een groot probleem en kom je er niet met multitasken.

Nu is een APU die dus 2 a 4 cores combineerd met zooi GPu kernen veel zijdiger.

In cuda boeken vermeld men ook dat wat goed deelbaar is en goed verdeelbaar is over die many shaders core. Wordt gedaan op GPU cores. Dat deel wat slecht deel baar is en niet rendabel loopd maar CPU beter kan op CPu cores draaien.
Dus als er straks 80 CPU cores beschikbaar zijn dan sta je daar met je zwaar seriele taak dat effectief een coretje kan gebruiken.

Dus er zullen steeds taken zijn die het meer van CPU core IPC moet hebben.
Er komen nu smp ruimte voor grof deelbaar taken die genoeg hebben aan dozijn cores.
En extreem fijn deelbaar. Die honderden tot duizend gpu cores gaan gebruiken.

Het lijkt mij dat iNtel wel bij elke architektuur generatie ook de IPC kan verhogen.

Ook de Turbo mode waar eentje of deel van de cores sneller klok hebben en de rest uit. Speeld op dit probleem in.

[Dreamvoid]

Je hoeft alleen niet noodzakelijk die duizend SIMD units in de gpu te hangen, je kan ze ook in de cpu hangen. En als je 1 gedeelde bus maakt voor je "APU", dan is de grens niet eens meer te trekken tussen gpu en cpu deel, dan wordt het gewoon een verzameling integer units, SIMD units, etc achter 1 brede bus. In feite werken AMD en Intel naar exact dezelfde toekomst toe.

[Reactie gewijzigd door Dreamvoid op 22 juli 2024 21:33]

[SG]

Het begon met unified shader. Maar het eind doel lijkt Larabee gedachte.
Maar gaf ookal aan dat ondanks je diespace efficenter gebruikt wordt je ook consesies doet.
Specialisatie werk als unit beter kwa performance per transistor count. Maar is bij andere taken idle.
Ik zie er toch een trade off in en zeker geen win win situatie. Want ipv enkele big core en many small cores. Wat APU eigenlijk is.
Kun je ook gemiddelde nemen en midde weg kiezen medium cores.

IPV 16 big vs 1600 small
80 medium cores

Maar mischien zijn er architekturische foefjes mogelijk.

zoals cascade techniek dat 4 coretjes die elk 64bit FP kunnen maar gezamelijk 256bit kunnen doen.

[Verwijderd]

Cpu en gpu verschil kwa smp is nu factor 100 of meer.
Bijvoorbeeld quad core vs 448 shaders.

six core vs 512 en bij AMD nog meer.

Da's dikke marketing-nonsense! GPU-designers tellen elke afzonderlijke ALU als een core. Die zijn echter helemaal niet onafhankelijk. Als je op dezelfde wijze gaat tellen voor een CPU kom je bij een quad-core met twee 256-bit AVX vectoreenheden per core aan 64 ALUs. Neem daarbij nog eens in acht dat een CPU veel hoger geklokt is, en kleiner is qua chipoppervlak, en de GPU heeft al helemaal geen grote voorsprong meer.

Een GPU is nog in het voordeel door ondersteuning voor gather en FMA bewerkingen. Maar daar komt met AVX2 dus ook verandering in...

[SG]

GPU bieden nu al GIGAFlops aan. Dedicated voor GFX.
Nextgen GPU gaan met elke dieshrink weer verder.
De CPU daarintegen moet meerdere treads verwerken van wat de OS schedular het voorschoteld. Dus tenzij AVX units onafhankelijk aan te sturen zijn. Kan een virus scanner en nog meer ander achtergrond zooi wat cores bezetten.

Dus er blijfd niet veel over van die Gflops. Al helemaal als er redelijk gemultitask wordt.

Het is non dedicated cpu power vs dedicated gpu power.

Om gelijk te presteren al GPU moet een nondedicated CPU veel meer power bieden zodat er genoeg over is om een gpu te evenaren.

[Verwijderd]

GPU bieden nu al GIGAFlops aan.

CPUs ook.

Nextgen GPU gaan met elke dieshrink weer verder.

Maakt niks uit. Nieuwe halfgeleidertechnologie biedt de CPU en de GPU gelijke groei. Maar de CPU maakt daar bovenop een brote inhaalbeweging dankzij brede vectoren en FMA. GPUs hebben dat al. Dus ze convergeren naar elkaar toe en uiteindelijk heeft een APU geen voordelen meer tegenover een CPU met hoge vector-throughput.

De CPU daarintegen moet meerdere treads verwerken van wat de OS schedular het voorschoteld.

Een moderne GPU draait ook meerdere onafhankelijke threads (maar men noemt ze kernels).

Dus tenzij AVX units onafhankelijk aan te sturen zijn. Kan een virus scanner en nog meer ander achtergrond zooi wat cores bezetten.

Applicaties kunnen een core niet "bezetten". Ze worden dynamisch verdeeld. En toekomstige 8, 16, 32, enz. cores zullen rekenkracht te over hebben, o.a. om ook grafische taken voor hun rekening te nemen.

Dus er blijfd niet veel over van die Gflops. Al helemaal als er redelijk gemultitask wordt.

Het is non dedicated cpu power vs dedicated gpu power.

Absolute nonsens. Een APU met 500 GFLOPS aan de CPU-kant en 500 GFLOPS aan de GPU-kant, is geen haar beter dan een homogene CPU van 1 TFLOP.

Vertex en pixel shaders werden vroeger ook op 'dedicated' cores uitgevoerd. Nu hebben GPUs 'unified' shader cores. Door dynamisch de werklast te verdelen op hetzelfde type core gaan de prestaties omhoog!

Om gelijk te presteren al GPU moet een nondedicated CPU veel meer power bieden zodat er genoeg over is om een gpu te evenaren.

Exact. En met AVX2 en toekomstige extensies staat er niks in de weg om een homogene CPU minstens zo krachtig te maken als een APU.

[Devpartner]

GPU bieden nu al GIGAFlops aan.
CPUs ook.


Gpu -> > 1TFlops
Cpu ~ 100GFlops.

Njaaaaaaa.....

[Verwijderd]

Gpu -> > 1TFlops
Cpu ~ 100GFlops.

Sandy Bridge haalt 200 GFLOPS. En met FMA verdubbelt dat weeral, zonder noemenswaardig de grootte van cores te veranderen. GPUs van vergelijkbare chipgrootte halen nog geen TFLOP, en zijn waardeloos op hun eentje.

Dus als we objectief de mogelijkheden vergelijken zal het echt niet zo heel lang duren eer de CPU- en GPU-architectuur zodanig dicht geconvergeerd zijn dat het geen zin meer heeft om verschillende cores te hebben.

[Devpartner]

AMD heeft kaarten rated op 2TFlops op een die size van 255mm2 op 40nm.

Tuurlijk verschillen ze in mogelijkheden... Maar stellen dat AVX2 en Haswell de gpgpu kracht van gpu's gaat benaderen is gewoon een flagrante leugen.

Btw trinity die over 6maanden komt heeft DUBBEL zoveel flops als uw imaginaire haswell.

En ook die gpu's gaan efficienter worden in aanspreken en dergelijke.

Het is net de gpu architectuur die de huidige fpu architectuur gaat vervangen en meer die mogelijkheden erbij gaan pakken dan andersom.

[Terrestraeon]

Als nu de developers ook meegaan is het ok. Ik vindt het namelijk spijtig dat er nog altijd zoveel vertrouwd wordt op Directx9. DirectX10 en 11-spellen zijn nog altijd mager gezaaid, of krijgen door een update achteraf pas ondersteuning (zoals Crysis 2 onlangs DirectX11 ondersteuning kreeg)

[SG]

Dat ligd eerder aan de huidige over dated ouwe consoles.
Maar BF3 port is DX9 geschrapd.
BF2 was er ook vroeg bij om dx8.0 te schrappen.wel DX8.1 PS1,4

[Cubic X]

Ik dacht altijd dat Windows 8 met DirectX 12 kwam, heb ik iets gemist of heb ik dat zelf bedacht?

Ah, artikel nogmaals aandachtig gelezen...er is dus nog twijfel over.

[Reactie gewijzigd door Cubic X op 22 juli 2024 21:33]

[Verwijderd]

Windows 7 is ook versie 6.1, dus als 12 dan 11.1 is wordt alles een stuk logischer.

[sfranken]

Vista is ook 6.1 he

[R3NC0N]

Dat is onjuist.

Vista is 6.0

Windows 7 is 6.1, omdat het zo goed als dezelfde kernel heeft.
Windows 7 kun je zien als een 'uitbreiding' van Vista. Ze hebben echter voor de naam 7 gekozen, omdat ze van de slechte naam van Vista af wilden.

ot:
Hmm.. Ik vraag me af of er veel verandering zit tussen 11.1 en 11. Er was namelijk nauwelijks verschil tussen 10 en 10.1. Er was uiteraard wel verschil, maar je kon het nauwelijks zien.

[Reactie gewijzigd door R3NC0N op 22 juli 2024 21:33]

[SG]

Mij lijkt dx11.1 mogelijk gevolg van wat nV en AMD nextgen wordt op nieuwe dieshrink.
De huidige gen heefd al refresh gehad. Voor begin 2012 verwacht ik nieuwe gen gpu's..
In 2013 zit AMD en nV mogelijk al op DX12 en hun igp ook.
maar loopt iNtel met hun dx11.1 zooi achter zoals nu met hun dx10.1. vs DX11 APU.

2013 is grof gezien 2 podukt cyclies verder dus tov van nu toekomt roadmap gedoe.

En dus voor de Retail gpu firma een nextgen en refresh verder.

[Fordox]

ik heb eerlijk gezegd een schijthekel aan directx. het is een universele decodeer script voor je grafische kaart. daardoor word maar 10% van de eigenlijke grafische kaart gebruikt. als ze nou voor de populaire chipsets een eigen decoder maakten.

[et36s]

10% waar haal je dat cijfer weg?

Het lijkt me dat DirectX behoorlijk efficient is anders koos men wel voor een ander weg.

[sfranken]

DirectX heeft een overhead van zo'n 30 procent. Dus 70% van je grafische kaart word benut voor hetgene waar hij voor ontworpen is.

OpenGL is veel efficienter. Laten we hopen dat ze dat met DX11.1 oplossen.

[Ramon]

Kan je dat onderbouwen? Geloof er niet zo in eigenlijk. En zeker niet dat je met OpenGL die resterende 30% wél kan inzetten. Bovendien is DirectX gewoon handiger.... Daarnaast, dat PC games niet zo snel gaan qua grafische pracht als zou kunnen tegenwoordig heeft volgens mij meer te maken met dat developers console first doen en daarna pas aan de PC denken tegenwoordig.

[lezzmeister]

En een tendens naar (al dan niet gratis) spellen. World of Tanks, Alliance of Valiant Arms, Spiral Knights, Champions Online, hele waslijst, en die willen een zo groot mogelijk publiek bereiken, ook die student met laptop met brakke grafische kaart of dat gezin met een laag inkomen waar geen extra moelah is voor een echt sterke grafische kaart.

Kun je wel allemaal grafische pracht erin mikken maar dan zijn er maar weinigen die het gaan bekijken.

[Dreamvoid]

Als DirectX werkelijk een overhead van 30% had zou geen enkele developer het gebruiken. Het is niet alsof je op Windows geen toegang hebt tot OpenGL ofzo.

[Reactie gewijzigd door Dreamvoid op 22 juli 2024 21:33]

[SG]

Daar vergis je toch sterk in. Performance is heel belangrijk maar iets overtroef dat. zoals.
Time to market. Men gaat niet in den treure optimisen omdat je dan zooi jaren verder bent. Het is eerder totdat optimizen niet veel meer yield. Of geld en tijd op is. En vaak mis je nog veel optimize potentie.
Content pipeline efficente productie flow. Die script engines en edit tools. Vooral sccript engine komen met hoge kost en offert men performance op. Ergens gelezen dat Epic UE script engine performance factor 10 scheeld tov hardcoded.

De doel van DirectX en opengl is standaardisatie. Zodat je als dev niet je tijd verspleed in specifieke en gevarieerde hardware ondersteuningen. Daar zit uiteraard de kost aan door overhead van die hardware abstratcie laag. Maar daar krijg je wel wat voor terug. zoals meer tijd om je te focusen om game gerelateerde programmeren. Ipv nukken van platform hardware aan te spreken.

IDsoft zou nu liever Directx willen gebruiken maar dat doen ze niet omdat ze hun grote opengl codebase overboard moet.

[blorf]

De doel van DirectX en opengl is standaardisatie

Welke standaardisatie? Daar is toch al een driver voor? Volgens dit bericht wordt er hardware gemaakt om software te ondersteunen. Ik zie daar de logica niet van in. Tenminste, niet als het gaat om het verbeteren van de prestaties of mogelijkheden m.b.t. graphics. Wel om de hardware Windows-only te maken. Maar daar heeft niemand wat aan behalve Intel en MS.
Maar ja, ik hoef er niet mee te zitten. Ik speel vrijwel geen games meer en heb dat speelgoed + Windows niet meer nodig.

[SG]

Driver staat niet voor standaard maar kan een standaard volgen.
Driver is de software koppeling tussen hardware en OS.
Elk os heefd zijn driver model. Maar directx en opengl komt daar nog boven op.

[Dreamvoid]

Overstappen is idd niet makkelijk, maar voor een structurele 30% performancewinst doe je vroeg of laat echt wel een poging. Maar er gebeurt juist eerder het omgekeerde (zoals je al aanhaalt, IDSoft), devs willen eerder naar DirectX toe switchen.

[SuperDre]

Je bedoelt weer terug gaan naar het stenen tijdperk waar je mocht hopen dat jouw chipset wel ondersteund was.. nee dankje, en je kletst gewoon uit je nek dat er maar 10% werkelijk gebruikt zou worden.. Overigens met Direct3D heb je gewoon toegang tot de GPU hoor..

[LOTG]

Ok er komt dus nog een 11.1 en dan is er een kans dat W8 12 krijgt? Als W8 12 krijgt dan zie ik geen tijd om een point release van 11 te doen. Denk niet dat Intel/Nvidia/AMD op zo'n kort window zitten te wachten en dan of 11.1 skippen of 12 zeer laat gaan supporten, gezien W8 volgend jaar moet komen (en haswell een jaar erna pas).

[SG]

Directx versie is niet strik os gebonden.
Maar wordt geleverd met een die vorige oudere veries ook ondersteund.
Maar men kan een nieuwere runtime versie altijd je OS kwa versie verhogen mits kernel dat toestaat.

Dus ik vermoed dat de next lichting van AMD en NV DX11.1 GPU worden. En men dus DX11.1 runtime op Vista en W7 wordt geinstalleerd om gebruik te kunnen maken van optionele DX11.1 suportende games.