AMD kondigt Heterogeneous Queuing aan

AMD heeft een techniek geïntroduceerd die de gpu-cores in een apu gelijkwaardig stelt aan de cpu-cores. Dat moet leiden tot een betere verdeling van de werklast over de beide typen cores, waardoor de processor zijn rekenkracht optimaal zou kunnen inzetten.

De techniek die centrale en grafische rekeneenheden gelijk moet stellen, wordt door AMD Heterogeneous Queuing, kortweg hQ, genoemd. Het is de derde poot van AMD's grote plan om accellerated processing units of apu's, efficiënter te maken. De overige twee componenten, HSA en hUMA, afkortingen voor respectievelijk Heterogeneous System Architecture en Heterogeneous Unified Memory Architecture, zorgen voor toewijzing op applicatieniveau tot de cpu of gpu en de uitwisseling van data tussen beide processortypen. Het ontbrekende deel in de driepoot is gelijkwaardigheid: tot dusver moet de cpu een werklast naar de gpu doorsturen, waarbij het besturingssysteem en drivers betrokken zijn.

Met hQ moet die extra stap gerealiseerd worden: de cpu geeft in hQ-apu's werklasten direct door aan de gpu, zonder tussenkomst van drivers. Bovendien kan de gpu ook workloads naar de cpu sturen, iets dat tot dusver niet mogelijk was. Door de directe uitwisseling van commando's tussen cpu- en gpu-cores moeten latencies verminderd worden en zouden apu-prestaties aanzienlijk verbeterd worden. Door de betere verdeling kan de apu optimaler benut worden, wat een energiebesparing op zou moeten leveren.

De techniek moet niet alleen in AMD's apu's geïmplementeerd worden: het bedrijf heeft de techniek middels de HSA Foundation publiek gemaakt, waardoor de open standaard ook door andere fabrikanten ingezet zou kunnen worden. Vooral mobiele chips zouden van de combinatie HSA, hUMA en hQ profiteren: onder meer ARM en Imagination zouden de techniek in toekomstige producten gaan implementeren.

Reacties (95)

[Verwijderd]

AMD is goed bezig! Eerst Mantle, en nu dit. In combinatie met hun APU's die tot nu toe ver voor liggen op Intel, kan dit wel eens ervoor zorgen dat hun positie weer wat beter word. Goed om te zien.

[MAX3400]

Ik begrijp niet zozeer waarom AMD voor ligt op Intel?

Intel heeft in 2008 al whitepapers gepubliceerd en daar al enige tijd hardware voor liggen om het verdelen van workloads (al dan niet in combinatie met een bijbehorende/ondersteunde kernel) tussen verschillende CPU's en hun eigen memory-controller binnen hetzelfde chassis.

Praktisch: een dual-socket machine met 2 x 32GB RAM zou theoretisch 64GB aan 1 CPU kunnen toekennen en 0GB aan de 2e CPU. Dit wordt NUMA genoemd en lijkt me in mijn ogen een nog betere verdeling op te leveren van resources.

Ik heb liever 1 losse GPU en 1 losse CPU die 100% belast worden voor een bepaalde taak dan dat een "kleine" APU zelf nog moet gaan nadenken over wat er gedaan moet gaan worden en door wie.

[Reactie gewijzigd door MAX3400 op 23 juli 2024 00:54]

[Spekkie88]

Wat ik juist begrijp van de hele driepoot is dat er op een lager niveau gekeken wordt of iets beter door de cpu of gpu berekend kan worden. Waar het nu vaak nog ligt bij de applicatie/ drivers om te beslissen welke berekeningen beter op cpu of gpu berekend kunnen worden.
Wat ik er altijd van heb begrepen is het op deze manier zelfs mogelijk om deelberekeningen af te schuiven op de gpu die door de huidige opzet alleen door de cpu berekend moesten worden, maar de gpu sneller in is, of andersom.

Dit had er mee te maken dat dan eerst de data naar een ander deel geheugen moest worden gekopieerd/verplaatst (nu opgelost door hUMA) en dat het commando vanuit de applicatie/driver gegeven moest worden waar er nu (voor zover ik het begrijp) de scheduler van de apu in staat is berekeningen te verdelen over cpu en gpu.

Daarnaast meen ik me te herinneren dan hUMA ook inhield dat een cpu direct toegang had tot het geheugen van een dedicated (AMD) kaart en andersom...

Hopelijk kan dit concept de beroerde FP prestaties wellicht opkrikken waardoor AMD weer meekan komen met intell. Only time will tell...

[Astennu]

AMD is stukje bij beetje alle bottelneks uit het originele bulldozer ontwerp aan het aanpakken. Steamroller wordt de volgende grote stap en die kan nog wel eens veel groter zijn als de stap naar Piledriver.

En daar na komt Excavator. Volgens de geruchten krijgt die AVX2 waarvoor de FPU op de schop moet. Dus grote kans dat ze dan meer veranderen dan alleen de AVX support.

Hopelijk kunnen ze langzaam iets op intel inlopen. Tijd zal het leren. Een beetje concurrentie is niet verkeerd.

[mad_max234]

Wat ik juist begrijp van de hele driepoot is dat er op een lager niveau gekeken wordt of iets beter door de cpu of gpu berekend kan worden. Waar het nu vaak nog ligt bij de applicatie/ drivers om te beslissen welke berekeningen beter op cpu of gpu berekend kunnen worden.
Wat ik er altijd van heb begrepen is het op deze manier zelfs mogelijk om deelberekeningen af te schuiven op de gpu die door de huidige opzet alleen door de cpu berekend moesten worden, maar de gpu sneller in is, of andersom.

Zoek op fusion, AMD heeft het jaren lang onder die naam gepromoot, maar mocht dat niet meer. Driepoot is weer iets nieuws van marketing om het aan consument uit te leggen, luk verhaaltje. Maar is gewoon een van de zoveel stappen die gedaan zijn en worden om cpu en gpu te fuseren.

Voorheen was het juiste code op de juiste core, simpel gezegd maakt het bij fusion apu niks meer uit welke code je stuurt naar de apu, die beslist of code beste door gpu of cpu berekend kan worden of zelfs delen van een berekening. APU kijkt welke code type berekening het zijn en laat het dan gewoon uitvoeren door het deel van de apu wat het efficiënt's ermee kan omgaan.

AMD heeft altijd gezegd dat rond 2015 apu moet komen waar cpu en gpu eigenlijk niet meer los van elkaar bestaan, moet allemaal samensmelten, word 1 onderdeel ipv 2 lossen onderdelen, fusion.

[GeniusDex]

Een groot nadeel van een losse GPU en losse CPU is dat er veel overhead zit in het verplaatsen van een bereking tussen GPU en CPU. Als een post-processing stap van een GPU-algoritme het beste op een CPU kan plaatsvinden moet bijvoorbeeld eerst alle data gekopieëerd worden.

Waar AMD nu mee bezig is is het laten verdwijnen van deze grenzen, waardoor je voor elke stap in je berekening kunt kijken of deze het beste kan gebeuren op je CPU of op een GPU, zonder dat er (veel) overhead in een wissel daartussen zit. Dit kan zorgen voor aardige prestatieverbeteringen van bepaalde algoritmes.

[Verwijderd]

Een groot nadeel van een losse GPU en losse CPU is dat er veel overhead zit in het verplaatsen van een bereking tussen GPU en CPU. Als een post-processing stap van een GPU-algoritme het beste op een CPU kan plaatsvinden moet bijvoorbeeld eerst alle data gekopieëerd worden.

Waar AMD nu mee bezig is is het laten verdwijnen van deze grenzen...

