CJ's AMD Radeon Info & Nieuwsdiscussietopic - Deel 132

[marcop82]

De meeste AMD drivers in 2015 zijn beta, dat zegt niet dat ze brak zijn maar dat men niet moet klagen als het mis gaat. In contrast, Nvidia brengt elke maand WHQL drivers uit die ook niet vrij van issues zijn.

[Verwijderd]

Sterker nog er is nog nooit een driver geweest die bug vrij is alleen heeft niet iedereen gelijk last van de bugs. Ik zelf instaleer bèta's, devlopers en custom drivers zonder angst en vrijwel altijd zonder enige problemen voor jaren nu en dat geldt ook voor AMD drivers vermoed ik. De meeste problemen komen door de gebruikers zelf of door hun pc.

[ Voor 18% gewijzigd door Verwijderd op 30-09-2015 09:00 ]

[Phuncz]

De gebruiker is dan ook áltijd de reden dat het fout loopt, dat ze die nog steeds toegang geven tot een PC...

Maar ik ben dus wel blij dat ik in 2014 en 2015 kan zeggen dat ik me niet meer herinner wanneer ik een BSOD heb gehad of onstabiele games in het algemeen. Pluimpje voor Windows 7, AMD en Nvidia en de game ontwikkelaars !

[rikadoo]

Klein vraagje, ik heb de laatste drivers geinstalleerd van AMD, nu 15.9 beta geloof ik nu heb ik alleen last van een rare bug ? Zodra ik een serie kijk met MPC en het dan een paar minuten op pauze zet om vervolgens verder te gaan blijft het scherm zwart en lijkt het erop als het beeld vastloopt, het geluid werkt wel. Dit probleem heb ik met 15.7 niet, alleen met de beta`s 15.8 en 15.9. Het is niet heel storend ofzo en kan altijd terug naar 15.7 maar ik vraag me af of er misschien een instelling oid bij is gekomen en hebben er meer mensen toevallig last van?

[sdk1985]

Dat probleem heb ik destijds ook meerdere malen gehad met mijn E-350 APU, het kwam ook elke grote release weer terug (zat in 12,13 en 14). Was overigens wel specifiek voor XBMC/Kodi en de Trakt plugin speelde ook nog een rol (om het nog specifieker te maken ). Voor HTPC daarom maar gehouden bij finals (e.g de .12 versies). Ga je gamen dan is dat waarschijnlijk geen handige "oplossing" want dan mis je aanpassingen voor de nieuwste games.

[ Voor 42% gewijzigd door sdk1985 op 30-09-2015 18:37 ]

[Garwinski]

Er schijnt erg veel last te zijn van memory leaks in 15.9, dat kan een heleboel problemen opleveren met dingen die vastlopen etc. In deze thread worden veel problemen gemeld:

http://forums.guru3d.com/showthread.php?t=402805

[rikadoo]

Hmm heb eigenlijk nooit echt problemen gehad met beta drivers, maar nu alleen deze vage bug. Nja is ook niet erg dan maar niet op pauze, voor de rest geen problemen overigens met de drivers. Is op Windows 10 met 2x R9290x crossfire. Mocht er iemand een oplossing weten hoor ik het graag, vind er iig niets op internet over.

[LongBowNL]

rikadoo schreef op woensdag 30 september 2015 @ 20:08:
Hmm heb eigenlijk nooit echt problemen gehad met beta drivers, maar nu alleen deze vage bug. Nja is ook niet erg dan maar niet op pauze, voor de rest geen problemen overigens met de drivers. Is op Windows 10 met 2x R9290x crossfire. Mocht er iemand een oplossing weten hoor ik het graag, vind er iig niets op internet over.

Report het probleem in ieder geval aan AMD. Dat kunnen ze het misschien oplossen.
http://www.amdsurveys.com/se.ashx?s=5A1E27D23A3DE979

[Bullus]

Catalyst 15.9.1 beta

Resolved Issues:

• [77609] A video memory leak can occur when browser and other windows are resized

[LongBowNL]

Het lijkt erop dat de CPU overhead stapje voor stapje meer wordt.

Laat maar, het lijkt erop dat een overclock van mij alleen maar negatieve resultaten had.

Van links naar rechts:
Windows 7 15.7
Windows 10 15.7
Windows 10 15.8 met 50 MHz overclock op de GPU core
Windows 10 15.9.1 met 50 MHz overclock op de GPU core
Windows 10 15.9.1 op stock

http://www.3dmark.com/com...77552/aot/77556/aot/77557

[ Voor 32% gewijzigd door LongBowNL op 01-10-2015 10:59 . Reden: Overclocken helpt niet echt hier :X ]

[sdk1985]

LongBowNL schreef op donderdag 01 oktober 2015 @ 10:46:
Het lijkt erop dat de CPU overhead stapje voor stapje meer wordt.

Laat maar, het lijkt erop dat een overclock van mij alleen maar negatieve resultaten had.

Van links naar rechts:
Windows 7 15.7
Windows 10 15.7
Windows 10 15.8 met 50 MHz overclock op de GPU core
Windows 10 15.9.1 met 50 MHz overclock op de GPU core
Windows 10 15.9.1 op stock

http://www.3dmark.com/com...77552/aot/77556/aot/77557

Maar hoe loopt je cpu precies. Heb je de Turbo op x41 gezet voor alle core loads (1,2,3,4) of is de basis x41 en gebruik je de turbo dus niet meer?

[LongBowNL]

Turbo x41. Ik heb Intel Stepping gewoon aan staan.

[sdk1985]

LongBowNL schreef op donderdag 01 oktober 2015 @ 15:05:
Turbo x41. Ik heb Intel Stepping gewoon aan staan.

Heb ik de eerste maand ook geprobeerd maar dat is een hele inconsistente manier om over te clocken en daarom meteen, wat mij betreft, ongeschikt voor benchmarks.

Je kunt beter de normale multiplier (33) zoeken en deze omgooien naar 41. Van de Turbo blijf je vervolgens af. Hiermee gebeurd het volgende

idle: normaal 1.6 GHz
load: alle cores naar 4.1 GHz

Pc blijft dus gewoon zuinig maar je kunt niet terugvallen naar x33. Mocht je het leuk vinden dan kun je natuurlijk de Turbo wel (nog) hoger instellen. Maar zelf vond ik dat niet nodig (x42).

[ Voor 8% gewijzigd door sdk1985 op 01-10-2015 15:38 ]

[Pure_evil]

sdk1985 schreef op donderdag 01 oktober 2015 @ 15:15:
[...]

Heb ik de eerste maand ook geprobeerd maar dat is een hele inconsistente manier om over te clocken en daarom meteen, wat mij betreft, ongeschikt voor benchmarks.

Je kunt beter de normale multiplier (33) zoeken en deze omgooien naar 41. Van de Turbo blijf je vervolgens af. Hiermee gebeurd het volgende

idle: normaal 1.6 GHz
load: alle cores naar 4.1 GHz

Pc blijft dus gewoon zuinig maar je kunt niet terugvallen naar x33. Mocht je het leuk vinden dan kun je natuurlijk de Turbo wel (nog) hoger instellen. Maar zelf vond ik dat niet nodig (x42).

Het is ondertussen al een paar jaartjes geleden dat ik mijn 2500k wat opgefokt heb maar herinner me dat turbo oc'en inderdaad niet lekker werkte, zeer onregelmatige resultaten in benches en games in mijn geval.
Uiteindelijk na paar dagen ook gewoon multi omhoog gezet + wat power opties aangepast maar daarvoor moet je eens een guide ofzo zoeken, dat zit veel te ver in mijn geheugen.

[LongBowNL]

EPU van Asus bemoeit zich er ook vast wel mee. Ik heb nu de Turbo uitgezet, maar toch zet hij stappen met multipliers van 16x (laagste) en 29x (ergens in het midden) en 41x (goed!). Niet belangrijk en verder geheel off-topic. Ik ga wel verder knutselen.

[Verwijderd]

Ik heb ook niets met turbo leuk dat het tijdens een stress test op volle toeren draait maar als je een game speelt zakt de mp altijd een stapje omlaag omdat er niet zo veel cpu kracht nodig is op dat moment.

[Sp3ci3s8472]

Microsoft koopt Havok van Intel

Havok to join Microsoft

Zou mooi zijn als ze wellicht ook GPU accelerated physics via Direct Compute of OpenCL erin zouden stoppen. Dat zou een doodsteek zijn voor Physx.
Ik dacht ergens te hebben gelezen dat Intel weinig met Havok deed de laatste aantal jaar, nu MS meer de opensource kant aan het opgaan is en eindelijk inovatiever bezig is goed nieuws voor middleware zoals Havok.

Was Intel ook niet de reden dat AMD niet verder kon gaan met GPU accelerated physics destijds? Kan mij voorstellen dat Intel liever had dat mensen een snellere CPU kochten dan dat alles naar de gpu werd offgeload.

Edit, uit het archief :P:

ATI was al eerder bezig met GPU accelerated physics dan Nvidia, alleen jammer dat het nooit gemeengoed is geworden.

offtopic:
Dat we dit eerst op fok.nl moeten lezen zegt alweer genoeg over tweakers.net.
Fok noem ik nou niet echt een techsite en als je het daar al eerder kan lezen .

[ Voor 15% gewijzigd door Sp3ci3s8472 op 02-10-2015 22:13 ]

[Help!!!!]

Sp3ci3s8472 schreef op vrijdag 02 oktober 2015 @ 22:05:
Microsoft koopt Havok van Intel

Zou mooi zijn als ze wellicht ook GPU accelerated physics via Direct Compute of OpenCL erin zouden stoppen. Dat zou een doodsteek zijn voor Physx.
Ik dacht ergens te hebben gelezen dat Intel weinig met Havok deed de laatste aantal jaar, nu MS meer de opensource kant aan het opgaan is en eindelijk inovatiever bezig is goed nieuws voor middleware zoals Havok.

Was Intel ook niet de reden dat AMD niet verder kon gaan met GPU accelerated physics destijds? Kan mij voorstellen dat Intel liever had dat mensen een snellere CPU kochten dan dat alles naar de gpu werd offgeload.

Interessant nieuwtje.

offtopic:
Dat we dit eerst op fok.nl moeten lezen zegt alweer genoeg over tweakers.net.
Fok noem ik nou niet echt een techsite en als je het daar al eerder kan lezen .

Volg redelijk wat grote techsites maar had het ook nog nergens anders gelezen dus zo slecht doet Tweakers het in dit geval niet. Maar Tweakers frontpage zou wel wat 'scherper' kunnen

[LongBowNL]

Ik heb gisteren al de nieuwssubmit geplaatst (voor jouw post), dus misschien komt hij er vandaag nog door.

[Verwijderd]

Sp3ci3s8472 schreef op vrijdag 02 oktober 2015 @ 22:05:

Als je even geduld heb krijg je gratis Flex physx van Nvidia want die werkt ook over open source

[ Voor 10% gewijzigd door Verwijderd op 03-10-2015 11:17 ]

[Sp3ci3s8472]

Verwijderd schreef op zaterdag 03 oktober 2015 @ 10:58:
[...]


Als je even geduld heb krijg je gratis Flex physx van Nvidia want die werkt ook over open source

Dit zou een interessante post zijn als je er een bron bij zou posten. Nu voegd het weinig toe aan de discussie .

Wat ik zo snel kon vinden is dat Physx nu opensource is voor developers die in het gameworks programma zitten. Het is dus zover ik weet nog steeds closed source voor AMD, daar zit dus weinig vooruitgang in.

Persoonlijk zie ik liever dat een minder partijdige partij (hopenlijk laten ze Linux ondersteuning niet vallen), hence microsoft iets gaat doen met GPU accelerated physics. Nvidia is nou niet echt het aardigste jongetje in de klas en ik vertrouw ze daardoor voor geen meter als het aankomt om iets netjes uit te brengen.

[ Voor 8% gewijzigd door Sp3ci3s8472 op 03-10-2015 16:03 . Reden: er is een bron :p ]

[Verwijderd]

Het is ook nog met net uit Flex en is nog volop in ontwikkeling. Nvidia wil in de toekomst Flex ook over DirectCompute laten lopen zo dat het over een AMD gpu mogelijk maakt wat tot nu toe alleen mogelijk is over de CPU.met huidige physx.

PhysXInfo.com: Is FLEX purely GPU accelerated library, or will it support CPU execution? Is it plausible to see FLEX ported to OpenCL or DirectCompute?

Miles Macklin: Right now we have a CUDA implementation and a DirectCompute implementation is planned. We are considering a CPU implementation.
http://physxinfo.com/news...unified-gpu-physx-solver/

Na enkele updates werk Flex ook steeds beter en op Linux zelfs beter dan in Windows.

[ Voor 50% gewijzigd door Verwijderd op 03-10-2015 15:55 ]

[enchion]

enchion schreef op donderdag 24 september 2015 @ 22:08:
[...]


Dit is wel erg slecht van MS en gooit gelijk een zak zout/zoutmijn naar alle vorige benchmarks die we gezien hebben.

btw Powermanagement moet helemaal uitschakelbaar gemaakt worden op windows, wat het niet is, met betrekking op performance is power management niks anders dan een virus.
Kan me ook niet aan het idee onttrekken dat het invloed heeft op dingen als microstutter.

Iets te snel aannames maken is niet goed van mij.

Heb het net geprobeerd in Windows 10 en waarempel, je kan de Power-service gewoon uitschakelen. (lijkt het na kort proberen)

Bij Windows 7 en 8 werkte dan het geluid niet meer omdat MS die services van elkaar afhankelijk hadden gemaakt.
In Windows 10 werkt het geluid gewoon wel, enige aparte is dat mn netwerk tray icoontje zegt dat er geen netwerk is, terwijl ik wel gewoon kan internetten !
Veel dingen zoals pagerendering van internet pagina`s werkt ook een stuk beter/sneller.


