:strip_icc():strip_exif()/u/19522/crop6124d729ee8a5_cropped.jpg?f=community)
When a man finds a conclusion agreeable, he accepts it without argument, but when he finds it disagreeable, he will bring against it all the forces of logic and reason
Ja jij wil tunen, want je bent een tweaker.
De gemiddelde plof-op-de-bank-en-speel gamer heeft geen zin om dat te doen voorbij "low / medium / high / ultra", en hoewel die meestal eerder een console dan een PC zullen hebben is dat natuurlijk ook waar de engines en de spellenbakkers zich grotendeels op richten. Het is dan ook allesbehalve onredelijk dat beeldkwaliteit inruilen voor speelbaarheid waarschijnlijk een goede default is, want als producent sla je een modderfiguur & word je in reviews genadeloos afgefakkeld als je spel 5 FPS haalt op defaults met de gemiddelde hardware. Er is zelfs iets voor te zeggen dat dat dan dynamisch gebeurt in plaats van bijvoorbeeld constant gewoon alle textures op low te forceren, want dan heb je in ieder geval soms nog een betere ervaring.Het zou inderdaad een goed idee zijn als er een schuifje was om dynamische frutselarij uit te zetten zodat eerlijke vergelijkingen mogelijk zijn. En valsspelen, tja. Voor benchmarks wel, maar je zult in de handleiding van je spel tevergeefs zoeken naar de "spelregels" van wat de instellingen precies doen, zodat je je moeilijk kunt beroepen op misleiding.
Wat zeg ik, spellen hebben al heel lang geen handleidingen meer.
Dat raakt kant noch wal. Niet "dat slaat kant noch wal". Wel "dat slaat als een tang op een varken".
Ik heb nog fantastische handleidingen van bijvoorbeeld flight sims uit het verleden, wat eigenlijk gewoon een studieboek was van hoe je moest vliegen en dogfighten. Tegenwoordig is het wat dat betreft wel treurig.:
[...]
Wat zeg ik, spellen hebben al heel lang geen handleidingen meer.
When a man finds a conclusion agreeable, he accepts it without argument, but when he finds it disagreeable, he will bring against it all the forces of logic and reason
:strip_exif()/u/211274/bestabstractwallpapers5.gif?f=community)
When a man finds a conclusion agreeable, he accepts it without argument, but when he finds it disagreeable, he will bring against it all the forces of logic and reason
When a man finds a conclusion agreeable, he accepts it without argument, but when he finds it disagreeable, he will bring against it all the forces of logic and reason
/u/400/defember100.png?f=community)
Micron Publishes Updated DRAM Roadmap: 32 Gb DDR5 DRAMs, GDDR7, HBMNext
[ Voor 73% gewijzigd door Help!!!! op 27-07-2023 18:05 ]
PC Specs
Asus ROG Strix B650E-E | AMD 7700X | G-Skill 32GB DDR5 6000C30 M-die | 4090 FE | LG 38GN950-B 3840*1600p 160Hz | Corsair RM1000x Shift | WD Black SN850X 1TB M.2
/u/226258/tweakersavatar.png?f=community){kind=avatar}
Jaren terug? Een maand geleden, bedoel je. Of de tool voor Ampere 2 jaar geleden. Meer is er nooit geweest. DP is bij Nvidia al sinds 2013 buggy (3 verschillende monitors op 4 verschillende Nvidia GPU's, met meerdere kabels). Ze waren laat met DP en hebben het nooit fatsoenlijk geïmplementeerd. Lijkt er op dat ze dat nu pas hebben gedaan. Nvidia en monitors is sowieso altijd een probleem geweest (DVI-I DL gaf 15 jaar geleden problemen; DVI-I SL en DVI-D SL+DL werkten zonder problemen; eerste HDMI implementaties hadden soortgelijke problemen dankzij hun non-standaard implementatie op GT200). En breek me de bek niet open over multi-monitor bij Nvidia
Met ADA is het probleem geloof ik opgelost want de update van een paar weken of maanden terug is voor oudere series. Storm in een glas water.:
[...]
Jaren terug? Een maand geleden, bedoel je. Of de tool voor Ampere 2 jaar geleden. Meer is er nooit geweest. DP is bij Nvidia al sinds 2013 buggy (3 verschillende monitors op 4 verschillende Nvidia GPU's, met meerdere kabels). Ze waren laat met DP en hebben het nooit fatsoenlijk geïmplementeerd. Lijkt er op dat ze dat nu pas hebben gedaan. Nvidia en monitors is sowieso altijd een probleem geweest (DVI-I DL gaf 15 jaar geleden problemen; DVI-I SL en DVI-D SL+DL werkten zonder problemen; eerste HDMI implementaties hadden soortgelijke problemen dankzij hun non-standaard implementatie op GT200). En breek me de bek niet open over multi-monitor bij Nvidia
:strip_icc():strip_exif()/u/145751/check-in-minion-small2.jpg?f=community)
Nee, de basis werkt over het algemeen wel. Maar doe iets dat verder dan simpel beeld + geluid op een enkel scherm gaat en je gaat gekke dingen zien. Multi monitor (zoals @Sp3ci3s8472 suggereert, iets waar ik pas pakweg een jaar vanaf ben gestapt, na bijna 20 jaar
) is altijd een probleem geweest bij Nvidia. En daar kun je zat over vinden. Maar het wordt erger als je DP + HDMI combineert met verschillende refreshrates. Je moet dan af en toe de DP monitor opnieuw insteken omdat hij hem niet meer "ziet"; en tijdens boot zal hij de HDMI monitor gebruiken...behalve op Kepler, waar het dan ook nog eens uit maakte wélke HDMI poort de monitor op zat, want de gedeelde poort werkte daarvoor dan weer niet. Daisy chainen is ook hartstikke buggy; maar werkt tenminste wel soort van, in tegenstelling tot Apple, die dat doodleuk simpelweg niet toestaan.Het is niet voor niets dat Nvidia hun DP implementatie pas met Kepler (2012 dus) mainstream maakten, ook al had zelfs Tesla (2007 of 2008 met de refresh) al kaarten met DP. Begrijp me niet verkeerd, ik zeg niet dat Nvidia giga veel problemen heeft met monitors of DP, maar de problemen bestaan wel en bestaan ook al heel lang én zijn te reproduceren. 90+% van de gebruikers zal er nooit tegen aan lopen omdat ze op een enkele 1080p60 monitor zitten via HDMI.
Bovenstaande zijn allemaal dingen waar ik met AMD nooit last van heb gehad. Nu heb ik niet veel AMD GPU's gehad. 5870, 6950 en daarna Nvidia tot m'n 6650 XT nu, dus ik weet niet hoe het in de tussentijd is geweest, maar met die eerste twee heb ik er toen zelfs 3 monitors aan gehangen om Eyefinity te proberen en dat werkte zonder problemen. 2 van die 3 monitors zijn tot vorig jaar ook in gebruik geweest
Overigens zou DP inderdaad dé standaard moeten zijn (technisch superieur op alle vlakken en royalty-free - het enige dat "mist" is CEC...), maar het is pas relatief recent (+- 5 jaar hooguit?) dat je het écht op veel monitors ziet en zelfs dan zijn er nog steeds high-end monitors die enkel met HDMI geleverd worden. Zie bijvoorbeeld de Neo G8 (non-OLED): 2xHDMI 2.1, that's it. Vreemd genoeg is het hopen op meer type-C waar mensen nu aan beginnen te wennen. Vooralsnog is HDMI nog steeds dé standaard en dat zal buiten monitors helaas ook nog lang zo blijven, dankzij de mafia daarachter (waar Samsung overigens bij hoort
). En daardoor zullen we het ook altijd op monitors zien en zal er soms voor gekozen worden om DP achterwege te laten.
:strip_icc():strip_exif()/u/86810/display.jpg?f=community)
i7 12700K,GB WindForce RTX4090,32GB KF436C16RB1K2/32,Gigabyte Z690 UD DDR4,Corsair RM1000x,WD Black SN850 2TB,Phanteks Eclipse P360A,Quest 3 VR Headset,Corsair iCUE H100i RGB Pro XT 240mm
:strip_icc():strip_exif()/u/218864/crop5db0c8ff43fff_cropped.jpeg?f=community)
When a man finds a conclusion agreeable, he accepts it without argument, but when he finds it disagreeable, he will bring against it all the forces of logic and reason
Ook daar heb je het doorgaans over identieke schermen en waarschijnlijk niet op DP
Ik denk dat je even goed naar de b's moet kijken
GDDR6 modules zijn nu beschikbaar in 16 Gb modules en GDDR7 wordt beschikbaar in 24 (en later 32) Gb modules. Punt daarbij is echter de kleine b: bits. 16 Gb = 2 GB, 24 Gb = 3 GB, 32 Gb = 4 GB.
Hoeveel geheugen je in totaal hebt heeft verder geen bal met die modules te maken, enkel met de geheugenbus. Een GDDR chip heeft een 32-bit interface, dus van 32 tot 512 bits kun je (zonder clamshelling) met 16 Gb modules tot 32 GB komen, waarbij elk veelvoud van 2 daar tussenin geldig is (omdat de modules 2 GB zijn).
Met 24 of 32 Gb modules is dat precies hetzelfde, echter heb je het dan over veelvouden van 3 of 4. 36 / 4 = 9 * 32 = 288-bits bus. Vreemd en onwaarschijnlijk, maar kan gewoon. 18 / 4 = 4,5 en gaat dus niet. Daarentegen is 18 / 2 = 9 * 32 = diezelfde 288-bits bus, maar dan zit je dus wel op 16 Gb modules, niet op 32 Gb. Maar dat kan nu dus ook al. En 36 kan nu ook al, met een 576-bits bus of clamshelling op 288. En met 24 Gb modules heb je het over 6 chips, dus een 192-bits bus
HBM is een heel ander verhaal.
Edit: die 11 GB van de 1080 Ti / 2080 Ti komt ook gewoon van de bus: 352-bit bus; 352 / 32 = 11 chips en de chips waren toen 8 Gb oftewel 1 GB dus dan kom je op 11 GB (of 22 met clamshell). De volledige controller op beide was 384-bit, dus 12/24 GB.
[ Voor 8% gewijzigd door Werelds op 01-08-2023 11:55 ]
Dat is juist (vrijwel) allemaal DP, schermen zijn uiteraard wel identiek in de meeste gevallen (al komt het bijvoorbeeld wel voor dat er 2 identieke schermen zijn en dan een 3de afwijkend in bijv. een portrait mode) juist HDMI wordt vrij weinig gebruikt zakelijk, dat is eigenlijk allemaal DP van het lagere segment tot de high end. Een boel van die systemen (HPE / Dell e.d.) hebben zelfs niet eens HDMI meer. 3 identieke Schermen is trouwens ook niet ongebruikelijk, allerlei combinaties zijn mogelijk.:
[...]
Ook daar heb je het doorgaans over identieke schermen en waarschijnlijk niet op DP
Het enige waar ik HDMI eigenlijk nog regelmatig gebruikt zie worden is laptops. Maar ook dat gaat in sneltrein vaart naar USB-C of naar USB-C Docking stations, waar dan meerdere DP poorten op zitten. Het zou mij weinig verbazen als HDMI zakelijk straks vrijwel alleen nog voor incidentele connecties gebruikt wordt.
Maar ook in privé, zie ik mijn omgeving ook steeds minder HDMI gebruikt worden in combinatie met de PC. Ik gebruik het zelf al jaren niet meer (2x DP) voor heen met Nvidia en nu met AMD. Beide trouwens geen issues. Maar ook wanneer ik een systeem bouw voor mensen is dat de laatste jaren eigenlijk altijd geplaatst met (meerdere) DP in gebruik en niet HDMI.
[ Voor 43% gewijzigd door Dennism op 01-08-2023 12:05 ]
Ja dat is precies het nieuws dat ik vertaal naar::
Ik denk dat je even goed naar de b's moet kijken
GDDR6 modules zijn nu beschikbaar in 16 Gb modules en GDDR7 wordt beschikbaar in 24 (en later 32) Gb modules. Punt daarbij is echter de kleine b: bits. 16 Gb = 2 GB, 24 Gb = 3 GB, 32 Gb = 4 GB.
12, 18, 24 en 36GB ipv 8, 12, 16 en 24GB
links = rechts met 24 Gb / 3 GB ipv 16 Gb / 2 GB.
In theorie heb je gelijk, in de praktijk niet. Daarom voegde ik de "met de huidige board ontwerpen" aan toe. Natuurlijk kan je modules naar wens combineren en op elk aantal GB uitkomen dat je maar wil, maar dan moet je je board ontwerp aanpassen. Misschien moeten ze dat toch al door de wijziging van GDDR6 naar GDDR7, maar als je uitgaat van gebruik van 1 grootte geheugenmodule per board ontwerp - praktisch verdedigbare keuze bij montage - èn als je uitgaat van chips met een typische geheugenbus van 128-bit, 192-bit, 256-bit en 384-bit, dan zijn de mogelijkheden in de praktijk beperkt, namelijk:
12, 18, 24 en 36GB en 8, 12, 16 en 24GB
Daarbij vind ik nog steeds 18GB opvallend omdat het geen veelvoud is van van 4. Ik heb het niet over videokaarten die de 4, 6, 8 of 12 geheugen controllers beperkt aansluiten. Ik ga daarbij uit van een even aantal geheugen controllers op een chip, omdat er geen tegenvoorbeeld bestaat (binnen GPU chips, voor zover ik weet). Mogelijk een ontwerpbeperking. 10 of 14 geheugen controllers maakt het niet beter, 16 wel.
Ja je komt dan met 36 / 4 of 18 / 2 uit op een beperkt aangesloten bus zoals 288-bit van oorspronkelijk een 384-bit chip (9 van de 12 controllers), 18 / 3 kan prima en geeft een 192-bit bus. Een 576-bit bus heb ik nog nooit gezien of gehoord, je zou dan 18 geheugencontrollers aansluiten, van de oorspronkelijk, 24? 32?:
Met 24 of 32 Gb modules is dat precies hetzelfde, echter heb je het dan over veelvouden van 3 of 4. 36 / 4 = 9 * 32 = 288-bits bus. Vreemd en onwaarschijnlijk, maar kan gewoon. 18 / 4 = 4,5 en gaat dus niet. Daarentegen is 18 / 2 = 9 * 32 = diezelfde 288-bits bus, maar dan zit je dus wel op 16 Gb modules, niet op 32 Gb. Maar dat kan nu dus ook al. En 36 kan nu ook al, met een 576-bits bus of clamshelling op 288. En met 24 Gb modules heb je het over 6 chips, dus een 192-bits bus
Wat wel kan is mixen, ook met de huidige generatie. Als we dan uitgaan van een "normale" bit bus, kan je al aardig wat geheugen configuraties krijgen met GDDR6 geheugen modules:
Bijvoorbeeld 128-bit met 8Gb en 16Gb GDDR6: 4, 5, 6, 7, 8GB , waarbij 5GB bestaat https://www.gpuzoo.com/GPU-NVIDIA/GeForce_GTX_1060_5_GB.html en 7GB ook: https://gadgettendency.co...ith-rtx-3060-performance/
5 configuraties.
Dezelfde 128-bit met GDDR7 16Gb, 24Gb en 32Gb: 8, 9, 10, 11, 12, 13, 14, 15, 16GB.
9 configuraties.
Aantal configuraties = (aantal controllers * aantal modules om uit te kiezen) - (aantal controllers -1)
Voor 384-bit (12 controllers) en 16,24,32 Gb (3) modules dus 36 - 9 = 25 configuraties. Alles mogelijk tussen de 24GB en 48GB
Voor de 1080Ti is een van de 32-bit controllers niet gebruikt, het chip design is dus nog steeds een 384-bit "normaal / gebruikelijk" GP102 getuige de 12GB op de Titan X / Xp en 12 geheugen controllers op de chip zelf.
De 5GB en 7GB kaarten huizen ook allebei een chip met een even aantal geheugen controllers. Of ze allemaal aangesloten worden is een tweede.
kleine muisjes hebben grote wensjes: Beschuit Met Gestampte Mensjes
Dan ga je er van uit dat ze niet naar een 96- of 64-bit bus gaan voor de echte onderkant. Zie de 3050 6 GB voor laptops met een 96-bit bus en de 6400 & 6500 XT met een 64-bit bus.
Nvidia en AMD kennende zou ik er niet zomaar van uit gaan dat de instap verwend zal gaan worden. Misschien de mainstream x060/x600-kaarten voor een 'mainstream-prijs' van 400 euro of zo
.
When a man finds a conclusion agreeable, he accepts it without argument, but when he finds it disagreeable, he will bring against it all the forces of logic and reason
10 is ook geen veelvoud van 4? Of 6? En ook die 12 is juist geen veelvoud van vier, dat hebben we omdat we op veelvouden van 1 en 2 zaten met 8 en 16 Gb modules - en voorheen op veelvouden van 512 MB, 256...enzovoort
Dat is juist mijn punt, er is niets vreemds aan die 18 GB als je met 24 Gb modules werkt. Zo komt dat gewoon uit. De 10 GB van een 3080 zit op een 320-bit bus met 8 Gb modules.
Geheugen controllers worden overigens ook nooit beperkt aangesloten; als een MC ingeschakeld is, wordt hij ook aangesloten. Op een 3080 10 GB zijn er 2 controllers uitgeschakeld (van de 12). Zo ook op de 970 3.5 + 0.5 GB, alle 8 MC's waren gewoon ingeschakeld en aangesloten. Dat ze vervolgens binnen de chip een fout maakten en intern moesten schakelen tussen 2 MC's is een ander verhaal
Je koppelt hier veel te veel dingen aan elkaar die eigenlijk relatief los van elkaar staan.
Neem een chip met 12 MC's, ongeacht of dat AMD of Nvidia is en ongeacht welke generatie chip. Die heeft 12 * 32 = 384 pinnen voor geheugen chips. Het PCB heeft vervolgens dus ook 12 sets van 32 traces voor geheugen chips. Schakelt de GPU fabrikant vervolgens 2 MC's uit, kan dat PCB gewoon gebruikt worden, dan laten ze 2 plekken open.. Wat er vervolgens over die traces loopt doet er in principe niet toe. In de praktijk is dat niet 100% waar, omdat er met nieuwere (G)DDR generaties soms strengere eisen gesteld worden, pinouts veranderen, enzovoort. Dat is nu niet het geval, wat betekent dat de bestaande PCB's al voldoende zijn voor GDDR7. Wat verandert is de signaal encodering, waar het PCB geen bal mee te maken heeft. De spanning verandert ook (van 1,35V naar 1,2V en later 1,1V), maar het PCB zelf heeft daar ook niets mee te maken, dat zijn de onderdelen óp het PCB.
De grootte heeft niets te maken met het PCB. Enkel de modules zelf en de GPU zijn daarvoor van belang. Er zijn tal van modders die grotere chips op PCB's hebben gesoldeerd. De meest recente die ik me kan herinneren is de 3070 waar de 8 Gb modules vervangen werden door 16 Gb modules. De BIOS moet dan wel aangepast worden zodat hij weet waar hij mee te maken heeft, maar that's it. Wat niet kan, is GDDR6 vervangen door GDDR7 op bestaande GPU's. De GPU kan niet overweg met de PAM3 van GDDR7, dus dat gaat niet werken. Maar daar heeft het PCB geen bal mee te maken.
Die 576 was een hypothetisch voorbeeld, puur om het rekenwerk te demonstreren
Dat is toch precies wat ik zeg? Overigens is de 1060 GDDR5, dus groter dan 8 Gb bestaat voor dat ding niet. Is ook een 160-bit bus (niet 128), want er is één MC uitgeschakeld, de volledige chip is 192-bit.
Wat níet kan, wat jij hier wel suggereert, is groottes tegelijkertijd mixen. Die 1060 @ 160-bit kan enkel overweg met 2,5 of 5 GB (en nog minder dan dat, als je kleinere GDDR5 chips zou gebruiken, vergeet niet dat we al 15 jaar GDDR5 chips hebben
). Op die specifieke chip kun je geen 4 of 6 aansluiten, want er moeten 5 MC's aangesloten worden en er zijn geen GDDR5 chips van 6,4 Gb / 800 MB. De volledige chip kan ook enkel met 3, 6 of 12 GB werken. Hetzelfde geldt voor de S70; dat is een 224-bit bus en vereist GDDR6, dus je krijgt óf 7 GB óf 14 GB op die specifieke chip, want GDDR6 is beschikbaar in capaciteiten van 8 en 16 Gb. Het PCB daarentegen zal gewoon 8 plekken hebben, want de volledige chip (S80) heeft een 256-bit bus.Dit klopt dus volstrekt niet, althans niet met alle GPU's tot op heden, want die kunnen met slechts één grootte overweg. Je hebt exact 3 mogelijke configuraties zonder clamshelling: 24, 36 en 48. Met clamshelling kun je dan ook nog 72 en 96 doen, dus 5 totaal. Meer of minder dan dat is niet mogelijk. Dat kan pas als er een MC uitgeschakeld wordt en de bus dus kleiner wordt. Voor het PCB maakt dat dus niets uit, gewoon een plek open laten.Aantal configuraties = (aantal controllers * aantal modules om uit te kiezen) - (aantal controllers -1)
Voor 384-bit (12 controllers) en 16,24,32 Gb (3) modules dus 36 - 9 = 25 configuraties. Alles mogelijk tussen de 24GB en 48GB
Je herhaalt nu precies wat ik zeg, met als verschil dat je het aansluiten verkeerd begrijpt. Het is niet dat er gekozen wordt een MC niet aan te sluiten, het is dat die MC uitgeschakeld is, de bus daardoor kleiner is en er dus minder chips aangesloten kúnnen worden.
Klopt, met instap kaart bedoel ik een recommended instapkaart, en niemand raadt de 6500 etc. aan, precies vanwege de te lage bandbreedte en/of PCIe lanes. En ja dat zijn verschillende dingen.:
[...]
Dan ga je er van uit dat ze niet naar een 96- of 64-bit bus gaan voor de echte onderkant. Zie de 3050 6 GB voor laptops met een 96-bit bus en de 6400 & 6500 XT met een 64-bit bus.
Nvidia en AMD kennende zou ik er niet zomaar van uit gaan dat de instap verwend zal gaan worden. Misschien de mainstream x060/x600-kaarten voor een 'mainstream-prijs' van 400 euro of zo
Maar zelfs voor 64-bit (chips in) videokaarten gaat het geheugen omhoog van minimaal 4 naar 6 of 8GB bij deze transitie van GDDR6 naar GDDR7.
kleine muisjes hebben grote wensjes: Beschuit Met Gestampte Mensjes
When a man finds a conclusion agreeable, he accepts it without argument, but when he finds it disagreeable, he will bring against it all the forces of logic and reason
We hebben nieuwe kaarten gezien van 16, 20 en 24. Dus voor mij blijft 18 daarin vreemd. Waarom niet 16 of 20? Welke game gaat mikken op 18 (geen enkele)?
Ah, kijk weer wat nieuws geleerd. Op zich logisch, anders gaan shaders (proberen te) praten met MC's die niks kunnen. Uitgeschakeld in BIOS of gelaserd/geknipt in hardware?
Mogelijk, ik koppel graag verschillende gegevens voor nieuwe inzichten. Blame my associative mind.
Het PCB ontwerp kan dus wel hergebruikt worden, alleen de chip zelf niet. Ik gaf aan zelfde PCB, om de nieuwe geheugen mogelijkheden en configuraties duidelijk te maken. Geen verschil van mening hier.
Ook hier zijn we het eens. Ik had van die 5GB en 7GB kaarten niet de originele chip bus gespecificeerd, maar je punt blijft dat MC's uitgeschakeld moeten worden op chip niveau, niet op PCB niveau.:
[...]
Die 576 was een hypothetisch voorbeeld, puur om het rekenwerk te demonstreren
[...]
Dat is toch precies wat ik zeg? Overigens is de 1060 GDDR5, dus groter dan 8 Gb bestaat voor dat ding niet. Is ook een 160-bit bus (niet 128), want er is één MC uitgeschakeld, de volledige chip is 192-bit.
Interessant, dat vereenvoudigt mogelijke configuraties sterk. Is dit omdat de GPU chip aannames moet kunnen doen over geheugen-capaciteit, als een shader met een MC praat?:
Wat níet kan, wat jij hier wel suggereert, is groottes tegelijkertijd mixen. Die 1060 @ 160-bit kan enkel overweg met 2,5 of 5 GB (en nog minder dan dat, als je kleinere GDDR5 chips zou gebruiken, vergeet niet dat we al 15 jaar GDDR5 chips hebben
Eens, dan worden de GDDR7 configuraties, met 24Gb, 32Gb, zonder clamshell:
--
128-bit, 24Gb: 12GB
128-bit, 32Gb: 16GB
--
192-bit, 24Gb: 18GB
192-bit, 32Gb: 24GB
--
256-bit, 24Gb: 24GB
256-bit, 32Gb: 32GB
--
384-bit, 24Gb: 36GB
384-bit, 32Gb: 48GB
--
512-bit, 24Gb: 48GB
512-bit, 32Gb: 64GB
--
Gelukkig komt het voor de eindgebruiker op hetzelfde neer: minder geheugen.
kleine muisjes hebben grote wensjes: Beschuit Met Gestampte Mensjes
When a man finds a conclusion agreeable, he accepts it without argument, but when he finds it disagreeable, he will bring against it all the forces of logic and reason
PC Specs
Asus ROG Strix B650E-E | AMD 7700X | G-Skill 32GB DDR5 6000C30 M-die | 4090 FE | LG 38GN950-B 3840*1600p 160Hz | Corsair RM1000x Shift | WD Black SN850X 1TB M.2
Welke nieuwe kaarten? Heb ik wellicht gemist, heb de topics niet echt bijgehouden. Maar waarom niet 16 of 20: omdat je bijvoorbeeld 6 MC's hebt en je dan dus op 12/24 (single/clamshell) uit komt met 16 Gb chips, op 18/36 met 24 Gb chips. En uiteindelijk op 24/48 met 32 Gb. Met die 6 MC's is 16 of 20 simpelweg niet mogelijk, geen van beide getallen is deelbaar door 6
Meestal gewoon uitgeschakeld in de firmware, wellicht omdat de MC zelf een defect heeft bijvoorbeeld.
Yep, precies dat. Het beschikbare geheugen moet geadresseerd kunnen worden en het is nogal onhandig als je X identieke L2$ blokken aan afwijkende hoeveelheden geheugen moet hangen. Dan moet je ineens gaan routeren omdat MC 1 misschien maar half zo veel adressen kan bedienen als MC2. De shaders doen dat verder niet echt zelf, daar zit nog een hoop tussen, maar als puntje bij paaltje komt, komt het daar inderdaad wel op neer.
Technisch gezien uiteraard wel te doen, maar het zou de hele handel nog een stuk complexer maken dus dat doen ze niet. Sterker nog, de firmware is niet alleen op de hoogte van de grootte van de chips, maar zelfs van het type chip. Je kunt Samsung en Micron ook niet zomaar mixen, want die hebben net iets andere timings en dergelijke. Ze moeten allemaal identiek zijn.
Die 32 Gb chips komen overigens ook pas over een paar jaar, bij mijn weten heeft nog niemand daar iets van geproduceerd. Dus voorlopig blijft het op de veelvouden van 3. Minder niet per se, we gaan er overal met minimaal 1 GB per MC op vooruit
We zullen wel meer chips gaan zien met kleine bussen, wellicht té klein.
When a man finds a conclusion agreeable, he accepts it without argument, but when he finds it disagreeable, he will bring against it all the forces of logic and reason
:strip_exif()/u/95908/Franlin-klein.gif?f=community)
When a man finds a conclusion agreeable, he accepts it without argument, but when he finds it disagreeable, he will bring against it all the forces of logic and reason
/u/324913/crop56a24cce05cd3_cropped.png?f=community)
Dat doet Nvidia al sinds Pascal met GP100. Vervolgens Volta als aparte architectuur, toen wel A100, maar ook apart van de rest van Ampere en nu Hopper in plaats van een "AD100". Het lijkt wel tick tock.
Maar als je kijkt hoe AD102 nu werkelijk presteert tegenover AD103, dan snap ik het wel. Die RTX4090 zou eigenlijk nog eens 30% (voor een totaal meer rond de 60%) sneller moeten zijn dan de RTX4080 als je naar de SM's kijkt. Dat is die niet en ik denk niet dat geheugenbrandbreedte het helemaal verklaard. Ik zie Nvidia eigenlijk ook niet met een compleet nieuwe architectuur komen die breekt met de Maxwell/Turing fundamenten, dus meer SM's voor gaming lijkt me vooralsnog, vrij zinloos. Meer caches lijkt me zinvoller omdat ik vermoed dat Ada tegen een aardige limiet aanloopt qua BvH creatie.
Let ook op die RTX4090 over een tijdje. Die zie ik met bijvoorbeeld Zen 5 of Arrow Lake, opeens een stukje weglopen van de rest van Ada Lovelace of RDNA3. Gebeurd ook al met de 7800X3D tegenover zoiets als een 5800X3D, 7700X, 13700K etc.
Never argue with an idiot. He will drag you down to his own level and beat you with experience.
When a man finds a conclusion agreeable, he accepts it without argument, but when he finds it disagreeable, he will bring against it all the forces of logic and reason
When a man finds a conclusion agreeable, he accepts it without argument, but when he finds it disagreeable, he will bring against it all the forces of logic and reason
PC Specs
Asus ROG Strix B650E-E | AMD 7700X | G-Skill 32GB DDR5 6000C30 M-die | 4090 FE | LG 38GN950-B 3840*1600p 160Hz | Corsair RM1000x Shift | WD Black SN850X 1TB M.2
/u/233413/crop574768220d598_cropped.png?f=community)
Ik heb het draadje even door zitten spitten, maar het is mij nog niet helemaal duidelijk of je zelf een bios faal met de hand kunt aanpassen, of dat je nu alleen kunt crossflashen? Als ze "alleen" alle bypasses hebben omgezet, maar je moet nog altijd een signed bios hebben, dan moet ik een beetje denken aan hetgeen ik ooit voor de 2000-series had gedaan, alleen had ik niet ervoor gezorgd dat je ook verschillende GPU dies kon flashen, want wie wil dat nou? Buiten oplichters die dus nu kaarten met een ander typenummer gaan verkopen op eBay...
Ampere and Ada - only signed bioses have full access ~ but pretty much every Boardpartners Bios is signed
Ja, dit is dus eigenlijk hetzelfde, alleen met meer flags omgezet, waardoor cross-die ook kan. Interessant dat het zo lang duurde voordat iemand anders hetzelfde heeft gedaan.
Dit werkt dus nog altijd niet.
[ Voor 64% gewijzigd door Paprika op 21-08-2023 13:44 ]
En Nvidia komt met DLSS3.5 met de focus op Ray Reconstruction voor een verbeterde denoising. Komt uiteraard naar Cyberpunk. 
https://videocardz.com/ne...uction-launches-this-fall
https://videocardz.com/ne...uction-launches-this-fall
[ Voor 32% gewijzigd door DaniëlWW2 op 22-08-2023 13:32 ]
Never argue with an idiot. He will drag you down to his own level and beat you with experience.
/u/46804/crop5f989efcbb253.png?f=community)
Lees nog eens mijn post door of bekijk het filmpje, ik heb het niet over gpu bandbreedte
. Daarnaast heeft geheugen bandbreedte vrij weing te maken met of je nu 10GB of 20GB video geheugen gebruikt.Laat ik overigens gelijk mijn stelling aanpassen, op de 4090 lijkt het een cpu geheugen bandbreedte probleem, ben benieuwd of dit met AMD gpus ook zo is doordat die minder driver overhead hebben.
[ Voor 8% gewijzigd door Sp3ci3s8472 op 02-09-2023 20:04 ]
Zo kan iedereen ergens wat achter zoeken en gezien het probleem overal op zo erg is zal het wel snel met updates worden opgelost.:
[...]
Lees nog eens mijn post door of bekijk het filmpje, ik heb het niet over gpu bandbreedte
Laat ik overigens gelijk mijn stelling aanpassen, op de 4090 lijkt het een cpu geheugen bandbreedte probleem, ben benieuwd of dit met AMD gpus ook zo is doordat die minder driver overhead hebben.
/u/75044/crop5fb7030b0d077.png?f=community)
Dat hebben ze wel gedaan. Zie hier.
Omdat de game op die manier "beter" wordt voor Nvidia's klanten, maar niet voor de klanten van Intel en Nvidia. Lijkt me vrij eenvoudig. AMD heeft veel minder baat bij het betalen van devs voor FSR implementaties, omdat ze daar ook de concurrenten mee helpen.
Je bedoelt hoe het andersom ook zo is, waarbij FSR2 heel eenvoudig geïmplementeerd kan worden in games die al DLSS hebben en waarbij modders dat, net zoals met DLSS, ook gedaan hebben?
Een open standaard? Zoals FSR2 zelf bedoel je, dat volledig open source is en op alle GPU's werkt (effectiviteit op hele oude GPU's even daar gelaten), in tegenstelling tot slechts 3 generaties van Nvidia?
Of bedoel je zoiets als Nvidia's Streamline middleware voor RT, waar Nvidia het tot op de dag van vandaag heeft over "Nvidia plugins", "Intel plugins" en "Hardware Vendor #3"?
Als Nvidia een open standaard zou willen, waarom hebben ze dat dan niet meteen bij MS, AMD, Intel en de Khronos Group aangedragen?
Sorry, maar dit soort posts zijn gewoon FUD. Als er één partij is die 0,0 interesse heeft in open standaarden, is het Nvidia wel. OpenCL hebben ze bijvoorbeeld ook nooit echt aan mee gewerkt. Als ze dachten dat ze de macht er voor hadden, zouden ze net als Apple ook echt wel hun eigen render API introduceren. Godzijdank heeft Microsoft daar voor games de overmacht. Ik sta er nog steeds van te kijken dat ze wel soort van achter Vulkan staan.
Ga voor de gein eens kijken wat er écht open is van Nvidia, Intel en AMD. Één van die 3 is een stuk meer gesloten dan de andere twee. Kleine hint: hun kleur kun je niet met een ander combineren tot paars
Hun definitie van "open" is ook iets heel anders, want ze leveren dan vaak alsnog zwarte dozen.
Ik heb hier onlangs ook op de FP een reactie over geplaatst. Zie https://www.pcgamingwiki....t_high-fidelity_upscaling
Niets exact geteld (schrijf ik wel een script voor als het hier een keer regent
)- ~400 games in totaal
- ~220 met een vorm van FSR
- ~280 met een vorm van DLSS
- ~50 FSR2 titels zonder DLSS; minder dan 5 daarvan zijn AAA (met andere woorden, vooral kleine devs die de gratis, open source oplossing implementeren)
- ~150 DLSS2 titels zonder FSR
- ~25 DLSS2 titels met FSR 1.0 (meer werk dus)
- ~75 games die DLSS2+ en FSR2+ hebben
Bijna de helft van de 400 is dus Nvidia-biased - en ja, sommige van die games zijn lang vóór FSR2 uit gekomen, dus dat is ze vergeven. Maar niet allemaal - en er zijn ook patches met nieuwere versies van DLSS uitgekomen voor sommige van die games.
Wat mij betreft is het juist DLSS dat games kapot maakt. Het zal me worst wezen dat het soms net iets beter werkt dan FSR2, want het werkt ook voor een beperkt deel van gamers. Zolang de meest populaire videokaarten nog steeds producten met een architectuur van 7 jaar geleden (Pascal; of TU116/117, die functioneel equivalent zijn) zijn heeft zulke exclusiviteit geen enkele bestaansreden. Dat is alsof 12 jaar geleden met D3D11 tessellation vanaf dag 1 vereist zou zijn voor alle games.
Laat MS, Intel, AMD en Sony de handen maar ineen slaan voor een universele, geoptimaliseerde techniek - waarschijnlijk met FSR2/3 als basis, net zoals Mantle de basis vormde voor de huidige API's. Laat Valve ook maar mee doen, want die hebben ook veel goed werk gedaan de laatste jaren. En als ik dan toch bezig ben, laat Apple hun gaming aspiraties maar eens waar maken en ook mee doen. Daar zouden wij, als consumenten, veel meer baat bij hebben dan bij zo'n techniek als DLSS die niet werkt juist op de producten die het momenteel hard nodig hebben. De GPU markt is nog steeds hartstikke kapot.
PC Specs
Asus ROG Strix B650E-E | AMD 7700X | G-Skill 32GB DDR5 6000C30 M-die | 4090 FE | LG 38GN950-B 3840*1600p 160Hz | Corsair RM1000x Shift | WD Black SN850X 1TB M.2
Van wat ik van Starfield heb gezien (mijn RX7900XT kwam zonder), denk ik eigenlijk dat een andere, simpelere verklaring hier speelt. Ik vermoed eigenlijk dat er geen duistere deals met clausules zijn. Ik denk gewoon dat het een Todd Howard game is waar ze op de meest simpele manier iets hebben afgevinkt. Game moet upscaling hebben en dan doen we toch FSR2 want dat werkt op alle GPU's en de Xbox Series S/X. Modders mogen het dan oplossen, zoals altijd.
De game lijkt namelijk niet bepaald goed om te gaan met CPU's. Totaal onverwacht met Bethesda.
Resultaat is dat de game eigenlijk al slecht draait op veel AMD videokaarten en soms ronduit waardeloos op Nvidia. Je hebt voor zoveel videokaarten gewoon FSR2 nodig om überhaupt een speelbare frame rates te behalen. En ik zie de grafische verklaring ervoor echt niet.
Ik weet ook niet of ik zomaar geloof dat Nvidia weinig moeite gestoken heeft in optimalisatie. Ik vermoed eerder dat deze game dusdanig flinke problemen heeft in de hele render pipeline dat Nvidia hun aanpak van meer shaders/lagere occupency gewoon niet werkt omdat ze hun shaders niet aan het werk krijgen, omdat er niet genoeg werk is. Daarom lijken de RX7600 en RTX4060 dicht bij elkaar te liggen en word het steeds slechter voor Nvidia met de grotere GPU's. Pas op 4K herstelt het zich weer een beetje, maar voornamelijk de RTX4090. Ondertussen lijkt RDNA beter om te gaan met de niet geoptimaliseerde zooi die nu uit Bethesda is gekomen.
Als hier al een sinistere deal was geweest, dan had het voor FSR3 moeten zijn. Want deze game lijkt het nodig te hebben. Maar ja, dat werkt ook voor Nvidia, Intel en de Xbox.
Never argue with an idiot. He will drag you down to his own level and beat you with experience.
Wellicht iets te maken met instancing? Als ik het goed begrijp wordt een groot gedeelte van de wereld procedureel gegenereerd wat zich met die engine misschien minder goed leent voor dingen zoals instancing?:
[...]
Van wat ik van Starfield heb gezien (mijn RX7900XT kwam zonder), denk ik eigenlijk dat een andere, simpelere verklaring hier speelt. Ik vermoed eigenlijk dat er geen duistere deals met clausules zijn. Ik denk gewoon dat het een Todd Howard game is waar ze op de meest simpele manier iets hebben afgevinkt. Game moet upscaling hebben en dan doen we toch FSR2 want dat werkt op alle GPU's en de Xbox Series S/X. Modders mogen het dan oplossen, zoals altijd.
De game lijkt namelijk niet bepaald goed om te gaan met CPU's. Totaal onverwacht met Bethesda.
Resultaat is dat de game eigenlijk al slecht draait op veel AMD videokaarten en soms ronduit waardeloos op Nvidia. Je hebt voor zoveel videokaarten gewoon FSR2 nodig om überhaupt een speelbare frame rates te behalen. En ik zie de grafische verklaring ervoor echt niet.
Ik weet ook niet of ik zomaar geloof dat Nvidia weinig moeite gestoken heeft in optimalisatie. Ik vermoed eerder dat deze game dusdanig flinke problemen heeft in de hele render pipeline dat Nvidia hun aanpak van meer shaders/lagere occupency gewoon niet werkt omdat ze hun shaders niet aan het werk krijgen, omdat er niet genoeg werk is. Daarom lijken de RX7600 en RTX4060 dicht bij elkaar te liggen en word het steeds slechter voor Nvidia met de grotere GPU's. Pas op 4K herstelt het zich weer een beetje, maar voornamelijk de RTX4090. Ondertussen lijkt RDNA beter om te gaan met de niet geoptimaliseerde zooi die nu uit Bethesda is gekomen.
Als hier al een sinistere deal was geweest, dan had het voor FSR3 moeten zijn. Want deze game lijkt het nodig te hebben. Maar ja, dat werkt ook voor Nvidia, Intel en de Xbox.
Ook FSR2 lijkt vrij weinig te doen in sommige instanties, met name op Nvidia kaarten.
Ik wacht nog even voor ik het spel ga kopen (het blijft een Bethesda spel dus ik wacht o.a. op updates
), heb namelijk nog niet gekeken of het goed op Linux draait middels Proton. Het zou hilarisch zijn als het met Proton beter draait dan op Windows zo meteen.
Daniel Owen had een snelle test gedaan met verschillende CPU's op 1080p met 50% resolution scale, dus eigenlijk 540p op een 4090: YouTube: Starfield CPU Bottlenecks Tested- Is your CPU ready for Starfield?. Ziet er echt uit dat dit spel CPU limited is. De gedeeltes waar de fps echt laag is, is juist de stad en die is niet procedureel gegenereerd maar met de hand gemaakt lijkt me. De cpu limit kan ook in totaal iets anders liggen zoals AI of zo. Ik heb me nooit in de scripting taal van de creation kit engine gekeken dut dit is maar een gok maar veel custom scripting talen in spellen worden vaak naar zelfbedachte bytecode gecompileerd en gebruiken vaak in-house interpreters. Deze zijn minder doorontwikkeld als .net, python of lua oid. Dus geen hippe features zoals JIT compilation. Daar kan dus behoorlijk wat CPU overhead in zitten.:
[...]
Wellicht iets te maken met instancing? Als ik het goed begrijp wordt een groot gedeelte van de wereld procedureel gegenereerd wat zich met die engine misschien minder goed leent voor dingen zoals instancing?
Ook FSR2 lijkt vrij weinig te doen in sommige instanties, met name op Nvidia kaarten.
Ik wacht nog even voor ik het spel ga kopen (het blijft een Bethesda spel dus ik wacht o.a. op updates
Tja Ampere en Ada ondersteunen geen double rate FP16, waar FSR2 juist veel gebruik van maakt.
Het is ook zo dat we eigenlijk pas iets meer dan een jaar, überhaupt FSR2 en XeSS hebben.
Het is ook wel noemenswaardig dat qua upscaling relevante lage precisie capaciteiten, Intel en AMD eigenlijk behoorlijk vergelijkbaar zijn.
ARC en RDNA doen immers 2x FP16 per ALU in packed math. Voor AMD dus 64x FP15 per SIMD32 en voor ARC 32x FP16 omdat Intel haar SIMD32 net zoals Turing bestaat uit 16x FP en 16x INT. Turing doet hetzelfde als ARC hier. Ampere en Ada hebben geen 2x FP16 packed math meer. Die draaien FSR2 noodgedwongen in de FP32 fall back layer.
Vervolgens doen ARC haar XMX engines, RDNA3 WMMA en de twee Turing tensor cores met SIMD32 allen 128x INT8 per clock (256 met FMA). Ampere en Ada hebben een tensor core per SIMD32 met dezelfde 128x INT8 (256 met FMA) als twee Turing tensor cores.
Intel zou de XMX versie van XeSS beschikbaar kunnen maken voor RDNA3 en Turing/Ampere/Ada. Dat ze het niet doen is, vermoed ik, omdat Intel graag dat voordeel over AMD wil behouden alsmede een forse lijst aan andere software zaken moet aanpakken. Helaas want XeSS lijkt soms beter te zijn dan FSR2 en de openstelling aan RDNA3 zou ook verbeteringen voor FSR2 kunnen afdwingen.
De andere kant op is dat nu AMD hun eigen frame generation heeft en er komt ook een FSR2 native resolution AA mode. Gezien het langzame uitsterven van MSAA en de vaak slechte TAA, is dat zeker welkom als standaard optie. Zeker als je ook de FSR2 sharpening slider geïmplementeerd krijgt.
Ze kunnen daar nu wel eens de focus gaan leggen op FSR2 verbeteren met matrix hardware ondersteuning. Immers ondersteunt RDNA3 ook 128x FP16 (256 FMA) in matrix mode. Intel haar XMX engine doet daar 64 (128 FMA). Turing haar twee tensor cores doen elk 32x FP16 (64 FMA) Totaal is dus 64x FP16 (128 FMA). Ampere en Ada doen ook 128x FP16 (256 FMA) met de enkele tensor core. In theorie zou AMD het kunnen spelen dat ze een open source "FSR2 AI quality" maken die meer rekenkracht tot haar beschikking heeft met RDNA3 dan ARC of Turing. Ampere en Ada trekken dat gelijk. Of die mode komt alleen voor RDNA3 zoals Intel het met XeSS heeft gedaan. In dat geval zou met name Nvidia zwaar benadeeld worden. Immers doen Turing, Ampere en Ada elk maar 32x FP16 (64 met FMA) per clock.
Probleem daar is alleen dat ze comptabiliteit met RDNA1 en RDNA2 opgeven of een fall back moeten maken met shader based FP16, waarmee je voor de extra kwaliteit, minder frame rate verbetering haalt uit de upscaling omdat er meer workload op de ALU's valt. Een dergelijke fall back zou ook redelijk moeten werken op ARC. Op Nvidia niet. Een potentieel cynisch argument voor AMD om het zo te doen en dan echt proberen DLSS2 in de hoek te drukken met een kwalitatief hoogwaardigere FSR2. Want dat algoritme lijkt echt niet slecht te zijn. Maar een verdubbeling van rekenkracht zou denk ik niet mis staan. Dat is dan alleen voornamelijk wel voor RDNA3. Intel en Nvidia
Want inhakend op de discussie hiervoor. Nvidia open sourced echt bijna niks. Nvidia geeft überhaupt zelden toegang tot hun tech aan derden. DLSS2 zie ik niet beschikbaar komen voor AMD of Intel. Het is inmiddels tot het niveau dat DLSS2 game ondersteuning, vrij standaard word vermeld in Nvidia haar kwartaalcijfers. Het is allang geen extra meer. Het is een vitaal onderdeel van hun marketingstrategie. Dat gaan ze niet opgeven. En dat zou het ook juist zo relevant voor zowel Intel als AMD moeten maken om het te doorbreken.
Er is al een DLSS2 mod.
Dit ja.
DLSS2 is in principe de beste nu. Dat komt waarschijnlijk vooral omdat Nvidia er al langer mee bezig is en het alleen laat draaien op zeer specifieke hardware. Er is voor DLSS2 gewoon een beduidend hogere minimale hardware standaard. Maar nog steeds hebben veel gamers die hardware niet.
FSR2 is vooralsnog het beste antwoord, maar lijkt ook wel te vragen om een goed aangepaste implementatie. Dan is er ook nog XeSS. Daarmee loop je altijd het risico dat niet elke upscaler even goed geïmplementeerd is. Het liefst heb ik er ook maar een. Of het XeSS of FSR2 is, kan me weinig schelen. Ideaal gezien worden beiden ook voorzien van bredere en meer capabele hardware ondersteuning zodat je niet echt de situatie krijgt dat je het "juiste merk" videokaart moet hebben voor de beste ervaring. Dat staat me namelijk tegen aan hoe XeSS nu is. Zoals ik hierboven al zei. AMD kan dit ook doen. Ik hoop van niet, maar ik vermoed dat dit ook gaat komen waarbij Turing, RDNA1-2 en ARC met minder capabele hardware zitten.
Never argue with an idiot. He will drag you down to his own level and beat you with experience.
When a man finds a conclusion agreeable, he accepts it without argument, but when he finds it disagreeable, he will bring against it all the forces of logic and reason
In sommige gevallen is Nvidia eerder, maar er is gewoon een filosofisch verschil in de aanpak van dit soort dingen tussen de bedrijven. Zelfs toen AMD/ATI de overhand had, deden zij niet dit soort dingen en Intel doorgaans ook niet. En dat heeft weer te maken met het feit dat die bedrijven (Intel, AMD en toentertijd ATI, maar ook bijvoorbeeld Matrox, Cirrus, Apple, enzovoort) uit een tijd stammen dat er veel meer concurrentie was en niemand zo'n overmacht kon krijgen; hooguit IBM zou je dat toe kunnen schrijven, maar zelfs dat was niet vergelijkbaar omdat er toen ook wat losser om werd gegaan met reverse engineering en dergelijke (godzijdank
). Je zou zoiets er gewoon nooit op continentale schaal doorgedrukt krijgen, laat staan wereldwijd.Er zijn tal van voorbeelden waar je dit kunt zien (Mantle/Vulkan/D3D12 heb ik al genoemd), mijn favoriete voorbeeld daarvan is echter tessellation. Het idee van tessellation bestaat al heel lang. AMD (of toen, ATI) kan dat al in hardware sinds 2001 - alles vanaf de 8500 en nieuwer heeft een vorm van tessellation in hardware (ook Xenos in de Xbox); TruForm noemden ze dat. Het had in 2007 als vereiste in D3D10 moeten komen, maar Nvidia was er nog niet klaar voor, dus het kwam pas in 2008 in D3D11 (eigenlijk SM 5.0). De units in de oudere GPU's waren helaas niet compatible met die spec (vooral vanwege de pipeline structuur), maar functioneel deed het hetzelfde. In de paar games/engines die de extensies wel ondersteunden, werkte het wel goed en kostte het nagenoeg geen performance. Dat kwam doordat het ook met weinig input werkte en pipelines toen heel anders in elkaar zaten; nadeel was dat het soms wel rare dingen deed (werkte bijvoorbeeld voor geen meter met de wapen models in CS 1.x
), juist vanwege het gebrek aan input.
In die tijd had ATI dat er makkelijk door kunnen drukken bij devs in die periode, maar zo werkte het bedrijf simpelweg niet - en dat is met de overname niet veranderd. Als business model is Nvidia's aanpak beter als je het succesvol uitvoert, maar voor ons als consument is die aanpak juist ruk. De consument heeft 0,0 baat bij Nvidia's aanpak, want features worden op die manier op een subset van hardware ondersteund en lopen zo het risico niet gebruikt te worden en een stille dood te sterven.
Het probleem daar is dat het onder andere Frank Azor is, een bewezen fantast met een historie van zaken die op zijn best marketing blunders genoemd kunnen worden en / of minachting voor de klant. AMD had, willen ze in deze geloofwaardig overkomen, het best een andere C-Suite executive uit de kast kunnen trekken voor die statement
Persoonlijk had ik graag gezien dat AMD deze man nooit had aangenomen, en nu hoop ik dat ze z.s.m afscheid nemen na de PR debacles de afgelopen jaren van deze man, vooral op Twitter. Denk bijvoorbeeld aan dit 'gedoe' op Twitter destijds over launch volumes.. https://wccftech.com/amd-...000-graphics-card-volume/
Daarnaast, wordt er zelfs tijdens het gesprek om de hete brij heen gedraaid door Frank, zoals de journalist opmerkt tijdens de inleiding van het artikel.
Maar wat mij als AMD aandeelhouder nog het meest irriteert, waarom nu na bijna 2 maand oid zo'n halfslachtige statement bij The Verge (al is het iets minder halfslachtig dan de statement in juni). Waarom niet kort maar krachtig destijds de waarheid vertellen toen HUB, GN, WCCFTech e.d. daar mee bezig waren terwijl Nvidia dat wel deed. Ik snap dat dus niet, tenzij ze destijds de waarheid niet kort maar krachtig konden vertellen omdat er toch 'iets' speelde. Wat dat iets dan ook exact was.
Dan heb je ook nog deze tweet (ondertussen verwijderd)::
[...]
Het probleem daar is dat het onder andere Frank Azor is, een bewezen fantast met een historie van zaken die op zijn best marketing blunders genoemd kunnen worden en / of minachting voor de klant. AMD had, willen ze in deze geloofwaardig overkomen, het best een andere C-Suite executive uit de kast kunnen trekken voor die statement
Persoonlijk had ik graag gezien dat AMD deze man nooit had aangenomen, en nu hoop ik dat ze z.s.m afscheid nemen na de PR debacles de afgelopen jaren van deze man, vooral op Twitter. Denk bijvoorbeeld aan dit 'gedoe' op Twitter destijds over launch volumes.. https://wccftech.com/amd-...000-graphics-card-volume/
Daarnaast, wordt er zelfs tijdens het gesprek om de hete brij heen gedraaid door Frank, zoals de journalist opmerkt tijdens de inleiding van het artikel.
[...]
Maar wat mij als AMD aandeelhouder nog het meest irriteert, waarom nu na bijna 2 maand oid zo'n halfslachtige statement bij The Verge (al is het iets minder halfslachtig dan de statement in juni). Waarom niet kort maar krachtig destijds de waarheid vertellen toen HUB, GN, WCCFTech e.d. daar mee bezig waren terwijl Nvidia dat wel deed. Ik snap dat dus niet, tenzij ze destijds de waarheid niet kort maar krachtig konden vertellen omdat er toch 'iets' speelde. Wat dat iets dan ook exact was.
https://www.reddit.com/r/...al_foundry_what_i_can_say
Hij verduidelijkt wel dat hij geen weet heeft van Starfield en dat dit niet één van de devs was die hij heeft gesproken:
https://twitter.com/dark1x/status/1698394695922000246
Nogal wat rook eerlijk gezegd.
When a man finds a conclusion agreeable, he accepts it without argument, but when he finds it disagreeable, he will bring against it all the forces of logic and reason
When a man finds a conclusion agreeable, he accepts it without argument, but when he finds it disagreeable, he will bring against it all the forces of logic and reason
When a man finds a conclusion agreeable, he accepts it without argument, but when he finds it disagreeable, he will bring against it all the forces of logic and reason
Bedankt voor de link .
Ik heb de plaatjes vergeleken, maar beter dan native is erg wensvol of ze hebben een MyFi definitie van wat beter is. Er zijn bepaalde objecten die er 'beter' uitzien, maar dat kan ook vanwege een soort sharpening effect komen/inkleuren van 'schaduw'. Globaal gezien redelijk wat detail verlies, dat vooral te zien is aan de textures, diepte van de schaduw, bomen die op een redelijke afstand staan etc.
Kijk maar eens hoe dramatisch de laatste afbeelding is, waarbij het detail van de marmeren vloer bijna helemaal verloren gaat. Het blijft een upscale poetsmiddel mensen en zal globaal niet beter zijn dan Native.
En nooit beter dan Native + DLAA.
.Ik heb de plaatjes vergeleken, maar beter dan native is erg wensvol of ze hebben een MyFi definitie van wat beter is. Er zijn bepaalde objecten die er 'beter' uitzien, maar dat kan ook vanwege een soort sharpening effect komen/inkleuren van 'schaduw'. Globaal gezien redelijk wat detail verlies, dat vooral te zien is aan de textures, diepte van de schaduw, bomen die op een redelijke afstand staan etc.
Kijk maar eens hoe dramatisch de laatste afbeelding is, waarbij het detail van de marmeren vloer bijna helemaal verloren gaat. Het blijft een upscale poetsmiddel mensen en zal globaal niet beter zijn dan Native.
En nooit beter dan Native + DLAA.