De overhead verdwijnt niet door een CPU en GPU op dezelfde chip te plaatsen. Er moet nog steeds veel data tussen de verschillende types cores verstuurd worden, en de taken verdelen en herverdelen kost tijd. Om werkelijk de "grenzen" te doen verdwijnen moeten de CPU en GPU versmelten en dezelfde instructiestroom gebruiken. Homogeneous computing dus in plaats van heterogeneous. Intel staat daarin het verst met AVX-512 ondersteuning in de maak.

...waardoor je voor elke stap in je berekening kunt kijken of deze het beste kan gebeuren op je CPU of op een GPU...

Het is een waanidee dat je snel kan nagaan waar een berekening het best gebeurt. De enige manier om het met zekerheid te weten is door het uit te voeren op beide en te vergelijken. Maar da's uiteraard nutteloos om dynamisch de balans te bepalen. De enige oplossing is om cores te maken die geschikt zijn voor alle soorten berekeningen. Unified cores, die een homogene instructieset uitvoeren. Dan hoeft er niks meer beslist te worden.

De GPU zelve bestond vroeger ook uit heterogene cores voor vertex- en pixel-verwerking, maar bestaat nu uit unified cores. Nu stevenen we recht af op de unificatie van CPU en GPU.

[Verwijderd]

Er moet nog steeds veel data tussen de verschillende types cores verstuurd worden, en de taken verdelen en herverdelen kost tijd. Om werkelijk de "grenzen" te doen verdwijnen moeten de CPU en GPU versmelten en dezelfde instructiestroom gebruiken. Homogeneous computing dus in plaats van heterogeneous.

Ja, wat AMD hier doet lijkt meer de richting op te gaan van bv de Cell-processor. Daar had je ook nog steeds 1 unit (de PPE) die al de data moest rondpompen naar de andere (SPEs).
En dat was nou niet echt ideaal om voor te programmeren/optimaliseren.

[Croga]

Ik heb liever 1 losse GPU en 1 losse CPU die 100% belast worden voor een bepaalde taak dan dat een "kleine" APU zelf nog moet gaan nadenken over wat er gedaan moet gaan worden en door wie.

Dat is leuk zolang je pure CPU taken en pure GPU taken hebt; iets wat sterk ondersteund wordt door de huidige CPU/GPU architectuur.

AMD's doel is juist om de APU in te zetten voor alles wat er in de computer moet gebeuren. Sommige taken die nu door de CPU uitgevoerd worden zouden veel efficienter door de GPU uitgevoerd kunnen worden maar op dit moment is dat onmogelijk omdat de entiteiten teveel gescheiden zijn. AMD's APUs, en zeker hQ, gaan er voor zorgen dat taken simpelweg door het meest geschikte stukje silicium uitgevoerd worden.

APUs stonden eerst bekend om hun gigantische grafische prestaties, vergeleken met andere embedded grafische oplossingen. Intel is dat nu een klein beetje in aan het halen (hoewel in het "budget gaming" segment nogsteeds geen concurrentie is). Binnenkort verwacht ik echter dat APUs ook op "algemeen" processing niveau een sprong zullen maken omdat ze taken simpelweg beter kunnen verdelen dan de concurrentie.

[Verwijderd]

AMD's APUs, en zeker hQ, gaan er voor zorgen dat taken simpelweg door het meest geschikte stukje silicium uitgevoerd worden.

Simpelweg? Dat is allesbehalve simpel. Als ik je een willekeurig stukje code geef, hoe bepaal je of dat best op de CPU of GPU moet uitgevoerd worden? Da's een zeer gecompliceerde taak en hangt bovendien af van factoren die pas tijdens de uitvoer van een applicatie gekend zijn.

Dit probleem wordt geëlimineerd door unified computing. De CPU-cores worden daarbij uitgerust met het soort brede vector-ALUs die je in de GPU aantreft. Intel sleutelt aan zo'n homogene oplossing met AVX-512.

AMD tracht software-oplossingen te vinden voor wat in essentie een hardware-probleem is. Dat werkt nooit zoals gehoopt. Kijk bijvoorbeeld naar Transmeta, dat probeerde x86 te vertalen naar een VLIW-instructieset met behulp van software. Ze hoopten dat de kwaliteiten van een VLIW-architectuur de kost van software-translatie zou overwegen. Niet dus. AMD tracht nu wanhopig om de GPU in te schakelen voor generieke berekeningen, maar heeft daar ook verschillende lagen software voor nodig...

Programmeurs gaan nooit massaal voor een heterogene architectuur gaan ontwikkelen. Dat kost tijd en geld voor weinig garantie op betere prestaties. AVX-512 in een homogene architectuur kan daarentegen eenvoudig door de compiler gebruikt worden met geen of minimale inspanning van de programmeur en biedt tot 16x hogere prestaties dan scalaire code.

[Croga]

AMD tracht software-oplossingen te vinden voor wat in essentie een hardware-probleem is.

Nee, dat doen ze dus juist niet. hQ is een hardware oplossing voor exact het probleem wat je aandraagt.

AMD tracht nu wanhopig om de GPU in te schakelen voor generieke berekeningen, maar heeft daar ook verschillende lagen software voor nodig...

Hoezo wanhopig? En hoezo verschillende lagen software? Zoals al gezegd; hQ is een hardwarematige oplossing voor het aansturen van de "GPU cores". In feite exact hetzelfde als waar intel "mee bezig" is. AMD doet dat nú.

AVX-512 in een homogene architectuur kan daarentegen eenvoudig door de compiler gebruikt worden met geen of minimale inspanning van de programmeur en biedt tot 16x hogere prestaties dan scalaire code.

Het spijt me dit te moeten zeggen maar dit klinkt wel heel erg fanboi. AVX-512 doet weinig anders dan de APUs van AMD alleen doet het het een paar jaar later. AMD doet ditzelfde maar doet dit nú, niet op een onduidelijk nader te bepalen moment in de toekomst.

[Verwijderd]

Nee, dat doen ze dus juist niet. hQ is een hardware oplossing voor exact het probleem dat je aandraagt.

Nope. hQ is nog steeds een softwarelaag. Het bypasst het besturingssysteem en drivers, maar de queues vullen en verwerken gebeurt grotendeels softwarematig.

Bij een homogene unified architectuur hoeven er geen taken in queues gestopt te worden. Je voert gewoon de parallel code onmiddellijk uit met behulp van AVX-512 instructies. De data blijft ook meer lokaal in de caches en hoeft niet naar andere cores.

Hoezo wanhopig?

AMD deed het goed ten tijde van hun eerste 64-bit processors. Maar ze wilden een significant voordeel bereiken op Intel die de x86 architectuur domineert. Hun aanpak was om de instructieset van de GPU te gebruiken, op heterogene wijze, om zo x86 van minder belang te maken. Waar ze echter niet op rekenden is dat AVX-512 op homogene wijze dezelfde rekenkracht rechtstreeks beschikbaar maakt in de CPU cores.

Homogene code is vele malen gemakkelijker te beheersen door compilers en programmeurs, en krijgt dus de voorkeur. HSA vergt grote inspanningen en kent vele pitfalls. Dus van een ROI perspectief is het een no-brainer om voor unified computing te gaan. AMD probeert de inherente problemen van heterogeen programmeren op te lossen met softwarelagen en kostelijke duplicatie van functionaliteit in de verschillende cores. Dat toont hoe zeer dit een wanhoopsdaad aan het worden is. Steeds maar nieuwe specificaties opstellen om hun hardware enigszins efficiënt te gebruiken maakt het alleen maar meer complex.

Na vele malen de HSA specificatie gelezen te hebben weet ik nog steeds niet wat de beste aanpak is om daadwerkelijk een programma ervoor te schrijven. We moeten wachten op de hardware om te zien hoe het zich exact gedraagt, en dat kan sterk verschillen tussen vendors en verschillende generaties. Een nachtmerrie voor programmeurs dus. AVX-512 daarentegen kent geen verassingen en men is op dit moment bezig met ondersteuning ervoor in alle grote compilers.

