CJ's AMD Radeon Info & Nieuwsdiscussietopic - Deel 141

[D0gtag]

DervishD schreef op woensdag 19 juli 2017 @ 18:38:
[...]

Als AMD het patent op deze techniek heeft (hopelijk waren ze zo slim om er patent op aan te vragen) dan valt er voor Nvidia helemaal niets na te maken.

Interconnect tussen chips is niks nieuws en varianten erop betekent niet dat je het kopieert.
Remember HyperTransport? was een copie van intels FSB, zelfde idee andere uitvoering, communicatie tussen de verschillende IC's.
Infinityfabric is zeg maar HyperTransport v2, gebruikt geloof ik ook het zelfde messaging protocol als HT.
Intel heeft het ook een stap verder genomen en noemt het mesh.

Toevoeging van Budapest event, het verschil in de systemen was 300usd. Het verschil is tussen een vega en 1080 systeem (de systemen die daar stonden), het evenement was in samenwerking met asus. 200 euro is ook het verschil tussen een 27inch freesync en gsync monitor. blijft er 100€ over voor de gpu.
Maar ik neem aan dat het de vega luchtgekoeld was (assumption is the mother of all fuck-ups)

[ Voor 20% gewijzigd door D0gtag op 19-07-2017 19:12 ]

[418O2]

Is die 300 inclusief die 200 watt sterkere voeding die de vega nodig heeft?

[Sp3ci3s8472]

D0gtag schreef op woensdag 19 juli 2017 @ 18:48:
[...]

Interconnect tussen chips is niks nieuws en varianten erop betekent niet dat je het kopieert.
Remember HyperTransport? was een copie van intels FSB, zelfde idee andere uitvoering, communicatie tussen de verschillende IC's.
Infinityfabric is zeg maar HyperTransport v2, gebruikt geloof ik ook het zelfde messaging protocol als HT.
Intel heeft het ook een stap verder genomen en noemt het mesh.

Toevoeging van Budapest event, het verschil in de systemen was 300usd. Het verschil is tussen een vega en 1080 systeem (de systemen die daar stonden), het evenement was in samenwerking met asus. 200 euro is ook het verschil tussen een 27inch freesync en gsync monitor. blijft er 100€ over voor de gpu.
Maar ik neem aan dat het de vega luchtgekoeld was (assumption is the mother of all fuck-ups)

Nee, HyperTransport is geen copy van Intels FSB. Als je die bewering maakt dan kan je elke bus een copy van een ander noemen.
Bij AMD zat de memory controller vanaf de AMD64 chips op de cpu in plaats van op de Northbridge. HyperTransport communiceerd dan ook direct met het geheugen zonder een Northbridge ertussen.
Bij Intel was het CPU -> Northbridge -> geheugen, een hele andere setup. HyperTransport was best inovatief en gaf lagere latencies.

HyperTransport is overigens serieel en de FSB parallel.

http://www.avadirect.com/...erTransport-Technologies/

AMD heeft zelf aangegeven dat InfitinyFabric niet gebasseerd is op HyperTransport, het is dus geen HyperTransport v2.
http://www.anandtech.com/...on-1800x-1700x-and-1700/9

A number of people have speculated that the fabric used in AMD’s new design is based on HyperTransport, however AMD has confirmed that they are using a superset HyperTransport here for Zen, and that the Infinity fabric design is meant to be high bandwidth, low latency, and be in both Zen and Vega as well as future products. Almost similar to the CPU/GPU roadmaps, the Fabric has its own as well.

Het verschil tussen de schermen kan inderdaad tussen de 100 en 200 zitten, zeker voor de wat duurdere schermen. Ik denk dat het verschil iets van 150 euro is (zit er mooi tussenin ).

offtopic:
Probeer als je iets post het ook te onderbouwen met bronnen, maakt niet uit als je het fout hebt (dat zit ik vaak genoeg).

[ Voor 18% gewijzigd door Sp3ci3s8472 op 19-07-2017 19:23 ]

[ArcticWolf]

418O2 schreef op woensdag 19 juli 2017 @ 19:18:
Is die 300 inclusief die 200 watt sterkere voeding die de vega nodig heeft?

Ze bevelen 850W aan voor Vega.. .maar geen idee waar die overige 450W voor nodig is

[nLr]

ArcticWolf schreef op woensdag 19 juli 2017 @ 19:23:
[...]

Ze bevelen 850W aan voor Vega.. .maar geen idee waar die overige 450W voor nodig is

Heb nu 650, ben niet echt van plan om die te gaan upgraden om eerlijk te zijn. Wil gaan voor die XTX voor zo ver de info bekend is..

[D0gtag]

Sp3ci3s8472 schreef op woensdag 19 juli 2017 @ 19:20:
[...]


Nee, HyperTransport is geen copy van Intels FSB. Als je die bewering maakt dan kan je elke bus een copy van een ander noemen.
Bij AMD zat de memory controller vanaf de AMD64 chips op de cpu in plaats van op de Northbridge. HyperTransport communiceerd dan ook direct met het geheugen zonder een Northbridge ertussen.
Bij Intel was het CPU -> Northbridge -> geheugen, een hele andere setup. HyperTransport was best inovatief en gaf lagere latencies.

HyperTransport is overigens serieel en de FSB parallel.

http://www.avadirect.com/...erTransport-Technologies/

Het verschil tussen de schermen kan inderdaad tussen de 100 en 200 zitten, zeker voor de wat duurdere schermen. Ik denk dat het verschil iets van 150 euro is (zit er mooi tussenin ).

Goh is hij anders, had ik niet verwacht. Lees je ook de rest ven het verhaal over patent, dan snap je waarom het Hypertransport heet en geen FSB.
Maar wat is de overeenkomt tussen HT en FSB....

The primary use for HyperTransport is to replace the Intel-defined front-side bus

Het gaat om IP niemand wilde vastzitten aan intels eigendom dus kwam HT wat nieuwer is en verbeteringen bracht aan het idee.

More modern designs use point-to-point connections like AMD's HyperTransport and Intel's DMI 2.0 or QuickPath Interconnect (QPI). These implementations remove the traditional northbridge in favor of a direct link from the CPU to the Platform Controller Hub, southbridge or I/O controller.[9]

De overheenkomst is dat ze de zelfde functie hebben alleen andere werking.

Uit jou link:

A number of people have speculated that the fabric used in AMD’s new design is based on HyperTransport, however AMD has confirmed that they are using a superset HyperTransport here for Zen

Er staat niet dat het niet zo is er staat juist dat er gebruik van gemaakt wordt zoals dat gespeculeerd was.
wiki:

Infinity Fabric is a superset of HyperTransport announced by AMD in 2016 as an interconnect for its GPUs and CPUs. It is also usable as interchip Interconnect for communitcation between CPUs and GPUs.[6][7] The company said the Infinity Fabric would scale from 30 GBytes/s to 512 GBytes/s, and be used in the Zen-based CPUs and Vega GPUs which were subsequently released in 2017.

[ Voor 17% gewijzigd door D0gtag op 19-07-2017 19:36 ]

[Damic]

TomasH schreef op woensdag 19 juli 2017 @ 18:22:
[...]

Dat zullen de die-hard AMD fans die nu 1200-1800 euro uitgeven aan een Frontier Edition vast een leuke troll vinden dan...

It's soooo SHINY BLUE

[ArcticWolf]

nLr schreef op woensdag 19 juli 2017 @ 19:28:
[...]


Heb nu 650, ben niet echt van plan om die te gaan upgraden om eerlijk te zijn. Wil gaan voor die XTX voor zo ver de info bekend is..

Die 850W slaat ook nergens op, ik heb de Corsair RM650x en ga er ook vanuit dat die voldoende is voor welke (single) GPU dan ook.

[Sp3ci3s8472]

D0gtag schreef op woensdag 19 juli 2017 @ 19:28:
[...]

Goh is hij anders, had ik niet verwacht. Lees je ook de rest ven het verhaal over patent, dan snap je waarom het Hypertransport heet en geen FSB.
Maar wat is de overeenkomt tussen HT en FSB....

[...]

Het gaat om IP niemand wilde vastzitten aan intels eigendom dus kwam HT wat nieuwer is en verbeteringen bracht aan het idee.

[...]

De overheenkomst is dat ze de zelfde functie hebben alleen andere werking.

Je zit hier op een technisch forum, het is niet mijn bedoeling om alles wat jij zegt als fout te bestempelen. Als het zo obvious is als wat jij post dan gaat de "inner geek" los.

Dus verbeter ik je, in de hoop dat je er iets van leert.

Het enige punt waarin de FSB en Hypertransport gelijk zijn is dat ze beide uiteindelijk zorgen dat de CPU bij zijn geheugen kan komen. Technisch zijn ze gewoon heel anders.
Een paar andere vergelijkingen, die naar mijn mening krom zijn.
Coax, Ethernet en Glasvezel, ja er gaat internet overheen maar het is zo anders en de protocollen zijn niet vergelijkbaar.
PATA en SATA spreken allebei met disken/cdrom drives etc. Techniek is totaal niet te vergelijken.
HDMI, DP en VGA.

offtopic:
Je kan me een pietje precies noemen, maar het zou vergelijkbaar zijn als je moeder tegen elke console Playstation zou zeggen. Wat helaas altijd gebeurt .
Ik ga zo te veel offtopic, dit zou beter in het AMD topic voor cpu's kunnen, wellicht daar de discussie voortzetten?

Ik zag je edit wat laat .

AMD figured that the FSB would slow down and kill their efficiency advantage, which was AMD's selling point. By putting the memory controller directly on the processor chip, the FSB was no longer needed to connect processor and memory via the chipset.

Het is dus niet de afhankelijkheid van Intel maar de afhankelijkheid van de trage bus. Er is een reden dat ook Intel met de FSB gestopt is.

Ik kan mij er beter in vinden als je zou zeggen dat InterConnect op HyperTransport lijkt.

Ook al is het een superset van Hypertransport, hetzelfde kan je zeggen over elke videokaart die elkaar opvolgt. Er zijn genoeg dingen uit de HD5870 series die meegenomen zijn naar een nieuwere kaart maar dan op een andere manier geimplementerd.
Dit wordt zo een semantische discussie, ieder heeft zijn kijk er op.

[ Voor 24% gewijzigd door Sp3ci3s8472 op 19-07-2017 19:47 ]

[nero355]

Sp3ci3s8472 schreef op woensdag 19 juli 2017 @ 19:37:
PATA en SATA spreken allebei met disken/cdrom drives etc. Techniek is totaal niet te vergelijken.

Zijn beiden anders wel IDE

[D0gtag]

Sp3ci3s8472 schreef op woensdag 19 juli 2017 @ 19:37:
[...]


Je zit hier op een technisch forum, het is niet mijn bedoeling om alles wat jij zegt als fout te bestempelen. Als het zo obvious is als wat jij post dan gaat de "inner geek" los.

Dus verbeter ik je, in de hoop dat je er iets van leert.

Het enige punt waarin de FSB en Hypertransport gelijk zijn is dat ze beide uiteindelijk zorgen dat de CPU bij zijn geheugen kan komen. Technisch zijn ze gewoon heel anders.
Een paar andere vergelijkingen, die naar mijn mening krom zijn.
Coax, Ethernet en Glasvezel, ja er gaat internet overheen maar het is zo anders en de protocollen zijn niet vergelijkbaar.
PATA en SATA spreken allebei met disken/cdrom drives etc. Techniek is totaal niet te vergelijken.
HDMI, DP en VGA.

offtopic:
Je kan me een pietje precies noemen, maar het zou vergelijkbaar zijn als je moeder tegen elke console Playstation zou zeggen. Wat helaas altijd gebeurt .
Ik ga zo te veel offtopic, dit zou beter in het AMD topic voor cpu's kunnen, wellicht daar de discussie voortzetten?

Oke je innergeek kan niet lezen, het ging over patenten, FSB en HT zijn het zelfde idee alleen technisch anders om geen issues met patenten te hebben. Dat de techniek anders is lijkt me duidelijk maar HT was het antwoord op FSB. Kan je wel een intergeek bs verhaal komen en maar blijven zwetsen over 'dat je dan alles wel het zelfde kan noemen'. Het feit blijft dat HT een direct antwoord was op FSB en FSB ontworpen was voor intel door intel. HT is open en voor meerdere bedrijven met verschillende architecturen.
Laat je innergeek nog een keer kijken naar infinity fabric en wat er precies stond in dat anandtech artikel.

A number of people have speculated that the fabric used in AMD’s new design is based on HyperTransport, however AMD has confirmed that they are using a superset HyperTransport here for Zen

Daar staat dat ze inderdaad een superset van HT gebruiken, bedankt.

---

Het volgende slaat gewoon helemaal nergens op en is een gebrek aan geek:
PATA(1986) en SATA(2003) zijn opeenvolgende technieken (dus na elkaar op de markt gebracht) het doel was niet om als concurrent van Pata op de markt te komen.
HDMI = DVI werken het zelfde en je kan dus ook hdmi -> dvi adapters vinden minus audio dan.
Het is geen concurrerende standaard en dat was het ook nooit voor bedoeld DVI was de voorganger van HDMI en zijn beiden compatibel.
DP was een antwoord op de tekorten van HDMI en is niet antwoord op HDMI, snap je het verschil.
HDMI zit nog steeds op tv's in verbeterde versies.
DP en Unified Display Interface zijn concurrerende systemen, doen het zelfde alleen zijn technisch anders. UDI was het antwoord op HDMI maar iedereen stapte over op DP.
Snapt je innergeek waar het nu over gaat? Niet de technische werking maar de legale status. Als het exact het zelfde zou werken is dat inbreuk op een patent, dus moet het technisch anders werken, niet alleen een naamsverandering.

nV maakt dus een systeem wat twee cores aan elkaar verbind ala infinity fabric maar het werkt technisch vast anders. Dus kan AMD het wel patenteren (wat ze ook doen) maar niet tegenhouden dat iemand het idee gebruikt om het zelfde te doen met andere technische achtergrond (twee chips verbinden om een snellere gpu te maken en goedkoper te produceren --=het idee).


Het idee, de technische werking is hierbij niet relevant nV gaat natuurlijk niet exact het zelfde doen technisch, als je dat wel dacht: lees is hoe patenten werken.
Patenten zijn vaak een idee als b.v. Bounce-Back Effect van apple gekopieerd door Samsung,
De technische werking is niet relevant het gaat om het idee wat gepatenteerd is.
De interconnect tussen chips is al jaren oud dus dat idee kan je niet meer patenteren, om dit te omzeilen maken ze een specifiek patent genaamd infiniti fabric: b.v. connectie tussen aantal cores via serieele banen.
nV noemt het Nlink en geeft op:connectie tussen aantal cores via meerdere paralelle banen.
Hoppa andere technische werking, nieuw patent, beiden de zelfde functie.

---

Je zit hier op een technisch forum, het is niet mijn bedoeling om alles wat jij zegt als fout te bestempelen. Als het zo obvious is als wat jij post dan gaat de "inner geek" los.

Dus verbeter ik je, in de hoop dat je er iets van leert.