Maw als iemand nog eens zin heeft om te benchmarken kan dat nu met Win10 dus ook zonder powermanagement.

[Verwijderd]

enchion schreef op zaterdag 03 oktober 2015 @ 17:06:
[...]

Had je ergens last van dan qua cpu gebruik in balans mode?

[enchion]

Verwijderd schreef op zaterdag 03 oktober 2015 @ 17:17:
[...]
Had je ergens last van dan qua cpu gebruik in balans mode?

Jij bent waarschijnlijk al helemaal gewend geworden aan hoe de PC reageert als powermanagement aanstaat.
Verschil is best groot, en nee ik had officieel nergens last van, CPU loopt alleen te flipperen tussen powerstates, waardoor elke keer als je ergens op klikt (na even een stukje gelezen te hebben) er een microdelay tussen zit voordat er iets gebeurt, waar ik me wel aan stoor.
Verschil dat ik merk is tussen High Performance mode en Power Service Off mode dus, waarin Power Service Off mode dus veel direkter aanvoelt. (soort van microstutter die opgelost wordt)

Mijn eerste reactie was op een benchmark van Extremetech, nl https://www.extremetech.c...test-directx-12-benchmark

Maw die test kan dus ook volledig zonder tussenkomst van Powermanagement gemeten worden. (is nog eerlijker)
Is dan dus ook zichtbaar te maken of verschillen door Microsoft gegenereerd worden.

[Verwijderd]

Net eens getest maar bij mij levert het niets op met aan of uit want de fps blijft het zelfde min 48 max 117 avg 80

[enchion]

Verwijderd schreef op zaterdag 03 oktober 2015 @ 18:06:
Net eens getest maar bij mij levert het niets op met aan of uit want de fps blijft het zelfde min 48 max 117 avg 80

Ik zou het verschil eerder verwachten bij microstutter en framedrops, dan bij gemiddelde FPS.

[Verwijderd]

Zoals je ziet ook geen framedrops microstutters kan ik op zich nog testen met Frafs.

PM on


PM off


Je ziet een heel klein verschil maar dat kan van alles zijn zoals een iets warmere gpu bij de laatste run waardoor 10mhz minder boost.

Zo zie je maar weer dat ik nooit onzin post

[ Voor 78% gewijzigd door Verwijderd op 03-10-2015 18:52 ]

[enchion]

Ziet er imho precies hetzelfde uit. (Maar bedankt voor het testen, moet morgen ofzo zelf ook nog eens testen met bv Thief)