Het spijt me dit te moeten zeggen maar dit klinkt wel heel erg fanboi.

Misschien "klinkt" het voor jou fanboi maar het zijn louter feiten. Het is niet mijn fout dat die feiten heel aanlokkelijk zijn in vergelijking met heterogeen computen.

AVX-512 doet weinig anders dan de APUs van AMD alleen doet het het een paar jaar later.

Inderdaad het "doet"hetzelfde, maar het verschil zit hem in homogeen versus heterogeen. HSA gaat niet in grote getale door programmeurs gebruikt worden als kort erna een homogene oplossing beschikbaar komt die veel eenvoudiger te gebruiken is en betere garanties geeft op prestatiewinst. Het komt nog zeer vaak voor dat iets niet sneller draait op de GPU dan op de CPU door alle heterogene overhead en de beperkingen van de GPU (hoge latencies, weinig opslag per thread, lachwekkende scalaire prestaties, etc.).

AMD doet ditzelfde maar doet dit nú, niet op een onduidelijk nader te bepalen moment in de toekomst.

De volledige HSA architectuur is verre van beschikbaar op dit moment. Met al de vertraging die AMD al ondervonden heeft duurt het minstens tot 2015 voordat eraan begonnen kan worden om ervoor te ontwikkelen.

AVX2 is een 256-bit voorloper van AVX-512 en wordt op dit moment gebruikt in de ontwikkeling van nieuwe software. Overschakelen op AVX-512 is praktisch triviaal eens het beschikbaar is.

Wie er effectief voorsprong heeft is moeilijk te bepalen. Maar uiteindelijk doet een jaartje of zo er absoluut niks toe. In tien jaar is alles onherroepelijk unified en homogeen. Heterogeen is simpelweg te omslachtig en bovendien schaalt het slecht met als enige oplossing om de vector-ALUs nog dichter bij de CPU-cores te brengen. Dus richting een unified architectuur! Intel slaat de heterogeneous stap over omdat die toch geen toekomst heeft. En in dat opzicht zitten ze dus gigantisch veel voor op AMD.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 00:54]

[Croga]

Wie er effectief voorsprong heeft is moeilijk te bepalen. Maar uiteindelijk doet een jaartje of zo er absoluut niks toe. In tien jaar is alles onherroepelijk unified en homogeen. Heterogeen is simpelweg te omslachtig en bovendien schaalt het slecht met als enige oplossing om de vector-ALUs nog dichter bij de CPU-cores te brengen. Dus richting een unified architectuur! Intel slaat de heterogeneous stap over omdat die toch geen toekomst heeft. En in dat opzicht zitten ze dus gigantisch veel voor op AMD.

Aan de andere kant kun je ook stellen dat Intel dus nu nog geen ervaring op doet en helemaal niet weet of wat ze aan het doen zijn ook werkelijk zal werken. Terwijl AMD nu al feedback krijgt van alle kanten en daar op kan reageren. In de IT wereld staat dat ook wel bekend als "big bang" versus "iteratief" waarbij, bij software development, dat laatste bewezen vele malen meer daadwerkelijke waarde levert.

Maar als ik je beschrijving lees heb je zeker gelijk in het punt "wie er voorsprong heeft is moeilijk te bepalen". Zeker omdat AMD uiteraard ondertussen ook een homogene architectuur aan het ontwikkelen is.

[Verwijderd]

Aan de andere kant kun je ook stellen dat Intel dus nu nog geen ervaring op doet en helemaal niet weet of wat ze aan het doen zijn ook werkelijk zal werken. Terwijl AMD nu al feedback krijgt van alle kanten en daar op kan reageren.

Nogmaals, AVX2 is een 256-bit voorloper van AVX-512. Ze zijn dus wel degelijk ervaring aan het opdoen en krijgen ook feedback van alle kanten.

AVX-512 is trouwens rechtstreeks afgeleid van de 512-bit instructieset van de Xeon Phi, en daar hebben ze ook al veel nuttige feedback van. Xeon Phi is op zijn beurt afgeleid van het Larrabee project, dat welliswaar faalde als discrete GPU maar net omdat het een heterogene architectuur vormde. Precies door die reeds jarenlange ervaring weten ze dat heterogeen niet werkt en dat ze de 512-bit vector-ALUs moeten inbouwen in de CPU-cores.

In de IT wereld staat dat ook wel bekend als "big bang" versus "iteratief" waarbij, bij software development, dat laatste bewezen vele malen meer daadwerkelijke waarde levert.

MMX: 64-bit
SSE: 128-bit
AVX: 256-bit
AVX-512: 512-bit

Niet iteratief genoeg voor je? De "big bang" aanpak hier is heterogeen rekenen, dat nog geen doorbraak heeft gekend en waar AMD hopeloos naar oplossingen voor zoekt, terwijl homogeen rekenen al decennia de betrouwbare standaard die iteratief is uitgebreid tot breedtes gelijkaardig aan die gebruikt door de GPU.

Zeker omdat AMD uiteraard ondertussen ook een homogene architectuur aan het ontwikkelen is.

Oh ja? Kan je me daar dan eens een link naar sturen? AVX2 ondersteuning staat nog niet eens officieel op hun roadmap, en als ze een alternatieve ISA aan het ontwikkelen waren dan hadden we daar nu wel al iets van gehoord want zoiets doe je niet zonder samenwerking met onderzoekscentra en dergelijke...

[Verwijderd]

Ik heb liever 1 losse GPU en 1 losse CPU die 100% belast worden voor een bepaalde taak dan dat een "kleine" APU zelf nog moet gaan nadenken over wat er gedaan moet gaan worden en door wie.

Volgens mij begrijp je niet helemaal dat de APU niet de beslissing neemt welk onderdeel (CPU of GPU) de berekeningen gaat doen maar dat dit dus direct door de software word gedaan.
Zie schema bovenste regel: Application (met 2 directe pijlen naar zowel cpu als gpu)
Dat is dus wel degelijk uniek en een primeur.

Ter illustratie: Niet grafische berekeningen kunnen toch direct naar de gpu.

Daarnaast kunnen zowel gpu als cpu in een later stadium ook nog opdrachten geheel of gedeeltelijk doorsturen naar elkaar. ( X pijlen van onder kruislings -midden- naar boven)

[Reactie gewijzigd door Verwijderd op 23 juli 2024 00:54]

[Verwijderd]

Ik bedoelde meer dat hun APU's qua prestaties ver voor liggen op die van Intel. Op CPU-vlak niet, maar op GPU-vlak zeker wel. Ga maar eens op een Intel-APU gamen en op een AMD-APU met hetzelfde prijspunt: dan krijg je op de AMD een stuk meer FPS.

[mad_max234]

Ik bedoelde meer dat hun APU's qua prestaties ver voor liggen op die van Intel. Op CPU-vlak niet, maar op GPU-vlak zeker wel. Ga maar eens op een Intel-APU gamen en op een AMD-APU met hetzelfde prijspunt: dan krijg je op de AMD een stuk meer FPS.

Dat was voor kort de regel dat amd snelste gpu in haar apu's had, maar intel HD5200 is snelste igpu, die is gemiddeld net iets vaker sneller dan gpu van de A10-6800K. Daarbij is het een mobile apu waar de hd5200 inzit, is niet eens desktop variant. AMD heeft kaveri nodig om intel weer achter zich te laten, maar intel zit ook niet stil en is duidelijk bezig met gat te dichten. Vorige generatie was gat nog heel erg groot, deze generatie heeft intel AMD al ingehaald.

http://www.anandtech.com/show/6993/
http://nl.hardware.info/n...igp-onder-de-loep-genomen

[Verwijderd]