Inderdaad, het zou een stuk makkelijker zijn als je kon lezen. En je valse arrogantie:
Misschien leer je iets van anderen door niet op mensen neer te kijken, want ik hoor alleen maar onzekerheid en je hebt niks verteld wat daadwerkelijk iets met de kern te maken had. Je bent alleen maar aan het herkauwen wat je wel denkt te weten, als je gelezen had.. had je gezien waar het daadwerkelijk om gaat.
Pata sta verhaal, laat me niet lachen, oh wacht dat deed je wel.
Technische werking is niet relevant, het gaat om de functie die ze kopiëren niet de technische werking. HT is functioneel een kopie van FSB (maar technisch blablabla... vermoeiend)
Mesh is een functie kopie van infinity en nV maakt een functie kopie van infinity niet een technische kopie.
Hopelijk komt het door en kan je iets leren van een ander en word je een beter mens.

Remember HyperTransport? was een copie van intels FSB, zelfde idee andere uitvoering, communicatie tussen de verschillende IC's.

[Phuncz]

nero355 schreef op woensdag 19 juli 2017 @ 19:58:
[...]

Zijn beiden anders wel IDE

SATA gebruikt toch AHCI ? IDE op SATA is in emulatie.

[-The_Mask-]

DaniëlWW2 schreef op maandag 17 juli 2017 @ 16:44:
[...]


Sapphire, Gigabyte Aorus XTR en Asus ROG strix als je er eentje goedkoop kan vinden. Powercoler zou ik echt niet weten, maar hun RX480 was niet erg goed, XFX was heel goed voor de RX480, nu geen idee maar ik denk niet slecht. Volgens mij was Sapphire ook de grootste van de AMD AIB partners, dus eentje van hun vinden zal niet moeilijk zijn. MSI heeft deze ronde de bal mis geslagen qua koeling en geluidsproductie.

XFX was helemaal niet heel goed, dat was alleen maar een bewering van JayzTwoCents in zijn review waar die allemaal onzin verkondigde. Zoals de verkondiging dat de videokaart heel zuinig was, met als bewijs een software meting welke helemaal niet het verbruik volledige verbruik van de videokaart liet zien.

Verwijderd schreef op dinsdag 18 juli 2017 @ 14:24:
[...]

Je weet het pas zeker als het is gemeten, wie weet wat AMD heeft gewijzigd zonder er tot nu toe over te hebben gecommuniceerd. Zoals ik het zie hadden we een zeer sterk vermoeden, aan zekerheid grenzende waarschijnlijkheid.

Het was al duidelijk omdat het nu eenmaal zo werkt. Hogere spanning is hoger verbruik en hoger verbruik is lagere GPU frequentie. Lagere spanning is lager verbruik en dus een hogere GPU frequentie. Dat is gewoon hoe AMD videokaarten werken als je het maximale verbruik beperkt.

D0gtag schreef op dinsdag 18 juli 2017 @ 17:04:

Er komt geen 56 CU versie voor consumenten, hardware info link paar dagen terug. Er komen 3 versies 2 aircooled een met 56CU's voor de OEM markt. De consumeten versies hebben beiden 64CU's
Vega XL (56), Vega XT en Vega XTX (beide 64)

Als Hardware.info A zegt dan is het vaak B en andersom.

Daarnaast zou het vreemd zijn om geen 3584 stream processor videokaart uit te brengen. Er was is immers ook gewoon een Fury X met 4096 stream processors en Fury met 3584 stream processors. Als je dan de volledige Vega RX op ~1600MHz tegenover de GTX 1080 zet dan zet je degene met 3584 streamprocessors tegenover de GTX 1070.

Werelds schreef op dinsdag 18 juli 2017 @ 20:22:
[...]

Nvidia is idioot voorspelbaar. Qua prestaties was G80 de laatste verrassing en G92 was de perfecte iteratie daarvan. Maxwell was een verrassing qua efficiëntie. Voor de rest is het allemaal bijzonder voorspelbaar geweest.

Klopt alles was al duidelijk ver van te voren. Enige bijzondere was idd performance/watt van Maxwell.

-The_Mask- schreef op dinsdag 18 februari 2014 @ 18:08:
Wauw, dit had ik echt niet verwacht....

http://www.techpowerup.co...VIDIA/GeForce_GTX_750_Ti/

-The_Mask- schreef op dinsdag 18 februari 2014 @ 18:28:
Ja nVidia kan met Maxwell op 28nm er nog heel wat uithalen.

Als ze alles verdubbelen met dezelfde kloksnelheid krijg je ongeveer GTX 770 prestaties met een verbruik dat dan 1/3 lager ligt, vergelijkbaar met de GTX 660.

Verdrievoudiging je alles met behoud van dezelfde kloksnelheid ga je over de GTX 780 Ti heen met een verbruik dat op het niveau van een GTX 770 ligt.

Verviervoudiging kan qua verbruik wel en qua prestaties zal het natuurlijk helemaal snel zijn, maar je zal een extreem grote die krijgen, lijkt mij niet dat nVidia dat gaat doen. Dat zouden ze eventueel voor 20nm kunnen bewaren, maar denk niet dat het gaat gebeuren. Zal waarschijnlijk beetje anders zijn, meer op GPGPU gericht.

Al weer drie en een half jaartjes terug.

Sp3ci3s8472 schreef op dinsdag 18 juli 2017 @ 21:04:
[...]


Dat kan ik dus niet goed geloven, dan hadden ze namelijk beter een Fury X op 1700Mhz kunnen uitbrengen met hetzelfde resultaat. Dat was waarschijnlijk ook nog goedkoper geweest.

Zelfs met vloeibaar stikstof kom je niet eens in de buurt van zulke kloksnelheden volgens mij, dus dat zit er echt niet in.

Fredi schreef op dinsdag 18 juli 2017 @ 21:15:

Nieuws van Samsung die de produktie van zijn 8 GB HBM2-modules opschroeft is ook bemoedigend voor komst van een 16 GB Vega versie.

Die is natuurlijk al te koop.

DaniëlWW2 schreef op dinsdag 18 juli 2017 @ 22:47:
[...]


In ieder geval komt er voor de volgende cyclus minstens een Titan, en een Ti, en AMD heeft waarschijnlijk geen antwoord, tenzij er wel een Vega 2 komt in 2018, en dan Navi in 2019.

Vega 20, dus een refresh van Vega 10 die je vindt in Vega RX en Vega Frontier staat op de roadmaps. Alleen een refresh is niet meer dan een refresh. Zoals de HD4890 een refresh was van de HD4870, de RX 580 van de RX 480 enzovoort, dat zijn geen grote verschillen.

DaniëlWW2 schreef op dinsdag 18 juli 2017 @ 22:58:
Ga ook eens lurken op SA en dit is behoorlijk onder de radar gebleven.
https://semiaccurate.com/...inct-server-accelerators/

Radeon Instinct komt dus ook Q3, en de M18 is dus een Fiji chip. Die zag ik echt niet aankomen.

Je had het zelf al gepost in dit topic: DaniëlWW2 in "CJ's AMD Radeon Info & Nieuwsdiscussietopic - Deel 140" Daar staat ook gewoon Fiji bij voor de MI8.

ArcticWolf schreef op woensdag 19 juli 2017 @ 07:41:
[...]

ik heb nog een Termi in m'n laptop zitten (GTX765M), wordt echt bizar heet en dan zit er nog een turbo-fan knop erop en dan blaast ie zo hard dat je de kamer kan verwarmen in de winter, dan moet je ook niet je hand voor de uitlaat steken

Dat komt omdat het koellichaam niet voldoet of de koeler heeft niet meer heel goed contact door uitgedroogde pasta of er zit veel stof in. Dat kan gebeuren naar meerdere jaren. Maar als die het van het begin af aan heeft gedaan is het meestal gewoon een koeler die niet voldoet.

ArcticWolf schreef op woensdag 19 juli 2017 @ 19:31:
[...]

Die 850W slaat ook nergens op, ik heb de Corsair RM650x en ga er ook vanuit dat die voldoende is voor welke (single) GPU dan ook.

Is het ook, Vega is al extreem qua verbruik en dat brengt gewoon problemen met zich mee, meer dan 300W voor een enkele videokaart wil je gewoon eigenlijk niet. Maar zelfs al is het 400W dan nog kan een high-end 650W voeding natuurlijk nog gemakkelijk. Behalve als je het wil combineren met een zwaar overgeklokte Threadripper of Core i9 10, 12 of 16 core, dan wordt het pas krap.

[Sp3ci3s8472]

D0gtag schreef op woensdag 19 juli 2017 @ 20:40:
[...]

Oke je innergeek kan niet lezen, het ging over patenten, FSB en HT zijn het zelfde idee alleen technisch anders om geen issues met patenten te hebben. Dat de techniek anders is lijkt me duidelijk maar HT was het antwoord op FSB. Kan je wel een intergeek bs verhaal komen en maar blijven zwetsen over 'dat je dan alles wel het zelfde kan noemen'. Het feit blijft dat HT een direct antwoord was op FSB en FSB ontworpen was voor intel door intel. HT is open en voor meerdere bedrijven met verschillende architecturen.
Laat je innergeek nog een keer kijken naar infinity fabric en wat er precies stond in dat anandtech artikel.

[...]

Daar staat dat ze inderdaad een superset van HT gebruiken, bedankt.

---

Het volgende slaat gewoon helemaal nergens op en is een gebrek aan geek:
PATA(1986) en SATA(2003) zijn opeenvolgende technieken (dus na elkaar op de markt gebracht) het doel was niet om als concurrent van Pata op de markt te komen.
HDMI = DVI werken het zelfde en je kan dus ook hdmi -> dvi adapters vinden minus audio dan.
Het is geen concurrerende standaard en dat was het ook nooit voor bedoeld DVI was de voorganger van HDMI en zijn beiden compatibel.
DP was een antwoord op de tekorten van HDMI en is niet antwoord op HDMI, snap je het verschil.
HDMI zit nog steeds op tv's in verbeterde versies.
DP en Unified Display Interface zijn concurrerende systemen, doen het zelfde alleen zijn technisch anders. UDI was het antwoord op HDMI maar iedereen stapte over op DP.
Snapt je innergeek waar het nu over gaat? Niet de technische werking maar de legale status. Als het exact het zelfde zou werken is dat inbreuk op een patent, dus moet het technisch anders werken, niet alleen een naamsverandering.

nV maakt dus een systeem wat twee cores aan elkaar verbind ala infinity fabric maar het werkt technisch vast anders. Dus kan AMD het wel patenteren (wat ze ook doen) maar niet tegenhouden dat iemand het idee gebruikt om het zelfde te doen met andere technische achtergrond (twee chips verbinden om een snellere gpu te maken en goedkoper te produceren --=het idee).


Het idee, de technische werking is hierbij niet relevant nV gaat natuurlijk niet exact het zelfde doen technisch, als je dat wel dacht: lees is hoe patenten werken.
Patenten zijn vaak een idee als b.v. Bounce-Back Effect van apple gekopieerd door Samsung,
De technische werking is niet relevant het gaat om het idee wat gepatenteerd is.
De interconnect tussen chips is al jaren oud dus dat idee kan je niet meer patenteren, om dit te omzeilen maken ze een specifiek patent genaamd infiniti fabric: b.v. connectie tussen aantal cores via serieele banen.
nV noemt het Nlink en geeft op:connectie tussen aantal cores via meerdere paralelle banen.
Hoppa andere technische werking, nieuw patent, beiden de zelfde functie.

---

[...]

Inderdaad, het zou een stuk makkelijker zijn als je kon lezen. En je valse arrogantie:
Misschien leer je iets van anderen door niet op mensen neer te kijken, want ik hoor alleen maar onzekerheid en je hebt niks verteld wat daadwerkelijk iets met de kern te maken had. Je bent alleen maar aan het herkauwen wat je wel denkt te weten, als je gelezen had.. had je gezien waar het daadwerkelijk om gaat.
Pata sta verhaal, laat me niet lachen, oh wacht dat deed je wel.
Technische werking is niet relevant, het gaat om de functie die ze kopiëren niet de technische werking. HT is functioneel een kopie van FSB (maar technisch blablabla... vermoeiend)
Mesh is een functie kopie van infinity en nV maakt een functie kopie van infinity niet een technische kopie.
Hopelijk komt het door en kan je iets leren van een ander en word je een beter mens.

[...]

Daarom gaf ik ook aan dat het semantiek is. Jij vergelijkt het op het niveau waar het voor dient (functioneel), en in zijn meest basale vorm is dat dus communicatie tussen twee dingen. Ik kijk er technisch naar en vind het daarom anders. We hebben beide gelijk alleen omdat we er op een ander detail niveau naar kijken, en op een technisch forum zoals dit mag er best op een technisch vlak naar worden gekeken anders kan je alle discussies die we hier voeren over de interne werking van AMD en Nvidia kaarten links laten liggen en alleen de leaks van de performance plaatsen want een AMD videokaart is een videokaart en een Nvidia videokaart is ook een videokaart ze doen beide hetzelfde.
Dat is het punt wat ik probeer over te brengen.

Daarom nu de onthulling alles is gebasseerd op FSB . NVLink, HyperTransport, Intels QPI enzovoort. Ze hadden beter gewoon FSB kunnen blijven gebruiken . De reden waarom AMD weg wilde bij FSB is dat het traag was en zorgde voor een hogere latency, dat ze daarom ook niet meer afhankelijk waren van Intel was natuurlijk een leuke bijkomst.

Fijn dat je je hebt ingelezen over de verschillende video standaarden, zijn we het in ieder geval over dat eens. Dus ze brengen beeldjes van de videokaart naar je beeldscherm, dat VGA geen audio kan en HDMI wel maakt niet uit want ze vervullen hetzelfde doel.
Die laatste zin kan je dus negeren.

A number of people have speculated that the fabric used in AMD’s new design is based on HyperTransport, however AMD has confirmed that they are using a superset HyperTransport here for Zen.

Waar ze met however dus de nadruk willen leggen op het verschil tussen een superset en "based upon". Althans dat is mijn interpretatie, de jouwe mag wat mij betreft anders zijn.

[D0gtag]

Sp3ci3s8472 schreef op woensdag 19 juli 2017 @ 21:31:
[...]


Daarom gaf ik ook aan dat het semantiek is. Jij vergelijkt het op het niveau waar het voor dient (functioneel), en in zijn meest basale vorm is dat dus communicatie tussen twee dingen. Ik kijk er technisch naar en vind het daarom anders. We hebben beide gelijk alleen omdat we er op een ander detail niveau naar kijken, en op een technisch forum zoals dit mag er best op een technisch vlak naar worden gekeken anders kan je alle discussies die we hier voeren over de interne werking van AMD en Nvidia kaarten links laten liggen en alleen de leaks van de performance plaatsen want een AMD videokaart is een videokaart en een Nvidia videokaart is ook een videokaart ze doen beide hetzelfde.
Dat is het punt wat ik probeer over te brengen.