Reden waarom ik verschil merk buiten spellen, maw gewoon in desktop performance kan natuurlijk zijn omdat het lage CPU belasting betreft, waardoor de CPU vaak aan het bakkeleien is of hij nou rustig of snel moet reageren.

Het is alsof een variabele inputlag/microlag is weggehaald wat daarmee ook zou overeenkomen.

Kan ook met de hoeveelheid CPU cores enof het merk CPU te maken hebben. (Ik heb een AMD 3xcore CPU, wat erg ongunstig is mbt de powermanagement "thresholds". (cpubelastingspunten waar hij overschakelt naar een hogere of lagere powerstate)

Anyway het is in ieder geval handig om dingen helemaal zonder te kunnen testen, om 100% zekerheid te hebben.

Verwijderd schreef op zaterdag 03 oktober 2015 @ 18:19:
Zo zie je maar weer dat ik nooit onzin post

Heb ik ook nooit gesteld.

[ Voor 11% gewijzigd door enchion op 03-10-2015 19:11 ]

[Phuncz]

Verwijderd schreef op zaterdag 03 oktober 2015 @ 18:19:
Zo zie je maar weer dat ik nooit onzin post

Vat het niet aanvallend op, zo bedoel ik het niet, maar zoiets dwing je niet af door het zelf te stellen. Dat moet men voor zichzelf uitmaken.

Zo bewijst je post met screenshots niet dat het probleem wat echion beschrijft totaal niet gebeurt, enkel dat jij het met jouw configuratie niet hebt. Informatie moet altijd naar waarde geschat worden. Dus is het correct tot stand gekomen, komt het van een betrouwbare en onpartijdige bron, hoe groot is de sample size, zijn alle belangrijke variabelen opgenomen, etc etc.

Het is leuk dat je het test en je duidt zo aan dat het probleem niet 100% iedereen aantast. Maar jij kan ook even goed de 1% zijn die er geen last van heeft. Of Echion kan juist die 1% zijn die het alleen heeft. Met een sample size van 2 personen (artikel buiten beschouwing) bereik je natuurlijk geen correct beeld.

[-The_Mask-]

Het is vandaag al weer 5 jaar geleden dat CJ is overleden.

[Sp3ci3s8472]

-The_Mask- schreef op zondag 04 oktober 2015 @ 01:58:
Het is vandaag al weer 5 jaar geleden dat CJ is overleden.

Echt een gemis .

[tomcatha]

5 jaar... lijkt net gisteren.
Het is idd nooit meer het zelfde geworden sinds dien. Zowel de leaks als de persoonlijke kant...

[Help!!!!]

Met allen hierboven. Gaat veel te hard. RIP CJ !

[ Voor 5% gewijzigd door Help!!!! op 04-10-2015 09:35 ]

[paragon]

5 jaar alweer...

[SG]

Sp3ci3s8472 schreef op vrijdag 02 oktober 2015 @ 22:05:
Microsoft koopt Havok van Intel

Havok to join Microsoft

Zou mooi zijn als ze wellicht ook GPU accelerated physics via Direct Compute of OpenCL erin zouden stoppen. Dat zou een doodsteek zijn voor Physx.
Ik dacht ergens te hebben gelezen dat Intel weinig met Havok deed de laatste aantal jaar, nu MS meer de opensource kant aan het opgaan is en eindelijk inovatiever bezig is goed nieuws voor middleware zoals Havok.

Was Intel ook niet de reden dat AMD niet verder kon gaan met GPU accelerated physics destijds? Kan mij voorstellen dat Intel liever had dat mensen een snellere CPU kochten dan dat alles naar de gpu werd offgeload.

Edit, uit het archief :P:
[video]
ATI was al eerder bezig met GPU accelerated physics dan Nvidia, alleen jammer dat het nooit gemeengoed is geworden.

offtopic:
Dat we dit eerst op fok.nl moeten lezen zegt alweer genoeg over tweakers.net.
Fok noem ik nou niet echt een techsite en als je het daar al eerder kan lezen .

Ja vanaf de R420 dacht ik. De eerste gen gpgpu.
Dat intel er niet veel mee deed is omdat de reden van hun hostile overname is on havok FX module te killen. Want havok mag van intel geen gpgpu gebruiken.
Nu met Microsoft. Zal dat mogelijk wel terug komen. Misschien dat ze het werk ergen ip plank hebben en oudere versies van cuda en ATI steam compute om kunnen gooien naar HSML direct compute.
Denk niet dat OpenCL zal ondersteunen. Maar met het oog op android en ios ondersteuning etc. Mogelijk misschien ook. Maar grote kans van niet.

[haarbal]

Opencl ondersteuning zou vooral mooi zijn voor multiplatform devs die ook een ps4 versie willen.

[tomcatha]

ik zie microsoft wel opnieuw samen werken met amd, hebben ze het in verleden wel meerdere keren gedaan

[LongBowNL]

Fury X2 gespot bij onze vrienden van WCCFTech:
http://wccftech.com/amd-d...denamed-radeon-r9-gemini/

Codename Gemini?

[Nature]

Bij de Fury X2 in de tabel staat dat hij 8192 stream processors heeft en 8GB HBM memory (4GB per chip)
ze zouden ook moeten zeggen 8192 stream processors (4096 per chip) toch? Anders lijkt het of het geen crossfire is. Ik weet er staat X2 maar aangezien ze het wel verduidelijken bij het geheugen
kan iemand toch denken dat het geen crossfire is, er staat ook nergens crossfire in het artikel.

edit hier wel wat meer over crossfire http://wccftech.com/amd-r9-fury-x2-dual-gpu/

[ Voor 9% gewijzigd door Nature op 04-10-2015 23:13 ]

[LongBowNL]

Ik doe er even stiekem een R9 390 review doorheen. Laat maar eens zien hoe goed deze draait in vergelijking met een nVidia 970. Energieverbruik is natuurlijk nog een dingetje.
www.tomshardware.com/revi...ro-r9-390-8g-d5,4245.html

[Nature]

LongBowNL schreef op maandag 05 oktober 2015 @ 17:35:
Ik doe er even stiekem een R9 390 review doorheen. Laat maar eens zien hoe goed deze draait in vergelijking met een nVidia 970. Energieverbruik is natuurlijk nog een dingetje.
www.tomshardware.com/revi...ro-r9-390-8g-d5,4245.html

Dat is toch hetzelfde als wat we allemaal al wisten GTX970 wat beter op 1080p en de R9 390 wat beter op 1440p. Hier dezelfde Sapphire Nitro kaart nog eens dan alleen op 1080p
http://www.tomshardware.d...estberichte-241919-3.html

[spNk]

Tja alleen mogen we eigenlijk geen overclocked modellen vergelijken met reference kaarten . Daar word regelmatig op gehamerd, ook in het groene topic.

Desalniettemin een zeer interessante kaart natuurlijk.

[Sp3ci3s8472]

spNk schreef op maandag 05 oktober 2015 @ 20:33:
Tja alleen mogen we eigenlijk geen overclocked modellen vergelijken met reference kaarten . Daar word regelmatig op gehamerd, ook in het groene topic.

Desalniettemin een zeer interessante kaart natuurlijk.

Wilde het inderdaad opbrengen , tot ik zag dat ook de GTX970 een OC heeft. De vergelijking met de 290x is daardoor wel krom.

In ander nieuws:
AMD LiquidVR™ Technology Wins Prestigious Lumiere Award

[ Voor 16% gewijzigd door Sp3ci3s8472 op 07-10-2015 14:45 . Reden: nieuw nieuws ]

[LongBowNL]

Andere benchmarks dan, van Star Wars Battlefront. Een game van DICE en Electronic Arts, dus onderdeel van het Gaming Evolved programma van AMD.

http://www.guru3d.com/art...rformance-benchmarks.html

Kleine impressie:


Het testen is nog niet klaar vanwege de restricties die Origin legt op het verwisselen van hardware.

[ Voor 0% gewijzigd door LongBowNL op 07-10-2015 21:57 . Reden: interpunctie ]

[Sp3ci3s8472]

LongBowNL schreef op woensdag 07 oktober 2015 @ 21:42:
Andere benchmarks dan, van Star Wars Battlefront. Een game van DICE en Electronic Arts, dus onderdeel van het Gaming Evolved programma van AMD.

http://www.guru3d.com/art...rformance-benchmarks.html

Kleine impressie:
[afbeelding]

Het testen is nog niet klaar vanwege de restricties die Origin legt op het verwisselen van hardware.

Mooie scores voor het rode kamp .

Het is mij alleen niet duidelijk of er DX11 of DX12 wordt gebruikt, misschien dat ik daar overheen heb gelezen.

[haarbal]

Deze beta is nog niet dx12 geloof ik. Maar goed, als je even preload kan je het morgen zelf uitproberen.

[LongBowNL]

DX11. De DX12 patch wordt pas later dit jaar verwacht, net zoals het ging bij de voorgaande Battlefield (3 of 4) en Mantle.

[tomcatha]

kleine verschillen eigenlijk, Krijg het idee dat er ergens een bottleneck is.

[Verwijderd]

Het is ook nog maar een Beta, net als bij bf4 word de performance vast nog beter maar het ziet er al goed uit dik boven de 100fps op 1080p. Om 4 uur vandaag stat de open beta en je kunt de game al vast voorladen.


Ik lees her en der dat de game max dx 11.1 ondersteund in de beta.

[ Voor 14% gewijzigd door Verwijderd op 08-10-2015 07:06 ]

[Zeara]

Ziet er netjes uit ja.
Ik vind het wel frappant dat de 960 het zo veel slechter doet dan de 380/285.

[Verwijderd]

Vreemd? Het is een beta die nog heel erg geoptimaliseerd word, Dice kennende en Frostbite engine kennende. Of het moet deze keer zo zijn dat vram in deze game voor hickUp kunnen zorgen vanwege hoe het gebruikt word? Na een paar maand na de release ziet het er vast hele ander uit.

[Zeara]

Ik weet dat het een beta is en dat dit slechts een indicatie is voor end-performance. Maar de verschillen tussen de 980ti/Fury X, 970/290, 980/390x/290x zijn een stuk kleiner dan tussen de 960/380/285. En op die manier bedoelde ik het. Alles ligt dicht tegen elkaar aan, behalve de 960 tegenover de 380/285.

Enige reden die ik zo snel kan bedenken is dan dat misschien die 192 bit geheugenbus toch te weinig is voor frostbite.

[Verwijderd]

Dan is het nog raar want op 4k is de 960 weer sneller dus is het probleem ook niet echt de geheugenbus?

[hidde212]

Het lijkt me logisch dat voor een €200 kaart 4K resultaten niet echt representatief zijn. Ik denk overigens dat de reden voor de betere prestaties van de GTX960 bij 4K komen door de betere geheugencompressie bij nVidia.

[Zeara]

Verwijderd schreef op donderdag 08 oktober 2015 @ 11:29:
Dan is het nog raar want op 4k is de 960 weer sneller dus is het probleem ook niet echt de geheugenbus?

Ah ja, daar had ik totaal over heen gekeken. Ik vond die resolutie niet interessant voor die kaarten dus compleet gemist

Dan weet ik het ook niet direct.

[Phuncz]

http://wccftech.com/eta-ark-dx12-update-dev/

quote: Ark Developer

After we found out it was heavily dependent on drivers and the hardware vendors progress we slowed ours a bit. It's still being worked on, but we have no plans on releasing it until it at least runs better than the DX11 version. And that is a hard thing to generate an ETA for.

Heavily dependent on drivers ? Hardware vendors progress ?
Dit is toch wel heel erg opvallend, maar het lijkt wel de richting uit te gaan waarvoor ik al vreesde, dat Nvidia's issues met DX12 de implementatie van DX12 in games gaat tegenhouden. Hopelijk brengt Star Wars: Battlefront binnenkort wel DX12 support uit, die engine draait blijkbaar neutraal op beide merken.

[ Voor 4% gewijzigd door Phuncz op 08-10-2015 22:19 ]

[Sp3ci3s8472]

Phuncz schreef op donderdag 08 oktober 2015 @ 22:18:
http://wccftech.com/eta-ark-dx12-update-dev/


[...]

Heavily dependent on drivers ? Hardware vendors progress ?
Dit is toch wel heel erg opvallend, maar het lijkt wel de richting uit te gaan waarvoor ik al vreesde, dat Nvidia's issues met DX12 de implementatie van DX12 in games gaat tegenhouden. Hopelijk brengt Star Wars: Battlefront binnenkort wel DX12 support uit, die engine draait blijkbaar neutraal op beide merken.

The Way It's Meant to be Played™!

Eigenlijk denk ik dat DX12 ook prima op de AMD kaarten loopt maar de developers mogen het niet bij naam noemen en zeggen daarom vendors . Wat ook zou kunnen is dat het ook prima op Nv kaarten draait, alleen draait het beter op de AMD kaarten en dat kan natuurlijk niet in een Nv titel.

Als de developers de performance van AMD kaarten express gaan/lijken te bottlenecken dat laat ik deze titel mooi links liggen .

[Trygve]

Heavily dependent on drivers? Wonderlijk dit weer, DX12 zou juist veel minder afhankelijk zijn van titel-specifieke optimalisaties dan DX11. Ik geloof er weinig van, dit ruikt naar de boel zoveel mogelijk willen vertragen.

[Verwijderd]

Sp3ci3s8472 schreef op vrijdag 09 oktober 2015 @ 00:35:
[...]


The Way It's Meant to be Played™!

Eigenlijk denk ik dat DX12 ook prima op de AMD kaarten loopt maar de developers mogen het niet bij naam noemen en zeggen daarom vendors . Wat ook zou kunnen is dat het ook prima op Nv kaarten draait, alleen draait het beter op de AMD kaarten en dat kan natuurlijk niet in een Nv titel.

Als de developers de performance van AMD kaarten express gaan/lijken te bottlenecken dat laat ik deze titel mooi links liggen .

Het is een pro AMD game dus Nvidia heeft er niets mee te maken.
Nee maar zonder gekheid, deze game is serieus kapot draaid al zo brak ook. Ik denk niet dat dx 12 veel verschil zal maken zeker niet met ACE's het is namelijk meer gpu afhankelijk unreal kennende.

[ Voor 13% gewijzigd door Verwijderd op 09-10-2015 09:19 ]

[LongBowNL]

Q&A met Robert Hallock: https://community.amd.com/thread/189889

maverick
Hi there,

An Aquanox Dev said this: "We’d Do Async Compute Only With An Implementation That Doesn’t Limit NVIDIA Users". I'd like to hear your opinion on this statement.

rhallock
I imagine it's difficult to design an implementation for hardware that doesn't support the feature.

Maar er staan nog meer serieuzere antwoorden tussen.

[Help!!!!]

^
LOL @ rhallock response!

[Verwijderd]

Het is moeilijk inderdaad maar mogelijk anders zij hij wel dat het onmogelijk was haha.
Ik ben niet alleen maar benieuwd naar Ace performance, er zit mee in DirectX 12 en ben benieuwd wat het allemaal in de toekomst nog toevoegt. Iedereen heeft het maar over één ding en er is zo veel meer.

[ Voor 54% gewijzigd door Verwijderd op 09-10-2015 10:53 ]

[enchion]

T`is wachten op de console games en private opgezette indie games die naar de PC komen om te laten zien wat het werkelijke verschil is.

Console games die geen specifieke nVidia of AMD backing hebben, en de private funded indie games zoals No Mans Sky (hoewel daar al wel iemand van de marketing op gesprongen is lijkt me).

Dan kan natuurlijk het verschil nog steeds scheef zijn aan de hand van de capaciteit van de hardware omdat dat bedrijf een keuze heeft gemaakt om de "makkelijkste of meest doeltreffende of meest toekomstgerichte" implementatie te gebruiken ipv rekening te houden met alle mogelijkheden.

[Sp3ci3s8472]

Leuke Q&A .

Q:
monstercameron 08-Oct-2015 15:51 (in response to erin.maiorino)
What ever happened to the truaudio sdk.

A:
rhallock 08-Oct-2015 15:56 (in response to monstercameron)
I had a reply to this, but don't know where it went.

We bypassed the need for a TrueAudio SDK by building plugins and support directly into the off-the-shelf audio engines licensed by game devs. In the audio space, this is generally easier than giving them an SDK and telling them to design their own plugins for an engine they've already licensed.

Leuk om te zien dat TrueAudio nog steeds "aanwezig" is en makkelijker te bereiken voor devs.

[eL_Jay]

Sp3ci3s8472 schreef op vrijdag 09 oktober 2015 @ 14:20:
Leuke Q&A .


[...]


Leuk om te zien dat TrueAudio nog steeds "aanwezig" is en makkelijker te bereiken voor devs.

Zijn er ook niet sponsored devs mee aan de slag gegaan dan? Volgens mij is het net zo niche als Physx, TressFX en mantle (ergo wordt het alleen geimplementeerd als Nvidia/AMD er geld in pompen)

[Phuncz]

Verwijderd schreef op vrijdag 09 oktober 2015 @ 09:11:
[...]

Het is een pro AMD game dus Nvidia heeft er niets mee te maken.

Nvidia heeft misschien geen banden met de ontwikkelaar maar UE4 (Unreal Engine 4) waar deze game op draait, is overduidelijk geoptimaliseerd op Nvidia hardware.

En dan wordt dit wel duidelijker:

quote: Kaladinar

Can you explain exactly what's going on with the DX12 update? One month ago you said it was ready and it would have given 20% performance boost. Today, a developer of yours said there's no ETA and it won't be released until it's "at least better" than DX11.

quote: WC_Jesse

Trust me there are no conspiracy theories, here! DX12 is a new technology and it's very complicated even for the largest teams to get everything working smoothly. We care greatly about this but want the experience to be extremely polished and exactly what people expect. The DX11 technology the engine is built on is extremely mature and DX12 just isn't ready for us yet for a variety of reasons. It just comes down to other technical wins like server performance and general client optimization that apply to ALL users being our first priority for now.

Vrij duidelijk wie met die "ALL" bedoeld wordt.

quote: WC_Jesse

We will support Vulkan when UE4 fully supports it. So we didn't decide against it, it's just not ready for us yet. Trust me, I want Vulkan BAD as well as OS X Metal, because the graphics API is the big reason there is such a difference between Mac, Linux and the PC version of the game.

Ook weer duidelijk dat Studio Wildcard afhankelijk is van wat de engine ondersteund. Niets nieuws natuurlijk.

https://www.reddit.com/r/...ly_launched_early_access/

Terwijl Studio Wildcard misschien geen blaam treft, lijkt het me logisch dat de reden van de vertraging de Unreal Engine 4 is. Dan vind ik het niet bizar om te speculeren dat Nvidia aan Epic heeft gevraagd te wachten met DX12 te enablen zolang dat Nvidia niet tevreden is met de prestaties. En dat terwijl de UE4 developers al meer dan een jaar met DX12 bezig zijn:
http://blogs.nvidia.com/b...xwell-and-dx12-delivered/

Of het heeft met een ander aspect te maken, dat Nvidia's Kepler en Maxwell beperkt overweg kunnen met Async Compute, waar tot nog niet zolang geleden nog wazig over wordt gedaan. Aangezien de consoles en AMD's kaarten met GCN 1.x het wel ondersteunen, waren de ontwikkelaars er misschien vanuit gegaan dat Nvidia dat ook zou hebben.

[ Voor 7% gewijzigd door Phuncz op 09-10-2015 18:43 ]

[enchion]

Eigenlijk had AMD dus om het echt slim te spelen, wat bewuste "fouten" in de drivers kunnen stoppen om net iets langzamer te zijn dan nVidia op DX12.

Om dan bij de driver ten tijde van de game releases de fout te repareren.

[Jeroenneman]

enchion schreef op vrijdag 09 oktober 2015 @ 18:45:
Eigenlijk had AMD dus om het echt slim te spelen, wat bewuste "fouten" in de drivers kunnen stoppen om net iets langzamer te zijn dan nVidia op DX12.

Om dan bij de driver ten tijde van de game releases de fout te repareren.

DX12 is toch juist een low level API. Daarom zie je AMD ook veel meer voordeel hieruit halen. Nvidia had al goede drivers, en dat voordeel valt deels weg.

[Phuncz]

Async Compute draagt anders ook redelijk wat bij aan performance.

[SG]

Verwijderd schreef op vrijdag 09 oktober 2015 @ 10:48:
Het is moeilijk inderdaad maar mogelijk anders zij hij wel dat het onmogelijk was haha.
Ik ben niet alleen maar benieuwd naar Ace performance, er zit mee in DirectX 12 en ben benieuwd wat het allemaal in de toekomst nog toevoegt. Iedereen heeft het maar over één ding en er is zo veel meer.

Nou nee kwa feature set is DX11 gelijk aan DX12 met subtile verschillen en DX11.3 trek het aardig gelijk.
DX12 is dichter bij de hardware aan te sturen met dunne driver, dus puur voor effecientie en lost de cpu en driver overhead op.

Dus die ACE versterkt het doel van DX12 nog meer.
Maar ja dat komt pas tot zijn recht als je extreem CPU en dus drawcalls gaat toepassen.
En niet elke soort game zal flink meer drawcalls nodig hebben.
En krachtige CPU met hoge IPC zal ook aardig kunnen mee komen.

Jeroenneman schreef op vrijdag 09 oktober 2015 @ 18:47:
[...]


DX12 is toch juist een low level API. Daarom zie je AMD ook veel meer voordeel hieruit halen. Nvidia had al goede drivers, en dat voordeel valt deels weg.

Nvidia driver is kolosale software package met game detectie en shader recompiler dat heel veel doet en daar mee meer uit DX11 haalt. Ook past non ACE architectuur daar perfect bij. De reden dat AMD het minder doet in DX11 kan naast kleine driverteam budged ook de ACE architectuur zijn.

__________________

En ja nV agressieve style van zaken doen en performance kroon manie zal hun uiteraard lobbien om DX12 patches tegen te houden als hun ACE implementatie gewoon stuk minder is dan die van AMD.

[Verwijderd]

Phuncz schreef op vrijdag 09 oktober 2015 @ 18:36:
[...]


Terwijl Studio Wildcard misschien geen blaam treft, lijkt het me logisch dat de reden van de vertraging de Unreal Engine 4 is. Dan vind ik het niet bizar om te speculeren dat Nvidia aan Epic heeft gevraagd te wachten met DX12 te enablen zolang dat Nvidia niet tevreden is met de prestaties. En dat terwijl de UE4 developers al meer dan een jaar met DX12 bezig zijn:
http://blogs.nvidia.com/b...xwell-and-dx12-delivered/

Of het heeft met een ander aspect te maken, dat Nvidia's Kepler en Maxwell beperkt overweg kunnen met Async Compute, waar tot nog niet zolang geleden nog wazig over wordt gedaan. Aangezien de consoles en AMD's kaarten met GCN 1.x het wel ondersteunen, waren de ontwikkelaars er misschien vanuit gegaan dat Nvidia dat ook zou hebben.

Ik geloof er in ieder geval niet gelijk in wat je zegt ik geloof wat er staat over driver probleem zo wel bij nvidia als amd waar hun zelf aan moeten werken, zo word het gezegd en alu hoedjes doe ik niet aan sorry.

[Sp3ci3s8472]

Verwijderd schreef op zondag 11 oktober 2015 @ 11:14:
[...]


Ik geloof er in ieder geval niet gelijk in wat je zegt ik geloof wat er staat over driver probleem zo wel bij nvidia als amd waar hun zelf aan moeten werken, zo word het gezegd en alu hoedjes doe ik niet aan sorry.

Als dingen zoals Fable Legends en Ashes of the Singularity bij AMD goed draaien dan geloof ik niet in die zogenaamde driver problemen die ze zouden hebben. Bij Nvidia is het bekent dat ze geen Async Compute goed ondersteunden via de driver en dat het daarom bij AotS slechter draait. De Oxide Gaming heeft zelf aangegeven dat Nvidia nu aan de driver werkt omdat deels op te lossen.
Ik ben eerder geneigd te geloven dat Nvidia momenteel een slechtere driver heeft dan een game developer te geloven die GameWorks heeft geimplementeerd. Dat heeft niks met een alu hoedje te maken .

De driver van AMD is waarschijnlijk ook een stuk volwassener omdat ze gewoon alle ervaring die ze met Mantle hebben gekregen nu kunnen gebruiken.
Over het algemeen zijn de WHQL drivers van Nvidia minder stabiel dan die van AMD, dat er nog steeds iets heerst dat AMD slechtere drivers maakt is jammer.

[spNk]

Ach we weten toch allemaal dat Spliffire niet kan geloven dat AMD in sommige opzichten sneller/beter is dan Nvidia? Ik zou er niet eens woorden meer aan vuil maken .

[Nature]

Puur uit nieuwsgierigheid, in welke opzichten is AMD sneller/beter dan Nvidia? bedoel je met beter bang for buck? en dan sneller in wat voor opzicht moet ik dat zien?

[spNk]

Ze ondersteunen meer/andere features en zijn zoals het lijkt er sneller mee. Async compute in dit geval.

[Sp3ci3s8472]

Nature schreef op zondag 11 oktober 2015 @ 21:28:
Puur uit nieuwsgierigheid, in welke opzichten is AMD sneller/beter dan Nvidia? bedoel je met beter bang for buck? en dan sneller in wat voor opzicht moet ik dat zien?

Onder andere het lijstje wat spNk opnoemt en ze werken vaker aan nieuwe technieken. Waaronder GDDR3, GDDR5, HBM, Tesselation, Eyefinity, Mantle. Ze stappen sneller over naar kleinere process nodes.
Wat je zelf al aangeeft, ze hebben in de low-highend (niet ultra highend) betere bang for buck.

Ik heb Nvidia nog nooit een nieuwe geheugen standaard zien ontwikkelen. Nvidia is goed in het maken van proprietaire software en marketing (en omkoping? ), het ontwerpen van nieuwe hardware technieken ligt ze minder (GTX480 kuch kuch).

[Verwijderd]

spNk schreef op zondag 11 oktober 2015 @ 17:09:
Ach we weten toch allemaal dat Spliffire niet kan geloven dat AMD in sommige opzichten sneller/beter is dan Nvidia? Ik zou er niet eens woorden meer aan vuil maken .

Zeg ik ergens dat ik dat niet geloof AMD, waarom zo vooroordelen want ik ga niet gelijk in sprookjes verhalen geloven, zo ben ik namelijk niet tot er feiten zijn. Zo kan iedereen wel roepen wat er wel of niet aan de hand is, en als de game developer zegt dat het een dat probleem is vertrouw is daar eerder op dan een paar pro AMD gebruikers die er over vertellen.

Sp3ci3s8472 schreef op maandag 12 oktober 2015 @ 00:59:
[...]


Onder andere het lijstje wat spNk opnoemt en ze werken vaker aan nieuwe technieken. Waaronder GDDR3, GDDR5, HBM, Tesselation, Eyefinity, Mantle. Ze stappen sneller over naar kleinere process nodes.
Wat je zelf al aangeeft, ze hebben in de low-highend (niet ultra highend) betere bang for buck.

Ik heb Nvidia nog nooit een nieuwe geheugen standaard zien ontwikkelen. Nvidia is goed in het maken van proprietaire software en marketing (en omkoping? ), het ontwerpen van nieuwe hardware technieken ligt ze minder (GTX480 kuch kuch).

Kuch AMD heeft die geheugenstandaard ook niet ontwikkeld dat was Hynix ze laten lijken of AMD dat heeft ontwikkeld maar hebben er aan mee geholpen door het op hun kaarten te zetten Veder kan Nvidia er niets aan doen dat ze geen ACe's hebben en ontwikkelen ze zelf ook nieuwe standaard wat niet altijd afgesloten is zoals goede AA technieken als voorbeeld.

[ Voor 45% gewijzigd door Verwijderd op 12-10-2015 10:51 ]

[Zeara]

Volgens mij zijn er in het specifieke geval van ARK verschillende posts voorbij gekomen waar zowel Nvidia als AMD verbeteringen lieten zien bij DX12 ten op zichte van DX11. Alleen was de verbetering bij AMD 40% en bij Nvida "maar" 20%. Of natuurlijk rond die percentages. Bottom line was, beide gingen er op vooruit maar AMD meer.

Ik denk ook dat dat allemaal hier ergens was gepost.

[Verwijderd]

SLI werkte ook nog niet en CF ook niet in DX12 daar gooien ze het op las ik ergens.

[Sp3ci3s8472]

Verwijderd schreef op maandag 12 oktober 2015 @ 10:01:
[...]


Zeg ik ergens dat ik dat niet geloof AMD, waarom zo vooroordelen want ik ga niet gelijk in sprookjes verhalen geloven, zo ben ik namelijk niet tot er feiten zijn. Zo kan iedereen wel roepen wat er wel of niet aan de hand is, en als de game developer zegt dat het een dat probleem is vertrouw is daar eerder op dan een paar pro AMD gebruikers die er over vertellen.

Dat is het dus niet, wij beredeneren het op voorgaande informatie (of je dat gelooft is je eigen keuze). Nvidia blijkt in AotS hun drivers niet op orde te hebben en werken met de ontwikkelaar eraan om ze in orde te krijgen. Als een andere developer dan aangeeft dat "fabrikanten" hun drivers niet op orde hebben dan is het heel normaal dat het vingertje naar Nvidia gaat, de reden dat hij fabrikanten zegt is omdat ze in alliantie met Nvidia GameWorks implementeren en ze Nvidia wellicht geen slechte publiciteit willen geven.

Kuch AMD heeft die geheugenstandaard ook niet ontwikkeld dat was Hynix ze laten lijken of AMD dat heeft ontwikkeld maar hebben er aan mee geholpen door het op hun kaarten te zetten Veder kan Nvidia er niets aan doen dat ze geen ACe's hebben en ontwikkelen ze zelf ook nieuwe standaard wat niet altijd afgesloten is zoals goede AA technieken als voorbeeld.

Er staat duidelijk bij HBM dat het AMD en Hynix is. GDDR5 is door een werknemer bij AMD ontwikkelt. Dit is hier allemaal eerder gepost in dit topic.
Wat GDDR3 betreft ben ik niet zeker van want dat is al weer een hele tijd terug. Nvidia heeft zover ik weet aan geen enkele geheugen standaard (mee)gewerkt.

Goede AA technieken zoals? MFAA bestaat al eeuwen in de vorm van Temporal AA, dit had AMD al in hun 9xxx serie +/-15 jaar geleden. TXAA is een gedrocht, het ziet er niet uit (mijn mening) en is traag vergeleken met veel betere en voor iedereen toegankelijke technieken zoals SMAA. Over FXAA valt nog wat te zeggen ik vind dat er iets beter uitzien dan MLAA.
Die nieuwe AA technieken worden vaak uit papers geplukt en geimplementeerd, hoewel zowel AMD als Nvidia ook zelf research er naar doen zover ik weet.

Maar sinds wanneer is dit het verdedig "Nvidia topic" geworden? Geen probleem dat je in sommige gevallen wat tegengas (indien goed onderbouw/bron) geeft maar het begint wel heel erg eendradig te worden.
Als we bij elke post van ons een post van jouw krijgen met als inhoud "Ja, maar Nvidia kan dit ook" dan lijkt mij dit het verkeerde topic voor jou.

Zeara schreef op maandag 12 oktober 2015 @ 10:04:
Volgens mij zijn er in het specifieke geval van ARK verschillende posts voorbij gekomen waar zowel Nvidia als AMD verbeteringen lieten zien bij DX12 ten op zichte van DX11. Alleen was de verbetering bij AMD 40% en bij Nvida "maar" 20%. Of natuurlijk rond die percentages. Bottom line was, beide gingen er op vooruit maar AMD meer.

Ik denk ook dat dat allemaal hier ergens was gepost.

Dat is inderdaad een tijd terug gepost, een ontwikkelaar van Ark heeft dit "per ongeluk" op hun eigen forum gepost . Volgens mij was het meer performance voor AMD en weinig verschil voor Nvidia.

[Verwijderd]

Neem me niet kwalijk over HMB want ik weet zeker dat het al jaren terug in ontwikkeling was maar dat ging op stacked DRAM ergens rond 2006. Ik ben het er mee eens dat TXAA in veel gevallen er niet mooier op word maar doelde op FXAA en MFAA. TXAA is alleen mooi in GTA 5 van wat ik heb gezien en in Crysis 3 ziet het er slechter uit. daar werkt zelfs MSAA nog slechter dan FXAA of SMAA.
Dat ik verdedig klopt maar dat komt vooral door halve waarheden die de wereld in word geholpen word daar
soms wat kriegel door. maar dat ligt aan mezelf.

[ Voor 63% gewijzigd door Verwijderd op 12-10-2015 13:11 ]

[Verwijderd]

Verwijderd schreef op maandag 12 oktober 2015 @ 10:01:


Kuch AMD heeft die geheugenstandaard ook niet ontwikkeld dat was Hynix ze laten lijken of AMD dat heeft ontwikkeld maar hebben er aan mee geholpen door het op hun kaarten te zetten Veder kan Nvidia er niets aan doen dat ze geen ACe's hebben en ontwikkelen ze zelf ook nieuwe standaard wat niet altijd afgesloten is zoals goede AA technieken als voorbeeld.

over halve waarheden gesproken...

[Verwijderd]

Verwijderd schreef op maandag 12 oktober 2015 @ 13:41:
[...]


over halve waarheden gesproken...

Beter lezen ik kom er namelijk op terug

[Verwijderd]

Verwijderd schreef op maandag 12 oktober 2015 @ 13:56:
[...]


Beter lezen ik kom er namelijk op terug

Het idee is ook niet heel bijzonder, DRAM chips stacken om zo ruimte te besparen en hogere efficiente te verkrijgen.

Zo zijn er ook meerdere oplossing om dram te stacken, HBM is hier 1 van en AMD heeft zeker veel meegewerkt aan het realiseren hiervan.

Je kunt alles wel versimpelen door te zeggen dat het idee van stacked DRAM al veel eerder bestond ,maar dat betekend nog niet dat dit automatisch al geimplementeerd kan worden voor een videokaart, Hier zit veel meer werk en research achter, iets waar AMD zeker aan heeft mee geholpen.

Ik durf zelf te zeggen dat zonder AMD we nog lang geen HBM (voor videokaarten) of iets soortgelijks hadden op dit moment.

[Trygve]

Verwijderd schreef op maandag 12 oktober 2015 @ 14:09:
[...]


Het idee is ook niet heel bijzonder, DRAM chips stacken om zo ruimte te besparen en hogere efficiente te verkrijgen.

Zo zijn er ook meerdere oplossing om dram te stacken, HBM is hier 1 van en AMD heeft zeker veel meegewerkt aan het realiseren hiervan.

Je kunt alles wel versimpelen door te zeggen dat het idee van stacked DRAM al veel eerder bestond ,maar dat betekend nog niet dat dit automatisch al geimplementeerd kan worden voor een videokaart, Hier zit veel meer werk en research achter, iets waar AMD zeker aan heeft mee geholpen.

Ik durf zelf te zeggen dat zonder AMD we nog lang geen HBM (voor videokaarten) of iets soortgelijks hadden op dit moment.

HBM is inderdaad veel meer dan alleen reepjes RAM op elkaar stapelen. Het meest innovatieve dat voortgekomen is uit het partnerschap van AMD en Hynix is naar mijn mening toch wel de interposer (of eigenlijk TSV als geheel) waar GPU en geheugen op zitten, wat in dit geval zorgt voor uiterst lage latencies. En tenslotte nog die achterlijk brede geheugenbus Alleen heb ik nog geen gamebenchmark voorbij zien komen waarin de meerwaarde van die brede bus er echt uit springt.

[Xtr3me4me]

r100 schreef op maandag 12 oktober 2015 @ 16:13:
[...]


HBM is inderdaad veel meer dan alleen reepjes RAM op elkaar stapelen. Het meest innovatieve dat voortgekomen is uit het partnerschap van AMD en Hynix is naar mijn mening toch wel de interposer (of eigenlijk TSV als geheel) waar GPU en geheugen op zitten, wat in dit geval zorgt voor uiterst lage latencies. En tenslotte nog die achterlijk brede geheugenbus Alleen heb ik nog geen gamebenchmark voorbij zien komen waarin de meerwaarde van die brede bus er echt uit springt.

Klopt, omdat er nog geen enkele game bestaat die ontwikkelt is en gebruik maakt van de volle potentie van deze grote brede geheugenbus.
Games zijn wel heel wat meer afhankelijk dan een leuke brede geheugenbus, laat ik het zo zeggen dat de GPU hier baat bij moet hebben op basis van de instructie wat de GPU krijgt.

DX12 laat zien wat de mogelijkheden zijn, maar zowel Nvidia nog AMD zijn bij lange nog niet klaar voor de volle potentie van DX12, waarbij rendering zoveel malen hoger ligt, dat we tegen de tijd de volle potentie van DX12 kunnen gebruiken, we al 4 generaties verder zijn.

Zelfs 4 titans hadden moeite met de Witcher cry demo. Nee, we zijn nog niet gereed om de volle kracht van DX12 te benutten.
Dus allemaal heel erg leuk die HBM1 en HBM2, maar de kracht van de GPU is gewoon weg niet zover.
En nee, ook niet met Pascal en die andere generatie van AMD. Als je kijkt de voorgaande jaren en je volgt het patroon en de nieuwe techniek op basis van steeds nieuwe DX, zul je ook wel inzien dat deze generatie meer een "trail" versie is voor DX12.

just my 2 cents

[spNk]

r100 schreef op maandag 12 oktober 2015 @ 16:13:
[...]
En tenslotte nog die achterlijk brede geheugenbus Alleen heb ik nog geen gamebenchmark voorbij zien komen waarin de meerwaarde van die brede bus er echt uit springt.

Mwa, het RAM hoeft door die brede bus maar op 500mhz te draaien .

[haarbal]

r100 schreef op maandag 12 oktober 2015 @ 16:13:
HBM is inderdaad veel meer dan alleen reepjes RAM op elkaar stapelen. Het meest innovatieve dat voortgekomen is uit het partnerschap van AMD en Hynix is naar mijn mening toch wel de interposer (of eigenlijk TSV als geheel) waar GPU en geheugen op zitten, wat in dit geval zorgt voor uiterst lage latencies. En tenslotte nog die achterlijk brede geheugenbus Alleen heb ik nog geen gamebenchmark voorbij zien komen waarin de meerwaarde van die brede bus er echt uit springt.

De meerwaarde van HBM is dat je enorme bandbreedte met laag verbruik kan realiseren, zonder veel van de gpu chip op te offeren aan de memory interface.

Iets lagere latency is misschien mooi meegenomen, maar niet cruciaal, en de breedte van een bus is totaal onbelangrijk, het gaat om de bandbreedte.

[Sp3ci3s8472]

haarbal schreef op maandag 12 oktober 2015 @ 16:55:
[...]

De meerwaarde van HBM is dat je enorme bandbreedte met laag verbruik kan realiseren, zonder veel van de gpu chip op te offeren aan de memory interface.

Iets lagere latency is misschien mooi meegenomen, maar niet cruciaal, en de breedte van een bus is totaal onbelangrijk, het gaat om de bandbreedte.

Inderdaad!

Nog een voordeel van HBM is dat je het PCB kleiner kan maken en dat het veel makkelijker is om te ontwerpen (minder complex). Waarschijnlijk heb je niet meer heel veel PCB lagen nodig indien je HBM gebruikt.
We zitten nu redelijk op het einde van GDDR5, het had wellicht nog 1 a 2 generaties mee kunnen gaan in de highend maar daarna houdt het op. Een PCB met een 512 geheugenbus is moeilijk om te ontwerpen, een met 1024 lijkt mij niet valide. Je moet voor zorgen dat elk lijntje van je GPU naar je geheugen even lang is zodat de latency gelijk is, met grotere bussen is dat moeilijker.

[Trygve]

haarbal schreef op maandag 12 oktober 2015 @ 16:55:
[...]

De meerwaarde van HBM is dat je enorme bandbreedte met laag verbruik kan realiseren, zonder veel van de gpu chip op te offeren aan de memory interface.

Iets lagere latency is misschien mooi meegenomen, maar niet cruciaal, en de breedte van een bus is totaal onbelangrijk, het gaat om de bandbreedte.

Woops, ik bedoelde inderdaad de bandbreedte, niet de busbreedte. Overigens is die busbreedte wel interessant omdat het geheugen minder hard hoeft te lopen om dezelfde bandbreedte als GDDR5 te krijgen. Dat is ze nu al ruim gelukt, dus we gaan nog zien hoeveel hoger het geheugen komend jaar gaat zijn op nieuwe kaarten.

@Sp3ci3s8472: misschien zitten we wel op het einde van GDDR5 voor high-end kaarten, maar ik kan mij niet voorstellen dat de volgende serie van nVidia en AMD ook al HBM gebruikt in het midrange segment. Daarvoor zullen de totale kosten van een kaart met HBM nog te hoog zijn denk ik.

[haarbal]

Sp3ci3s8472 schreef op maandag 12 oktober 2015 @ 17:07:
Inderdaad!

Nog een voordeel van HBM is dat je het PCB kleiner kan maken en dat het veel makkelijker is om te ontwerpen (minder complex). Waarschijnlijk heb je niet meer heel veel PCB lagen nodig indien je HBM gebruikt.
We zitten nu redelijk op het einde van GDDR5, het had wellicht nog 1 a 2 generaties mee kunnen gaan in de highend maar daarna houdt het op. Een PCB met een 512 geheugenbus is moeilijk om te ontwerpen, een met 1024 lijkt mij niet valide. Je moet voor zorgen dat elk lijntje van je GPU naar je geheugen even lang is zodat de latency gelijk is, met grotere bussen is dat moeilijker.

Je bespaart op je PCB, maar je moet helaas wel een interposer maken.

[Sp3ci3s8472]

r100 schreef op maandag 12 oktober 2015 @ 17:20:
[...]


Woops, ik bedoelde inderdaad de bandbreedte, niet de busbreedte. Overigens is die busbreedte wel interessant omdat het geheugen minder hard hoeft te lopen om dezelfde bandbreedte als GDDR5 te krijgen. Dat is ze nu al ruim gelukt, dus we gaan nog zien hoeveel hoger het geheugen komend jaar gaat zijn op nieuwe kaarten.

@Sp3ci3s8472: misschien zitten we wel op het einde van GDDR5 voor high-end kaarten, maar ik kan mij niet voorstellen dat de volgende serie van nVidia en AMD ook al HBM gebruikt in het midrange segment. Daarvoor zullen de totale kosten van een kaart met HBM nog te hoog zijn denk ik.

Daarom zei ik ook highend . Voor de midend kaarten is het zeker nog een tijdje mogelijk. GDDR5 is helaas wel iets onzuiniger dan HBM, en het is juist leuk als midend kaarten zuinig zijn.

@haarbal
Inderdaad de extra kosten daarvoor had ik even over het hoofd gezien. Een interposer kan gelukkig op een groter procedé worden gemaakt en als Nvidia en AMD interposers nodig gaan hebben dan zou dit misschien de kosten kunnen drukkken?

[LongBowNL]

Nieuwe NIET officiële driver: http://forums.guru3d.com/showthread.php?t=403070
(Install at own risk!)

[Nature]

spNk schreef op zondag 11 oktober 2015 @ 23:05:
Ze ondersteunen meer/andere features en zijn zoals het lijkt er sneller mee. Async compute in dit geval.

Nvidia heeft wel Async compute zij hebben er alleen nog geen (goede) driver waarom zouden ze ook voor een benchmark, AMD zal betere Async hebben voorzover ik heb gelezen omdat AMD zowiezo meer inzet op compute zag je ook aan de crypto-coin mining tijd.
AMD zal wat meer extra performance krijgen dan Nvidia in DX12, Nvidia zal wat visuele extraatjes krijgen door DX12 daar kunnen ze misschien weer wat van maken om toe te voegen aan GW, deze visuele dingen kan AMD weer softwarematig emuleren maar wel weer met performance hit.
Hier heb ik de enige echt complete nuttige info vandaan die ik tot nu toe heb gezien:
http://wccftech.com/nvidi...ist-features-explained/3/

AMD:
Lets start with AMD’s edge. Since I will be tackling Async shaders on the next page, lets start with Resource Binding. Resource Binding is basically, the process of linking resources (such as textures, vertex buffers, index buffers) to the graphics pipeline so that the shaders can process the resource. This means that AMD’s architecture is mostly limited only by memory and while this is a desirable trait, it is something that will happen out of sight, without translating to anything a gamer can observe on-screen.

Nvidia:
''Finally, we come to Nvidia. Nvidia has something that no other IHV currently has: and that is Conservative Rasterization and Raster Order Views. While the qualifying requirement is only Tier 1, GM200 has Tier 2 Conservative Rasterization support.
Here is the thing however, Conservative Rasterization is a technique that samples pixels on screen based on the primitive in question and is much more accurate than conventional rasterization – in other words, it will make a difference to the end user in the form of special graphical effects. Conservative Raster itself will give way to many interesting graphical techniques – Hybrid Ray Traced Shadows for one.

Sp3ci3s8472 schreef op maandag 12 oktober 2015 @ 00:59:
Onder andere het lijstje wat spNk opnoemt en ze werken vaker aan nieuwe technieken. Waaronder GDDR3, GDDR5, HBM, Tesselation, Eyefinity, Mantle. Ze stappen sneller over naar kleinere process nodes.
Wat je zelf al aangeeft, ze hebben in de low-highend (niet ultra highend) betere bang for buck.

Ik heb Nvidia nog nooit een nieuwe geheugen standaard zien ontwikkelen. Nvidia is goed in het maken van proprietaire software en marketing (en omkoping? ), het ontwerpen van nieuwe hardware technieken ligt ze minder (GTX480 kuch kuch).

AMD is wel ondergewaardeerd wat dat betreft, omkoping nou ik durf eigenlijk wel te zeggen dat het niet gebeurd, als het gebeurd moet er al iemand naar buiten zijn gekomen denk ik want er zijn zo veel mensen bij betrokken.
Wel maakt Nvidia het programmeren wel makkelijker voor ontwikkelaars in de zin dat je een halfbakken produkt kan uitbrengen en dat Nvidia er wel wat van maakt met hun drivers, ik heb wel eens gehoord ik weet niet of het waar is maar dat het R&D budget voor 60% aan hardware en 40% aan software besteed wordt. En programmeer meer met met tessellation omdat Nvidia dat gebruikt dan draait je game op +/-70% van de PC's goed en dat wordt meer omdat er extreem veel meer Nvidia kaarten worden verkocht.

[LongBowNL]

En dan nu wel de officiële driver 15.10:
http://support.amd.com/en...atalyst-windows-beta.aspx

De problemen met de 390-series zijn nu hopelijk opgelost.

[Verwijderd]

Phil Rogers AMD Fellow Jumps Ship to NVIDIA
http://hardocp.com/news/2...p_to_nvidia/#.Vh34qOjtlBc

Hij ruikt vast geld. Als ik hier een persoonlijke mening over mag geven vind ik dat dit soort mensen nooit voor de tegenpartij mogen gaan werken. Het gaat zo vaak fout door belangrijke zaken door te spelen.

[marcop82]

We denken bij dit soort jump-ships altijd dat men dit het doet voor de kansen of het geld, soms is het ook omdat de werksfeer in de groep niet goed is of omdat men niet goed kan functioneren met de bedrijfsregels.
Wat opvalt is dat dit weeral een hoge functie is die het bedrijf verlaat nadat het principiele werk gedaan is, HSA in dit geval.

[Help!!!!]

Tja, die man werkt al een eeuwigheid voor ATI/AMD. Mag hij dan nooit ergens anders gaan werken

Zie hem liever ook niet naar nVidia gaan maar je kan niet verwachten dat ie voor altijd bij AMD blijft denk ik.

[Jeroenneman]

Verwijderd schreef op woensdag 14 oktober 2015 @ 08:41:
Phil Rogers AMD Fellow Jumps Ship to NVIDIA
http://hardocp.com/news/2...p_to_nvidia/#.Vh34qOjtlBc

Hij ruikt vast geld. Als ik hier een persoonlijke mening over mag geven vind ik dat dit soort mensen nooit voor de tegenpartij mogen gaan werken. Het gaat zo vaak fout door belangrijke zaken door te spelen.

Tja, als AMD dat niet wilde hadden ze best een clausule in het contract kunnen opnemen.

Niet geheel ongebruikelijk in deze bedrijven.