Da's wel erg kort door de bocht.
Voor een groot deel hangt de performance van een GPU af van hoeveel shader-processors je op de die wilt stoppen. AMD kiest ervoor om er relatief veel op te doen (daarom hebben ze dus ook max 4-core CPUs ernaast, de rest van de die is voor de GPU).

Intel kiest er juist voor om de GPUs relatief klein en energiezuinig te houden, wat interessant is voor de gemiddelde zakelijke notebookgebruiker bv.

Maar als je kijkt naar de verhouding van transistorcount:performance, dan doet Intel het echt niet minder dan AMD.
Sterker nog, Intel's architectuur is juist beter in dingen als tessellation en OpenCL
Tesselation gaat bv erg lekker: http://www.anandtech.com/...radeon-hd-8670d-hd-4600/3
Als je hier kijkt, zie je dat een HD4000 met extreme tessellation gewoon een Radeon 5770 verslaat: http://www.geeks3d.com/20...gl-4-tessellation-tested/
En hier met OpenCL doet Intel het ook erg goed: http://www.anandtech.com/...radeon-hd-8670d-hd-4600/4

Dus Intel ligt echt niet achter op AMD qua GPU-technologie. Sterker nog, het lijkt erop dat Intel een betere architectuur heeft dan AMD, ze zouden hem alleen nog iets op moeten schalen om ook in alle situaties betere performance dan AMD te hebben. Maar dat is een keuze.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 00:54]

[DutchMuffin90]

Tesselation gaat bv erg lekker: http://www.anandtech.com/...radeon-hd-8670d-hd-4600/3
Als je hier kijkt, zie je dat een HD4000 met extreme tessellation gewoon een Radeon 5770 verslaat: http://www.geeks3d.com/20...gl-4-tessellation-tested/

Hierbij moet wel even aangemerkt worden dat de oude VILW Architectuur gewoon niet goed om kon gaan met Tesselation omdat het toen nog nauwelijsks geimplementeerd werd, pas bij DirectX11 meen ik. Een betere vergelijking is een GCN apu, waar de tesselation pas echt ondersteund werd te vergelijken. Anders is het een beetje en appels en peren vergelijking

[Astennu]

Klopt. Maar de tesselator in de HD7770 is 1x zo snel als die in de HD5770. Terwijl het er nog steeds maar 1 is.

De Steamroller APU krijgt GCN.

[Verwijderd]

Maar de tesselator in de HD7770 is 1x zo snel als die in de HD5770. Terwijl het er nog steeds maar 1 is.

Dus AMD heeft dat destijds niet goed ontworpen.... Dat is een grote bottleneck inderdaad, waar Intel blijkbaar geen last van heeft. Fijn dat we het daar over eens zijn.

De nieuwste GCN-kaarten hebben nog steeds een extreem zwakke tessellator trouwens: http://www.anandtech.com/...x-review-feat-asus-xfx/18

[Reactie gewijzigd door Verwijderd op 23 juli 2024 00:54]

[Astennu]

Ik ga het nog een keer zeggen dan kap ik er mee want je wilt niet luisteren. AMD is degene die Tesselation bedacht heeft.

Ze zijn gaan kijken naar wat het beste bruikbaar is voor games zonder een super zware hit op de FPS te krijgen. Toen kwamen ze bij tesselation factors van 4x en 8x. Daar zijn ze voor gaan optimaliseren.

Er zijn genoeg slides te vinden hoe de AMD tesselator met hogere factors om gaat. Dit zijn slides van AMD zelf.

Games gebruiken 4x en 8x factors. De link die jij laat zien test met 64x. Leuk maar geen een game gebruikt dat. En geen een game gaat dit de komende 4 jaar gebruiken. Dus waarom er moeite in steken om voor 32x en 64x te optimaliseren?

Ik noem dit efficiënt ontworpen. Ipv overbuild to win benshmarks.

Doe alsjeblieft wat meer onderzoek voordat je loos dingen gaat lopen roepen.

[Vayra]

Sorry, maar dat AMD Tesselation heeft bedacht is gewoon pertinent onwaar. En daarmee wordt eigenlijk de rest van je verhaal ook aardig ontkracht. Ik vind de stijl van de discussie ook niet echt lekker, maar dat terzijde.

"Nothing is better than a dedicated unit for doing tessellation. Initially planned for Direct3D 10 (which explains its presence in the Radeon HD series), it seems that Microsoft, ATI, and Nvidia weren’t able to reach an agreement in time, and so it disappeared from the specifications, only to return with a vengeance with Direct3D 11. So, tessellation is the big new feature of Direct3D 11—or at least the one that’s easiest to sell for non-specialists."

Tesselation is een techniek die al veel langer bestaat dan gaming. De implementatie in gaming is maar 1 voorbeeld van 'tesselation'. M.C. Escher gebruikte de techniek ook voor zijn kunstwerken bijvoorbeeld. Dat AMD dit bedacht zou hebben is dus klinkklare onzin, en de toepassingen van Tesselation in gaming zijn al helemaal niet van AMD, maar zoals je hierboven leest een techniek die door alle partijen wordt gebruikt. Op een gegeven moment, in eerste instantie bij Dx10, maar uiteindelijk pas echt bij Dx11, is tesselation dermate belangrijk geworden dat er een dedicated unit voor in de gpu's kwam. Dat de HD5770 daar eerder mee was heeft vast met Dx10 en de twijfel omtrent tesselation in die versie, te maken.

Ik herken de juichverhalen over AMD wel uit duizenden. Altijd als AMD met termen van een mondvol hard komt roepen in presentatie slides, zijn er op tweakers en andere hardwaresites hele volksstammen die dat gedachteloos gaan naroepen. Toch heb ik sterke twijfels bij dingen als Mantle, die nieuwe geluidstechnologie, en dergelijke. Heel veel van die kindjes sterven een vroegtijdige dood, en veel andere worden eigenlijk kort na launch van het product al tot een niche gemaakt, omdat de rest van de industrie de technologie niet heeft, en geen developer vindt AMD belangrijk genoeg om er een game omheen te bouwen. Want hoe hard DICE het woordje Mantle ook roept, BF4 zal uiteraard net zo prima speelbaar zijn op een Geforce, anders trappen ze keihard tegen meer dan de helft van hun playerbase met een Nvidia kaartje.

Al met al, eerst zien dan geloven.

[Reactie gewijzigd door Vayra op 23 juli 2024 00:54]

[Astennu]

Je hebt gelijk. En ik heb als je iets verder leest ook aangepast wat ik bedoelde. Ik bedoelde het hardware matige versnellen van Tesselation in games.

Ik denk dat we nu allemaal blij zijn dat we hardware tesselation hebben? Ik ben er in ieder geval heel blij mee. Hetzelfde geld voor S3TC. Ook zo iets wat veel gebruik is in games wat S3 toen de tijd een keer bedacht heeft.

Ik snap dat je sceptisch bent over dingen als Mantle en True audio. Maar je moet in mijn ogen wel nieuwe dingen blijven proberen. Misschien is het niets en flopt het. En misschien voegt het wel degelijk dingen toe aan de game ervaring en dan is het maar al te prettig als het meer gebruikt gaat worden.

Ik vind het idee achter de laatste twee technieken wel goed. Ik ben alleen heel benieuwd naar het gebruik in de praktijk en compatibiliteit met nieuwere hardware.

[Vayra]

Klopt, we zitten kort op elkaar te posten, na de refresh zag ik alle nieuwe toevoegingen