Daarom nu de onthulling alles is gebasseerd op FSB . NVLink, HyperTransport, Intels QPI enzovoort. Ze hadden beter gewoon FSB kunnen blijven gebruiken . De reden waarom AMD weg wilde bij FSB is dat het traag was en zorgde voor een hogere latency, dat ze daarom ook niet meer afhankelijk waren van Intel was natuurlijk een leuke bijkomst.

Fijn dat je je hebt ingelezen over de verschillende video standaarden, zijn we het in ieder geval over dat eens. Dus ze brengen beeldjes van de videokaart naar je beeldscherm, dat VGA geen audio kan en HDMI wel maakt niet uit want ze vervullen hetzelfde doel.
Die laatste zin kan je dus negeren.


[...]

Waar ze met however dus de nadruk willen leggen op het verschil tussen een superset en "based upon". Althans dat is mijn interpretatie, de jouwe mag wat mij betreft anders zijn.

We hebben niet allebei gelijk jij hebt het over iets anders, jij kan naar het technische verhaal kijken zolang als je wilt, de vraag ging daar niet over.

DervishD schreef op woensdag 19 juli 2017 @ 18:38:
[...]

Als AMD het patent op deze techniek heeft (hopelijk waren ze zo slim om er patent op aan te vragen) dan valt er voor Nvidia helemaal niets na te maken.

De kern ging over het patent op deze techniek.
Patent kan je omzeilen door een andere techniek, dat het technisch anders is juist exact waar het over gaat. Kan jij er wel technisch naar kijken en zeggen dat het technisch anders is zit je alleen maar een antwoord te geven op een vraag die niet gesteld is.
Ik heb al meerdere keren daarvoor aangegeven dat het technisch anders is, het gaat NOGMAALS om het idee in een patent, nV wil het idee kopiëren van inifnity fabric dit doen ze door min of meer de zelfde werking te verkrijgen door een andere technische uitvoering. (antwoord op de vraag van DervishD)
Ze moeten een andere technische uitvoering hebben want anders word het een patent oorlog in de rechtszaal die ze gewoon verliezen.
Ik heb niet op technisch of functioneel niveau gekeken, ik kijk naar de vraag en geef antwoord die erop past.
Het technische aspect is niet relevant als je al weet dat het technisch altijd anders moet zijn, tenzij ze patent kopen.
Ik kan ook een heel technisch verhaal erbij zetten om me zelf belangrijk te laten voelen.
En er is geen interpretatie verschil alleen jou ego staat in de weg. Superset is een toevoeging op de bestaande hypertransport set, dat moet de innergeek in je toch wel weten?
Navi is gen 6 na navi komt pas een nieuwe architectuur, zelfs Wikipedia weet dat (staat ook in de presentatie van AMD)

-The_Mask- schreef op woensdag 19 juli 2017 @ 21:18:

[...]

Als Hardware.info A zegt dan is het vaak B en andersom.

Daarnaast zou het vreemd zijn om geen 3584 stream processor videokaart uit te brengen. Er was is immers ook gewoon een Fury X met 4096 stream processors en Fury met 3584 stream processors. Als je dan de volledige Vega RX op ~1600MHz tegenover de GTX 1080 zet dan zet je degene met 3584 streamprocessors tegenover de GTX 1070.

Ik verwacht wel dat er andere varianten komen maar niet bij launch (ze moeten iets met de resten uit de wafer ) Maar de oem versie kan best wel is kloppen (apple imac, staat ook in de sheet van apple)

[ Voor 13% gewijzigd door D0gtag op 19-07-2017 22:21 ]

[Verwijderd]

D0gtag schreef op woensdag 19 juli 2017 @ 14:31:
[...]


Moet toegeven, je bent wel een ras optimist als het om AMD gaat.

Nee, ik ben een realist! We weten pas wat RX Vega kan nadat die uitkomt, tot die tijd kan je enkel speculeren. Voor het geval jij het niet door hebt, de heren drijven in het begin van dat filmpje de spot met de mensen die op basis van Vega FE 'conclusies' trekken over Vega omdat die mensen uit hun nek lullen en niet begrijpen wat het verschil is tussen professionele kaarten en gaming kaarten. Een van die verschillen heb ik eerder op de dag nog aangegeven.

[ Voor 16% gewijzigd door Verwijderd op 19-07-2017 22:19 ]

[D0gtag]

Verwijderd schreef op woensdag 19 juli 2017 @ 22:19:
[...]

Nee, ik ben een realist! We weten pas wat RX Vega kan nadat die uitkomt, tot die tijd kan je enkel speculeren. Voor het geval jij het niet door hebt, de heren drijven in het begin van dat filmpje de spot met de mensen die op basis van Vega FE 'conclusies' trekken over Vega omdat die mensen uit hun nek lullen en niet begrijpen wat het verschil is tussen professionele kaarten en gaming kaarten. Een van die verschillen heb ik eerder op de dag nog aangegeven.

Nee, ik had het niet door...op dit technische forum.. maar laten we nogmaals realistisch kijken. Vega FE is uit, VEGA FE = cgn 1.5 VEGA chip, die we terug gaan vinden in de gaming vega, software is nog niet klaar. De hardware hebben we nu al wel in handen. We weten dus redelijk veel wel. We hebben nu net een budapest event gehad waarbij hij gelijk kwam met een 1080 (volgens mij was de verwachting dat hij beter was dan een 1080 en onder een 1080ti) dus mogelijk was dat de air cooled versie. Je mag verwachten dat een paar weken voor launch de drivers inmiddels wel klaar zijn.
We weten het vermogen en daarbij dus ook wat zijn OC potencieel is.
Er zijn realistische schattingen van wat driver optimalisatie kan doen tav de vega FE, we weten pas exact wat een vega kan bij launch, maar de schattingen zijn wel redelijk accuraat en gebaseerd op wat we wel weten en dat is gewoon veel meer dan enkel speculeren.

Dus dat zij er spot mee drijven betekent meteen dat het niet kan, want dit zijn de goden van videokaarten?
De WX7100 is een polaris met workstation drivers dus je kan er op gamen maar dan zal je het zelfde resultaat zien als met vega, niet zo goed als een rx580.
Daar heb je dus meteen mijn punt, je kan er op gamen want zonder (de juiste) driver implementatie heb je alleen raw power en dus een indicatie van wat er gaat komen. Jammer dat er geen game benchmarks zijn van deze kaart kan je ze naast de rx580 leggen en guesstimaten naar vega toe.

Zie p5000 vs 1080, beiden de zelfde chip.

[ Voor 15% gewijzigd door D0gtag op 19-07-2017 22:50 ]

[-The_Mask-]

D0gtag schreef op woensdag 19 juli 2017 @ 22:39:
[...]

We hebben nu net een budapest event gehad waarbij hij gelijk kwam met een 1080 (volgens mij was de verwachting dat hij beter was dan een 1080 en onder een 1080ti)

Al meer dan een jaar staat in de topicstart ongeveer dubbel zo snel als een Polaris 10 RX470/RX480 videokaart, dat is dus GTX 1080 gebied. Dat is al die tijd niet veranderd, in die tijd is er namelijk gewoon geen serieus ander gerucht of leak langs geweest dat iets anders deed vermoeden, nu nog steeds niet. Eigenlijk is alleen het verbruik stukken hoger dan verwacht. Maar dat komt omdat de kloksnelheid ook veel hoger dan verwacht is en dat is funest voor de performance/watt.

[Fredi]

-The_Mask- schreef op woensdag 19 juli 2017 @ 21:18:

[...]

Die is natuurlijk al te koop.

Ik bedoelde een eventuele 16 GB RX Vega versie, denk dat je dat wel weet.

[D0gtag]

-The_Mask- schreef op woensdag 19 juli 2017 @ 22:49:
[...]

Al meer dan een jaar staat in de topicstart ongeveer dubbel zo snel als een Polaris 10 RX470/RX480 videokaart, dat is dus GTX 1080 gebied. Dat is al die tijd niet veranderd, in die tijd is er namelijk gewoon geen serieus ander gerucht of leak langs geweest dat iets anders deed vermoeden, nu nog steeds niet. Eigenlijk is alleen het verbruik stukken hoger dan verwacht. Maar dat komt omdat de kloksnelheid ook veel hoger dan verwacht is en dat is funest voor de performance/watt.

[afbeelding]

Ja dat geloof ik best, maar ik heb het niet uit de topic start, want AMD zei dat al bij de introductie opvolger polaris. Maar we hebben nu gewoon veel meer data.
Ik hoop echt dat vega een beest van een kaart is, maar geloven doe ik het niet.
Als ik kan kiezen tussen een 500€ kaart of een 800€ kaart die het zelfde levert.. de keuze mag duidelijk zijn.
Als vega teleur stelt hou ik voorlopig mijn 970 en wacht ik wel even op volta eind dit jaar.

[-The_Mask-]

D0gtag schreef op woensdag 19 juli 2017 @ 22:57:
[...]

Ja dat geloof ik best, maar ik heb het niet uit de topic start, want AMD zei dat al bij de introductie opvolger polaris.

Wat zei AMD?

Als ik kan kiezen tussen een 500€ kaart of een 800€ kaart die het zelfde levert.. de keuze mag duidelijk zijn.
Als vega teleur stelt hou ik voorlopig mijn 970 en wacht ik wel even op volta eind dit jaar.

Vega is iig toch wel meer dan dubbel zo krachtig, zelfs met GTX 1080 prestaties, dus het is toch een flinke stap vooruit. Een GTX 970 zit immers maar op RX 470 prestaties.

Fredi schreef op woensdag 19 juli 2017 @ 22:57:
[...]


Ik bedoelde een eventuele 16 GB RX Vega versie, denk dat je dat wel weet.

Ja eh nee, aangezien de ene persoon A zegt en B bedoelt omdat het B is, de andere zegt B en bedoelt A omdat het A is en weer een ander zegt A, bedoelt daarmee ook A, maar het is B en weer een ander zegt B, bedoelt daarmee B, maar het is A. Dan volg ik het op laatst niet meer.

[D0gtag]

-The_Mask- schreef op woensdag 19 juli 2017 @ 23:08:
[...]

Wat zei AMD?

[...]

Vega is iig toch wel meer dan dubbel zo krachtig, zelfs met GTX 1080 prestaties, dus het is toch een flinke stap vooruit. Een GTX 970 zit immers maar op RX 470 prestaties.


[...]

Ja eh nee, aangezien de ene persoon A zegt en B bedoelt omdat het B is, de andere zegt B en bedoelt A omdat het A is en weer een ander zegt A, bedoelt daarmee ook A, maar het is B en weer een ander zegt B, bedoelt daarmee B, maar het is A. Dan volg ik het op laatst niet meer.

Ik kan me ergens een slide herinneren met 2x faster then previous gen. Maar het gaat mij meer om wat we nu weten.

Ik wilde vega om zo'n compleet AMD systeem te hebben, ipv een amd met 1080ti.
Natuurlijk is vega of de 1080 sneller dan mijn 970 maar ik zoek niet een kaart die sneller is dan mijn 970 want anders had ik ook de1070 kunnen nemen. Ik wil gewoon de beste kaart voor 4k en dan kom je snel uit bij een 1080/ti maar volta staat bijna voor de deur en vega over een paar weken, ik wacht nu al zo lang op vega, die paar maanden hou ik nog wel uit op me 970

[Verwijderd]

-The_Mask- schreef op woensdag 19 juli 2017 @ 21:18:
Het was al duidelijk omdat het nu eenmaal zo werkt. Hogere spanning is hoger verbruik en hoger verbruik is lagere GPU frequentie. Lagere spanning is lager verbruik en dus een hogere GPU frequentie. Dat is gewoon hoe AMD videokaarten werken als je het maximale verbruik beperkt.

Ja, maar hoe wist jij zo zeker dat die kaart nog stabiel zou werken met de standaard klokfrequentie bij het verlagen van de spanning met ongeveer 0,1 V (wat redelijk standaard lijkt te zijn, bij FuryX en Polaris is 0,1 V een goede eerste gok)?

[ Voor 4% gewijzigd door Verwijderd op 19-07-2017 23:38 ]

[-The_Mask-]

D0gtag schreef op woensdag 19 juli 2017 @ 23:16:
[...]

Ik kan me ergens een slide herinneren met 2x faster then previous gen. Maar het gaat mij meer om wat we nu weten.

Je bedoelt dat AMD een slide heeft laten zien waarin ze aangaven dat Vega 2 maal zo snel is als Polaris? Zoiets zullen ze nooit hebben gezegd, over prestaties van een toekomstig product wordt nooit gesproken.

maar volta staat bijna voor de deur

Dat zal ook nog wel een tijd duren. Er is zelfs nog niet eens een gerucht geweest over gaming Volta kaarten, dat wordt dus niet eerder dan volgend jaar. En het echte topmodel, dus de opvolger van de GTX 1080 Ti zal hoogstwaarschijnlijk nog meer dan een jaar duren. nVidia begint de laatste jaren met een Gx104 wat als topmodel op de markt wordt geplaatst, voor iets van een half jaar voordat het echte topmodel komt. Zo was een GTX 1080 dus ook een tijd het topmodel, terwijl we al wisten dat het niet het topmodel was omdat die gebaseerd was op de GP104. De kans dat we dan nu straks ook weer een GV104 eerst gaan zien is ook heel groot en pas later het echte topmodel en zal waarschijnlijk nog meer dan een jaar duren.

[-The_Mask-]

Verwijderd schreef op woensdag 19 juli 2017 @ 23:30:


Ja, maar hoe wist jij zo zeker dat die kaart nog stabiel zou werken met de standaard klokfrequentie bij het verlagen van de spanning met ongeveer 0,1 V

Niet, maar dat verschilt ook per kaart, het is niet dat elke kaart werkt met 0,1V minder dan had AMD namelijk zelf de spanning wel 0,1V lager ingesteld. Wat wel duidelijk is dat de prestaties omhoog gaat als de spanning omlaag gaat als de kaart wordt beperkt door wat die maximaal mag verbruiken. Hoever de kaart is onder te klokken zal echter voor elk product anders zijn. De wel bekende silicon lottery dus.

[Fredi]

-The_Mask- schreef op woensdag 19 juli 2017 @ 23:08:
[...]

Ja eh nee, aangezien de ene persoon A zegt en B bedoelt omdat het B is, de andere zegt B en bedoelt A omdat het A is en weer een ander zegt A, bedoelt daarmee ook A, maar het is B en weer een ander zegt B, bedoelt daarmee B, maar het is A. Dan volg ik het op laatst niet meer.

Voor AMD zou het goed zijn om ook een 16 GB Vega RX aan te bieden want dan hebben ze iets om zich te onderscheiden van nVidia. nVidia biedt nu max 12 GB vram aan op hun consumentenkaarten. 8 GB is nu nog genoeg maar 16 GB vram is meer futureproof.

[Fredi]

Verwijderd schreef op woensdag 19 juli 2017 @ 23:30:
[video]

[...]

Kan goed analyseren die kerel van AdoredTv. De conclusie is dus dat het systeem met de smoothste gameplay het Vega-systeem is.

[ Voor 31% gewijzigd door Fredi op 20-07-2017 01:18 ]

[Gelunox]

Fredi schreef op donderdag 20 juli 2017 @ 01:16:
[...]


Kan goed analyseren die kerel van AdoredTv. De conclusie is dus dat het systeem met de smoothste gameplay het Vega-systeem is.

Als je even verder kijkt zie je dat hij speculeert dat dat misschien komt omdat er een 1070 ipv 1080 in het nV systeem zit.

[nero355]

Phuncz schreef op woensdag 19 juli 2017 @ 21:07:
SATA gebruikt toch AHCI ? IDE op SATA is in emulatie.

De termen zijn een beetje messed up, maar dit vind ik wel een mooie uitleg :

IDE (Integrated Drive Electronics) was the original name, then they standardized on ATA (Advanced Technology Attachment) as being a broader standard that included additions like CD-ROMs and such. When SATA ( Serial ATA ) came out, people started using PATA (Parallel ATA) to refer to the older parallel connected bus (those using ribbon cable), to be more specific than the term ATA, which can refer to either. Both are part of the ATA standard, and use the same logical command sets, but SATA obviously has a different electrical interface. Both types of drives (SATA and PATA) are IDE devices.

Gejat van : https://superuser.com/que...-between-ata-pata-and-ide


En nu terug naar de RX VEGA die maar niet wil uitkomen

[Fredi]

nero355 schreef op donderdag 20 juli 2017 @ 02:05:

En nu terug naar de RX VEGA die maar niet wil uitkomen

Nog 10 dagen.

Morgen is er dat AMD event in Portland, USA. Misschien weten we dan weer iets meer.

[ArcticWolf]

Fredi schreef op donderdag 20 juli 2017 @ 03:39:
[...]


Nog 10 dagen.

Morgen is er dat AMD event in Portland, USA. Misschien weten we dan weer iets meer.

Nou als die hetzelfde is als in Europa laatst dan kom je weinig te weten

[D0gtag]

-The_Mask- schreef op donderdag 20 juli 2017 @ 00:08:
[...]

Je bedoelt dat AMD een slide heeft laten zien waarin ze aangaven dat Vega 2 maal zo snel is als Polaris? Zoiets zullen ze nooit hebben gezegd, over prestaties van een toekomstig product wordt nooit gesproken.


[...]

Dat zal ook nog wel een tijd duren. Er is zelfs nog niet eens een gerucht geweest over gaming Volta kaarten, dat wordt dus niet eerder dan volgend jaar. En het echte topmodel, dus de opvolger van de GTX 1080 Ti zal hoogstwaarschijnlijk nog meer dan een jaar duren. nVidia begint de laatste jaren met een Gx104 wat als topmodel op de markt wordt geplaatst, voor iets van een half jaar voordat het echte topmodel komt. Zo was een GTX 1080 dus ook een tijd het topmodel, terwijl we al wisten dat het niet het topmodel was omdat die gebaseerd was op de GP104. De kans dat we dan nu straks ook weer een GV104 eerst gaan zien is ook heel groot en pas later het echte topmodel en zal waarschijnlijk nog meer dan een jaar duren.

Ik verwacht volta begin 2018, de ti komt pas eind volgend jaar, dat duurt mij een beetje te lang. Eerst zien of vega verrast, zo ja zien we volta ook eerder.

[winwiz]

Leuk hoe opvattingen/meningen in korte tijd kunnen veranderen net hou het uitkomt... Bijna voor de deur is dus begin 2018

[Paprika]

winwiz schreef op donderdag 20 juli 2017 @ 08:22:
Leuk hoe opvattingen/meningen in korte tijd kunnen veranderen net hou het uitkomt... Bijna voor de deur is dus begin 2018

Mensen zouden volgens enkelen in dit draadje al sinds april vorig jaar op Vega moeten wachten.... Pascal kaarten kopen zou een slechte investering zijn en binnen enkele weken zou je kaart nog maar de helft waard zijn...

[D0gtag]

Fredi schreef op donderdag 20 juli 2017 @ 00:19:
[...]


Voor AMD zou het goed zijn om ook een 16 GB Vega RX aan te bieden want dan hebben ze iets om zich te onderscheiden van nVidia. nVidia biedt nu max 12 GB vram aan op hun consumentenkaarten. 8 GB is nu nog genoeg maar 16 GB vram is meer futureproof.

Nee dat zou het niet zijn, aangezien 8GB ruim voldoende is voor nu en aankomende jaren en AMD HBCC heeft geïntroduceerd om dit future proof te maken. 4gb is nu nog voldoende in de meeste gevallen, al zijn er titels die meer kunnen gebruiken. Stel dat HBCC niet instaat is om mem daadwerkelijk te 'verdubbelen' maar slechts 50% toevoegt heb je alsnog 12GB
(HBCC verhoogt het geheugen natuurlijk niet maar volgens AMD halveert het het geheugen gebruikt, waardoor je effectief dus meer geheugen hebt).

Bijna alle AA titels zijn ports van consoles, consoles als de scorpio van ms hebben nu 12GB ram (shared) en kunnen 4k aan. Resolutie en textures bepalen voor een grote mate het geheugen gebruik/behoefte. Ik zie de komende jaren nog weinig actie op 8k gaming (4k is nog niet eens mainstream) en dus ook geen 8k textures, heb je een tekort aan VRAM zet je AA uit Ik vind AA sowieso weinig toevoegen op 4k, maar dat kan aan mijn ogen liggen

[ Voor 18% gewijzigd door D0gtag op 20-07-2017 10:57 ]

[-The_Mask-]

D0gtag schreef op donderdag 20 juli 2017 @ 10:43:
[...]
Stel dat HBCC niet instaat is om mem daadwerkelijk te 'verdubbelen' maar slechts 50% toevoegt heb je alsnog 12GB

Huh?

[superwashandje]

@-The_Mask-
volgens mij bedoeld hij de verdubbeling van het effectief beschikbaar geheugen door het halveren van het geheugengebruik. volgens mijn snelle berekening zou het op zoiets neerkomen:

HBCC factor aanwezig in gebruik factor effectief aanwezig 50% 8 4 2 16 75% 8 6 1,33 10,67

disclaimer: kunnen zeker fouten in zitten door snel ff opgesteld:P

edit: geen idee hoe je die tabel netter kan maken door de kolommen te matchen

[ Voor 28% gewijzigd door superwashandje op 20-07-2017 12:03 ]

[edward2]

D0gtag schreef op donderdag 20 juli 2017 @ 10:43:
[...]
Ik zie de komende jaren nog weinig actie op 8k gaming (4k is nog niet eens mainstream) en dus ook geen 8k textures, heb je een tekort aan VRAM zet je AA uit Ik vind AA sowieso weinig toevoegen op 4k, maar dat kan aan mijn ogen liggen

Je hebt iig geen 8K content nodig om 8K res..op te merken, maar net zoals AA op 4K, is vooral de ppi van belang, dus of jij AA nodig hebt op 4K hangt van je schermgrootte, je voorkeur en het type texture,( specular textures aliasen als een gek) af.
Ik game zelf op 5K op een 27" scherm en dat heeft een aardig hoge ppi, maar gooi er vaak nog wat AA overheen, SMA (met reshade) voor zware spellen en sgssaa voor de wat oudere.

[ Voor 4% gewijzigd door edward2 op 20-07-2017 12:27 ]

[nero355]

Fredi schreef op donderdag 20 juli 2017 @ 00:19:
Voor AMD zou het goed zijn om ook een 16 GB Vega RX aan te bieden want dan hebben ze iets om zich te onderscheiden van nVidia. nVidia biedt nu max 12 GB vram aan op hun consumentenkaarten. 8 GB is nu nog genoeg maar 16 GB vram is meer futureproof.

Dacht ik ook eerst, maar doordat je tegenwoordig allerlei compressie en slimme manieren van het verwerken van de graphics hebt is het echt niet nodig

Met de R9 290X kwam ik op 5760x1200 weleens aan de 8GB, echter met de GTX 1080 zit ik ongeveer aan de 4100 MB hooguit.
Ik denk dan ook dat VEGA meer in de buurt van de 1080 zal zitten dan de 290X wat dit betreft. Ook het HBCC gedoe wat al werd genoemd zal er waarschijnlijk flink aan mee helpen!

[haarbal]

Die cache controller lijkt me meer een feature die ze voor compute ontwikkeld hebben, kan de performance flink helpen als je dataset niet in memory past.

Voor games zal het ook helpen als je over de 8GB heen gaat, maar de performance zal nog steeds beter zijn als ze hem gewoon binnen de 8GB houden. En 8GB is niet bepaald krap, dus dat zal geen probleem zijn voor redelijke developers.

[Julian-AMD]

Slecht nieuws http://www.finanzen.nl/va...n-week-geleden-1002185769

[Toettoetdaan]

Voor de mensen die zich afvragen wat HBCC kan doen voor games; bekijk even dit filmpje: YouTube: AMD Radeon RX Vega HBCC High Bandwith Cache Controller

[ Voor 36% gewijzigd door Toettoetdaan op 20-07-2017 14:42 ]

[418O2]

Toettoetdaan schreef op donderdag 20 juli 2017 @ 14:39:
Voor de mensen die zich afvragen wat HBCC kan doen voor games; kijk even het filmpje op deze pagina: http://www.pcgameshardwar...-Bandwidth-Cache-1222168/

wel met 2Gb VRAM ingeschakeld, worth noting

[Toettoetdaan]

418O2 schreef op donderdag 20 juli 2017 @ 14:42:
[...]

wel met 2Gb VRAM ingeschakeld, worth noting

Je kunt het natuurlijk meteen afschieten, maar in de context of 8GB future proof is haalde mensen HBCC aan. Ik denk dat als we binnen de levensduur van deze kaarten op 8GB vram verbuik komen, dit de levensduur kan verlengen. Daarom zou ik een Vega RX met 16GB niet nodig vinden.

Maargoed, zoals je zegt is dit met 2GB vram, dus mischien leuk voor een toekomstige APU met maar één 4GB HBM stack, maar voor Vega RX lijkt het minder relevant.

Note: Raja heeft gezegd dat het ook helpt in situaties waarin er nog genoeg geheugen over is, maar hoeveel het helpt heef hij niet gezegd.

[418O2]

Toettoetdaan schreef op donderdag 20 juli 2017 @ 14:50:
[...]

Je kunt het natuurlijk meteen afschieten, maar in de context of 8GB future proof is haalde mensen HBCC aan. Ik denk dat als we binnen de levensduur van deze kaarten op 8GB vram verbuik komen, dit de levensduur kan verlengen. Daarom zou ik een Vega RX met 16GB niet nodig vinden.

Maargoed, zoals je zegt is dit met 2GB vram, dus mischien leuk voor een toekomstige APU met maar één 4GB HBM stack, maar voor Vega RX lijkt het minder relevant.

Note: Raja heeft gezegd dat het ook helpt in situaties waarin er nog genoeg geheugen over is, maar hoeveel het helpt heef hij niet gezegd.

Er moet wel heel wat gebeuren wil 8Gb niet meer voldoende zijn binnen de lifespan van deze kaart. Maar we gaan het meemaken

[D0gtag]

-The_Mask- schreef op donderdag 20 juli 2017 @ 11:19:
[...]

Huh?

Effectief geheugen dus, AMD claimt een verdubbeling(100%) dus effectief is 8GB 16, maar als het niet zo efficiënt is als AMD beweert dan alsnog heb je effectief ruim voldoende aan HMB 50%= 4GB, effectief heb je dan 12GB. Hoe dan ook, ik denk niet dat vega onvoldoende geheugen heeft, en aangezien HMB duur is (lage verkoop aantallen) en meer producten in de portfolie ook de winstmarge drukken, AMD er niet aan moet beginnen (of in een later stadium, met beter procedé en hogere clock).

superwashandje schreef op donderdag 20 juli 2017 @ 11:48:
@-The_Mask-
volgens mij bedoeld hij de verdubbeling van het effectief beschikbaar geheugen door het halveren van het geheugengebruik. volgens mijn snelle berekening zou het op zoiets neerkomen:

Ja dat heb ik ook toegevoegd, paar seconden later. :

(HBCC verhoogt het geheugen natuurlijk niet maar volgens AMD halveert het het geheugen gebruikt, waardoor je effectief dus meer geheugen hebt).

haarbal schreef op donderdag 20 juli 2017 @ 14:20:
Die cache controller lijkt me meer een feature die ze voor compute ontwikkeld hebben, kan de performance flink helpen als je dataset niet in memory past.

Voor games zal het ook helpen als je over de 8GB heen gaat, maar de performance zal nog steeds beter zijn als ze hem gewoon binnen de 8GB houden. En 8GB is niet bepaald krap, dus dat zal geen probleem zijn voor redelijke developers.

Niet als HBCC een apart logic gedeelte heeft op de/een chip, dus hardware matig tussen gpu en hmb. HBCC is niet software matig en ik zie niet in waarom het performance zou moeten beperken. Wat AMD ook al heeft laten zien in tests. (altijd eerst zien dan geloven, maar toch)

nV heeft al laten zien dat het vrij potent is met hun 4de gen delta colour compr.

Omdat het hardware matig is hoeven developers het ook niet te implementeren aangezien de kaart/user kan bepalen of wel of niet wordt toegepast.

[Verwijderd]

TomasH schreef op woensdag 19 juli 2017 @ 18:22:
[...]

Dat zullen de die-hard AMD fans die nu 1200-1800 euro uitgeven aan een Frontier Edition vast een leuke troll vinden dan...

Voor de laatste paar mensen die het nog niet begrepen hebben, Vega FE is GEEN gamingkaart. Als een gamer dat geld heeft besteed aan deze kaart voor gaming dan heeft hij het enkel aan zichzelf te wijten, zelfs Raja Koduri heeft gamers gewaarschuwd niet deze kaart te kopen.

Gelunox schreef op donderdag 20 juli 2017 @ 01:23:
[...]


Als je even verder kijkt zie je dat hij speculeert dat dat misschien komt omdat er een 1070 ipv 1080 in het nV systeem zit.

Hij geeft een lijst met mogelijke verklaringen = analyseren

[ Voor 23% gewijzigd door Verwijderd op 20-07-2017 16:11 ]

[Verwijderd]

-

[ Voor 100% gewijzigd door Verwijderd op 20-07-2017 16:10 ]

[D0gtag]

418O2 schreef op donderdag 20 juli 2017 @ 14:42:
[...]

wel met 2Gb VRAM ingeschakeld, worth noting

Ze hebben nog geen titels die 8GB gebruiken meesten gebruiken niet eens 4gb vandaar dat ze deze test hebben gedaan.
Stel je voor dat je al deze sprites moet inladen van wolfenstein in je vram.

[haarbal]

D0gtag schreef op donderdag 20 juli 2017 @ 15:34:
Niet als HBCC een apart logic gedeelte heeft op de/een chip, dus hardware matig tussen gpu en hmb. HBCC is niet software matig en ik zie niet in waarom het performance zou moeten beperken. Wat AMD ook al heeft laten zien in tests. (altijd eerst zien dan geloven, maar toch)