Over die nieuwe technologieen; ik vind dat er wat meer focus mag zijn op het perfectioneren van bestaande tech. Als je ziet hoe lang het heeft geduurd voordat AMD stuttering wat beter op orde had bijvoorbeeld, dan geeft mij dat eerder een beeld van een bedrijf dat vooral gericht is op dikke marketingtermen die vervolgens niet zo heel veel inhouden. Overigens is AMD daar niet alleen in natuurlijk, het Nvidia voorbeeld met PhysX is er ook zo een; of TXAA. Veel geroeptoeter voor een paar extra particles en wat gladdere lijntjes. Zoiets verwacht ik ook bij Mantle: een paar procent performance winst. True-Audio: leuk, maar alleen hoorbaar voor de echte audiofiel met een koptelefoon van 150 euro op zijn hoofd. Voorbeelden te over: MSI gaming bordjes: 25 euro meerprijs voor een rood draakje en een netwerkchipje met Gaming erop. Maar geen bench die een verschil kan aantonen. Tja...

En ondertussen draaien we nog steeds op gaming rigs met minimaal een dikke quadcore, als het geen octocore is, maar games benutten maar de helft van de beschikbare kracht. Multithreading, weten we het nog, dat was het grote ding 7 jaar geleden. Toch draait tot nu toe alleen Crysis 3 op meer dan vier cores.

[Reactie gewijzigd door Vayra op 23 juli 2024 00:54]

[Astennu]

Dat ben ik met je eens. Al die AA modes die amper gebruikt worden en weinig toevoegen en Physx wat flopte omdat het niet open genoeg is (waardoor vooral cpu physics gebruikt wordt)

Dat soort dingen zijn jammer.
Dat van de microstuttering van Multi GPU setups van AMD is ook erg jammer. Ik merkte het al bij mijn 4870 X2 maar wist niet wat het was. Het was er ook niet altijd. (niet iedereen merkt het)
Gelukkig werken ze er nu aan en zijn ze het aan het oplossen. Maar jammer dat het zo lang geduurd heeft.

Het lijkt er wel op dat nieuwe games (met deels dank aan de nieuwe consoles) wel 4-8 cpu's cores gaan benutten. Ze hebben daar 8 minder krachtige cores dus dan moet je wel.
Crysis is een spel wat het nu al kan benutten. Hopelijk volgen er meer.

Ik snap wat je bedoelt met die audio. Maar ik ben zo iemand die veel om goed geluid geeft. Net als ik van mooie beelden en effecten houd. Maar ik kan me voorstellen dat veel mensen hier niet op zitten te wachten of het verschil niet horen. Maar er zijn ook mensen die het verschil tussen Medium en Ultra of 720p en 1080p niet zijn. Het ligt ook erg aan de persoon of je het kunt waarderen.

Ik hoop dat nVidia, AMD en Intel vooral door gaan met het bedenken van nieuwe features. Maar houd ze AUB wel open zodat iedereen het kan gebruiken. En dat we er vervolgens allemaal van kunnen genieten zonder dat we een specifiek merk hardware moeten hebben.

[[Shadow]]

[...]


Intel is de enige die echt bijdraagt aan standaarden. Tegen wil en dank de x86-standaard natuurlijk, maar ook dingen als PCI, PCI-e, SATA en USB zijn mede door Intel tot stand gekomen.

Van nVidia en AMD zou ik eigenlijk niets kunnen noemen dat niet gesloten was en/of niet geflopt. Jij wel?

x64.

PS: x86 is niet open.

[Verwijderd]

x64 is een extensie van x86. Bovendien is AMD sowieso gebonden volgens de x86-licentie om alle extensies op x86 kostenloos beschikbaar te maken aan andere x86-licentienemers.
AMD had hier dus geen keus, is meer het gevolg van x86 zelf.

[[Shadow]]

x64 is een extensie van x86. Bovendien is AMD sowieso gebonden volgens de x86-licentie om alle extensies op x86 kostenloos beschikbaar te maken aan andere x86-licentienemers.
AMD had hier dus geen keus, is meer het gevolg van x86 zelf.

x64 is een uitbreiding van x86 - Klopt. De rest van wat je hier zegt is gewoonweg niet waar.... AMD en Intel hebben een cross-licensing agreement voor x86 en x64, die na een hoop gesteggel in de rechtbank tot stand is gekomen.

[Verwijderd]

x64 is een uitbreiding van x86 - Klopt. De rest van wat je hier zegt is gewoonweg niet waar.... AMD en Intel hebben een cross-licensing agreement voor x86 en x64, die na een hoop gesteggel in de rechtbank tot stand is gekomen.

Jawel hoor, zoek maar op.
Het is een cross-licensing deal, maar niet gelijkwaardig. AMD betaalt aan Intel, en moet hun extensies kostenloos aan Intel en andere licentiehouders beschikbaar maken.
Zie hier bv:
http://arstechnica.com/ga...x86-licensing-violations/

AMD and Intel have renegotiated the former's license on several occasions, most recently in 2001, when AMD agreed to pay Intel royalties for the right to continue making x86 chips.
...
The question rests on whether or not Intel's access to the x86-64 patent is covered under the 2001 x86 license or was negotiated separately. Just to clear up some potential questions, no, Intel did not develop its own "x86-64," and yes, AMD did grant Intel a license. An old Inquirer article implies that AMD was less-than-eager to license AMD64 to its rival (implying that the new technology wasn't automatically grandfathered into the 2001 agreement), but an agreement was in place by April 25, 2002, as reported here. The 2001 license took effect on May 4, 2001, which leaves precious little time for AMD to have "Hammered" out separate agreements.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 00:54]

[Vayra]

Nee - precies de reden dat ook deze Heteorgeneous Queue weer met een dikke korrel zout mag worden genomen.

(Om toch weer even ontopic te gaan )

[Astennu]

Deels waar maar X86 is alles behalve open. Alleen AMD mag CPU's maken en daar betalen ze licentie geld voor.

Maar ik vraag me af wat er zou gebeuren als bv nVidia of Apple langs komt en vraagt om een X86 licentie.

Meeste is inderdaad Fixed vendor. AMD volgens mij achter OpenCL. Ze moesten ook wel iets omdat AMD CUDA had.

MAar helaas floppen veel van deze dingen. Ik denk dat Tesselation en S3TC een van de weinige voorbeelden zijn van dingen die opgenomen zijn. En misschien ook het Bumpmapping. Al weet ik niet pressies waar dat vandaan kwam. Ik dacht dat dat van Matrox kwam. Maar het kan ook zijn dat zij alleen de Environmental Bumpmapping bedacht hadden.

[Astennu]

Transmeta, Via en Cirix hebben volgens mij X86 gehad. Maar ik weet niet of Intel nog nieuwe licenties uit geeft. Misschien wel maar het is niet recent meer gebeurd.

Ik bedoel niet dat AMD OpenCL bedacht heeft. Alleen dat ze er achter zijn gaan staan. Als zijnde als je GPGPU wilt doen raden wij of DX Compute of OpenCL aan.
Waar nVidia vooral CUDA aan het promoten was.

Maar het ging er toch niet om of iets 1:1 overgenomen was? de vraag was volgens mij technieken die bedrijven gebruikte voor marketing die niet geflopt zijn.

Ik geef bij Bumpmapping toch ook aan dat ik de oorsprong niet wist? ik weet alleen dat Matrox het een tijdje heeft lopen promoten en dat het toen een tijdje veel in games en tech demo's gebruikt werd. Ik wist ook dat de GF3 een stap verder ging met nieuwere technieken.

[Astennu]

Laten we het dan zo zeggen ATi is de gene die het naar games gebracht heeft in de vorm van Trueform. (Radeon 8500
Daar is toen weinig gebruik van gemaakt.

Daarna hebben ze het opnieuw geprobeerd met de Xenos C1 chip (Xbox 360) En later de HD2xxx serie.
Deze hadden weer een hardware tesselator aan boord. Het kon na de Radeon 8500 ook wel maar dat was niet met hardware en dus langzamer)

Het heeft lang geduurd voordat het met DX11 eindelijk in de DirectX specs is opgenomen.