wat ze hebben laten zien is dit filmpje
YouTube: AMD Radeon RX Vega HBCC High Bandwith Cache Controller

50% betere fps en 2x zo hoge minimum fps vergeleken met het systeem dat met het normale mechanismen het probleem van te weinig vram op moet lossen. Maar als je je bedenkt hoe hard fps meestal inzakt als je je ram als vram moet gaan aanspreken blijft het slechte performance.

Maar wel een goeie feature als het toch gebeurt.

[Verwijderd]

JulianI-Intel schreef op donderdag 20 juli 2017 @ 14:33:
Slecht nieuws http://www.finanzen.nl/va...n-week-geleden-1002185769

Ik geef het tot de 3de week van augustus vooraleer dat volledig is geïmplodeerd.

[D0gtag]

haarbal schreef op donderdag 20 juli 2017 @ 16:40:
[...]

wat ze hebben laten zien is dit filmpje
YouTube: AMD Radeon RX Vega HBCC High Bandwith Cache Controller

50% betere fps en 2x zo hoge minimum fps vergeleken met het systeem dat met het normale mechanismen het probleem van te weinig vram op moet lossen. Maar als je je bedenkt hoe hard fps meestal inzakt als je je ram als vram moet gaan aanspreken blijft het slechte performance.

Maar wel een goeie feature als het toch gebeurt.

Met HBCC wordt er niet gebruik gemaakt van systeem ram, maar blijft alles in vram.
HBCC comprimeert de data stroom zodat de zelfde data de helft van de ruimte inneemt. Dus in het geval van vega, als een programma of game 10GB nodig heeft HBCC ervoor zorgt dat slechts 5GB vram aangesproken hoeft te worden en pas bij 16GB de volledige 8GB vol komt.
Wat mij alleen nog niet duidelijk is, wat de performance gains zijn zonder dat je bij je maximum komt.
Dus bij 4GB vram gebruik of dit dan (gecomprimeerd door HBCC) sneller verwerkt word omdat je in feite ook de praktische bandbreedte verdubbeld.
HMB2 kan iets van 500GB/s doen,
zonder HBCC 4GB@ 500GB/s,
met HBCC 4GB -effectief@ 1000GB/s. (2GB is met 500GB/s 2x sneller weg geschreven)
Of ik heb dat gemist.

winwiz schreef op donderdag 20 juli 2017 @ 08:22:
Leuk hoe opvattingen/meningen in korte tijd kunnen veranderen net hou het uitkomt... Bijna voor de deur is dus begin 2018

Dat heeft wat uitleg nodig,
'opvattingen/meningen in korte tijd kunnen veranderen net hou het uitkomt' vertel vertel, liefst met quotes

[ Voor 12% gewijzigd door D0gtag op 20-07-2017 18:43 ]

[Xtrafris]

Nouja, bandbreedte is in praktijk de hoeveelheid data die je per seconde kan lezen en/of schrijven. Als je een compressiestap moet maken in beide richtingen, vertraagt dat natuurlijk het proces. Als ze instant, lossless compression voor elkaar hadden gekregen denk ik niet dat ze het hiervoor gaan gebruiken. Zie ook: Pied Piper

[D0gtag]

Xtrafris schreef op donderdag 20 juli 2017 @ 18:47:
Nouja, bandbreedte is in praktijk de hoeveelheid data die je per seconde kan lezen en/of schrijven. Als je een compressiestap moet maken in beide richtingen, vertraagt dat natuurlijk het proces. Als ze instant, lossless compression voor elkaar hadden gekregen denk ik niet dat ze het hiervoor gaan gebruiken. Zie ook: Pied Piper

Natuurlijk maar de vraag is of de vertraging in compressie groter of kleiner is dan de tijd die het kost om de extra date weg te schrijven.

[Xtrafris]

Tsja, zonder echt in de materie te duiken kan ik daar niks zinnigs over zeggen natuurlijk, maar het lijkt me sneller om t gewoon weg te schrijven.

[418O2]

Xtrafris schreef op donderdag 20 juli 2017 @ 19:06:
Tsja, zonder echt in de materie te duiken kan ik daar niks zinnigs over zeggen natuurlijk, maar het lijkt me sneller om t gewoon weg te schrijven.

Als het goed te compresseren is en je ook hardware matig goed hebt geregeld valt de overhead wel mee denk ik

[winwiz]

D0gtag schreef op donderdag 20 juli 2017 @ 18:31:
[...]

...

[...]

Dat heeft wat uitleg nodig,
'opvattingen/meningen in korte tijd kunnen veranderen net hou het uitkomt' vertel vertel, liefst met quotes

Dit is naar aanleiding van jouw opmerkingen net boven die van mij. Quotes lijken me niet nodig.

[edward2]

418O2 schreef op donderdag 20 juli 2017 @ 19:07:
[...]

Als het goed te compresseren is en je ook hardware matig goed hebt geregeld valt de overhead wel mee denk ik

Ik weet niet of zo'n scenario mogelijk is, maar stel je kan iets wat anders veel rekenkracht kost, eerst comprimeren, of gecomprimeerd berekenen en zodoende ondanks dat er gecomprimeerd en gedecomprimeerd moeten worden, netto toch winst (in perf.) boeken?

[Toettoetdaan]

edward2 schreef op donderdag 20 juli 2017 @ 21:34:
[...]


Ik weet niet of zo'n scenario mogelijk is, maar stel je kan iets wat anders veel rekenkracht kost, eerst comprimeren, of gecomprimeerd berekenen en zodoende ondanks dat er gecomprimeerd en gedecomprimeerd moeten worden, netto toch winst (in perf.) boeken?

De berekening blijft natuurlijk even zwaar, maar het verplaatsen van data kost energie en dat bespaar je dus daarvan kan de turbo weer wat omhoog

[DaniëlWW2]

Je kan ook even die laatste anderhalve week rustig afwachten.
Er gaat waarschijnlijk niks bijzonders meer lekken. Er zal onzinnige marketing onzin verspreid worden. Ook zal er heel veel stupid worden verspreid door zowel "AMD fanboys" als "Nvidiots" maar uiteindelijk telt alleen de prestaties en hoeveel het kost. Weet alleen een kleine kring binnen AMD en dat gaat nier zomaar lekken.

* DaniëlWW2 is ook al afgestapt van de hype train bij het RX580 station.

[Sp3ci3s8472]

D0gtag schreef op donderdag 20 juli 2017 @ 18:31:
[...]

Met HBCC wordt er niet gebruik gemaakt van systeem ram, maar blijft alles in vram.

Nee, gewoon helemaal fout.

Lees dit eens:
https://www.pcper.com/rev...igned-Memory-Architecture
https://www.reddit.com/r/...s/5wqcrs/hbcc_what_is_it/
Of bekijk de slides van AMD eens.

Wat de high bandwith cache controller doet is het "fine grained" data van a naar b verplaatsen zo efficent mogelijk om ervoor te zorgen dat de data op de goede plaats staat op het moment dat jij het nodig hebt.
Voor consumer kaarten zou dit ram kunnen zijn maar voor professionele applicaties zoals video bewerken kan dit een NVME SSD zijn zodat er tot 512TB kan worden aangesproken.

Mijn simplistische uitleg zal niet 100% correct zijn dus lees daarom ook de link die ik geef.


Hoewel er wellicht ook datacompressie plaats vind is dat niet het punt van de HBCC.



Wat jij bedoelt is wellicht de HBC oftewel de high bandwith cache, wat in feite gewoon een hernoeming is van de framebuffer.

Quote van Raja

Raja Koduri – Chief Architect Radeon Technologies Group, AMD With regards to the High Bandwidth Cache from a gaming perspective. We looked at all the modern games, the big games that push memory hard, and one of the things we noticed is the VRAM – graphics memory – utilization. We look at how much of the VRAM that the game allocates. So if the game say needs 4GB of memory when we looked at actually how much of that memory is actually used to render pixels we found that many games, actually most games, don’t use more than 50% of what they allocate. That’s because the current/old GPU architecture doesn’t give you flexibility to move memory in fine granularity. So with Vega and with the High Bandwidth Cache and the HBC controller, for games it will utilize the amount of frame-buffer you have much more efficiently. So effectively you can think of it as Vega will be doubling your memory capacity for games.

Dus ze zorgen ervoor dat een spel minder geheugen alloceerd en de HBCC gebruikt dat vervolgens om hier slim textures in te zetten zodat dit snel beschikbaar is indien nodig.

Meer bandbreedte door compressie is iets wat al veel langer wordt gebruikt door zowel AMD als Nvidia, bij AMD heet het Delta Color Compression (was een selling point van de R9 285).

Nog een leuk punt is dat de compressie van bijvoorbeeld textures echt niet veel beter wordt. Dit is al heel efficient en wordt gedaan op het moment dat een texture wordt opgeslagen. Videokaart zijn gigantisch snel met het inladen van zulke data en het decomprimeren op het moment dat het nodig is.
Alleen bij games waar de textures op ultra staan en waar dat betekent dat ze zonder compressie zijn is er misschien wat te winnen qua compressie, en dit moet nog altijd lossless compressie zijn dus er zit een limiet aan (denk aan Huffman coding of iets dergelijks). Doe je dit niet lossless dan krijg je de volgende rel waarin AMD of Nvidia cheat.

offtopic:
Waarom besteed ik hier energie aan...

[Sandwalker]

edward2 schreef op donderdag 20 juli 2017 @ 21:34:
[...]


Ik weet niet of zo'n scenario mogelijk is, maar stel je kan iets wat anders veel rekenkracht kost, eerst comprimeren, of gecomprimeerd berekenen en zodoende ondanks dat er gecomprimeerd en gedecomprimeerd moeten worden, netto toch winst (in perf.) boeken?

Dat kan. Je kunt rekenen met gecomprimeerde dataelementen of data kan getransformeerd worden (bijv. Fast Fourier Transformatie) naar een coordinatensysteem wat zich beter leent voor dataverwerking. Wat ik hier echter uit lees is dat men informatie alvast berekent op het moment dat er capaciteit is en die reeds berekende informatie beschikbaar stelt op het moment dat de beschikbare capaciteit onvoldoende is. Wat is niet snap is hoe alvast bekend kan zijn wat er in de toekomst op het scherm getoverd moet worden (of wat van een toekomstig beeld al bekend is, zodat dat in cache kan blijven). Vanuit mp4 compressie snap ik het, maar daar heb je de toekomstige info al beschikbaar. Maar hier zou de toekomst in principe door de speler bepaald moeten worden en mis ik die link.

[The Source]

Lol begon de 2de hands markt van mining kaarten net een beetje op gang te komen staat BTC weer tegen de 3000 usd. Als de alt coins ook corrigeren blijven veel mensen mijnen...

[ArcticWolf]

The Source schreef op vrijdag 21 juli 2017 @ 08:32:
Lol begon de 2de hands markt van mining kaarten net een beetje op gang te komen staat BTC weer tegen de 3000 usd. Als de alt coins ook corrigeren blijven veel mensen mijnen...

Ja, BIP91 heeft meer dan 91% support, dus BTC to the moon

Maar goed, de difficulty van ETH is nog steeds erg hoog... dus is het alsnog niet de moeite om te blijven minen.

[foppe-jan]

ArcticWolf schreef op vrijdag 21 juli 2017 @ 09:17:
Maar goed, de difficulty van ETH is nog steeds erg hoog... dus is het alsnog niet de moeite om te blijven minen.

De markt is het met je oneens: https://etherscan.io/chart/hashrate

[DaniëlWW2]

The Source schreef op vrijdag 21 juli 2017 @ 08:32:
Lol begon de 2de hands markt van mining kaarten net een beetje op gang te komen staat BTC weer tegen de 3000 usd. Als de alt coins ook corrigeren blijven veel mensen mijnen...

Nou, zorg ervoor dat ze geen nieuwe kaarten kunnen bemachtigen.
Aan de andere kant, als de hype nu weer opleeft en Vega blijkt toch niet te zuigen, dan verkoop ik mijn gloednieuwe RX580 wel met een mooie winst en upgrade ik. Zijn er toch tweedehands kaarten beschikbaar.

[The Source]

DaniëlWW2 schreef op vrijdag 21 juli 2017 @ 10:23:
[...]


Nou, zorg ervoor dat ze geen nieuwe kaarten kunnen bemachtigen.

Wat bedoel je?

[DaniëlWW2]

The Source schreef op vrijdag 21 juli 2017 @ 10:25:
[...]

Wat bedoel je?

Afsnijden van leveringen zodat de hype afsterft. Koers volledig weg laten zakken. Dan voorraad distribueren voor de niet miners. Gaat natuurlijk niet gebeuren maar was leuk geweest.

[D0gtag]

Sp3ci3s8472 schreef op vrijdag 21 juli 2017 @ 01:46:
[...]


Nee, gewoon helemaal fout.
Heel BS verhaal:

offtopic:
Waarom besteed ik hier energie aan...

*knip* dit kan ook anders

haarbal schreef op donderdag 20 juli 2017 @ 16:40:
[...]

wat ze hebben laten zien is dit filmpje
YouTube: AMD Radeon RX Vega HBCC High Bandwith Cache Controller

50% betere fps en 2x zo hoge minimum fps vergeleken met het systeem dat met het normale mechanismen het probleem van te weinig vram op moet lossen. Maar als je je bedenkt hoe hard fps meestal inzakt als je je ram als vram moet gaan aanspreken blijft het slechte performance.

Maar wel een goeie feature als het toch gebeurt.

Zie je wat er staat:

Maar als je je bedenkt hoe hard fps meestal inzakt als je je ram als vram moet gaan aanspreken blijft het slechte performance.

Zie je waar het over gaat, Swappen en HBCC is bedoeld om swappen tussen VRAM en RAM te voorkopen om zo smooth framerates te houden. Dit willen ze dus voorkomen:

Maar als je je bedenkt hoe hard fps meestal inzakt als je je ram als vram moet gaan aanspreken

D0gtag schreef op donderdag 20 juli 2017 @ 18:31:
[...]

Met HBCC wordt er niet gebruik gemaakt van systeem ram, maar blijft alles in vram.
..

Nogmaals snap je nu wel waar dit over gaat, Sherlock, HBCC houdt alles in VRAM betekent in deze context dat het swappen voorkomt. Ik zeg niet HBCC heeft geen enkele connectie met RAM ..
Context, begrijpend lezen, leer het eens.
HBCC is niks anders dan compressie, want het haalt de onnodige data weg, en het kost nog steeds rekenkracht om dit te bewerkstelligen. MP3 (of jpg), ooit van gehoord? enige wat mp3 doet is simpel gezegd de onhoorbare delen weglaten, zie je de overeenkomst: HBCC laat de onzichtbare/niet te renderen delen achterwege. Simpele vergelijking zelf bedacht, niet van reddit.

Dit is al de tweede keer dat je antwoord geeft zonder te lezen, no shit Sherlock dat het wel ram gebruikt.
No shit Sherlock dat nV en AMD al aan compressie deden (zie hier)
Serieus je loopt alles te herkauwen van reddit en doet hier alsof je de messias bent. Je lees één post en negeert de rest.

LEZEN, CONTEXT en bespaar mij de moeite met je 'laat ik eens zien hoe interessant ik ben' verhalen.

winwiz schreef op donderdag 20 juli 2017 @ 20:41:
[...]


Dit is naar aanleiding van jouw opmerkingen net boven die van mij. Quotes lijken me niet nodig.

Really.. ging het daar over
Mijn vraag was niet waar jij daar antwoord op gaf.....

winwiz schreef op donderdag 20 juli 2017 @ 08:22:
Leuk hoe opvattingen/meningen in korte tijd kunnen veranderen net hou het uitkomt... Bijna voor de deur is dus begin 2018

'Leuk hoe opvattingen/meningen in korte tijd kunnen veranderen net hou het uitkomt.'
Aangezien jij al terecht opmerkte dat het over de opmerking erboven ging... die van mij was.
Was mijn vraag, hoe is mijn opvatting mening veranderd en hoe komt het mij beter uit.
Met quotes. Dat was mijn vraag....

offtopic:
Familie van Sp3ci3s8472?

[ Voor 14% gewijzigd door br00ky op 25-07-2017 08:04 ]

[Temujin]

DaniëlWW2 schreef op vrijdag 21 juli 2017 @ 10:23:
[...]


Nou, zorg ervoor dat ze geen nieuwe kaarten kunnen bemachtigen.
Aan de andere kant, als de hype nu weer opleeft en Vega blijkt toch niet te zuigen, dan verkoop ik mijn gloednieuwe RX580 wel met een mooie winst en upgrade ik. Zijn er toch tweedehands kaarten beschikbaar.

Dan ga je ervanuit dat Vega niet net zo goed door de miners word opgeslokt.

[DaniëlWW2]

Temujin schreef op vrijdag 21 juli 2017 @ 10:34:
[...]


Dan ga je ervanuit dat Vega niet net zo goed door de miners word opgeslokt.

Voor zover ik weet draait ETH mining nog steeds slecht op HBM(2). Verder zal de powerdraw, zelfs als die beter is beheerst, ook niet gaan helpen.

[Lord_Dain]

Toch hoop ik dat ik mijn Corsair RM550x voeding VEGA kan draaien in mijn systeem i.c.m. een i7 6700K. Zou jammer zijn als ik ook nog moet investeren in een nieuwe voeding straks.

[Sandwalker]

Lord_Dain schreef op vrijdag 21 juli 2017 @ 10:38:
Toch hoop ik dat ik mijn Corsair RM550x voeding VEGA kan draaien in mijn systeem i.c.m. een i7 6700K. Zou jammer zijn als ik ook nog moet investeren in een nieuwe voeding straks.

Dat is hetzelfde waar ik mee zit. Ik moet sowieso een nieuwe voeding kopen, maar die 450W die ik op het oog had gaat het niet worden. Of 550W genoeg is, dacht ik eerst van wel, maar met tot 400W powerdraw van de videokaart weet ik het zo net nog niet.

[Sp3ci3s8472]

D0gtag schreef op vrijdag 21 juli 2017 @ 10:32:
[...]

Omdat je nog steeds niet kan lezen: Volgende keer, gewoon niet antwoorden is beter voor iedereen.

[...]

Zie je wat er staat:

[...]

Zie je waar het over gaat, Swappen en HBCC is bedoeld om swappen tussen VRAM en RAM te voorkopen om zo smooth framerates te houden. Dit willen ze dus voorkomen:

[...]


[...]

Nogmaals snap je nu wel waar dit over gaat, Sherlock, HBCC houdt alles in VRAM betekent in deze context dat het swappen voorkomt. Ik zeg niet HBCC heeft geen enkele connectie met RAM ..
Context, begrijpend lezen, leer het eens.
HBCC is niks anders dan compressie, want het haalt de onnodige data weg, en het kost nog steeds rekenkracht om dit te bewerkstelligen. MP3 (of jpg), ooit van gehoord? enige wat mp3 doet is simpel gezegd de onhoorbare delen weglaten, zie je de overeenkomst: HBCC laat de onzichtbare/niet te renderen delen achterwege. Simpele vergelijking zelf bedacht, niet van reddit.

Dit is al de tweede keer dat je antwoord geeft zonder te lezen, no shit Sherlock dat het wel ram gebruikt.
No shit Sherlock dat nV en AMD al aan compressie deden (zie hier)
Serieus je loopt alles te herkauwen van reddit en doet hier alsof je de messias bent. Je lees één post en negeert de rest.

LEZEN, CONTEXT en bespaar mij de moeite met je 'laat ik eens zien hoe interessant ik ben' verhalen.

Lees je in over texture formaten en dan snap je waarom er niet (veel) verder kan worden gecomporimeerd op dat punt. Game developpers comprimeren textures al, en die hoeven niet nog eens worden uitgepakt.

GPU compressed texture formats like DXT / BC / ETC are specifically designed to be read directly from their compressed form. They don't need to be unpacked into a raw RGBA buffer.

https://gamedev.stackexch...u-handle-texture-and-vram
http://www.reedbeta.com/b...ture-compression-formats/

Ze gaan never nooit niet jpeg of mp3 als compressie gebruiken op de videokaart (dus zelf comprimeren, ipv de spelontwikkelaar) , laten we vooral lossy compressie toepassen zodat alle data ineens verpest is als we het weer nodig hebben. Daarom gaf ik als voorbeeld Huffman coding wat lossless compressie geeft.
De HBCC managed het geheugen beter, het zorgt er voor dat wat de games nu alloceren en niet nodig is wordt gebruikt door de HBCC om dingen alvast in te laden.
Tenzij AMD een wonder heeft verricht is er niet een magische compressie methode de ineen keer 50% reductie geeft in opslag van textures. Was die er wel dan was dit allang gebruikt door de verschillende game makers en ook andere industrieën. Had AMD meteen een patent op kunnen aanvragen en kunnen ze bij wijze van spreken stoppen met andere GPU's en CPU's en incashen op dat patent.

Met Delta Color compression waar jij naar linkte ook in je vorige post wordt het huidige frame gecomprimeerd zodat dit minder geheugen kost en minder geheugen bandbreedte om het van a naar b te verplaatsten. De naam komt van het feit dat als pixel 1 een bepaalde kleurwaarde heeft en degene daarnaast een vergelijkbare dan slaan ze alleen het verschil van die waarde op. Dat kost minder geheugen dan de volledige kleuren informatie van een pixel op te slaan bijvoorbeeld 255, 255, 255 en met delta color compression zou dit 60, 50, 100 kunnen zijn.

NVIDIA has utilized delta color compression for a number of years now. However the technology only came into greater prominence in the previous Maxwell 2 generation, when NVIDIA disclosed delta color compression’s existence and offered a basic overview of how it worked. As a reminder, delta color compression is a per-buffer/per-frame compression method that breaks down a frame into tiles, and then looks at the differences between neighboring pixels – their deltas. By utilizing a large pattern library, NVIDIA is able to try different patterns to describe these deltas in as few pixels as possible, ultimately conserving bandwidth throughout the GPU, not only reducing DRAM bandwidth needs, but also L2 bandwidth needs and texture unit bandwidth needs (in the case of reading back a compressed render target).

http://www.anandtech.com/...founders-edition-review/8

Er wordt nog steeds dingen die in het geheugen staan geswapped, alleen wordt dat slimmer gedaan, ik mag hopen dat er juist meer geswapped wordt, textures die niet worden gebruikt van vram -> ram.

Memory swapping is a memory reclamation method wherein memory contents not currently in use are swapped to a disk to make the memory available for other applications or processes. The exact state or "page" of memory is copied to the disk to make the data contiguous and easy to restore later.

[ Voor 0% gewijzigd door Sp3ci3s8472 op 21-07-2017 11:31 . Reden: zelf comprimeren vs ontwikkelaar ]

[Toettoetdaan]

Jongens, de emoties lopen erg hoog op zullen we even herkalibreren?

Ik heb trouwens al een tijd niets gehoord over TressFX terwijl v4 al drie maanden uit is (originle Vega release date?) ze zullen het wel aanhalen op de Vega presentatie denk ik.

Sandwalker schreef op vrijdag 21 juli 2017 @ 11:11:
[...]

Dat is hetzelfde waar ik mee zit. Ik moet sowieso een nieuwe voeding kopen, maar die 450W die ik op het oog had gaat het niet worden. Of 550W genoeg is, dacht ik eerst van wel, maar met tot 400W powerdraw van de videokaart weet ik het zo net nog niet.

Er zal vast niet één Vega RX zijn, hopelijk is er ook een met een beschaaft verbruik

[nLr]

Toettoetdaan schreef op vrijdag 21 juli 2017 @ 11:24:
Jongens, de emoties lopen erg hoog op zullen we even herkalibreren?

Ik heb trouwens al een tijd niets gehoord over TressFX terwijl v4 al drie maanden uit is (originle Vega release date?) ze zullen het wel aanhalen op de Vega presentatie denk ik.


[...]

Er zal vast niet één Vega RX zijn, hopelijk is er ook een met een beschaaft verbruik

Dat zal dan ten koste gaan van de prestaties neem ik aan

Ook ik ben erg benieuwd, met mijn 650x ga ik er wel vanuit dat het voldoende is maar neem dit wel mee in de overweging. Dat en de voortekenen heeft me nu al wel doen kijken naar een alternatief haha, een 1080Ti denk ik...

Nog weekje geduld hebben boisss

[D0gtag]

Sp3ci3s8472 schreef op vrijdag 21 juli 2017 @ 11:15:
[...]


Lees je in over texture formaten en dan snap je waarom er niet (veel) verder kan worden gecomporimeerd op dat punt. Game developpers comprimeren textures al, en die hoeven niet nog eens worden uitgepakt.

[...]

https://gamedev.stackexch...u-handle-texture-and-vram
http://www.reedbeta.com/b...ture-compression-formats/

Ze gaan never nooit niet jpeg of mp3 als compressie gebruiken op de videokaart (dus zelf comprimeren, ipv de spelontwikkelaar) , laten we vooral lossy compressie toepassen zodat alle data ineens verpest is als we het weer nodig hebben. Daarom gaf ik als voorbeeld Huffman coding wat lossless compressie geeft.
De HBCC managed het geheugen beter, het zorgt er voor dat wat de games nu alloceren en niet nodig is wordt gebruikt door de HBCC om dingen alvast in te laden.
Tenzij AMD een wonder heeft verricht is er niet een magische compressie methode de ineen keer 50% reductie geeft in opslag van textures. Was die er wel dan was dit allang gebruikt door de verschillende game makers en ook andere industrieën. Had AMD meteen een patent op kunnen aanvragen en kunnen ze bij wijze van spreken stoppen met andere GPU's en CPU's en incashen op dat patent.

Met Delta Color compression waar jij naar linkte ook in je vorige post wordt het huidige frame gecomprimeerd zodat dit minder geheugen kost en minder geheugen bandbreedte om het van a naar b te verplaatsten. De naam komt van het feit dat als pixel 1 een bepaalde kleurwaarde heeft en degene daarnaast een vergelijkbare dan slaan ze alleen het verschil van die waarde op. Dat kost minder geheugen dan de volledige kleuren informatie van een pixel op te slaan bijvoorbeeld 255, 255, 255 en met delta color compression zou dit 60, 50, 100 kunnen zijn.

[...]

http://www.anandtech.com/...founders-edition-review/8

Er wordt nog steeds dingen die in het geheugen staan geswapped, alleen wordt dat slimmer gedaan, ik mag hopen dat er juist meer geswapped wordt, textures die niet worden gebruikt van vram -> ram.

[...]

*knip* dit kan ook anders.

[ Voor 1% gewijzigd door br00ky op 25-07-2017 08:02 ]

[D0gtag]

Lord_Dain schreef op vrijdag 21 juli 2017 @ 10:38:
Toch hoop ik dat ik mijn Corsair RM550x voeding VEGA kan draaien in mijn systeem i.c.m. een i7 6700K. Zou jammer zijn als ik ook nog moet investeren in een nieuwe voeding straks.

550 zal je het wel meer redden, 275 gpu max en 130 systeem max. geeft ~400watt max. Ga je de cpu OC'en heb je alsnog genoeg ruimte. 150watt om mee te spelen.

[Damic]

* Damic is #SadPanda, Vega FE wilt niet meespelen met Fury's

[Sp3ci3s8472]

Damic schreef op vrijdag 21 juli 2017 @ 13:02:
* Damic is #SadPanda, Vega FE wilt niet meespelen met Fury's

Als in crossfire, of gewoon de kaarten naast elkaar.

[Damic]

Samen in 1 systeem, drivers pro vs gaming doen ambetant.

[Sp3ci3s8472]

Is waarschijnlijk ook lastig, de ene kaart is een pro kaart de ander niet. Was makelijker als de ene kaart een Intel Fury X was .


Nog domweg terugkomend op de context van dit stukje?

Met HBCC wordt er niet gebruik gemaakt van systeem ram, maar blijft alles in vram.

Zelfs in de context van gaming zal dat niet mogelijk zijn, de HBCC zal wellicht een poging doen. De kracht van de HBCC is juist dat ze alle medium voor data opslag zo kunnen aanspreken dat jij niet doorhebt dat er dingen verplaatst worden. Dat linkte ik in mijn vorige post.
Dus graag een bron die benadrukt wat jij stelt, vind jij die dan wil ik best een fout erkennen.

HBCC comprimeert de data stroom zodat de zelfde data de helft van de ruimte inneemt. Dus in het geval van vega, als een programma of game 10GB nodig heeft HBCC ervoor zorgt dat slechts 5GB vram aangesproken hoeft te worden en pas bij 16GB de volledige 8GB vol komt.

Hoe moet ik dit in context zetten? Heb je enige bron waarin wordt verteld dat er zoveel compressie is dat ze het dubbele kunnen opslaan?
Als AMD op deze manier compressie kan uitvoeren op al gecomprimeerde textures dan kloppen Google en Netflix bij ze aan en betalen ze daar miljarden voor.

Je kan het wel steeds over context hebben maar als je alle dingen die ik post inclusief bronnen die bepaalde dingen ontkrachten straal negeert dan is een normale discussie voeren niet mogelijk.
Als je een voorbeeld geeft over compressie, pak dan een goed voorbeeld inplaats van mp3 of jpeg. Dat is in de context van het verhaal juist niet de vorm compressie die je wilt toepassen.

Serieus je loopt alles te herkauwen van reddit en doet hier alsof je de messias bent. Je lees één post en negeert de rest.

Als jij het naar NL vertalen van (en dus herkauwen) van wat er op reddit en pcperspective staat messias werkt vind dan ga je gang, wat heb ik er bij te winnen om hier de messias uit te hangen? Dat doe jij al.....
De bron op reddit is een quote van Raja en als er iemand weet hoe het zit dan is hij het. Hetzelfde geld voor de bron pcperspective, Ryan Shrout weet het gewoon beter dan jij of ik, feit.
Ik vind het herkauwen van bronnen beter dan gebakken lucht verkondigen.

[ Voor 16% gewijzigd door Sp3ci3s8472 op 21-07-2017 14:58 ]