Dat de techniek opzich al langer bestaat geloof ik meteen. Maar het hardware matig versnellen en het beschikbaar maken in games is wel iets waar ATi zich voor in gezet heeft.

Leuk dat je er je geld mee verdient en wellicht weet je er inderdaad veel meer van. Maar je reageert wel erg kinderachtig met weinig onderbouwing en loopt meteen te flamen. Niet echt een manier om discussie te voeren en om anderen te overtuigen van je gelijk. Mensen nemen je dan niet snel serieus.

[Reactie gewijzigd door Astennu op 23 juli 2024 00:54]

[Verwijderd]

Laten we het dan zo zeggen ATi is de gene die het naar games gebracht heeft in de vorm van Trueform. (Radeon 8500
Daar is toen weinig gebruik van gemaakt.

Ja, maar vergeet niet dat de GeForce3 ook een vorm van tessellation aan boord had!
http://www.xbitlabs.com/a...s/display/geforce3_2.html

RTPatches - Hardware Tessellation of Smooth Surfaces

GeForce3 can do hardware tessellation or split smooth surfaces. Briefly speaking, this technology looks as follows. For example, to define an object of some surface, the GPU gets a set of vertexes. With their help GeForce3 creates a mathematical description of this curved surface. After that it builds up a polygon "net" (note that there can be any amount of polygons used and the "net" can be either tight or loose, it doesn't matter). This way the core doesn't receive a huge array of vertex coordinates, but just a few control vertexes, which unloads the AGP bus and saves it time and trouble transferring all these data.

Dat is minder bekend, want minder hard gemarket, maar het is er wel degelijk. De een had N-patches, de ander RT-patches.
Beiden waren geflopt omdat ze te beperkt bleken in de praktijk.

Het heeft lang geduurd voordat het met DX11 eindelijk in de DirectX specs is opgenomen.

Maar dat is een heel ander soort tessellation, die gebruik maakt van programmeerbare shaders, ipv de fixedfunction dingen die ATi/AMD tot dan toe had gebruikt.
En die tessellation is door Microsoft, AMD en nVidia samen ontwikkeld, en gestandaardiseerd. Het is iets te kort door de bocht om AMD alle credits te geven hiervoor.
En give credit where credit is due: Pas sinds DX11 is tessellation ook een success. En nVidia heeft gewoon met afstand de beste tessellation hardware. En ook Intel doet het beter dan AMD. Dus ja, dat AMD er al langer bezig mee was... leuk, maar wat wil je ermee zeggen?

Maar het hardware matig versnellen en het beschikbaar maken in games is wel iets waar ATi zich voor in gezet heeft.

Dat heb ik nooit ontkend. Ik heb zelf destijds ook een Radeon 8500 gebruikt, en gespeeld met TruForm.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 00:54]

[Astennu]

Ik had wel van die N-Patches gehoord. In die tijd alleen niets mee gedaan. De Gefroce 2 GTS die ik had kon het niet. Bij de 9700 zat er in ieder geval geen TrueForm engine meer in.

Dat de tesselator in de C1 ander was dan True form klopt. En dat een deel door de shaders gedaan wordt ook. Alleen gebruikt AMD volgens mij nog wel een stuk fixed function.

Persoonlijk vind ik de oplossing van nVidia wel mooier. Het schaalt beter.

AMD probeert dat deels op te vangen door de HD77xx 1 tesselator te geven en de 7870 en de 7970 er twee te geven. (R9 290 zou er 4 hebben) Maar dan heb je toch een iets minder mooie balans.

Ik ben het ook met je eens dat nVidia samen met MS en ATi naar de implementatie gekeken heeft voor DX11. Maar AMD had vanaf de HD2xxx al weer een tesselator in de hardware zodat dev's al het een en ander konden proberen. Ook al wijkt deze tesselator heel sterk af van de versie in de HD5xxx serie (hij kan ook wat minder)

Maar ik ben wel blij dat ze dat door gezet hebben zodat we nu tesselation in games hebben. Dat heeft de boel toch weer een stuk mooier gemaakt.

[MineTurtle]

Niet goed ontworpen... sure... de oudere reeksen intel cpus zijn dan volgens jou logica ook verkeerd ontworpen, gezien deze trager zijn dan de nieuwe... wake up

[MineTurtle]

Hmm juist ja, volgens mij ben jij degene die een GPU uit 2009 gaat vergelijken met de nieuwe serie? (HD5770) Net zoals de instructiesets van cpu's intussen verbeterd zijn, zijn de mogenlijkheden van videokaarten ook een stuk uitgebreider. Een videokaart met directx9 van vroeger is ook geen ontwerpfout omdat hij geen directx11 ondersteund? Bovendien heeft elke fabrikant zn voor en zn tegenpunten, de ene kaart is beter in games, de andere in grafish design, etc. Verschil moet er zijn en cuncurrentie moet er zijn, anders zijn straks alle cpu's/apu's/gpu's onbetaalbaar. Er zijn geen slechte gpu's/cpu's/apu's, je moet gewoon hetgeen kopen wat je zelf gaat gebruiken en nodig hebt.

[Reactie gewijzigd door MineTurtle op 23 juli 2024 00:54]

[Sp3ci3s8472]

Het GPU gedeelte op een APU van AMD is ook behoorlijk zuinig, het zal niet veel verschillen met degene die intel maakt dus ik vraag me af waarom alleen intel apus erg interessant zijn voor zakelijke (notebook) gebruikers.

Dat een HD5770 wordt verslagen in tesselation is niet speciaal, als je ziet dat hij de intel GPU inmaakt op de lagere twee settings die belangrijker zijn voor games.
Dat hij op maximale tesselation meer punten scored gaat je niks meer opleveren in games (waar het om draait). Bij AMD wordt gekeken naar de dichtheid van het aantal vertices op het scherm, is dit meer dan het aantal pixels dan wordt het via de driver niet meer getesseleerd (als je dit aanzet natuurlijk).
AMD heeft zijn tesselation unit ontworpen met dit in het achterhoofd. Bij Nvidia en waarschijnlijk Intel worden de shader units gebruikt voor tesselation wat er voor kan zorgen dat je op andere punten bottlenecks krijgt.

Dan nog worden in die testen een highend cpu (4770k) van intel (die 280 euro kost) tegenover een APU gezet. Dit geeft inderdaad een scheef beeld want de integrated graphics op intels highend zijn wellich erg snel, maar op de andere modellen zit vaak een tragere versie.
Uit het artikel van Anandtecht:

Despite Haswell's arrival on the desktop, AMD is in no trouble at all from a graphics perspective. At the high end, Richland maintains a 17 - 50% GPU performance advantage (~30% on average) over Intel's HD 4600 (Haswell GT2). All things equal, even Trinity is good enough to maintain this performance advantage - a clear downside of Intel not bringing its Iris or Iris Pro graphics to any socketed desktop parts.

[Astennu]

Dat vind ik wel erg kort door de bocht om te stellen dat Intel een betere GPU Architectuur heeft dan AMD. Ik denk namelijk niet dat Intel bij de mogelijkheden van AMD of nVidia in de buurt kan komen. Daar hebben ze denk ik nog 2-4 jaar voor nodig. Ze maken wel grote stappen daar ben ik het mee eens.

Een paar specifieke benshmarks die jij quote zeggen helemaal niets. Tesselation is een heel klein deel van de workload. AMD bij het ontwerp van zijn tesselators maar uit van een factor van 8x. Die normaal is voor game loads. Dit soort tests gaan veel verder. Dit is ook een rede waarom nVidia uitblinkt.

De HD5770 heeft maar een tesslator unit. Het aantal shaders maakt weinig uit voor de Tesselation performance er is bij AMD maar een bewerking die door de shaders gedaan wordt (ik ben even kwijt welke)

Leuk dat je veel tesselation performance in een low end chip stopt maar dat ga je nooit gebruiken omdat de rest niet snel genoeg is om games speelbaar te houden.

Daarnaast kun je zaken als grote en verbruik niet echt goed vergelijken. Intel gebruikt 22nm waar AMD 32nm heeft. Op die manier kun je niet zeggen of het aan de architectuur ligt. En gezien het verschil in productie proces zal een heel groot gedeelte daar vandaan komen.

En als we kijken naar de game performance (waar het in mijn ogen echt om gaat ipv alleen Syntetic benshmark performance):

http://www.anandtech.com/...radeon-hd-8670d-hd-4600/2

Zie je dat AMD dik wint ondanks dat de CPU cores veel trager zijn.

Begrijp me niet verkeerd ik vind de Intel GPU's al lang niet slecht meer. Maar om ze superieur te noemen aan die van nVidia of AMD vind ik veel te ver gaan.

[Reactie gewijzigd door Astennu op 23 juli 2024 00:54]

[Astennu]

Nee dat geeft alleen maar aan dat Intel veel aan de tesselation performance van zijn architectuur heeft gedaan. Meer niet. Dit zegt bv helemaal niets over de pixel performance van de GPU.

En Dat hij het in OpenCL goed doet zegt ook niets over de Game performance alleen over de GPGPU performance.

De Trinity en Richland APU hebben nog een oude VLIW4 architectuur. Niet vergelijkbaar qua GPGPU performance van GCN wat in de HD7xxx desktop kaarten gebruikt wordt. Daarnaast is de Tesselation performance van de HD7xxx kaarten ook een stuk beter dan van de HD69xx die ook VLIW4 was.

Zoals al gezegd. AMD kijkt met tesselation performance erg naar Game loads en niet naar Benschmark progs want die testen met factors die in games niet gebruikt worden.

Ik zou zeggen doe eens goed onderzoek naar de verschillende GPU architecturen en hoe het een en ander werkt. Dan zul je zien wat ik bedoel.

Ik ga verder niet meer in discussie want het begint een wellus nietus spelletje te worden. Ik zou zeggen veel plezier met je Intel HD GPU. Doe mij maar een Radeon of Geforce om te gamen. Leuk scoren in Benshmarks heb je weinig aan.

[ilaurensnl]

Pfffs, hier wordt te veel bij nagedacht. Intel is niet gemaakt voor games meer op efficiëntie en gebruik, Natuurlijk kan er wel spelletjes mee gespeeld worden echter is het mogelijkheden beperkt.

APU is specifiek gemaakt voor een balans tussen deze twee, gebruikt weinig, en is ook beperkt maar bied mogelijkheden voor gamen en updates voor gamen, althans op niet te hoge resolutie.

Beide hebben voordelen en nadelen, APU gebruikt meer, terwijl intel's gpu minder gebruikt.

Intel is meer dan genoeg voor een zakelijke computer of een computer dat op school wordt gebruikt. Bij laptops bijvoorbeeld is elke watt erg belangrijk voor de accuduur.

intel GPU/APU zijn geen vervanging voor de videokaart, om echt te kunnen gamen is dit nodig. Het is meer een balans zodat je geen veel gebruiker genaamd een videokaart hoeft te gebruiken in een computer waar toch niet op gegamed op wordt en dat scheelt weer geld omdat een videokaart meer kost en natuurlijk op energie rekening.

[Reactie gewijzigd door ilaurensnl op 23 juli 2024 00:54]

[.oisyn]

Die scores krijg je voor je taalgebruik en persoonlije aanvallen. Toevallige feitjes maken je reactiescore dan niet meer beter. Geen waardeoordeel, gewoon een observatie

[Reactie gewijzigd door .oisyn op 23 juli 2024 00:54]

[.oisyn]

Ik een AMD fanboy? Heb een Intel cpu en een nvidia gpu.

En ik hoef helemaal niets, ik verklaar gewoon je reactiescore. Ben totaal niet geïnteresseerd in je beweegredenen achter je manier van reageren, en dat is voor de score zelf ook compleet irrelevant.

Ik vraag me alleen af waarom je mij nu ineens aanvalt. Deed ik bij jou toch ook niet? Lange tenen much?

[Reactie gewijzigd door .oisyn op 23 juli 2024 00:54]

[.oisyn]

Jawel, dat zegt alles. Als ik een fanboy was dan kocht ik hun hardware uit voorliefde voor dat bedrijf, rationele argumenten ten spijt. Maar ik hou er überhaupt niet van om dat woord te gebruiken, mensen die dergelijke beschuldigingen uiten zijn vaak erger dan het type persoon waar ze de ander van beschuldigen te zijn.

Wat me echter meer tegen het been stuit is dat je gedane zaken niet eens achter je kunt laten. Ik dacht dat we er wellicht al om konden lachen, maar helaas, de wond is overduidelijk nog te diep. Ik kom met een -in mijn ogen- volledig logische verklaring van je reactiescore en meteen duik je weer in de aanval. Grow up.

Jij valt mij toch aan,

Nee dat deed ik niet, het is je eigen aggresiviteit die jou dat doet vermoeden. Maar goed, dan wil ik bij deze expliciet stellen dat het niet bedoeld was als persoonlijke aanval, en het feit dat jij degene bent waar ik op reageerde berust op louter toeval (bij eenieder ander persoon had ik exact dezelfde reactie geplaatst)

[Reactie gewijzigd door .oisyn op 23 juli 2024 00:54]

[.oisyn]

Luister, ik zal de laatste zijn die zal beweren dat er louter objectief wordt gemodereerd hier (of ergens anders for that matter), maar het feit dat je voor de ene reactie een onterechte score hebt gehad impliceert niet dat die voor de andere reacties ook onterecht is. Ik vind de -1 voor de post waar het oorspronkelijk om ging namelijk niet onverdedigbaar, en mijn punt was dat een goede argumentatie ("toevallige feitjes") de boel niet zal rechttrekken. Wat betreft je andere post over Android... onterecht? Wellicht, maar mensen zijn het X aapt Y na argument een beetje moe, zeker als een van die twee variabelen voor Apple staat. Het maakt dan niet meer uit of je gelijk hebt. Onterecht maar begrijpelijk, en zeker geen anti-scalibd of Android fanboys.

Dat er een hetze gaande is zijn louter je eigen onderbuikgevoelens. Wil natuurlijk niet zeggen dat het niet waar is, maar echt stuitend bewijs zie ik er niet voor.

[Reactie gewijzigd door .oisyn op 23 juli 2024 00:54]

[Verwijderd]

maar het feit dat je voor de ene reactie een onterechte score hebt gehad impliceert niet dat die voor de andere reacties ook onterecht is.

Ik zeg ook niet dat het allemaal onterecht is. Eigenlijk interesseert het me ook helemaal niet, dus laten we er maar over ophouden.

Dat er een hetze gaande is zijn louter je eigen onderbuikgevoelens.

Nou, dat niet zozeer. Wat me wel opvalt is dat er wel ENORM veel mensen zijn die helemaal gek zijn van AMD en alles wat AMD maakt en doet staan te verdedigen.
Nou ja, neem deze thread als voorbeeld. Het *enige* dat ik doe, in eerste instantie, is opmerken dat Intel's iGPUs eigenlijk technisch best okee zijn, gezien het lage aantal shaderprocessors dat ze meekrijgen, en zelfs sneller dan AMD als het op tessellation en OpenCL aankomt. Dit onderbouw ik met een stel benchmarks (wat al een reactie is op een aantal pro-AMD mensen die de Intel iGPUs niet op waarde kunnen schatten).

Vervolgens komen er tig man die mijn post helemaal uit z'n verband rukken, en op allerlei futiele details gaan lopen zeuren. Vaak nog zonder te weten waar ze het over hebben ook (geleuter over GCN... die HEB je helemaal nog niet in APUs... afgezien van het feit dat GCN nog steeds net zo zwak is in tessellation als z'n voorganger... claims dat AMD tessellation heeft uitgevonden... of OpenCL... en weet-ik-wat voor kromme onzin... Mensen die zelfs beginnen dat je helemaal niet met Intel iGPUs kunt gamen, dus hoe kom ik erop om te reopen dat het betere gaming GPUs zijn of wat dan ook... Wat ik dus helemaal niet geroepen heb, maargoed).