[sjekneck]

D0gtag schreef op vrijdag 21 juli 2017 @ 12:34:
[...]

550 zal je het wel meer redden, 275 gpu max en 130 systeem max. geeft ~400watt max. Ga je de cpu OC'en heb je alsnog genoeg ruimte. 150watt om mee te spelen.

Ik denk dat je rustig 450 watt mag rekenen voor een heel systeem onder load met Vega. Minder dan een 550 watt voeding lijkt me een dikke 'no go'. Test benchmarks zijn vaak ook verder kaal, dus geen extra schijven, drives en andere eventuele insteekkaarten/toebehoren.

550 watt als minimum aanhouden mits vega niet meer zuipt dan een 300watt en je niet gaat OC'en op CPU en GPU lijkt een een veilige grens.

[D0gtag]

sjekneck schreef op vrijdag 21 juli 2017 @ 14:14:
[...]

Ik denk dat je rustig 450 watt mag rekenen voor een heel systeem onder load met Vega. Minder dan een 550 watt voeding lijkt me een dikke 'no go'. Test benchmarks zijn vaak ook verder kaal, dus geen extra schijven, drives en andere eventuele insteekkaarten/toebehoren.

550 watt als minimum aanhouden mits vega niet meer zuipt dan een 300watt en je niet gaat OC'en op CPU en GPU lijkt een een veilige grens.