Ik word er gewoon erg moe van. AMD kan in de ogen van de gemiddelde tweaker helemaal niets fout doen, en je mag er totaal geen kritiek op hebben, hoe gerechtvaardigd die kritiek ook moge zijn. En wee je gebeente als je iets positiefs over de concurrentie zegt, wederom, hoe gerechtvaardigd ook.
AMD heeft gewoon geen grote voorsprong tov Intel op het gebied van GPUs. Als je het goed bekijkt, zie je dat Intel eigenlijk sinds de overname van ATi flink aan de weg heeft getimmerd qua GPUs. Daar plukken ze nu de vruchten van.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 00:54]

[StraightOn.NL]

Er waait wel duidelijk een nieuwe wind bij AMD, wellicht al lange tijd geleden in gang gezet...maar dat doet er niet toe

[Verwijderd]

Ja, de wind van wanhopig persberichten uit te sturen voor technologie die geen kans van slagen heeft...

Het klinkt allemaal leuk wat ze doen, maar de realiteit is dat heterogeen programmeren zeer complex is en de vele technieken die AMD ontwikkelt gaan geen groot verschil maken. De echte oplossing is om de kwaliteiten van de CPU en GPU te combineren in één core-ontwerp. Dat is het doel van Intel met AVX-512. Daarbij hoeven de taken niet verdeeld te worden over verschillende types cores. Elke core kan scalaire of parallelle code verwerken, zelfs tegelijk.