Drives (oude HDD's) zitten op 10watt mag elk, moderne drives komen tot 4 of 5 watt, ssd's vaak minder dan een watt. Insteek kaarten kunnen max 75 watt gebruiken aangezien dat het enige is wat een pci slot kan leveren. Maar het punt is, je kan redelijk makkelijk berekenen hoeveel stroom je nodig hebt aan de hand van je spullen. De berekening is redelijk makkelijk.
En je kan specifiek opzoeken wat je systeem trekt of je bent lui en je koopt gewoon een 800watt voeding

---

Vandaag is er een vega event is de US iemand meer info over?

Well according to friends going there the best thing were the two hostess ladies, so little was shown of the STUFF. As the articla states this was mostly a fake event, by the secrecy there it could have been RX 580 inside the AMD machine, nobody could tell as most games run were easy on the graphics card I was told.

Budapest event quote

[ Voor 16% gewijzigd door D0gtag op 21-07-2017 14:40 ]

[Verwijderd]

Lord_Dain schreef op vrijdag 21 juli 2017 @ 10:38:
Toch hoop ik dat ik mijn Corsair RM550x voeding VEGA kan draaien in mijn systeem i.c.m. een i7 6700K. Zou jammer zijn als ik ook nog moet investeren in een nieuwe voeding straks.

Ondervolt en dat komt wel goed, met een beetje geluk met een betere klokfrequentie (boost) en minder warmte.
Dat gezegd hebbende, ik kan me voorstellen dat een 650W voeding (dezelfde of een betere kwaliteit) wat prettiger is om andere redenen (efficiency, geluid fan), ik laat het aan Mask om hier eventueel over uit te wijden.

Sp3ci3s8472 schreef op vrijdag 21 juli 2017 @ 11:15:
Met Delta Color compression waar jij naar linkte ook in je vorige post wordt het huidige frame gecomprimeerd zodat dit minder geheugen kost en minder geheugen bandbreedte om het van a naar b te verplaatsten. De naam komt van het feit dat als pixel 1 een bepaalde kleurwaarde heeft en degene daarnaast een vergelijkbare dan slaan ze alleen het verschil van die waarde op. Dat kost minder geheugen dan de volledige kleuren informatie van een pixel op te slaan bijvoorbeeld 255, 255, 255 en met delta color compression zou dit 60, 50, 100 kunnen zijn.

Een bekende truc die ook bij PCM wordt gebruikt, bijvoorbeeld voor geluid. Er zijn veel frequenties maar alles zit in een beperkte band dus is het coderen van de verschillen efficiënter dan het voor elk signaal de frequentie opgeven. Het ligt voor de hand dat dit voor graphics bij spellen ook goed werkt aangezien je vlakken hebt waarbinnen de kleur weinig verschilt.

[ Voor 65% gewijzigd door Verwijderd op 21-07-2017 15:05 ]

[Slaut]

D0gtag schreef op vrijdag 21 juli 2017 @ 14:32:
[...]

Drives (oude HDD's) zitten op 10watt mag elk, moderne drives komen tot 4 of 5 watt, ssd's vaak minder dan een watt. Insteek kaarten kunnen max 75 watt gebruiken aangezien dat het enige is wat een pci slot kan leveren. Maar het punt is, je kan redelijk makkelijk berekenen hoeveel stroom je nodig hebt aan de hand van je spullen. De berekening is redelijk makkelijk.
[...]

Op pcpartpicker kun je een lijst van je systeem maken met verwacht verbruik, scheelt zelf weer werk.
Mijn systeem bijvorrbeeld: https://de.pcpartpicker.com/list/HRffjc
Voor Vega zal er nog geen TDP zijn, maar je kan iig berekenen hoeveel vermogen je over houdt zonder gpu.

[Fredi]

Sp3ci3s8472 schreef op vrijdag 21 juli 2017 @ 13:50:

[..]

Hoe moet ik dit in context zetten? Heb je enige bron waarin wordt verteld dat er zoveel compressie is dat ze het dubbele kunnen opslaan?
Als AMD op deze manier compressie kan uitvoeren op al gecomprimeerde textures dan kloppen Google en Netflix bij ze aan en betalen ze daar miljarden voor.

Je kan het wel steeds over context hebben maar als je alle dingen die ik post inclusief bronnen die bepaalde dingen ontkrachten straal negeert dan is een normale discussie voeren niet mogelijk.
Als je een voorbeeld geeft over compressie, pak dan een goed voorbeeld inplaats van mp3 of jpeg. Dat is in de context van het verhaal juist niet de vorm compressie die je wilt toepassen.

[...]

Het heeft niets te maken met compressie. Stel dat een game 4 GB vram alloceert dat zorgt de HBCC ervoor dat dit 2 GB wordt omdat van die 4 GB data 2 GB overbodig is. Ik weet niet meer juist waarom maar je kan het opzoeken.

@Verwijderd
Een 600W voeding heeft ook meestal 2 pci-e connectoren, een 500W maar een. Beter 30A door twee kabels jagen dan door een.

[ Voor 6% gewijzigd door Fredi op 21-07-2017 17:56 ]

[Sp3ci3s8472]

Dat probeer ik duidelijk te maken, HBCC heeft inderdaad niks te maken met compressie.

[madmaxnl]

Bereken hier je verbruik en dus benodigde voeding:
https://outervision.com/power-supply-calculator

[Damic]

madmaxnl schreef op vrijdag 21 juli 2017 @ 18:13:
Bereken hier je verbruik en dus benodigde voeding:
https://outervision.com/power-supply-calculator

Ik kom altijd uit op >9000

[BNieuwenhuizen]

Op AMD kaarten heb je 2 soorten compressie:

- statische compressie. Dit zijn standaard lossy formaten en over het algemeen leveren de spellen textures al in dit formaat aan. (Denk aan S3TC/DXT, ETC, ASTC)
- dynamische compressie. Dit komt in verschillende vormen, maar wat voor allen geldt is dat ze alleen bandbreedte besparen, geen geheugen. Dit komt omdat ze per blok van X bytes werken, maar de blokken niet dichter naar elkaar worden geschoven als ze gecomprimeerd kunnen worden. Dus als een blok gecomprimeerd is hoeven niet de volle X bytes uit het geheugen gehaald te worden, maar je reserveert er niet minder ruimte voor. (en de blokken zijn typisch 64-256 byte, dus gaat het ook niet helpen met paging, aangezien de pagesize 4KiB+ is)

Overigens kunnen plaatjes al een hele tijd gedeeltelijk in VRAM en gedeeltelijk in RAM zitten, iets waar games al gebruik van kunnen maken met sparse textures.

Wat nieuw is in Vega is dat de pagefault/segfault interrupts nu ook bruikbaar zijn om op eerste gebruik een stuk geheugen naar de GPU te kopieren. Dit maakt on-demand paging mogelijk en dat zou het geheugen gebruik significant kunnen reduceren, ten koste van het extra werk omdat het verplaatsen op een ongelegen moment en in stukken gebeurt natuurlijk.

Geen idee of HBCC slechts een marketing term is van AMDs implementatie van on-demand paging of dat er meer achter zit. (Alle diagrammen hebben dat extra blok, wat je niet voor de interrupts of een driver feature zou verwachtten, maar ik heb nog niks anders in de open-source driver gezien wat mogelijk te maken kan hebben met HBCC).

[Werelds]

D0gtag schreef op vrijdag 21 juli 2017 @ 10:32:
Nogmaals snap je nu wel waar dit over gaat, Sherlock, HBCC houdt alles in VRAM betekent in deze context dat het swappen voorkomt. Ik zeg niet HBCC heeft geen enkele connectie met RAM ..
Context, begrijpend lezen, leer het eens.

Het voorkomt swappen helemaal niet.

Het is niet zo dat als er 4 GB aan data geladen wordt dat dit in 2 GB VRAM gepropt wordt door middel van compressie.

Terwijl een GPU rendert gebruikt deze maar zelden alle data in het VRAM; en gooit deze ook data weg als ze gebruikt zijn en niet meer nodig zijn. De CPU heeft deze data over het algemeen ook opgeslagen in RAM als cache. Als de GPU vervolgens een stuk data nodig heeft dat niet in VRAM zit dan moet dat vanuit de driver en CPU eerst opgezocht worden waar dit in het RAM staat, uitgelezen worden en daarna via de PCI-e bus weer naar de GPU gestuurd worden (effectief dus weer één of meerdere draw calls).

Wat er met de HBCC (wat dus High Bandwidth Cache Controller is - dat laatste woord doet er toe) mogelijk wordt, is dat de die hele roundtrip bespaard wordt door de geheugen adressen tussen GPU en systeem synchroon te houden (coherence). De HBCC kan vervolgens direct* deze data uit lezen. Die hele 4 GB die niet in je 2 GB VRAM past staat wel al "geregistreerd" en kan ook gelezen worden alsof deze wél al in VRAM stond.

Daarom staat er op AMD's afbeelding ook heel duidelijk dat de HBCC verbonden kan zijn met System DRAM (je RAM dus), NV RAM (SSD) of zelfs network storage. Het hoe en wat daarachter hebben ze nog niet vrijgegeven en ik betwijfel of het voor consumenten verder gaat dan DRAM, maar het bespaart nog steeds een hele hoop latency en CPU cycles. Het idee is dat hoewel de GPU wellicht maar 16 GB geheugen heeft (wat voor veel HPC toepassing niet toereikend is) je nu ook de 128 GB RAM (of bijvoorbeeld een 2 TB SSD) van de server niet alleen met veel minder latency dan voorheen aan kan spreken, maar dat dit ook transparant gebeurt alsof het bij het VRAM hoort.

Wat nog veel belangrijker is, is dat de HBCC niet per se naar het VRAM hoeft te schrijven; deze kan schijnbaar direct naar rasterizers of caches schrijven, waardoor je al helemaal veel latency bespaart.

Met andere woorden, als een game dus 4 GB aan texture data heeft, maar dat niet allemaal nodig heeft wordt en je maar 2 GB VRAM hebt dan worden die 2 GB volgestouwd, de GPU doet wat werk, er komt weer 512 MB vrij en dan heb je ineens iets nodig uit die andere 2 GB aan data. Waar je voorheen de hele roundtrip naar CPU, driver, terug naar de GPU en dan nog eens write-latency naar VRAM had springt nu de HBCC er tussen. Die spreekt de bron cache aan (immers, het adres waar dit in het eigen geheugen gestaan zou hebben is nu coherent) en gooit dit wellicht meteen naar het L2 cache waardoor de GPU vrijwel meteen weer verder kan. Waar je eerst misschien 700ns verloor aan memory access en dergelijke is dat nu wellicht nog maar 100ns.

Bronnen hebben anderen en jijzelf al aangedragen. Het bovenstaande staat allemaal in de slides van AMD, posts van Raja of valt onder programmeer kennis.


Voor @BNieuwenhuizen: het is de verbinding naar andere delen van de GPU waar die controller voor bedoeld is. Het hoeft schijnbaar niet per se eerst naar VRAM. De volledige whitepaper zal met SIGGRAPH wel vrijgegeven worden, maar dat is hoe AMD het tot nu toe heeft besproken.

offtopic:
* In de werkelijkheid is het niet zo dat de GPU écht direct je geheugen chips aan spreekt, dat kan om allerlei redenen niet. Maar het zit er zo dicht bij als maar mogelijk is. In elk geval vele malen sneller dan de "normale" manier.

HBCC is niks anders dan compressie, want het haalt de onnodige data weg, en het kost nog steeds rekenkracht om dit te bewerkstelligen. MP3 (of jpg), ooit van gehoord? enige wat mp3 doet is simpel gezegd de onhoorbare delen weglaten, zie je de overeenkomst: HBCC laat de onzichtbare/niet te renderen delen achterwege. Simpele vergelijking zelf bedacht, niet van reddit.

Hè? Omissie === compressie?

Compressie betekent niet dat je onnodige data weg laat. Compressie betekent dat je data die meerdere keren voor komen slechts één keer op slaat, je laat deze echter niet weg - althans, bij lossless compressie. Bij lossy compressie is het ook eerder correct om te spreken van data samenvoegen dan data weg laten.

Het formaat waar die data in op werd geslagen bevat echter gegarandeerd metadata; wie het gemaakt heeft, in welk jaar, met welke software enzovoort. Dus terwijl er misschien 512 bytes zijn voor een afbeelding zelf, is er misschien 2 KB aan irrelevante data die je niet nodig hebt. Dat weg laten is geen compressie, dat is optimalisatie.

[ Voor 3% gewijzigd door Werelds op 21-07-2017 19:59 ]

[BNieuwenhuizen]

Werelds schreef op vrijdag 21 juli 2017 @ 19:53:
[...]

Het voorkomt swappen helemaal niet.

Het is niet zo dat als er 4 GB aan data geladen wordt dat dit in 2 GB VRAM gepropt wordt door middel van compressie.

Terwijl een GPU rendert gebruikt deze maar zelden alle data in het VRAM; en gooit deze ook data weg als ze gebruikt zijn en niet meer nodig zijn. De CPU heeft deze data over het algemeen ook opgeslagen in RAM als cache. Als de GPU vervolgens een stuk data nodig heeft dat niet in VRAM zit dan moet dat vanuit de driver en CPU eerst opgezocht worden waar dit in het RAM staat, uitgelezen worden en daarna via de PCI-e bus weer naar de GPU gestuurd worden (effectief dus weer één of meerdere draw calls).

Wat er met de HBCC (wat dus High Bandwidth Cache Controller is - dat laatste woord doet er toe) mogelijk wordt, is dat de die hele roundtrip bespaard wordt door de geheugen adressen tussen GPU en systeem synchroon te houden (coherence). De HBCC kan vervolgens direct* deze data uit lezen. Die hele 4 GB die niet in je 2 GB VRAM past staat wel al "geregistreerd" en kan ook gelezen worden alsof deze wél al in VRAM stond.

Daarom staat er op AMD's afbeelding ook heel duidelijk dat de HBCC verbonden kan zijn met System DRAM (je RAM dus), NV RAM (SSD) of zelfs network storage. Het hoe en wat daarachter hebben ze nog niet vrijgegeven en ik betwijfel of het voor consumenten verder gaat dan DRAM, maar het bespaart nog steeds een hele hoop latency en CPU cycles. Het idee is dat hoewel de GPU wellicht maar 16 GB geheugen heeft (wat voor veel HPC toepassing niet toereikend is) je nu ook de 128 GB RAM (of bijvoorbeeld een 2 TB SSD) van de server niet alleen met veel minder latency dan voorheen aan kan spreken, maar dat dit ook transparant gebeurt alsof het bij het VRAM hoort.

Wat nog veel belangrijker is, is dat de HBCC niet per se naar het VRAM hoeft te schrijven; deze kan schijnbaar direct naar rasterizers of caches schrijven, waardoor je al helemaal veel latency bespaart.

Maar dat kan met alle GCN GPUs al. Vrijwel niks hoeft perse in VRAM, zowel L2 als CB/DB caches kunnen systeem RAM (dat via de GTT beschikbaar is gemaakt) gebruiken zonder dat eerst naar VRAM te kopieren, en hier komt geen CPU aan te pas. Natuurlijk wel de gebruikelijke regels over dat PCI express langzamer is dan VRAM. De radeonsi drivers op linux gebruiken over het algemeen L2+CB om een texture te verplaatsen tussen RAM en VRAM (een kopie is gewoon een draw met je doeltexture als framebuffer).

Ook kan je expliciet van RAM naar L2 kopieren (via de CP DMA engine bijvoorbeeld), dus dat zou ook niet nieuw zijn.

De memory management onder linux werkt momenteel als volgt: de driver houdt voor elke batch drawcalls bij welke buffers (bevattende vertexdata, shaders, textures, framebuffer etc.) mogelijk benaderd worden en geeft naar soort gebruikt een prioriteit. Als die batch vervolgens naar de kernel gestuurd wordt, wordt die lijst met buffers meegestuurd en gaat de kernel proberen alle buffers in VRAM te krijgen, waarbij mogelijk ongebruikte buffers uit het VRAM gehaald worden. Pas nadat alle buffers verplaatst zijn wordt de batch naar de GPU gestuurd en tijdens het uitvoeren daarvan worden er geen buffers verplaatst (i.h.b zijn er dus geen roundtrips GPU->CPU->GPU nodig voor het verplaatsen).

Dat wachten op het verplaatsen is typish een groot deel van de onnodige stutter die je krijgt.

De reden dat ik dus niet echt zie wat HBCC nou zou moeten doen is omdat we dus al direct RAM kunnen gebruiken, dat niets nieuws zou zijn. En als HBCC automatisch RAM<->VRAM migraties zou doen zou dat betekenen dat de controller moet bijhouden welke delen van het RAM vrij zijn en welke gebruikt mogen worden, iets wat nogal een hoop controle uit handen van het OS haalt, zeker i.v.m. procesisolatie.

Dat gezegd hebbende heb ik ook niet veel naar talks en presentaties gekeken, dus ik kan wat ideeen over het hoofd zien

[Werelds]

BNieuwenhuizen schreef op vrijdag 21 juli 2017 @ 20:58:
Maar dat kan met alle GCN GPUs al. Vrijwel niks hoeft perse in VRAM, zowel L2 als CB/DB caches kunnen systeem RAM (dat via de GTT beschikbaar is gemaakt) gebruiken zonder dat eerst naar VRAM te kopieren, en hier komt geen CPU aan te pas. Natuurlijk wel de gebruikelijke regels over dat PCI express langzamer is dan VRAM. De radeonsi drivers op linux gebruiken over het algemeen L2+CB om een texture te verplaatsen tussen RAM en VRAM (een kopie is gewoon een draw met je doeltexture als framebuffer).

Ook kan je expliciet van RAM naar L2 kopieren (via de CP DMA engine bijvoorbeeld), dus dat zou ook niet nieuw zijn.

De memory management onder linux werkt momenteel als volgt: de driver houdt voor elke batch drawcalls bij welke buffers (bevattende vertexdata, shaders, textures, framebuffer etc.) mogelijk benaderd worden en geeft naar soort gebruikt een prioriteit. Als die batch vervolgens naar de kernel gestuurd wordt, wordt die lijst met buffers meegestuurd en gaat de kernel proberen alle buffers in VRAM te krijgen, waarbij mogelijk ongebruikte buffers uit het VRAM gehaald worden. Pas nadat alle buffers verplaatst zijn wordt de batch naar de GPU gestuurd en tijdens het uitvoeren daarvan worden er geen buffers verplaatst (i.h.b zijn er dus geen roundtrips GPU->CPU->GPU nodig voor het verplaatsen).

Dat wachten op het verplaatsen is typish een groot deel van de onnodige stutter die je krijgt.

De reden dat ik dus niet echt zie wat HBCC nou zou moeten doen is omdat we dus al direct RAM kunnen gebruiken, dat niets nieuws zou zijn. En als HBCC automatisch RAM<->VRAM migraties zou doen zou dat betekenen dat de controller moet bijhouden welke delen van het RAM vrij zijn en welke gebruikt mogen worden, iets wat nogal een hoop controle uit handen van het OS haalt, zeker i.v.m. procesisolatie.

Dat gezegd hebbende heb ik ook niet veel naar talks en presentaties gekeken, dus ik kan wat ideeen over het hoofd zien

Hmm vreemd. Ik heb de driver nooit echt bekeken, maar dat klinkt inderdaad erg veel als wat AMD tot nu toe over de HBCC heeft los gelaten. Ik wist ook niet dat dit allemaal al mocht met GCN, dat is leuke informatie

Wellicht komt het dan meer neer op het idee dat dit wellicht allemaal niet meer expliciet hoeft? Als je dat namelijk allemaal vanuit je engine moet doen betwijfel ik of je er iets bij wint, als je niet al tijd verliest. Zeker voor textures is de bandbreedte van GDDR of HBM in de meeste gevallen echt niet nodig.

Geheugen adressen zouden coherent zijn, dus ik denk dat er wel een beperking zit aan wat er aan de systeem kant gebruikt kan worden, maar ik ga er eigenlijk ook wel van uit dat dat gereserveerd zal worden.

SIGGRAPH binnenkort dus dan wordt het hopelijk allemaal duidelijk. Het is ook wel een feature die meer op HPC is gericht dan games, ook al is er in games ook winst te behalen doordat deze over het algemeen te veel in het geheugen stouwen.

[D0gtag]

Werelds schreef op vrijdag 21 juli 2017 @ 19:53:
[...]

Op het eerste deel:
Wat gebeurd er (traditioneel) als je 4GB ram hebt en 6GB moet inladen = 4GB vol 2GB komt in je ram.
Wat gebeurd er als je 4GB hebt en 6GB moet inladen en je hebt een HBCC, met de door jou beschreven technieken heeft hij slechts 3GB nodig en hou je dus 1GB over.
De manier hoe hij het doet is wat je beschrijft, de reden waarvoor hij het doet is om swapping te voorkomen in de traditionele zin.
Het resultaat hiervan is dat je geen systeem ram hoeft te gebruiken ten koste van performance.
Heb je 4GB maar je hebt 10GB nodig zal hij alsnog een deel gaan swappen met of zonder HBCC.
HBCC kan data direct naar de grafische processor sturen, dit alles om te voorkomen dat hij de langzamere methodes moet kiezen als ram of SSD want dat is zijn laatste keuze, kan je wel een directe verbinding hebben zit je nog steeds vast aan de pcie lane bottleneck en de tragere vram/ssd.
En HBCC is efficiënter, maar als de werkload groter wordt dan capaciteit: swapping. HBCC zorgt er alleen voor dat er meer ademruimte is. De GPU en VRAM kan maar zo veel hebben en ram en SSD blijven de zelfde beperkingen houden.

Ik snap werkelijk niet hoe je de werking kan opnoemen maar niet opnoemen wat het nou precies moet doen en voorkomen. (en waarom ze specifiek de framerates laten zien bij de test met HBCC)
Wat is de meest voorkomende reden van framedrops en stutter, nogmaals waarom denk je dat ze de FPS laten zien.

Het tweede deel:
Mp3 gebruikt een algoritme om bepaalde geluiden die b.v. overlappen of tonen die niet te horen zijn voor mensen weg te laten. Letterlijk verwijderen. Het heet daarom ook een lossy format. Als je een mp3 omzet naar wav wordt het nooit als het origineel, je verliest data.Je kan het samenvoegen noemen maar het is feitelijk verwijderen.

is the class of data encoding methods that uses inexact approximations and partial data discarding to represent the content.

Lossy compression reduces bits by removing unnecessary or less important information.[3]

Het zelfde met jpg, deze kijkt naar een waarde van een pixel en de omliggende waarden als deze binnen bepaalde parameters zitten stelt hij al die pixels gelijk (vandaar b.v. de banding in de lucht en de vlekken in zwaar gecomprimeerde jpg's). Dit is een manier van compressie die onomkeerbaar is.
Met jpg verlies je data. Het is geen samenvoeging van gelijke data het is een approximations van die data en voegt het samen. Het resultaat is het zelfde verwijderen van te veel informatie om een kleiner format te krijgen.
Als je een in RAW foto's schiet en dan naar jpg maakt kan je het zelf zien.
En kan je wel kinderachtig doen en zeggen: 'hé omissie is compression haha', nee, dat maak jij ervan. Omissie is de basis geweest van compressie en bij lossles is er inderdaad geen sprake van omissie.

"Raja Koduri – Chief Architect Radeon Technologies Group, AMD With regards to the High Bandwidth Cache from a gaming perspective. We looked at all the modern games, the big games that push memory hard, and one of the things we noticed is the VRAM – graphics memory – utilization. We look at how much of the VRAM that the game allocates. So if the game say needs 4GB of memory when we looked at actually how much of that memory is actually used to render pixels we found that many games, actually most games, don’t use more than 50% of what they allocate. That’s because the current/old GPU architecture doesn’t give you flexibility to move memory in fine granularity. So with Vega and with the High Bandwidth Cache and the HBC controller, for games it will utilize the amount of frame-buffer you have much more efficiently. So effectively you can think of it as Vega will be doubling your memory capacity for games.

HBCC -->give you flexibility to move memory in fine granularity, om te bepalen wat hij moet bewegen zit een algoritme of ander systeem wat de berekeningen maakt.
HBCC laat weg wat hij niet nodig heeft. het is geen compressie in de traditionele zin maar ze hebben beiden het zelfde uitgangs punt en resultaat. hoe krijg ik 2GB naar 1GB

The process of reducing the size of a data file is referred to as data compression.

[DaniëlWW2]

Ondertussen weer een thema van interesse voor RX Vega aangezien Vega FE met een geheugenbandbreedte bottleneck lijkt te zitten.

[SG]

My lijkt het eerder dat met DX12 en Vulkan je als dev zelf het Memory moet beheren en als dev weet je ook meer hoe de Engine en content dat gaat belasten. DX11 moet er aannames doen dus er blijft resources te lang bezet. Het lijkt mij belangrijk om drawcall te sorteren op resources gebruik. Bij gebruik van bepaalde set texturen als de fence vrijgegeven wordt na gebruik, kan de resource released worden en kan er dus wat anders ingeladen worden wat Command buffer 2 of 3 erna gaat gebruiken. Tijdens het laden is dus de volgende buffer in verwerking en door fence beschermt tegen te vroeg releasen.

in principe kan je dan meer texturen memory voor scene gebruiken maar is er wel nogal wat copy task over de PCIe bus.
Dan werkt het Vidram meer als grote cache dan werk geheugen.
Kan zijn dat die cache visie ipv Videomem heap beter aansluit bij video mem beheer van die nieuwste API.

Als dev regel je dus het optimaal prefetchen van texturen en andere resources . Het kan dan in beperkte mate om een complexe scene te renderen waar resource budget groter is dan Vidmem. Lukt dat prefecten niet.
Dan krijg je flinke stotters. Pipeline stalls ivm wachten op resources laden. PCIE 3,0 x 16 is dan wel aan te raden.

[Verwijderd]

madmaxnl schreef op vrijdag 21 juli 2017 @ 18:13:
Bereken hier je verbruik en dus benodigde voeding:
https://outervision.com/power-supply-calculator

Voor het totale vermogen is het handig, ik plaats wel wat vraagtekens bij de nauwkeurigheid van het gebruik, of dat er voldoende rekening wordt gehouden met het downclocken (automatisch), coreparking en zo.

[BNieuwenhuizen]

SG schreef op vrijdag 21 juli 2017 @ 23:08:
My lijkt het eerder dat met DX12 en Vulkan je als dev zelf het Memory moet beheren en als dev weet je ook meer hoe de Engine en content dat gaat belasten. DX11 moet er aannames doen dus er blijft resources te lang bezet. Het lijkt mij belangrijk om drawcall te sorteren op resources gebruik. Bij gebruik van bepaalde set texturen als de fence vrijgegeven wordt na gebruik, kan de resource released worden en kan er dus wat anders ingeladen worden wat Command buffer 2 of 3 erna gaat gebruiken. Tijdens het laden is dus de volgende buffer in verwerking en door fence beschermt tegen te vroeg releasen.

In de praktijk zul je zien dat als je binnen 1 frame dingen moet swappen (i.e. working set is groter dan VRAM) dan gaat dat heel erg ten koste van je performance. PCIe 3.0 x16 bandbreedte is 16 GiB/s, of ong 266 MiB/frame bij 60 fps. Op je typische VRAM grote is de hoeveelheid die je kan swappen minimaal.

Voor GPU-gegenereerde data zijn er idd wel wat mogelijkheden om met vulkan minder geheugen te gebruiken. i.e. als je in fase 1 van het renderen van een frame data genereert en gebruikt en daarna weggooit en in fase 2 ook, dan kunnen die hetzelfde geheugen gebruiken, waar dat met e.g. GL alleen werkte als je precies dezelfde texture gebruikte (i.e. ook geen formaat/grootte verschillen).

Waar een GPU wel veel mogelijkheden heeft is e.g. als als je alleen een object van veraf bekijkt om dan alleen de minder gedetailleerde miplevels te laden. Of als het game het hele level laadt, dan zijn de textures voor dingen die momenteel buiten beeldt zitten niet direct in VRAM nodig. Typisch zijn die dingen vrij constant over een paar seconden dus met caching met een flinke cache (e.g. als je het hele VRAM als cache ziet) zou dat kunnen helpen met VRAM gebruik.

[ Voor 0% gewijzigd door BNieuwenhuizen op 21-07-2017 23:27 . Reden: typo ]

[madmaxnl]

Je kan overclocks in de berekening meenemen, underclocks weet ik niet. Je kan zelf een belasting percentage voor je CPU opgeven.