Programmeurs hoeven dus geen complexe beslissingen meer te maken en veel te experimenten met wat het best werkt. De compiler kan scalaire of parallelle code genereren en die kan door gelijk welke core uitgevoerd worden zonder heen en weer te springen.

[Martinspire]

Is hier Mantle, hUMA en HSA voor nodig of kan dit ook los worden geïmplementeerd?

En komt dit ook in de X1 of PS4 te zitten dus?
Of is dit eigenlijk hetzelfde wat Microsoft in de Xbox One heeft gezet met de Data Move Engines?

[Reactie gewijzigd door Martinspire op 23 juli 2024 00:54]

[Verwijderd]

Even gokken: dit is een extensie op OpenCL (waar blijft de bronvermelding, tweakers?). Mantle is iets totaal anders, hUMA lijkt mij een vereiste als je het geheel efficient wilt laten verlopen. Je wilt in een simulatie niet elke frame data een en weer sturen van de GPU naar de CPU als er geen unifined memory architecture is. Als je dat hebt is de rest gewoon software.

Maar ik zet persoonlijk mijn vraagtekens bij de uitleg. Meestal, dus niet altijd, heb je een set taken waarvan een deel het beste op de GPU kan worden uitgevoerd, en een deel het beste op de CPU. Een developer welke een zekere kennis heeft over de hardware van zijn eindgebruikers kan de verdeling tussen de taken beter zelf regelen.

[MAX3400]

Mantle komt niet in de next-gen consoles; zowel AMD als Microsoft hebben recentelijk hier iets over verteld tijdens de release van Mantle.

http://www.legitreviews.c...en-console-support_126361
http://www.extremetech.co...so-unlikely-is-mantle-doa

[Reactie gewijzigd door MAX3400 op 23 juli 2024 00:54]

[Martinspire]

Het ging me ook niet om Mantle, maar om de nu aangekondigde hQ.

[stryker000]

Ik heb zonet een A8-6500 gekocht. Ik ben ook benieuwd of een firmware-update/update in OS dit gaat implementeren of het enkel gaat om nieuwere modellen..

[smekkos]

volgens mij gaat HSA alleen werken voor apu's met GCN gpu's. de A8-5500 en A8-6500 zijn nog VLIW4 net als de 6**** reeks. Het hele principe is denk ik niet toe te passen met een software update.

[aminam]

hopelijk is het genoeg om AMD het hoofd boven water te laten houden. maar als ik het zo lees dat doet AMD hard zijn best om weer een rol te gaan spelen in de mobiele markt. hun processoren zijn vaak te hitsig en te energie slurpend om in een laptop te proppen. misschien brengen ze daar in de toekomst verandering in en weten de mediamarkt mannetjes over 2 jaar wat AMD is.

[tweegroenethee]

Ik las laatst een artikel dat de hUMA technologie gebruikt gaat worden in de PS4, moeten de overige twee componenten dan ook gebruikt worden door de PS4?

[sjongenelen]

Misschien domme vraag, maar zijn dit speciale instructies die ín de APU (of CPU of GPU daarin) gebakken zitten, of moet ik dit meer zien als een verbetering in de driver?

edit:

Met hQ moet die extra stap gerealiseerd worden: de cpu geeft in hQ-apu's werklasten direct door aan de gpu, zonder tussenkomst van drivers.

te snel gelezen dus... naar ik aanneem kun je de firmware van een APU niet updaten dus zal wel echt ingebakken worden

[Reactie gewijzigd door sjongenelen op 23 juli 2024 00:54]

[JustMitchie]

Mooie ontwikkeling. Zeker ook omdat de APU steeds krachtiger wordt. Als dit zo doorgaat, kan de traditionele CPU worden afgeschreven en kunnen we kleinere systemen maken, met eenzelfde 'punch'. Dit is natuurlijk mooi. Alhoewel het sentiment niet wil dat ik straks een apu koop...

[Verwijderd]

Als dit zo doorgaat, kan de traditionele CPU worden afgeschreven...

De CPU en GPU gaan versmelten. En Intel heeft daarin een grote voorsprong. AVX-512 brengt het soort vector-rekeneenheden waar de GPU over beschikt, in de CPU-cores.

[VincentAbee]

AMD doet het best goed met het budget wat ze hebben.

[Verwijderd]

Hoe leidt je dat hieruit af? Dit is louter een persbericht voor toekomstige technologie. Da's een wanhoopsdaad om nog eens in de belangstelling te komen en investeerders aan te trekken. AMD is echter veel geld aan het verspillen aan technologie die geen toekomst heeft. Intel gaat met AVX-512 dezelfde rekenkracht aanbieden binnen de CPU-cores zelve. Deze homogene aanpak heeft helemaal geen behoefte aan al die heterogene technologie waar AMD nu z'n budget aan verspeelt.

[mutley69]

Het zou zo mooi zijn mocht AMD de Athlon-truk nog 's kunnen herhalen - maar, het blijft een bedrijf - en een bedrijf wil winst maken, en winst maximaliseren - dat wetende - hopen we op een "gezondere" markt. Met veel competitie.

[Verwijderd]

Nodeloos gecompliceerd. Intel werkt aan AVX-512 ondersteuning in de cores van de CPU zelve. Ter vergelijking AMD's GPUs hebben ook 512-bit brede vectoren. Intel's homogene aanpak zorgt er echter voor dat er geen overdracht van data en taken naar andere cores moet gebeuren. De code kan ook gemakkelijk door de compiler gegenereerd worden en programmeurs kunnen hun vertrouwde talen gebruiken.

[polli_]

AMD excavator zal ook AVX-512 ondersteunen volgens verschillende bronnen.

[Verwijderd]

Welke bronnen? De berichten die ik vind spreken enkel over AVX2, en dat is 256-bit.

[polli_]

Klopt is inderdaad AVX-2.