CJ's Radeon Info & Nieuwsdiscussie - Deel 125

[Verwijderd]

@Toettoetdaan; Uit die review is dit de conclusie bij BF3:

What is the total takeaway from our first set of results from Frame Rating, on Battlefield 3? First, if we look at only single GPU solutions, the GTX 680 falls behind the Radeon HD 7970 in average frame rate while exhibiting no more frame time variance or stutter. For SLI and CrossFire though, there isn’t even a debate and the real-world value of adding a second HD 7970 to your system is near zero. That’s a tough pill to swallow for any gamers out there with two cards already in their system and I expect we will get some hate-fueled email and comments on the subject but the data is true and matches our game play testing experiences.

Verbijsterende conclusie rond HD7970 CF bij deze game...

Nouja, overall eigenlijk;

It should come as no surprise that AMD was only recently made aware of these performance issues and was kind of stunned to find out how bad they were. The truth is that AMD could “hack” together a fix to make our frame time graphs look better but it would likely be a solution that introduced more problems than answers without doing the research required to get it right. The driver team has told me several times over the past two weeks that they should have a testable driver to fix the CrossFire problems “in 2 to 3 months.” Until then, buyers that consider a multi-GPU solution a goal or a requirement will want to seriously debate dropping Radeon cards from consideration.

[ Voor 32% gewijzigd door Verwijderd op 27-03-2013 19:35 ]

[Verwijderd]

Zelf heb ik nooit echt verschil tussen nvidia gpu's en AMD gpu's qua soepelheid opgemerkt (crossfire en sli) en ik denk dat het voor de meeste mensen zo geldt. Mensen die het opmerken willen ook geen sli.

[AquaSheep]

Wat ik trouwens nog niet helemaal begrijp is wat het effect is van micro-stuttering boven de refreshrate van een monitor. Stel je hebt een 60Hz monitor, dus elke 16ms refresht je monitor. Je videokaart output elke 10±5ms ruim boven de refreshrate van je monitor, dan heb je toch last van tearing ipv micro-stuttering? Omdat je dan meerdere GPU frames in je monitor frame stopt zou je toch niet zien dat een frame 15ms duurt en de volgende 5ms.

[DrBreakalot]

Bij dat soort framerates zal je de microstuttering waarschijnlijk als tearing zien, inderdaad. Treed er echter microstuttering op bij framerates van rond 60 fps en lager, zijn sommige frames meer dan één refreshcycle van je monitor te zien.

[Astennu]

Verwijderd schreef op woensdag 27 maart 2013 @ 19:39:
Zelf heb ik nooit echt verschil tussen nvidia gpu's en AMD gpu's qua soepelheid opgemerkt (crossfire en sli) en ik denk dat het voor de meeste mensen zo geldt. Mensen die het opmerken willen ook geen sli.

Inderdaad. Het is misschien iets constanter met SLI maar nog steeds meer dan met een single card.

Dat FCAT ziet er trouwens goed uit! ik ben erg benieuwd naar het 2e deel waar de benshmark resultaten getoond gaan worden.

[Werelds]

AquaSheep schreef op woensdag 27 maart 2013 @ 22:26:
Wat ik trouwens nog niet helemaal begrijp is wat het effect is van micro-stuttering boven de refreshrate van een monitor. Stel je hebt een 60Hz monitor, dus elke 16ms refresht je monitor. Je videokaart output elke 10±5ms ruim boven de refreshrate van je monitor, dan heb je toch last van tearing ipv micro-stuttering? Omdat je dan meerdere GPU frames in je monitor frame stopt zou je toch niet zien dat een frame 15ms duurt en de volgende 5ms.

Nee, het zijn twee losstaande dingen die tegelijkertijd kunnen optreden. Microstuttering zie je aan de daadwerkelijke beelden (alles maakt een "sprongetje" in-game, duidelijk dat er iets mist). Daar bovenop kun je ook nog tearing krijgen ja.

[Tyranium]

Help!!!! schreef op woensdag 27 maart 2013 @ 15:29:

Vervolg PCPER: Frame Rating Dissected: Full Details on Capture-based Graphics Performance Testing:

http://www.pcper.com/revi...aphics-Performance-Testin

Drivers used:
AMD: 13.2 beta 7
NVIDIA: 314.07 beta

Erg interessant allemaal. GPU testing gaat echt een ander verhaal worden

De resultaten uit die test zijn toch wel dramatisch voor AMD te noemen. Een paar voorbeelden:

Remember that the Observed FPS takes out runts and drops and is the result and benefit of measuring performance with our new Frame Rating system. Clearly the advantages that CrossFire appeared to have over SLI in the first result nearly completely negated and in many cases the observed performance of a two card HD 7970 configuration is no better than that of a single card.

The same cannot be said for NVIDIA’s SLI though – the frames are presented to the gamer in a consistent pattern that indicates good scaling and that looks nearly identical to that of the first FRAPS-based graph.

Not only a lower observed frame rate but a frame rate that is LOWER than the single card! I can tell you from first-hand experience that this definitely was the case in play through as well; it felt slower than the single card experience.

Hun conclusie is ook alles behalve positief:

....In half of our tested games, the pair of Radeon HD 7970s in CrossFire showed no appreciable measured or observed increase in performance compared to a single HD 7970. I cannot overstate that point more precisely: our results showed that in Battlefield 3, Crysis 3 and Sleeping Dogs, adding in another $400+ Radeon HD 7970 did nothing to improve your gaming experience, and in some cases made it worse by introducing frame time variances that lead to stutter....

Zie ik het nou fout of kunnen de voorgaande CF resultaten in reviews eigenlijk gewoon de prullenbak in?

[Help!!!!]

^
Obv hun testmethoden wel. In sommige games is het iets minder erg en V-Sync oplossingen helpen ook wel wat.

Belangrijk is ook dat, obv deze test en deze games, de Single GPU's geen probleem meer hebben!!!
De 7970GE is zelfs ietsje beter dan een 680.

nVidia heeft duidelik een groot voordeel op Multi GPU gebied. Zij zijn hier blijkbaar al veel langer mee bezig dan AMD voor wie het eigenlijk als een verassing komt wat een behoorlijke blamage is. Getuige ook nVidia's (hardware) framemetering functionaliteit die goed lijkt te werken.

Ook PC PER heeft hun FCAT artikel inmiddels online: http://techreport.com/rev...dia-frame-capture-tools/2

Interessante quote:

To our surprise, Petersen had obviously been working on these matters before we spoke, because he very quickly produced a fairly robust presentation related to micro-stuttering and Fraps captures. That was about a year and a half ago. Turns out Peteresen and his team have been working on FCAT tools for about two years.

Hele interessante pagina, die imo aantoont dat Fraps data zeker nog niet in de prullenbak thuishoort !!

http://techreport.com/rev...dia-frame-capture-tools/6

[ Voor 44% gewijzigd door Help!!!! op 28-03-2013 13:37 ]

[AquaSheep]

Werelds schreef op donderdag 28 maart 2013 @ 09:17:
[...]

Nee, het zijn twee losstaande dingen die tegelijkertijd kunnen optreden. Microstuttering zie je aan de daadwerkelijke beelden (alles maakt een "sprongetje" in-game, duidelijk dat er iets mist). Daar bovenop kun je ook nog tearing krijgen ja.

Dat "sprongetje" komt doordat een frame net wat langer op het scherm blijft (boven de refreshcycle van je monitor) en daarna wordt opgevolgd door een snelle frame. Boven de refreshrate heb je dat probleem toch niet? Als voorbeeld dit plaatje: http://techreport.com/r.x/frame-capture/skyrim-2runts.jpg. Je ziet meerdere frames met een groot verschil in frame times in een monitor frame. Doordat de frame times van je GPU output lager liggen dan de refreshrate van je monitor, zal een GPU frame dus nooit langer dan een refreshcycle op je monitor blijven. Wat je krijgt is een soort van micro-tearing ipv micro-stuttering en die micro-tearing is iets wat je misschien niet eens opvalt.

Het effect van een grote variantie in frame times boven de refreshrate van je monitor is dat de geobserveerde FPS flink lager ligt dan de FRAPS FPS. Niet zozeer micro-stuttering. Onder de refreshrate van je monitor leidt een grote variantie in frame times weer wel tot micro-stuttering.

[Toettoetdaan]

Toettoetdaan schreef op woensdag 27 maart 2013 @ 17:19:
Jammer dat nVidia's 'metering' functionaliteit niet uit kan, zodat ze SLI en CF beter kunnen vergelijken.

Help!!!! schreef op woensdag 27 maart 2013 @ 17:32:
Zeker de dual GPU AMD kaarten zijn vooralsnog obv dit artikel een grote no-go helaas. Lullig voor de 7990 en erg hard voor de CF bezitters....

Verwijderd schreef op woensdag 27 maart 2013 @ 19:12:
Verbijsterende conclusie rond HD7970 CF bij deze game...

Astennu schreef op donderdag 28 maart 2013 @ 07:46:
Inderdaad. Het is misschien iets constanter met SLI maar nog steeds meer dan met een single card.

Tyranium schreef op donderdag 28 maart 2013 @ 12:30:
De resultaten uit die test zijn toch wel dramatisch voor AMD te noemen. Een paar voorbeelden:
Hun conclusie is ook alles behalve positief:

[...]

Zie ik het nou fout of kunnen de voorgaande CF resultaten in reviews eigenlijk gewoon de prullenbak in?

Help!!!! schreef op donderdag 28 maart 2013 @ 12:51:
nVidia heeft duidelik een groot voordeel op Multi GPU gebied. Zij zijn hier blijkbaar al veel langer mee bezig dan AMD voor wie het eigenlijk als een verassing komt wat een behoorlijke blamage is. Getuige ook nVidia's (hardware) framemetering functionaliteit die goed lijkt te werken.

The FCAT analysis has shown us that Nvidia's frame metering tech for SLI does seem to work as advertised. Frame metering isn't necessarily a perfect solution, because it does insert some tiny delays into the rendering-and-display pipeline. Those delays may create timing discontinuities between the game simulation time—and thus frame content—and the display time. They also add a minuscule bit to the lag between user input and visual response. But then there's apparently a fair amount of low-stakes timing slop in PC graphics, as the gap between our Fraps and FCAT results (in everything but the Unreal-engine-based Borderlands 2) has demonstrated. The best thing we can say for frame metering is that it makes the Fraps and FCAT times for SLI solutions appear to correlate about like they do for single-GPU solutions. That's a really high-concept way of saying that it appears to work pretty well.

Bron: http://techreport.com/rev...ia-frame-capture-tools/11

Iedereen die alleen naar de grafieken kijkt denk dat het bij AMD hevig mis is en bij nVidia alles top draait, maar dat hoef helemaal niet zo te zijn!
nVidia vertraagt gewoon de frames die snel klaar zijn zodat er een vloeiendere frame output ontstaat, maar dat maakt het beeld niet vloeiender, alleen de grafiekjes.

Dus zolang die functionaliteit niet uit kan, of zolang er niet gemeten wordt hoe lang een frame in de pipeline zit, kunnen we CF en SLI niet vergelijken helaas.

We kunnen natuurlijk nog steeds zeggen dat AMD een hoop werk te doen heeft en dat ik uitkijk naar de drivers van juni, waarin al een aantal verbeteringen moet zitten.

[Verwijderd]

The secret to NVIDIA’s success lies it the hardware frame metering technology that it has built into the SLI infrastructure since the beginning, but is only just recently coming to light.

http://www.pcper.com/revi...aphics-Performance-Tes-12

Ik hoop juist niet dat hier door mensen bij AMD weg blijven want zoals ik merkte het niet met CF.
Het is alleen in grafiekjes goed te zien maar het gaat uit eindelijk er om hoe je gameplay ervaring is.

[ Voor 24% gewijzigd door Verwijderd op 28-03-2013 14:07 ]

[Help!!!!]

Toettoetdaan schreef op donderdag 28 maart 2013 @ 13:49:
...........
Bron: http://techreport.com/rev...ia-frame-capture-tools/11

Iedereen die alleen naar de grafieken kijkt denk dat het bij AMD hevig mis is en bij nVidia alles top draait, maar dat hoef helemaal niet zo te zijn!
nVidia vertraagt gewoon de frames die snel klaar zijn zodat er een vloeiendere frame output ontstaat, maar dat maakt het beeld niet vloeiender, alleen de grafiekjes.

Dus zolang die functionaliteit niet uit kan, of zolang er niet gemeten wordt hoe lang een frame in de pipeline zit, kunnen we CF en SLI niet vergelijken helaas.

We kunnen natuurlijk nog steeds zeggen dat AMD een hoop werk te doen heeft en dat ik uitkijk naar de drivers van juni, waarin al een aantal verbeteringen moet zitten.

Er is wellicht ook geen perfecte oplossing tav de issues die Multi-GPU met zich meebrengt.

Dat CF en SLI niet vergeleken kan worden zolang frame metering niet uit kan is imo zeker niet correct.
Alleen de filmpjes tonen het verschil voor mij gewoon al duidelijk aan. HardOCP bijv. roept dit ook al tijden. (SLI appears more fluid than CF).

Frame Metering introduceert wellicht zijn eigen nadelen maar tot nu toe wegen die blijkbaar ruimschoots op tegen de voordelen. Ik denk dat AMD heeeeel druk bezig is iets vergelijkbaars te creeeren.

ps: Het zou natuurlijk wel interessant zijn als AMD en nVidia zonder frame metering zouden kunnen worden vergeleken. Denk alleen dat nVidia dit zeker niet toe gaat staan.


At the end of the day gaat het imo verder niet om FPS, FCAT, Frame metering or whatever maar om hoe vloeiend je het beeld op je scherm ervaart.
De winst van deze hele ontwikkeling is dat de focus weer meer daar naar toe gaat.

[ Voor 13% gewijzigd door Help!!!! op 28-03-2013 14:25 ]

[Toettoetdaan]

Help!!!! schreef op donderdag 28 maart 2013 @ 14:07:
[...]

Frame Metering introduceert wellicht zijn eigen nadelen maar tot nu toe wegen die blijkbaar ruimschoots op tegen de voordelen. Ik denk dat AMD heeeeel druk bezig is iets vergelijkbaars te creeeren.

ps: Het zou natuurlijk wel interessant zijn als AMD en nVidia zonder frame metering zouden kunnen worden vergeleken. Denk alleen dat nVidia dit zeker niet toe gaat staan.

Misschien is een langer stilstaand beeld in der daad storender dan een beeld wat qua tijd niet helemaal klopt.
Uiteindelijk gaat het om de ervaring

AMD had in de tijd van de RV770 al een 'side-port' in de chip, de was bedoeld voor de dual-gpu kaart om zo micro-stuttering tegen te gaan en meer gebruik te maken van andere render methoden.

Uiteindelijk hebben ze deze functionaliteit -om stroomverbruik te beperken- nooit geactiveerd in de drivers, toen ABI's ook de 'site-port' in de HD4870X2 kaarten fysiek niet meer verbonden was de functionaliteit eigenlijk dood.
In het ontwerp van de RV870(HD5970) zat de 'side-poort' ook, maar omdat ze het ontwerp moesten verkleinen hebben ze dat eruit gesloopt.

Wie weet zien we het nog eens terug:

Sideport would have been useful in RV870, but it’s unfortunately not there. Although he did tell me not to be surprised if I saw Sideport again at some point. Carrell doesn’t give up easily.

Bron: http://www.anandtech.com/show/2937/5

[Help!!!!]

^
Inderdaad dat herinner ik me nog. Zou wel interessant zijn om te zien hoeveel verschil een werkende Sideport zou maken.

Denk verder dat er nog een hoop te onderzoeken valt en methoden ontwikkelen om e.e.a. inzichtelijk te houden voor de lezers. De reviews worden behoorlijk complex zo. Laat staan de enorme kosten in tijd en geld voor de review sites zelf om dit op te pakken.

[Toettoetdaan]

In der daad, deze methode is echt best wel omslachtig en duur, qua tijd en geld.
Ook is heel veel informatie voor de normale lezer niet interessant.

Het liefst zie ik gewoon de 'Observet FPS' grafiek van PCPER in de style van de benches van HardOCP. (dus dan voor de volledige scene/bench en niet de eerste 1500 frames of de eerste 60 seconde).

[Werelds]

AquaSheep schreef op donderdag 28 maart 2013 @ 13:45:
[...]

Dat "sprongetje" komt doordat een frame net wat langer op het scherm blijft (boven de refreshcycle van je monitor) en daarna wordt opgevolgd door een snelle frame. Boven de refreshrate heb je dat probleem toch niet? Als voorbeeld dit plaatje: http://techreport.com/r.x/frame-capture/skyrim-2runts.jpg. Je ziet meerdere frames met een groot verschil in frame times in een monitor frame. Doordat de frame times van je GPU output lager liggen dan de refreshrate van je monitor, zal een GPU frame dus nooit langer dan een refreshcycle op je monitor blijven. Wat je krijgt is een soort van micro-tearing ipv micro-stuttering en die micro-tearing is iets wat je misschien niet eens opvalt.

Het effect van een grote variantie in frame times boven de refreshrate van je monitor is dat de geobserveerde FPS flink lager ligt dan de FRAPS FPS. Niet zozeer micro-stuttering. Onder de refreshrate van je monitor leidt een grote variantie in frame times weer wel tot micro-stuttering.

Nee, want er worden frames gedropt tussen die cycles in. Het zijn twee compleet verschillende verschijnselen.

Neem een vierkant blok dat met constante snelheid van links naar rechts beweegt. De afstand die dat ding tussen frames 1 en 2 aflegt is dezelfde als tussen 2 en 3, 3 en 4, enzovoort. Tearing is als er tegelijkertijd frames 2 en 3 bijvoorbeeld worden weer gegeven; een deel van het blok loopt dan voor op de rest en jij krijgt een rare vorm te zien. Dit is waar V-Sync te pas komt, dan wordt alleen op die refresh cycle van de monitor een nieuw frame gebruikt (zonder V-Sync wordt er constant naar de buffer geschreven).

Microstuttering daarentegen is als frame 3 langer nodig heeft om te renderen dan frames 2 en 4; dan is de snelheid die jij op het scherm te zien krijgt dus niet constant, want de afstand die je te zien krijgt tussen 2 en 3 en vervolgens tussen 3 en 4 is anders. Het blok maakt dan een sprongetje op jouw scherm, hoewel het wel de bedoeling was dat hij constant bewoog.

Die twee kunnen dus ook tegelijk plaats vinden als er na zo'n traag frame meerdere snelle frames volgen. Het gevolg is dat je dan eerst dat blok in twee delen ziet en vervolgens beide delen onevenredig vooruitspringen. De twee doen zich dan ook op andere plekken voor in het hele proces (screen tearing komt *uit* de buffer, micro stuttering gaat *in* de buffer). Waar tearing een directe relatie heeft met framerate, heeft microstuttering dat niet. Bij lage framerates krijg jij nooit tearing te zien, maar kun je wel nog steeds microstuttering krijgen. Bij hoge framerates kunnen beide zich voordoen. Vandaar ook dat de oplossingen (voor zover dat mogelijk is in elk geval) voor beide anders zijn.

[Toettoetdaan]

Een paar pagina's terug hadden we het nog over Havok, dus dit is misschien wel interessant: Havok brings Anarchy to GDC

The biggest thing is that Project Anarchy is free to publish on iOS and Android, but you pay for other platforms. That would be consoles, Windows the larger, and other desktop OSes, but not Wince.

Het is nog niet dood dus

[SG]

Ik ben ook dat TressFX aan het volgen wat in de Tomb Raider game is toegepast. Wat realistischer haar op DX11 kaartjes. Direct Compute!

[Springstof]

Het vermoeden van de consumenten die voor nVidia kozen omdat ze vonden dat zij een betere ondersteuning van hun producten bieden blijkt nu dus gegrond.

[Hekking]

Toettoetdaan schreef op donderdag 28 maart 2013 @ 13:49:
Bron: http://techreport.com/rev...ia-frame-capture-tools/11

Iedereen die alleen naar de grafieken kijkt denk dat het bij AMD hevig mis is en bij nVidia alles top draait, maar dat hoef helemaal niet zo te zijn!
nVidia vertraagt gewoon de frames die snel klaar zijn zodat er een vloeiendere frame output ontstaat, maar dat maakt het beeld niet vloeiender, alleen de grafiekjes.

Dus zolang die functionaliteit niet uit kan, of zolang er niet gemeten wordt hoe lang een frame in de pipeline zit, kunnen we CF en SLI niet vergelijken helaas.

We kunnen natuurlijk nog steeds zeggen dat AMD een hoop werk te doen heeft en dat ik uitkijk naar de drivers van juni, waarin al een aantal verbeteringen moet zitten.

Ryan smith (Anandt.) is er dus ook een beetje bang voor dat AMD voor 'the easy way out' gaat en ook metering toepast maar we mogen in ieder geval blij zijn dat het hele verhaal nu zo onder het vergrootglas ligt( behalve op de tweakers FP

[superwashandje]

Springstof schreef op vrijdag 29 maart 2013 @ 07:50:
Het vermoeden van de consumenten die voor nVidia kozen omdat ze vonden dat zij een betere ondersteuning van hun producten bieden blijkt nu dus gegrond.

betere ondersteuning of betere ervaring? ervaring kan ik dus inkomen met al deze perikelen maar ondersteuning zou ik nog niet zo snel zeggen: AMD zegt eraan te werken en binnen een of twee maanden (?) met een verbetering/oplossing komen. Dat noem ik toch wel goede ondersteuning. ik kan me voorstellen namelijk dat dit niet iets is waar je overnacht een oplossing voor vind.

[ Voor 8% gewijzigd door superwashandje op 29-03-2013 09:19 ]

[Verwijderd]

SG schreef op donderdag 28 maart 2013 @ 22:01:
Ik ben ook dat TressFX aan het volgen wat in de Tomb Raider game is toegepast. Wat realistischer haar op DX11 kaartjes. Direct Compute!

Nadeel alleen het haar van Lara en verder bij niemand en dat geeft een raar beeld.
Ik had liever gezien dat TFX op meer dingen werd toegepast zoals op de booby's van Lara en
haar bij andere animaties. MAAR het is ook net nieuw en werkt nog niet optimaal, dus dat zal wel de
redenen zijn dat het alleen op het haar van Lara word toegepast.

[Werelds]

@ superwashandje: don't feed the....

[superwashandje]

hmm ja je hebt ook gelijk ook. laat maar idd mijn 7970 doet het heerlijk.

[Werelds]

Als het iemand anders was geweest had het nut gehad, maar bij Springstof niet. Daar verspil je gewoon je tijd aan, zijn vorige reactie in de twee topics is dan ook door iedereen genegeerd

[madmaxnl]

SG schreef op donderdag 28 maart 2013 @ 22:01:
Ik ben ook dat TressFX aan het volgen wat in de Tomb Raider game is toegepast. Wat realistischer haar op DX11 kaartjes. Direct Compute!

Het is imo de performance hit niet waard.

[nero355]

madmaxnl schreef op vrijdag 29 maart 2013 @ 17:16:
Het is imo de performance hit niet waard.

Dat zijn heel veel dingen niet en daarom laat ik tegenwoordig heel wat games zo ingesteld staan dat ik zoveel mogelijk FPS heb in plaats van grafische details waar je toch geen tijd voor hebt, omdat je aan het racen ben of aan het knallen

[deraco96]

Ik zie dat in bijv Skyrim best zitten, da's wel een game waarbij sommige mensen toch zeker af en toe even stil staan om te genieten van de omgeving (ik in ieder geval), een techniek om haar of bijvoorbeeld een cape in de wind te laten wapperen zou behoorlijk bijdragen aan het effect.

[Probook8979]

Maar dan kun je toch zeggen dat je beter een nvidia kaart halen ivm de physics ( CUDA ) die nvidia heeft en niet AMD, ofja... T wordt bij de AMD op de CPU. Berekendt ipv op de GPU..

Correct me if i'm wrong,

Als je t vergelijkt 'n 680 met een 7970 komt de nvidia steeds ietjes beter uit, alhoewel AMD zijm voordeel heeft met meer beeldschermen ( SLI ),

Ben nu op t punt om een nieuw videokaart te halen, zou echt niet weten welke brand.

" zal ik 70/100 euro meer uitgeven zodat ik nvdia heb, of zal ik 70/100 besparen.. "

Echt een dillema..

[Sp3ci3s8472]

Probook8979 schreef op zondag 31 maart 2013 @ 09:24:
Maar dan kun je toch zeggen dat je beter een nvidia kaart halen ivm de physics ( CUDA ) die nvidia heeft en niet AMD, ofja... T wordt bij de AMD op de CPU. Berekendt ipv op de GPU..

Correct me if i'm wrong,

Als je t vergelijkt 'n 680 met een 7970 komt de nvidia steeds ietjes beter uit, alhoewel AMD zijm voordeel heeft met meer beeldschermen ( SLI ),

Ben nu op t punt om een nieuw videokaart te halen, zou echt niet weten welke brand.

" zal ik 70/100 euro meer uitgeven zodat ik nvdia heb, of zal ik 70/100 besparen.. "

Echt een dillema..

Het is Physx ipv physics. Zowel AMD en Nvidia kunnen gewoon physics via de gpu, dit kan door DirectCompute en OpenCL. Cuda is een tegenhanger van OpenCL en DirectCompute.
Physx kan alleen op Nvidia kaarten maar er zijn maar heel weinig titels die dit ook echt doen.

Crossfire en SLI zijn gewoon even goed. De laatste testen die je ziet met microstuttering kan je niet goed vergelijken omdat Nvidia aan frame metering doet (het express vertragen van frames zodat het lijkt dat je een vloeiender beeld hebt).

Het is dus gewoon waar je voorkeur aangeeft , maar natuurlijk zullen we in dit topic AMD aanraden en in het Nvidia topic Nvidia .

[fynrd1]

Probook8979 schreef op zondag 31 maart 2013 @ 09:24:
Maar dan kun je toch zeggen dat je beter een nvidia kaart halen ivm de physics ( CUDA ) die nvidia heeft en niet AMD, ofja... T wordt bij de AMD op de CPU. Berekendt ipv op de GPU..

Correct me if i'm wrong,

Als je t vergelijkt 'n 680 met een 7970 komt de nvidia steeds ietjes beter uit, alhoewel AMD zijm voordeel heeft met meer beeldschermen ( SLI ),

Ben nu op t punt om een nieuw videokaart te halen, zou echt niet weten welke brand.

" zal ik 70/100 euro meer uitgeven zodat ik nvdia heb, of zal ik 70/100 besparen.. "

Echt een dillema..

Jij bent nou het type die helemaal in het verkoop praatje van physx is getrapt

[Verwijderd]

Toettoetdaan schreef op donderdag 28 maart 2013 @ 13:49:
nVidia vertraagt gewoon de frames die snel klaar zijn zodat er een vloeiendere frame output ontstaat, maar dat maakt het beeld niet vloeiender, alleen de grafiekjes.

Dus zolang die functionaliteit niet uit kan, of zolang er niet gemeten wordt hoe lang een frame in de pipeline zit, kunnen we CF en SLI niet vergelijken helaas.

Dit is naar mijn mening niet helemaal waar. Bij Nvidia vertraagd men juist wat frames om een betere (constantere) frametime tussen de verschillende beelden te creëren. Dit heeft juist tot gevolg dat het beeld wel vloeiender wordt en er minder microstuttering ontstaat. AMD geeft elke frame zo snel mogelijk weer wat de latency wel korter maakt (en dus snellere reactie), maar dus niet per se de weergave op het scherm vloeiender maakt. Ik ben het dus niet eens dat je beweert dat Nvidia alleen de grafiekjes vloeiender maakt en niet het beeld. Tal van reviews (waaronder HardOCP) bevestigen juist dat de gameplay bij Nvidia (icm SLI) vloeiender aanvoelt dan CF, terwijl de frames per seconde niet hoger liggen, of soms zelfs lager.
Ik denk dat het wel persoonlijk kan zijn waar de voorkeur ligt, maar ik denk dat meer mensen een voorkeur geven aan vloeiender beeld dan kortere reactietijd met eventuele microstuttering als gevolg.

[ Voor 9% gewijzigd door Verwijderd op 31-03-2013 18:04 ]

[Sp3ci3s8472]

Verwijderd schreef op zondag 31 maart 2013 @ 18:01:
[...]

Dit is naar mijn mening niet helemaal waar. Bij Nvidia vertraagd men juist wat frames om een betere (constantere) frametime tussen de verschillende beelden te creëren. Dit heeft juist tot gevolg dat het beeld wel vloeiender wordt en er minder microstuttering ontstaat. AMD geeft elke frame zo snel mogelijk weer wat de latency wel korter maakt (en dus snellere reactie), maar dus niet per se de weergave op het scherm vloeiender maakt. Ik ben het dus niet eens dat je beweert dat Nvidia alleen de grafiekjes vloeiender maakt en niet het beeld. Tal van reviews (waaronder HardOCP) bevestigen juist dat de gameplay bij Nvidia (icm SLI) vloeiender aanvoelt dan CF, terwijl de frames per seconde niet hoger liggen, of soms zelfs lager.
Ik denk dat het wel persoonlijk kan zijn waar de voorkeur ligt, maar ik denk dat meer mensen een voorkeur geven aan vloeiender beeld dan kortere reactietijd met eventuele microstuttering als gevolg.

Ik denk dat het ook sterk afhangt van het genre spel dat je speelt ik kan mij voorstellen dat je in een rustige setting (rpg/puzzle) je een vloeiender beeld wil omdat je dan beter van het spel kan genieten. Voor first person shooters denk ik dat die lagere inputlag fijner is.
Zelf wordt ik "zeeziek" van dingen als smoothing en interpolatie, ik heb daarom ook elke vorm van smoothing uitstaan. Maar zoals jij al aangeeft, dit is persoonlijk .

Zeeziek is natuurlijk overdreven maar ik vind het in ieder geval niet fijn spelen en ik hoop daarom ook dat de optie tussen wel of geen frame metering aan de gamer wordt overgelaten.

[Help!!!!]

^
Ik geloof niet dat de (nadelige) impact van frame metering zodanig is dat jij het uberhaupt kan merken.

Dat het niet gebruiken van frame metering wel een zodanige nadelige impact heeft is imo inmiddels wel overduidelijk bewezen.

Het is niet voor niks dat AMD ook bezig is om deze oplossing te ontwikkelen. Het mooie is dat zij van plan zijn om beide opties in de drivers te stoppen zodat je zelf kunt kiezen.

[Olaf van der Spek]

Toettoetdaan schreef op donderdag 28 maart 2013 @ 13:49:
Iedereen die alleen naar de grafieken kijkt denk dat het bij AMD hevig mis is en bij nVidia alles top draait, maar dat hoef helemaal niet zo te zijn!

De reviews tonen toch duidelijk aan dat AMD een groot aantal steken heeft laten vallen. Deze CF en Eyefinity problemen, naast de single-GPU micro-stuttering problemen, vind ik best erg. Vraag me dan ook af waar AMD echt mee bezig is geweest de laatste jaren, hoe kun je dit over het hoofd zien? Hoop dat AMD dit snel op kan lossen.

[Probook8979]

Sp3ci3s8472 schreef op zondag 31 maart 2013 @ 12:50:
[...]


Het is Physx ipv physics. Zowel AMD en Nvidia kunnen gewoon physics via de gpu, dit kan door DirectCompute en OpenCL. Cuda is een tegenhanger van OpenCL en DirectCompute.
Physx kan alleen op Nvidia kaarten maar er zijn maar heel weinig titels die dit ook echt doen.

Crossfire en SLI zijn gewoon even goed. De laatste testen die je ziet met microstuttering kan je niet goed vergelijken omdat Nvidia aan frame metering doet (het express vertragen van frames zodat het lijkt dat je een vloeiender beeld hebt).

Het is dus gewoon waar je voorkeur aangeeft , maar natuurlijk zullen we in dit topic AMD aanraden en in het Nvidia topic Nvidia .

Hmmm... Welke kaart heb jij dan?,

Maar AMD rekent toch zijn berekening op de CPU ipv op de GPU, dus je kunt dan zeggen dat de nvidia voordeel heeft?,

pfff ik vind dit zo moeilijk.. tussen de 7970 & 680..

[Probook8979]

fynrd1 schreef op zondag 31 maart 2013 @ 16:47:
[...]

Jij bent nou het type die helemaal in het verkoop praatje van physx is getrapt

Nee nee dat is 't niet, ik wil een zojusit een nieuw videokaart.. maar weet zojuist echt niet welke,

Heb nu een Nvidia GTS 450, ben nu echt toe aan een goeie videokaart, bijna al mijn vrienden hebben Nvidia,

Wat hun zojuist zeggen is dat ik Nvidia moet pakken i.v.m de CUDA en physixs dergelijke ( Fannboy i gues )

Bijna bij alle benchmark komt de 680 beter uit, Bij AMD is 't zó als je meer beeldschermen wilt hebben komt AMD in zijn voordeel vanwege de geheugenbus, maargoed.. dat meer beeldschermen gedoe is niet weggelegd voor mij,

Ben nu een beetje rond aan 't kijken van hoe en wat, en heb jullie mening daarbij nodig uiteraard. Want de prijs van AMD ( flaggenschip 7970 ) spreekt mij ook erg aan,

Zijn er nog meer reden waarom ik een AMD kaart in huis kan halen?,

Hoor 't graag van jullie

* verzonden via tell

[Sp3ci3s8472]

Probook8979 schreef op zondag 31 maart 2013 @ 22:30:
[...]


Hmmm... Welke kaart heb jij dan?,

Maar AMD rekent toch zijn berekening op de CPU ipv op de GPU, dus je kunt dan zeggen dat de nvidia voordeel heeft?,

pfff ik vind dit zo moeilijk.. tussen de 7970 & 680..

offtopic:
Een HD5870, daarvoor 9600 -> 6600gt (tijdelijk sli) -> 7800gs -> 4870x2.

[nero355]

Is een manier om microstuttering te laten zien door het te forceren met een of andere techdemo of zo ??

Ik heb nou eindelijk een tijdje met 4x5870 in mijn PC kunnen draaien en zou toch weleens naast meten dit een keer testen op een manier dat ik het ook daadwerkelijk zie.
Tevens heb ik door omstandigheden een i7 920 door de i7 3930K vervangen en ik heb het idee dat alles nu nog beter draait vanwege meer CPU kracht die de kaarten beter kan voeden zeg maar

Maar dat kan ook komen omdat mijn oude mobo blijkbaar aan het overlijden was en daar weer door mijn oude CPU niet helemaal werd benut door de games... kan ook!

[fynrd1]

Probook8979 schreef op zondag 31 maart 2013 @ 22:36:
[...]


Nee nee dat is 't niet, ik wil een zojusit een nieuw videokaart.. maar weet zojuist echt niet welke,

Heb nu een Nvidia GTS 450, ben nu echt toe aan een goeie videokaart, bijna al mijn vrienden hebben Nvidia,

Wat hun zojuist zeggen is dat ik Nvidia moet pakken i.v.m de CUDA en physixs dergelijke ( Fannboy i gues )

Bijna bij alle benchmark komt de 680 beter uit, Bij AMD is 't zó als je meer beeldschermen wilt hebben komt AMD in zijn voordeel vanwege de geheugenbus, maargoed.. dat meer beeldschermen gedoe is niet weggelegd voor mij,

Ben nu een beetje rond aan 't kijken van hoe en wat, en heb jullie mening daarbij nodig uiteraard. Want de prijs van AMD ( flaggenschip 7970 ) spreekt mij ook erg aan,

Zijn er nog meer reden waarom ik een AMD kaart in huis kan halen?,

Hoor 't graag van jullie

* verzonden via tell

Laat ik het zo zeggen, als je van beide kaarten een A-merk pakt zal je in iedergeval geen miskoop doen. Bevalt 1 van beiden je niet (wat mij sterk lijkt) retourneer je hem en neem je de andere. Ik ben zelf niet echt voor 1 kamp, nvidia heb ik de 8000serie, 9000serie, 200 en 400 serie van gehad. Ik heb toen de switch gemaakt naar een 5970 en was daar heel gelukkig mee. Physx miste ik totaal niet en de ervaring met drivers was velen malen beter. Ik heb zelf ook een week geleden geüpgrade naar een 7970 dc2t, ik was eigenlijk zo tevreden over amd dat ik geen interesse had om weer naar een nvidia kaart te kijken.
Ik vraag me overigens af hoeveel voordeel je als amd gebruiker hebt met het feit dat de ps4 (en Xbox?) van amd chips wordt voorzien.

[Verwijderd]

PhysX op de GPU wordt (letterlijk) maar door een handje vol games gebruikt. Tenzij er één game is die je daadwerkelijk dagelijks speelt die het gebruikt is dat het niet waard om mee te nemen in je keuze.

[Astennu]

Probook8979 schreef op zondag 31 maart 2013 @ 22:30:
[...]


Hmmm... Welke kaart heb jij dan?,

Maar AMD rekent toch zijn berekening op de CPU ipv op de GPU, dus je kunt dan zeggen dat de nvidia voordeel heeft?,

pfff ik vind dit zo moeilijk.. tussen de 7970 & 680..

Nee. Als een Game gebruik maakt van OpenCL of DirectX Compute Physics dan doet de GPU dit netjes.
Als je games hebt die CUDA Physx Gebruiken kan een AMD GPU daar niet aan bijdragen en doet de CPU dat.

Maar de meeste games hebben gewoon CPU Physics. En in de toekomst zullen (met dank aan de nieuwe Xbox en PS) vermoedelijk meer games gebruik gaan maken van Open standaarden voor Physics. Aangezien beide consoles een AMD APU gebruiken.

OpenCL en DirectX Compute werken ook op nVidia kaarten.

Ik zou me persoonlijk niet blind starten op dat CUDA. Een i5 of i7 is meer dan snel genoeg op Physics er bij te doen. Een AMD FX 8350 ook. Het is nice to have maar geen must have. Daarnaast ben ik persoonlijk helemaal geen fan van gesloten standaarden zoals CUDA.

Beide kaarten zijn prima. Maar als ik kijk naar Prijs prestatie zou ik voor een 7950 of 7970 non GE gaan. En dan zelf overclocken.
Als je dat niet wilt zou ik voor een leuke 7970 OC gaan. (gigabyte Windforce of zo)

[ Voor 9% gewijzigd door Astennu op 02-04-2013 15:20 ]

[deraco96]

TechReport heeft weer een nieuw artikel, dit keer met FCAT. Heb nu toevallig een paar losse pagina's gelezen vanaf een linkje op een ander forum, hier begint het. Het ziet er echt wel beroerd uit voor Crossfire, er blijken dus van allerlei frames tussen te zitten (bij FC3 iig, die heb ik al gelezen) die maar een paar rijen pixels innemen omdat het afwisselen van de frames van de twee GPU's zo inconsistent is. En nVidia doet alles bijna perfect, dat is nog wel het wrangst voor AMD.

Edit: Ik heb inmiddels zo'n beetje het artikel uit. Een enkele 7970 doet het meestal prima, maar vooral bij Crossfire in Skyrim en FC3 zijn er nog issues. Ook laat dit artikel wel zien vind ik dat zowel SLI als Crossfire eigenlijk weinig toevoegen als je kijkt 99-percentielwaardes, of naar de drempelwaardes. Het is soms eerder een 20% verbetering op dat vlak (wilde gok, als er al een verbetering is uiteraard) dan 100% schaling.

[ Voor 27% gewijzigd door deraco96 op 02-04-2013 21:25 ]

[DrBreakalot]

Is het niet zo dat hoewel de frametimes smoother lijken in SLI door frame metering, er alsnog microstuttering optreedt? Als de input niet constant is, maar de frametimes wel, zal een object toch stotterend bewegen? (input: afstand 0, 5ms later afstand 1, 10 ms later afstand 3; output: afstand 0, 7.5 ms later afstand 1, 7.5ms later afstand 3)
FCAT zal dan zeggen dat het er goed uitziet, hoewel het voor het oog volgens mij nog steeds stottert.

Natuurlijk lost het frames droppen, zoals AMD doet met Crossfire het probleem ook niet op, maar volgens mij is het beeld wel eerlijker en zal het er hetzelfde uitzien als het beeld dat SLI produceert.

[Toettoetdaan]

Wilco1e schreef op woensdag 03 april 2013 @ 03:16:
Is het niet zo dat hoewel de frametimes smoother lijken in SLI door frame metering, er alsnog microstuttering optreedt? Als de input niet constant is, maar de frametimes wel, zal een object toch stotterend bewegen? (input: afstand 0, 5ms later afstand 1, 10 ms later afstand 3; output: afstand 0, 7.5 ms later afstand 1, 7.5ms later afstand 3)
FCAT zal dan zeggen dat het er goed uitziet, hoewel het voor het oog volgens mij nog steeds stottert.

Natuurlijk lost het frames droppen, zoals AMD doet met Crossfire het probleem ook niet op, maar volgens mij is het beeld wel eerlijker en zal het er hetzelfde uitzien als het beeld dat SLI produceert.

Volgens mij klopt het helemaal wat je zegt.

Alleen schijnbaar is de ervaring toch beter als de de beelden consistent updaten dan dat de objecten smoot/correct bewegen.

Maar het zou interessant zijn om frame mesuring uit te zetten en dat te vergelijken. (Of in AMDs geval aan zodra het uit komt )

[Olaf van der Spek]

Wilco1e schreef op woensdag 03 april 2013 @ 03:16:
Is het niet zo dat hoewel de frametimes smoother lijken in SLI door frame metering, er alsnog microstuttering optreedt? Als de input niet constant is, maar de frametimes wel, zal een object toch stotterend bewegen?

Output rate metering heeft zeer waarschijnlijk ook invloed op de input rate door back pressure (vaste queue size), dus nee, waarschijnlijk is dit geen probleem.

Toettoetdaan schreef op woensdag 03 april 2013 @ 10:12:
Alleen schijnbaar is de ervaring toch beter als de de beelden consistent updaten dan dat de objecten smoot/correct bewegen.

Hoe kom je erbij dat objecten niet smooth bewegen. Loop je maar wat te speculeren?

[ Voor 25% gewijzigd door Olaf van der Spek op 03-04-2013 12:05 ]

[Sp3ci3s8472]

Olaf van der Spek schreef op woensdag 03 april 2013 @ 12:04:
[...]

Output rate metering heeft zeer waarschijnlijk ook invloed op de input rate door back pressure (vaste queue size), dus nee, waarschijnlijk is dit geen probleem.

[...]

Hoe kom je erbij dat objecten niet smooth bewegen. Loop je maar wat te speculeren?

Volgens mij vertraagd frame metering sommige frames zodat de tijd tussen de frames constanter is. Dit kan daardoor wel ervoor zorgen dat dingen die zich verplaatsen op het scherm zich niet op de correcte positie bevinden, waarschijnlijk is dat voor de meeste mensen niet eens waarneembaar.
Als ik frame metering goed begrijp dan gaat het volgende voorbeeld op:
Stel een cubes beweegt met een snelheid van 1 meter per seconde over je scherm. De driver krijgt van de videokaart de volgende frames: 0.25s, 0.4s, 0.75s en 1s. Frame metering zal dan proberen het grote verschil tussen 0.25 en 0.4 op te vangen door het frame van 0.4 pas op 0.5 vrij te geven. In dat geval schiet de cubes ineens van 0.4m naar 0.75m in 0.25s wat niet helemaal klopt maar nauwelijks merkbaar is omdat je normaal over ms praat en niet over secondes.

Als ik het fout heb wat framemetering is dan zou ik het graag willen weten , met info naar een werkelijke uitleg.

[deraco96]

Ik had precies hetzelfde idee. Alsnog lijkt mij frame metering wel beter, het gaat er gewoon om dat er gelijkmatig frames komen, die minieme verschillen ga je toch niet merken. Multi-GPU blijft natuurlijk sowieso een beetje behelpen en bij één is het toch al heel gelijkmatig.

[Olaf van der Spek]

Sp3ci3s8472 schreef op woensdag 03 april 2013 @ 12:29:
De driver krijgt van de videokaart de volgende frames: 0.25s, 0.4s, 0.75s en 1s.

Wat is het ideaal en waarom is de bal in frame 2 op 0.4m?
Waarschijnlijk zorgt metering er niet alleen voor dat de output rate constanter is, maar dat de input rate ook constanter wordt, aangezien er tussen output en input een vaste buffergrootte zit.

[Sp3ci3s8472]

Olaf van der Spek schreef op woensdag 03 april 2013 @ 14:56:
[...]

Wat is het ideaal en waarom is de bal in frame 2 op 0.4m?
Waarschijnlijk zorgt metering er niet alleen voor dat de output rate constanter is, maar dat de input rate ook constanter wordt, aangezien er tussen output en input een vaste buffergrootte zit.

Als je wil dat je average frame time hetzelfde blijft is ideaal om de 0.25s een frame te tonen in mijn voorbeeld. Maar als een kaart op 0.4s het frame rendered dan bevind de bal zich op 0.4m. Door frame metering wordt het frame pas vrijgegeven door de driver op 0.5s dus zal er een grote verschuiving tussen 0.5s en 0.75s zijn, namelijk 0.35m (ipv 0.25m).

Dit is natuurlijk alleen zo als dit inderdaad zo werkt met frame metering. Want volgens mij wordt dit door de driver afgehandelt nadat het frame gerendered is omdat de driver vooraf niet kan weten hoe lang de gpu over een bepaald frame zal doen.

Ik hoop dat anandtech nog een mooi artikel schrijft over dit onderwerp met de nadruk op frame metering.

Edit buffergrote blijf gewoon hetzelfde, dat is de standaard in door directx aangegeven render max 3 frames ahead dacht ik.

[ Voor 5% gewijzigd door Sp3ci3s8472 op 03-04-2013 15:42 ]

[Olaf van der Spek]

Sp3ci3s8472 schreef op woensdag 03 april 2013 @ 15:40:
Als je wil dat je average frame time hetzelfde blijft is ideaal om de 0.25s een frame te tonen in mijn voorbeeld. Maar als een kaart op 0.4s het frame rendered dan bevind de bal zich op 0.4m.

Het is natuurlijk niet de kaart die bepaald (-t?) wat en waar er gerendered wordt, dat bepaalt de game, vandaar mijn vraag: waarom 0.4m / 0.4s?

[RuddyMysterious]

Wat heeft de ongewilde vertraging van het afwerken van elke zoveel frames te maken met een mogelijke vertraging in de input?

Mij lijkt juist dat microstuttering gebeurt doordat je computer de realiteit van de engine bemonstert op vaste tijdstippen, maar dat er tussen het bemonsteren en het inkleden van de mooie frame die getoond moet worden niet telkens even veel tijd zit, waardoor het presenteren van de frames niet egaal-in-tijd gebeurt indien elk frame direct wordt gepresenteerd vanaf die daarvoor klaar is.

Doordat het bemonsteren op vaste tijdstippen gebeurt (in het ideale geval van een constante framerate) zal de input eveneens egaal bemonsterd worden.

Maar dat is mijn eigen visie zonder mij echt te verdiepen in de materie.

[Toettoetdaan]

DevilsProphet schreef op woensdag 03 april 2013 @ 16:55:
doordat je computer de realiteit van de engine bemonstert

Volgens mij gaat het anders om, de (game)engine zet een nieuwe frame op de stack van de driver, in plaat van dat de driver het aan de (game)engine vraagt.

[Sp3ci3s8472]

Olaf van der Spek schreef op woensdag 03 april 2013 @ 15:54:
[...]

Het is natuurlijk niet de kaart die bepaald (-t?) wat en waar er gerendered wordt, dat bepaalt de game, vandaar mijn vraag: waarom 0.4m / 0.4s?

Om een stuttering te veroorzaken zodat ik mijn voorbeeld kan uitleggen . Het spreek natuurlijk voor zichzelf dat een object dat op 1m/s beweegt op 0.4s op 0.4m zit.

@DevilsProphet dat zou ook best kunnen. Dat de driver zeg maar wacht voor een bepaalde tijd en dan pas de kaart een nieuwe frame laat renderen, maar zoals ik al zei het is onduidelijk wat er precies aan de hand is en ik hoop ook echt op een diepgaand artikel van anandtech aangezien die het beste (en meest technische) zijn in dat soort zaken, ipv een jip en janneke uitleg die andere sites geven .

The FCAT analysis has shown us that Nvidia's frame metering tech for SLI does seem to work as advertised. Frame metering isn't necessarily a perfect solution, because it does insert some tiny delays into the rendering-and-display pipeline. Those delays may create timing discontinuities between the game simulation time—and thus frame content—and the display time.

Bron:
http://arstechnica.com/ga...s-frame-capture-tools/11/

[ Voor 24% gewijzigd door Sp3ci3s8472 op 03-04-2013 20:08 . Reden: quote/bron ]

[Olaf van der Spek]

Sp3ci3s8472 schreef op woensdag 03 april 2013 @ 20:05:
[...]


Om een stuttering te veroorzaken zodat ik mijn voorbeeld kan uitleggen . Het spreek natuurlijk voor zichzelf dat een object dat op 1m/s beweegt op 0.4s op 0.4m zit.

Dan is zelfs met vsync de output onregelmatig en ligt de fout bij de game.

[Sp3ci3s8472]

Olaf van der Spek schreef op woensdag 03 april 2013 @ 20:07:
[...]

Dan is zelfs met vsync de output onregelmatig en ligt de fout bij de game.

Nee dat hoeft niet. Als de game een framerate heeft van 1000 frames per seconde maar de videokaart het niet bij kan benen dan zit het spel niet fout.

Als de game engine het niet bij kan benen dan heb je dus in feite een cpu bottleneck.

Maar Olaf ik probeer mijn theorie doormiddel van een overdreven en misschien niet al te goed gekozen voorbeeld duidelijk te maken, dat het voorbeeld niet klopt met vsync dat is dan even jammer want daar heb je 16.66ms nodig per frame om 60 frames per seconde te halen.

[ Voor 23% gewijzigd door Sp3ci3s8472 op 03-04-2013 20:13 ]

[dahakon]

Olaf van der Spek schreef op woensdag 03 april 2013 @ 12:04:
Hoe kom je erbij dat objecten niet smooth bewegen. Loop je maar wat te speculeren?

Hier even een stukje werkelijke speculatie:

Aangezien het een algemeen geaccepteerd 'feit' is dat crossfire ruk is en SLI fantastisch (lang leve internet fora) zal de gemiddelde persoon (en dus ook reviewer) onderbewust het SLI beeld als 'smoother' beschrijven, ook als er objectief geen verschil is. Dit komt omdat het menselijke brein heel gemakkelijk te beinvloeden is door dergelijke prikkels en de werkelijke observatie dus vertroebelen met onderbewuste aannames.

Alhoewel ik niet zal kunnen bewijzen dat er in deze specifieke situatie iets dergelijks plaats vindt, kan ik wel stellen dat er genoeg wetenschappelijk bewijs is die dit soort zaken duidelijk maakt.

[Help!!!!]

http://www.pcper.com/revi...-GTX-650-Ti-BOOST/Summary

Interessant stukje uit de conclusie:

HD 7850, HD 7790, GTX 650 Ti BOOST, GTX 650 Ti Performance

With only single GPU results to consider here, the results fall in line with what I wrote in the initial GTX 650 Ti BOOST review in late March. With the release of both it and the Radeon HD 7790 in March, the complicated budget graphics market got a bit more complicated.


The Radeon HD 7790 falls behind the GTX 650 Ti BOOST often

In general, the most competitive cards are the GTX 650 Ti BOOST and the Radeon HD 7850 and they swap "wins" in our benchmarks pretty regularly. If I had to give the nod to a single card it would be the GTX 650 Ti BOOST with slight wins in BF3, Crysis 3, Far Cry 3 and Skyrim. The HD 7850 is faster in DiRT 3 and Sleeping Dogs. But because the GTX 650 Ti BOOST is about $15-20 less expensive than the HD 7850, I think it is the better choice, all else being equal.

The secondary comparison is for the HD 7790 and the original GTX 650 Ti; there is very little to debate here though as the GTX 650 Ti is noticeably slower in basically all the games we tested. It has a smaller frame buffer, lower performance and is only $10 less, not an investment I would make today.


Final Thoughts

Don't get the wrong impression, this is in no way the end of our Frame Rating stories and I am only finalizing our first complete set of data today. The steps to get here have been difficult but now you have essentially all of the data and numbers that I have been building over the last year, with a lot of troubleshooting and analysis along the way.

I think the takeaway from the current state of Frame Rating is that while AMD's single GPU graphics cards offer fantastic performance per dollar, there is a fundamental problem with the CrossFire and CrossFire + Eyefinity technology that needs to be addressed by AMD. Even though there is still much research to be done on the subject of the full effect of the results and the discrepancies we are seeing in our CrossFire results, the fact is that something is fundamentally different between CrossFire and SLI, and in my hands on time with graphics cards over many years and over the last 18 months with this capture capability, NVIDIA is doing multi-GPU better.


The GTX 660 is the better multi-GPU option today

AMD has promised to fix this, and we are going to hold them to it. We differ on how dramatic an impact runt frames and dropped frames have on the user experience, but they are not denying that there is an issue many gamers are seeing. That's the good news. The bad news is that it may take until well into the summer to see something from AMD that will start to address the concerns we have. But better late than never and we'll continue to push forward.

Our next step is to look at the many user-submitted solutions for this AMD issue including the full effects of enabling Vsync, applications like RadeonPro and how we can measure changes in input latency because of frame meter.

It's going to be a busy summer...

[Verwijderd]

dahakon schreef op zaterdag 06 april 2013 @ 10:26:
[...]


Hier even een stukje werkelijke speculatie:

Aangezien het een algemeen geaccepteerd 'feit' is dat crossfire ruk is en SLI fantastisch (lang leve internet fora) zal de gemiddelde persoon (en dus ook reviewer) onderbewust het SLI beeld als 'smoother' beschrijven, ook als er objectief geen verschil is.

Ik ben het geheel met je eens dat het brein flink te beinvloeden is, maar ik kan me niet geheel indenken dat een site als bijv. HardOCP zich zoveel laat beinvloeden dat ze nu adviezen en conclusies geven die in werkelijkheid totaal niet kloppen.
Een idee voor een reviewsite is een praktijktest met een groepje van bijv. 20-30 mensen en deze een aantal games te laten spelen op een CF setup en SLI setup. Natuurlijk zonder dat ze weten welke hardware waar in zit en dan per game hun voorkeur qua gameplay vragen. Dit is waar het namelijk uiteindelijk om draait; hoe wordt het ervaren? Wieweet gaan we dit nog eens zien, zou er heel benieuwd naar zijn!

[Olaf van der Spek]

Sp3ci3s8472 schreef op woensdag 03 april 2013 @ 20:10:
Nee dat hoeft niet.

Als je de details van dit soort technologie niet kent kun je dit soort uitspraken toch niet (serieus) doen?

[madmaxnl]

Verwijderd schreef op zaterdag 06 april 2013 @ 21:45:
Dit is waar het namelijk uiteindelijk om draait; hoe wordt het ervaren? Wieweet gaan we dit nog eens zien, zou er heel benieuwd naar zijn!

Ja totdat we naar CPUs gaan kijken. Dan moet er opeens op 640x480 getest worden. In het geval van CPUs boeit het opeens totaal niet meer dat AMD en Intel nagenoeg dezelfde ervaring geven in de praktijk (gechargeerd, maar toch).

Ik ben het overigens wel met je eens.

[ Voor 6% gewijzigd door madmaxnl op 07-04-2013 00:05 ]

[Sp3ci3s8472]

Olaf van der Spek schreef op zaterdag 06 april 2013 @ 22:43:
[...]

Als je de details van dit soort technologie niet kent kun je dit soort uitspraken toch niet (serieus) doen?

Dat is inderdaad wel waar, ik weet niet alle ins of outs. Maar wat ik probeer te zeggen is dat vsync los staat van bijvoorbeeld de main loop in het spel. Intern lopen verschillende onderdelen op een andere frame rate (hoewel je daar niet van framerate mag spreken). Physics en AI lopen meestal op een lagere frame rate en worden geinterpoleerd dus dan nog zal de output met vsync niet altijd 100% zijn.

Het is dan ook de vraag of frame metering wordt gebruikt als vsync aanstaat, ik denk dat dit niet het geval is. Want het is heel simpel of je haalt wel 60fps of je haalt het niet en dan ga je automatisch naar 30fps tenzij je tripple buffering gebruikt of die alternatieve manier van Nvidia om met vsync om te gaan (Adaptive Vsync).

[Olaf van der Spek]

Sp3ci3s8472 schreef op zondag 07 april 2013 @ 11:58:
Dat is inderdaad wel waar, ik weet niet alle ins of outs. Maar wat ik probeer te zeggen is dat vsync los staat van bijvoorbeeld de main loop in het spel.

Vsync staat niet los van de rendering loop. In het ideale geval loopt die netjes X (60) keer per seconde. Als er dan een mismatch is tussen de world update thread en de rendering thread dan zou ik toch zeggen dat dat een fout in het spel is en niet iets waar de driver iets aan kan doen.

[Werelds]

Sp3ci3s8472 schreef op zondag 07 april 2013 @ 11:58:
Physics en AI lopen meestal op een lagere frame rate en worden geinterpoleerd dus dan nog zal de output met vsync niet altijd 100% zijn.

Onjuist, want juist die dingen lopen op een veel snellere cycle. Die gegevens zijn belangrijk voor het renderen, je wilt dat die zo accuraat mogelijk zijn elke keer dat er een nieuw frame wordt gestart.

Olaf van der Spek schreef op zondag 07 april 2013 @ 13:41:
Vsync staat niet los van de rendering loop.

Wel dus, afhankelijk van de variant van V-Sync die gebruikt wordt.



Wall of text warning

TL;DR versie: double-buffered V-Sync = waar Olaf op doelde. Double-buffered = kut, triple-buffered is wat we willen. Alleen zonde van de input lag

Disclaimer: hoop dat het er allemaal goed uit komt in de post, altijd lastig in tekst en wellicht heb ik me nog ergens vertypt ook

Ik moet er ook even bij vermelden dat het onderstaande behoorlijk vereenvoudigd is, want er zijn nog veel meer buffers die mee spelen, maar dit geeft de hoofdlijnen weer. Elke situatie die tearing en dergelijke kan veroorzaken komt uiteindelijk op hetzelfde neer: ongesynchroniseerde schrijf bewerkingen. De copy is ook geen echte copy, maar de buffers worden gewoon hernoemd en dergelijke, maar het onderstaande geeft het duidelijker weer voor iemand die niet weet hoe dit in code en game engines zou werken (voor diegenen die dat wel weten: de copy is gewoon het veranderen van een memory offset, als dat tijdens het lezen gebeurt krijg je dus alsnog de verkeerde frames te zien). Ook doen OpenGL en D3D triple buffering anders en is het bij D3D zelfs vervelend doordat er extra latency in zit. Enfin, als puntje bij paaltje komt is het onderstaande een representatie die goed genoeg is om het probleem weer te geven.



Here we go, hoe V-Sync werkt en wat tearing veroorzaakt, want niemand lijkt het te weten. Aannames en definities vooraf:
- 60 Hz monitor
- GPU die in principe meer dan 60 frames per seconde krijgt afgewerkt
- De monitor haalt frames op uit de framebuffer bij elke 'refresh' (LCD refresht niet letterlijk, maar dat even terzijde)

Output proces zonder V-Sync
De GPU rendert 60 + x frames per seconde en schrijft deze meteen weg naar de framebuffer zodra een frame klaar is.

Wat zich nu voor kan doen is dat de GPU net frame 3872 aan het wegschrijven is terwijl de monitor juist het frame uit de buffer haalt. Gevolg is dat een dat wat de monitor ophaalt deels 3872 en deels 3871 (het vorige frame) is. Dit is tearing, je ziet twee frames op je scherm.

Schematisch weergegeven ziet dat er uit zoals hieronder waarbij elke 6 puntjes 16.67ms zijn en een pipe een cycle (refresh, write, copy - afhankelijk van welk onderdeel het betreft). Framebuffer is even gefaked om de schrijf vertraging weer te geven, ongeveer 2.75ms (1 puntje).

Correcte, ideale situatie uitgaand van GPU die 120 FPS doet

code:

[.....|.....|.....|.....|.....|.....|.....|] Monitor
[...|..|..|..|..|..|..|..|..|..|..|..|..|..] Framebuffer
[..|..|..|..|..|..|..|..|..|..|..|..|..|..|] GPU

Tearing (Tearing op bovenste regel aangegeven met 'x') - dit voorbeeld varieert ergens tussen de 50 en 70 FPS

code:

[.....x...........x.......................]
[.....|.....|.....|.....|.....|.....|.....] Monitor
[.....|....|......|....|.....|.....|.....|] Framebuffer
[....|....|......|....|.....|.....|.....|.] GPU

Output proces met double-buffered V-Sync
De omschrijving zegt het al, er zijn nu twee buffers. Een framebuffer en een backbuffer. Double buffering heeft enkele restricties en beperkingen:
- De monitor haalt z'n frames nog steeds uit de framebuffer
- De GPU schrijft nieuwe frames naar de backbuffer, gevolgd door een copy van back- naar framebuffer
- Omdat de copy nog steeds tijd kost is de regel dat die copy pas plaats mag vinden NA een refresh (de GPU krijgt een signaaltje elke keer dat de framebuffer wordt opgehaald, die copy is dus een reactie op die lees actie)

Eind resultaat is dat jouw GPU intern wellicht nog gewoon op 60 + x FPS aan het renderen is, maar jij krijgt er maar 60 te zien; daarom laten Fraps e.d. ook maar 60 FPS zien, omdat zij hun info uit de framebuffer halen. Dit betekent echter dus ook dat sommige frames nooit in de framebuffer terecht komen, afhankelijk van hoe de refresh + copy cycles elkaar opvolgen. Sterker nog, als je GPU 120 FPS aan kan, dan zal de helft van alle frames nooit in de framebuffer komen, alleen kortstondig in de backbuffer. Dit verklaart ook meteen waarom V-Sync inherent input lag heeft, elk frame wordt immers een hele refresh cycle "te laat" weergegeven (om en nabij die 16.67ms in elk geval).

Dit kan echter nog steeds fout gaan. Stel nu dat je FPS tijdelijk naar 40 FPS dropt omdat er ineens wat grafische pracht en praal te zien is. Dat betekent dat er dus tijdens elke monitor refresh cycle slechts twee derde van een frame gerenderd kan worden. Dat betekent dat een deel van de frames twee keer wordt weer gegeven, omdat de GPU pas naar de framebuffer mag schrijven meteen NA een refresh cycle. Het gevolg is dat hoewel je GPU wellicht op 40 FPS zit te renderen, jij NOG minder frames daadwerkelijk te zien krijgt!

Wederom schematisch weergegeven zoals hierboven. Let op, ik heb het start punt van de GPU even verschoven, omdat dit een situatie "midden in" een sessie is, en niet vanaf het absolute begin. Met andere woorden, er zijn al frames gerenderd van tevoren, dus de buffers zijn niet leeg. Daarnaast geef ik even iets meer frames weer zodat je duidelijk ziet wat er gaande is.
Correcte, ideale situatie uitgaand van GPU die 120 FPS doet - je ziet dus ook dat bij 60+ FPS een groot deel van de frames nooit op je scherm komt

code:

[.....|.....|.....|.....|.....|.....|.....|] Monitor
[......|.....|.....|.....|.....|.....|.....] Framebuffer
[.|..|..|..|..|..|..|..|..|..|..|..|..|..|.] Backbuffer
[|..|..|..|..|..|..|..|..|..|..|..|..|..|..] GPU

40 FPS situatie

code:

[.....|.....|.....|.....|.....|.....|.....|.....|.....|.....|] Monitor
[............|...........|.....|...........|.....|...........] Framebuffer
[.........|........|........|........|........|........|.....] Backbuffer
[........|........|........|........|........|........|......] GPU

Zoals je ziet worden de eerste twee frames hier twee keer weer gegeven, maar frame 3 volgt frame 2 wel meteen op. Probleem is echter dat waar de GPU deze mooi 25ms uit elkaar heeft gerenderd, ze elkaar in 16.67ms opvolgen, wat in sommige situaties vreemd uit kan zien. Je ziet ook dat er in deze situatie maar liefst 10 refresh cycles van de monitor zijn geweest en slechts 5 nieuwe frames te zien geweest zijn. 30 FPS op die manier dus.

Dit is ook de V-Sync variant die wij zo tyfus irritant vinden, want om dit te vermijden moet er eigenlijk ook exact op een aantal frames gerenderd worden dat goed in die cycle valt: 60, 30, 20, 15 - elk getal waarvan 60 een veelvoud is. Veel engines doen dit dan ook; zodra de 60 FPS niet gehaald wordt, wordt er meteen gehakt naar 30 FPS. Dat is natuurlijk onzin als jij wel constant 55-59 FPS kunt renderen, want dan krijg je automatisch slechts 30 FPS te zien.


Output proces met triple-buffered V-Sync
Yep, je raadt het al, triple-buffering voegt een tweede backbuffer toe. De ideale situatie ga ik hier nu niet meer schetsen, want daar is in principe niets veranderd. Je zit wel nog steeds met 1 frame input lag natuurlijk.

40 FPS situatie

code:

[.....|.....|.....|.....|.....|.....|.....|.....|.....|.....|] Monitor
[............|.....|...........|.....|...........|.....|.....] Framebuffer
[........|........|........|........|........|........|......] Backbuffer #1
[.......|........|........|........|........|........|.......] Backbuffer #2
[......|........|........|........|........|........|........] GPU

Ik zou de grafiek nog langer moeten maken om het goed te laten zien (ik moet dit eigenlijk eens een keer in Excel gooien en gewoon in grafieken uitwerken), maar zoals je hier al kunt zien wordt nu slechts 1 op de 3 frames dubbel weergegeven. Met andere woorden, we krijgen twee derde van de frames te zien op de eerstvolgende cycle; dat is 40 FPS, precies waar we op zitten te renderen. De engine hoeft zichzelf dus ook niet te limiteren. Helaas doen UE3 games geen triple-buffering (waarom weet ik niet precies) en kost dit natuurlijk ook meer video geheugen, omdat er constant niet 1, niet 2 maar 3 frames in het geheugen zitten.

[ Voor 4% gewijzigd door Werelds op 07-04-2013 16:00 ]

[Paprika]

Werelds schreef op zondag 07 april 2013 @ 15:51:
[...]
omdat zij hun info uit de framebuffer halen.

Eigenlijk klopt dat niet helemaal. De meeste tools met een overlay (waaronder Fraps) hooken in Present (http://msdn.microsoft.com...op/bb174423(v=vs.85).aspx), wat betekent dat ze eigenlijk een frame tellen, voordat ie wordt weergegeven en even uit m'n hoofd plaats Fraps zelfs zijn hook behoorlijk vroeg in de functie, dus dan is ie nog niet eens in de backbuffer (dat gebeurd een paar instructies verder). Misschien bedoelde je dat, maar just in case.

Edit:


---

On second thought, EndScene plaatst hem natuurlijk al op de buffer? Faal post.

[ Voor 12% gewijzigd door Paprika op 07-04-2013 18:01 ]

[Olaf van der Spek]

Werelds schreef op zondag 07 april 2013 @ 15:51:
Wel dus, afhankelijk van de variant van V-Sync die gebruikt wordt.

Nietus.

Output proces met double-buffered V-Sync
Eind resultaat is dat jouw GPU intern wellicht nog gewoon op 60 + x FPS aan het renderen is, maar jij krijgt er maar 60 te zien; daarom laten Fraps e.d. ook maar 60 FPS zien, omdat zij hun info uit de framebuffer halen.

Dit klopt echt niet. De GPU rendert een frame in de back buffer, wacht op vsync en swapt dan front- en back buffers. De GPU moet wachten en kan geen nieuw frame renderen omdat er geen (derde) buffer beschikbaar is.

Dit verklaart ook meteen waarom V-Sync inherent input lag heeft, elk frame wordt immers een hele refresh cycle "te laat" weergegeven (om en nabij die 16.67ms in elk geval).

Klopt ook niet. De extra input lag door vsync is altijd < 16.7ms.

Ik zou de grafiek nog langer moeten maken om het goed te laten zien (ik moet dit eigenlijk eens een keer in Excel gooien en gewoon in grafieken uitwerken), maar zoals je hier al kunt zien wordt nu slechts 1 op de 3 frames dubbel weergegeven. Met andere woorden, we krijgen twee derde van de frames te zien op de eerstvolgende cycle; dat is 40 FPS, precies waar we op zitten te renderen. De engine hoeft zichzelf dus ook niet te limiteren. Helaas doen UE3 games geen triple-buffering (waarom weet ik niet precies) en kost dit natuurlijk ook meer video geheugen, omdat er constant niet 1, niet 2 maar 3 frames in het geheugen zitten.

Triple buffering heeft hogere lag en meer stuttering. De tijd tussen frame rendered en frame displayed is namelijk per definitie zeer variabel.
Ik vraag me af op de hogere framerate van triple buffering nog wel een voordeel is.

[bwerg]

Werelds schreef op zondag 07 april 2013 @ 15:51:
Zoals je ziet worden de eerste twee frames hier twee keer weer gegeven, maar frame 3 volgt frame 2 wel meteen op. Probleem is echter dat waar de GPU deze mooi 25ms uit elkaar heeft gerenderd, ze elkaar in 16.67ms opvolgen, wat in sommige situaties vreemd uit kan zien. Je ziet ook dat er in deze situatie maar liefst 10 refresh cycles van de monitor zijn geweest en slechts 5 nieuwe frames te zien geweest zijn. 30 FPS op die manier dus.

...

zoals je hier al kunt zien wordt nu slechts 1 op de 3 frames dubbel weergegeven. Met andere woorden, we krijgen twee derde van de frames te zien op de eerstvolgende cycle; dat is 40 FPS, precies waar we op zitten te renderen. De engine hoeft zichzelf dus ook niet te limiteren. Helaas doen UE3 games geen triple-buffering (waarom weet ik niet precies) en kost dit natuurlijk ook meer video geheugen, omdat er constant niet 1, niet 2 maar 3 frames in het geheugen zitten.

Niet dat ik het beter weet (dit soort posts zijn interessant om te lezen), maar tussen de synchronisatie van backbuffer en monitor lijkt geen verschil te zitten in de door jou geschetste situaties met 2 of 3 buffers. Bij beiden wordt om en om een frame dubbel weergegeven. Alleen het begin lijkt te verschillen, waardoor de ene situatie meer FPS geeft.

[Werelds]

Olaf van der Spek schreef op zondag 07 april 2013 @ 19:31:
Dit klopt echt niet. De GPU rendert een frame in de back buffer, wacht op vsync en swapt dan front- en back buffers. De GPU moet wachten en kan geen nieuw frame renderen omdat er geen (derde) buffer beschikbaar is.

Ik heb even wat opgezocht en zelf getest en je hebt gelijk, blijkbaar houden GPU's weldegelijk op met renderen als de backbuffers vol zitten. Ik meende dat men hier inmiddels anders mee om ging, maar blijkbaar niet. Ik ga er wel nog wat meer van uit zoeken. Wordt vervolgd

Klopt ook niet. De extra input lag door vsync is altijd < 16.7ms.

Nee hoor, dat geldt alleen als je ook aan de V-Sync cap zit. Dan zit het tussen de 0 en 16.67ms; vanwege hoe de timing uitvalt zit dat over het algemeen dichter tegen de bovengrens aan. Voeg daar nog eens de vertraging van de monitor aan toe en je zit al rap over de 16.67ms.

Onder de 60 FPS zit je sowieso over 1 frame (16.67ms) input lag (omdat je op refresh momenten nog geen nieuw frame klaar hebt staan) en bij buffered V-Sync zit dat bij sommige frames zelfs net over de 2 (of nog meer bij double buffered + erg lage framerate) heen. En dat is wederom de monitor vertraging nog niet mee geteld. Denk er maar eens over na; ongeacht wanneer de GPU klaar is met renderen, het kan nooit op het eerstvolgende frame weer gegeven worden met V-Sync, omdat hij de buffers nog niet mag swappen.

Triple buffering heeft hogere lag en meer stuttering. De tijd tussen frame rendered en frame displayed is namelijk per definitie zeer variabel.
Ik vraag me af op de hogere framerate van triple buffering nog wel een voordeel is.

Bij triple buffering is deze juist minder variabel dan bij double buffering; triple buffering forceert enige regelmaat. Wel betekent dat inderdaad dat je bijna gegarandeerde input lag hebt, terwijl bij double buffering dit soms wel, soms niet is. Hetzelfde geldt voor het stotteren; waar het bij triple buffered constant aanwezig is, is het wel regelmatig, terwijl het bij double buffered juist alle kanten op kan.


@ bwerg: mja, zoals ik al zei moeten de grafieken eigenlijk langer zodat je goed ziet dat het door de geforceerde regelmaat van triple buffering beter loopt.

[ Voor 3% gewijzigd door Werelds op 11-04-2013 14:12 ]

[Help!!!!]

Frame Rating: Visual Effects of Vsync on Gaming Animation

http://www.pcper.com/revi...ts-Vsync-Gaming-Animation

Doe eerst de pol en zoek daarna pas de antwoorden op !!!

[ Voor 18% gewijzigd door Help!!!! op 17-04-2013 11:46 ]

[RuddyMysterious]

Zoiets heeft iedereen ondertussen toch al volledig door? Ik snap het punt van pcperspective niet goed.

edit: de laatste pic op deze pagina is vrij interessant, want het is makkelijk in te zien dat in een SLI- of CFX-setup de GPU-tijd niet halveert ondanks het feit dat het aantal frames per seconde verdubbelt (in het meest ideale geval, natuurlijk), omdat elke GPU maar dezelfde framerate haalt als bij een single-GPU-setup. Dit zorgt ervoor dat SLI of CFX de framerate kan verbeteren, maar dat de inputlag nooit beter kan worden. En is lage inputlag niet minstens deels waar we naar willen streven, zeker bij shooters?

[ Voor 76% gewijzigd door RuddyMysterious op 17-04-2013 11:58 ]

[Help!!!!]

The King is Back: Raja Koduri Leaves Apple, Returns to AMD

http://www.anandtech.com/...aves-apple-returns-to-amd


7990 clocks confirmed
http://www.techpowerup.co...fig-Confirmed-Tested.html

[ Voor 32% gewijzigd door Help!!!! op 22-04-2013 12:56 ]

[Toettoetdaan]

[-The_Mask-]

En hier is die zelfs te koop!!!!111oneoneone

[Toettoetdaan]

-The_Mask- schreef op maandag 22 april 2013 @ 18:16:
En hier is die zelfs te koop!!!!111oneoneone

Ik mag toch hopen dat de AMD's verzie van de HD7990 gebruik maakt van een nieuwe revisie chips waardoor ze dezelfde clocks als de HD7970GE kunnen gebruiken en toch binnen die 375watt blijven.

Anders is het in der daad een trieste bedoening...

[A87]

Ik vind echt eens dat ze die Titan lager moeten prijzen want de 7990 komt rond 1000 euro oid en maakt er compleet gehakt van, single gpu of niet verschil is gewoon mega groot.
Als ik die tabel hierboven zie

Ik twijfel nog of ik de 7990 wil of een single gpu zonder die stutters.. merkte met 7970 crossfire nog wel microstutter. heb nu alleen 1 slot in dit nieuwe micro moederbord ^^

[ Voor 56% gewijzigd door A87 op 23-04-2013 18:31 ]

[Olaf van der Spek]

http://arstechnica.com/bu...derdog-stuck-it-to-intel/
http://arstechnica.com/bu...n-to-the-deepest-valleys/

Klinkt niet zo best

[Astennu]

-The_Mask- schreef op maandag 22 april 2013 @ 18:16:
En hier is die zelfs te koop!!!!111oneoneone

Er staan 3 kaarten en dat zijn allemaal non Official 7990's. Allemaal eigen initiatief.

[-The_Mask-]

Natuurlijk maar wat denk je dat dat plaatje van HWI is?

[Astennu]

-The_Mask- schreef op woensdag 24 april 2013 @ 08:41:
Natuurlijk maar wat denk je dat dat plaatje van HWI is?

Owh daar doelde je op. Ik dacht op de echte 7990 van AMD.

Ik vind het trouwens een mooi kaartje. Iets meer Future proof dan een GTX690. Maar verbruikt wel meer.
Mooie filler kaart maar ik heb zelf meer interesse in de echte opvolger van de HD7970. Helaas is de kans groot dat die volgend jaar pas uitkomen

[Help!!!!]

Licht aan de horizon voor AMD Crossfire

Frame Rating: AMD Improves CrossFire with Prototype Driver

http://www.pcper.com/revi.../great-start-AMDs-CrossFi

http://www.pcper.com/file.../BF3_2560x1440_PLOT_0.png

[ Voor 17% gewijzigd door Help!!!! op 24-04-2013 09:40 ]

[Astennu]

Help!!!! schreef op woensdag 24 april 2013 @ 09:39:
Licht aan de horizon voor AMD Crossfire

Frame Rating: AMD Improves CrossFire with Prototype Driver

http://www.pcper.com/revi.../great-start-AMDs-CrossFi

http://www.pcper.com/file.../BF3_2560x1440_PLOT_0.png

Dat is een gigantische verbetering. Ik ben benieuwd of dit met die andere mode is waar AMD het over had. Als ze het goed is gaan ze de gebruiker daar ook controle over geven om te kiezen welke mode je wilt gebruiken. Beide hebben hun voor en nadelen.

Edit: Zo te zien de implementatie van een soort van Frame Metering (zo heet het bij nVidia)

[ Voor 6% gewijzigd door Astennu op 24-04-2013 10:19 ]

[Help!!!!]

^
Klopt, ze doen nu hetzelfde als nVidia. Alleen bij nVidia zit het inmiddels in de hardware wat iets efficienter is.

AMD is inderdaad van plan dit als een optie (ook per game) in de driver te stoppen wat natuurlijk supernetjes is. Zelf denk ik wel dat het nut daarvan beperkt is. Ik geloof nl. niet dat de eventuele latency issues van frame rate metering dermate negatief zijn dat ze de voordelen teniet doen. Ben benieuwd naar tests op dit punt.

Als je de moeite neemt om zo'n filmpje vd prototype driver te downloaden dan kun je zelf checken wat je prettiger vindt. Ik vind het beeld van de prototypedriver echt stukken prettiger en het komt veel meer overeen met de smoothness die ik met 670SLI heb.

Verder moet ik zeggen dat AMD een zeer goed voorlopig resultaat heeft met hun prototype driver.

Het nadeel is natuurlijk wel dat dit pas een vroege alpha driver is en het waarschijnlijk nog wel even duurt voor de eindgebruiker erover kan beschikken. Tevens werkt het nog niet bij ifinity + crossfire. Dat gaat nog veel langer duren waarschijnlijk.

[Astennu]

Ze hebben aangegeven dat de driver Juni/Juli beschikbaar zou zijn. Duurt nog wel even maar ze doen er tenminste wel wat mee.

Het zou me niet verbazen als AMD de komende GPU generaties nog leuke sprongen gaat maken als het gaat om frame times. Nu ze daar zo op aan het letten zijn zullen ze daar met GPU design ook wel rekening mee gaan houden.

Voor de HD8xxx kunnen ze waarschijnlijk niet veel meer veranderen dus dat moet via drivers. Maar de generatie die er na komt kan er misschien al wel baat bij hebben.

[ Voor 19% gewijzigd door Astennu op 24-04-2013 10:34 ]

[Help!!!!]

Astennu schreef op woensdag 24 april 2013 @ 10:34:
Ze hebben aangegeven dat de driver Juni/Juli beschikbaar zou zijn. Duurt nog wel even maar ze doen er tenminste wel wat mee.

Het zou me niet verbazen als AMD de komende GPU generaties nog leuke sprongen gaat maken als het gaat om frame times. Nu ze daar zo op aan het letten zijn zullen ze daar met GPU design ook wel rekening mee gaan houden.

Voor de HD8xxx kunnen ze waarschijnlijk niet veel meer veranderen dus dat moet via drivers. Maar de generatie die er na komt kan er misschien al wel baat bij hebben.

Zeker.

Het resultaat wat ze nu al hebben weten te boeken valt me helemaal niet tegen en is denk ik een flinke opsteker omdat het weer vertrouwen biedt dat AMD Crossfire (ook de huidige generatie!!!) op orde kan krijgen.

Momenteel zou ik momenteel niet snel CF nemen/aanraden en SLI wel.
Echter, mocht AMD's final release vd prototype driver tzt alle issues oplossen, dan zou ik eerder voor CF/AMD gaan vanwege meer RAM op de kaarten en de geweldige gamebundel.

Heb sowieso wel het idee dat ze bij AMD met alle (recente) veranderingen wel weer helemaal wakker zijn op driver gebied maar ook qua developer relaties. Hopelijk houden ze dit vast!

[Astennu]

Inderdaad. Met GCN zijn ze ook helemaal bij Qua Compute mogelijkheden. En ook klaar voor de toekomst. De architectuur is goed. Niet ideaal voor gaming als je het vergelijkt met de GK104. Maar als je het vergelijkt met de GK110 doet hij het voor zijn die Size goed.
Hopelijk kunnen ze dit verder optimaliseren.

En wat je zelf ook al zij ze maken grote sprongen met hun drivers. En zijn ook steeds meer betrokken bij de ontwikkeling van games.

Ik ben heel blij met deze veranderingen.

[tomcatha]

valt het iemand anders ook al op hoe stil het is rond de nieuwe amd laptop video kaart generatie?
Solar system zou toch dit kwartaal uitkomen?

[Werelds]

Op software gebied is AMD inderdaad helemaal bij. Sterker nog, zulke sprongen als ze hebben gemaakt heb ik met m'n 680 nog niet mogen ervaren. Ze zitten er in ieder geval echt boven op en investeren er behoorlijk wat middelen in, dat is alleen maar positief.

En eigenlijk is GCN 1.0 perfect gebalanceerd t.o.v. Kepler. Denk maar eens terug aan GF100 tegenover Cayman; dat was 529mm^2 tegenover 334mm^2 en dan kreeg je 10% meer gaming performance naast de compute kracht. Met andere woorden, een pakweg 45-50% grotere die-size voor de compute kracht. Nu zit je met 352mm^2 tegenover 294mm^2; klein beetje sneller over het algemeen en de extra bandbreedte in het achterhoofd houdend zit je dan waarschijnlijk ergens tussen de 10% en 15% dat je aan extra die-size hebt puur voor de compute. En ik denk dat Tahiti harder over GK104 heen walst dan GF100 dat deed met Cayman (vergeet niet dat Cayman weldegelijk verrekte snel kon zijn, zie bitcoin-mining ).


Wat mij een beetje zorgen baart is dat Nvidia geen drol meer aan marketing doet. Al jaren krijg je er geen games bij en AMD is nu wel érg lekker bezig op dat vlak. Je krijgt bij een 7990 350 euro aan games, dat is gewoon belachelijk


Disclaimer: ik beweer niet dat de compute dingen apart op de die zitten, maar de architectuur vereist een ander floorplan, waardoor je ruimte verliest vanwege extra interconnects e.d.

[ Voor 12% gewijzigd door Werelds op 24-04-2013 16:05 ]

[nero355]

Help!!!! schreef op woensdag 24 april 2013 @ 10:31:
Tevens werkt het nog niet bij ifinity + crossfire. Dat gaat nog veel langer duren waarschijnlijk.

Eyefinity bedoel je i.cm. Crossfire ?! Dat zuigt dan best wel, want ik heb beide

Wat ik me afvraag : Zijn er websites die de input lag hebben getest bij zowel nVidia als ATI ??

ATI had tot nu toe "happerend beeld" volgens al die sites, maar de input was wel 1:1 met de game.
Dus dan lijkt me dat je bij nVidia veel meer input lag hebt, doordat vertragen van de frames per seconde vanwege de frametijden ??


Ik baal er trouwens van dat de "officiele 7990" geen Dual DVI + normale DP poort heeft : Kan je straks weer gaan kloten met converters of mag je nieuwe kabels gaan bestellen

Wat dat betreft zou ik op dit moment veel liever een nVidia kaart kopen : Die hebben dezelfde layout als mijn 5870 : Dual DVI + DP + HDMI waarbij ik eerlijk gezegd HDMI best kan missen, want daar doe ik niks mee

[Help!!!!]

nero355 schreef op woensdag 24 april 2013 @ 21:22:
[...]

Eyefinity bedoel je i.cm. Crossfire ?! Dat zuigt dan best wel, want ik heb beide

Dat klopt.

One thing to note: this fix does not yet address Eyefinity + CrossFire problems. The prototype and the current implementation of the fix are only going to address single monitor configurations due to the differences in how the multiple rendered images are composited. Resolutions up to 2560x1600 are handled by a hardware compositor while the 5760x1080 and above Eyefinity resolution use a software implementation that is apparently much more complex (and causes quite a few graphical issues we'll dive into later).

Wat ik me afvraag : Zijn er websites die de input lag hebben getest bij zowel nVidia als ATI ??

Nee, nog niet. Maar ze proberen dit wel te ontwikkelen.

ATI had tot nu toe "happerend beeld" volgens al die sites, maar de input was wel 1:1 met de game.
Dus dan lijkt me dat je bij nVidia veel meer input lag hebt, doordat vertragen van de frames per seconde vanwege de frametijden ??

Als je echt wilt weten hoe het zit kun je beter die artikelen lezen en het zelf proberen te begrijpen. Ik denk dat ik het redelijk begrijp maar het is imo best complexe materie.

Anyway, input lag is maar een naam en of dat de juiste beschrijving is, is ook maar de vraag. Maar wat je zegt klopt volgensmij.


Echter de hamvraag is inderdaad of die minieme latency uberhaupt merkbaar is. Ik merk het niet en heb er eigenlijk nog nooit iemand over horen klagen bij bijv. nVidia waar ze al veel langer deze techniek toepassen.
Diverse reviewsites zijn wel bezig te proberen methodes te ontwikkelen om erachter te komen hoeveel invloed die latency heeft.

Voor mij is het heel simpel, mijn eigen ervaringen met 6950CF en nu 670SLI bevestigen dat de stuttering echt veel erger is in CF dan in SLI. Sterker nog in SLI merk ik eigenlijk zowat nooit iets van stuttering. De filmpjes van bijv. PCper komen overeen met mijn ervaringen en zijn imho ook overduidelijk.

Ik heb nog nooit wat gemerkt van inputlag agv SLI. Dat wil niet zeggen dat het er niet is maar met de kennis van nu heb ik in ieder geval liever ietsje extra latency dan die hickups. Mijn SLI ervaring is echt wel veel beter dan mijn CF ervaring.

Dus ik zou me vooralsnog meer zorgen maken over AMD's CF issue dan de potentiele extra latency.
Bij AMD kun je straks zelf kiezen dus dat is sowieso het beste. Denk alleen niet dat veel mensen frame metering uit gaan zetten...

http://www.pcper.com/revi...aphics-Performance-Testin

Game time is the internal game clock that the software engine uses to keep track of the physical world. This clock could be based on a fixed time span for each tick or it could be variable or timed off of another source (like the OS or GPU driver). An Intel GPU engineer, Andrew Lauritzen, recently made a great post over on the Beyond3D.com forums about game time, back pressure on the game pipeline and much more. Here is a short portion of that post, but I would encourage everyone to read the entirety completely:

1) Smooth motion is achieved by having a consistent throughput of frames all the way from the game to the display.

2) Games measure the throughput of the pipeline via timing the back-pressure on the submission queue. The number they use to update their simulations is effectively what FRAPS measures as well.

3) A spike anywhere in the pipeline will cause the game to adjust the simulation time, which is pretty much guaranteed to produce jittery output. This is true even if frame delivery to the display (i.e. rendering pipeline output) remains buffered and consistent. i.e. it is never okay to see spikey output in frame latency graphs.

4) The converse is actually not true: seeing smooth FRAPS numbers does not guarantee you will see smooth display, as the pipeline could be producing output to the display at jittery intervals even if the input is consistent. This is far less likely though since GPUs typically do relatively simple, predictable work.

Clearly the best case for evaluating overall gaming performance will be to have access to the internal game and measure it in comparison the output from Frame Rating, the actual frames on your display. Differences there could be analyzed to find exact bottlenecks in the pipeline from game code to display. The problem is no game engine developers allow access to the information currently and the number of different engines in use today makes it difficult for even the likes of NVIDIA and AMD to gather data reliably. There is opportunity for change here if an API were to exist (in DirectX for example) that would give all game engines reliable time iterations that we would then have access to.

[Astennu]

Cat 13.4 Drivers zijn uit. Waarschijnlijk de performance fixes van de 13.3 beta + HD7790 en 7990 support:

Feature Highlights of AMD Catalyst™ 13.4

Support added for AMD Radeon HD7790 and AMD Radeon HD 7990
Catalyst Driver optimizations to improve performance in Far Cry 3, Crysis 3, and 3DMark
Significantly improves latency performance in Skyrim, Boderlands 2, Guild Wars 2, Tomb Raider and Hitman Absolution
Performance gains seen with the entire AMD Radeon HD 7000 Series for the following:
Batman Arkham City (1920x1200): Performance improvements up to 5%
Borderlands 2 (2560x1600): Performance improvements up to 10%
Quake Wars (1920x1200): Performance improvements up to 13%
Hitman Absolution (2560x1600): Performance improvements up to 11%
Wolfenstein MP (1920x1080): Performance improvements up to 11%
Civilization V (2560x1600): Performance improvements up to 5%
Delivers support for the following OpenGL 4.3 features:
GL_ARB_compute_shader
GL_ARB_multi_draw_indirect
GL_ARB_shader_storage_buffer_object
GL_ARB_arrays_of_arrays
GL_ARB_clear_buffer_object
GL_ARB_ES3_compatibility
GL_ARB_explicit_uniform_location
GL_ARB_fragment_layer_viewport
GL_ARB_invalidate_subdata
GL_ARB_program_interface_query
GL_ARB_shader_image_size
GL_ARB_stencil_texturing
GL_ARB_texture_buffer_range
GL_ARB_texture_query_levels
GL_ARB_texture_storage_multisample


Resolved Issues
This section provides information on resolved known issues in this release of the AMD’s Catalyst™ Software Suite, AMD Catalyst™ 13.4

With the Radeon HD7790 graphics card, corruption may be seen in the game Tomb Raider with TressFX enabled
Texture flickering may be observed in DirectX 9.0c enabled applications
Corruption observed in Tomb Raider with TressFX enabled for AMD Crossfire and single GPU system configurations
Corruption observed on objects and textures in the game, Call of Duty – Black Ops 2
Corruption observed in the game, Alan Wake (DirectX 9 Mode) when attempting to change in-game settings with Stereoscopic 3D using Tridef
Corruption observed on textures in the game, Battle Field: Bad Company 2 with forced anti-aliasing enabled
Adobe Photoshop CS6 experiences screen flicker under Windows 8 based system
Horizontal line corruption may be observed with forced anti-aliasing enabled in the game, Dishonored
System hang may occur when scrolling through the game selection menu in the game, DiRT 3
F1 2012 may crash to desktop on systems supporting AMD PowerXpress (Enduro) Technology

[Benga]

13.4 of 13.5 beta ?? Wat is nu best, met of zonder CF ? Met of zonder de CAP?

Wel wat verwarrend nu ...

[BarryKohne]

CAP heb je alleen nodig als je crossfire draait.

[nero355]

BarryKohne schreef op donderdag 25 april 2013 @ 18:22:
CAP heb je alleen nodig als je crossfire draait.

Alleen als de laatste CAP nieuwer is dan de driver

[MaXeRs]

De Beta 13.5 zijn ook uit.

http://support.amd.com/us...es/radeonaiw_vista64.aspx

[Verwijderd]

Weet iemand een beetje wat er in de pijplijn zit qua kaarten rond de HD7870XT en dergelijke kaarten? Ik begreep dat er een refresh/update aankomt, maar hoe of wat zie ik zo direct niet.

[Astennu]

Benga schreef op donderdag 25 april 2013 @ 17:50:
13.4 of 13.5 beta ?? Wat is nu best, met of zonder CF ? Met of zonder de CAP?

Wel wat verwarrend nu ...

13.4 is volgens mij gebaseerd op 13.3 beta
13.5 heeft nieuwe performance tweaks.

Dus voor de beste performance altijd de 13.5 beta ook met CF alleen dan moet je de CAP er bij installeren.

Verwijderd schreef op vrijdag 26 april 2013 @ 03:23:
Weet iemand een beetje wat er in de pijplijn zit qua kaarten rond de HD7870XT en dergelijke kaarten? Ik begreep dat er een refresh/update aankomt, maar hoe of wat zie ik zo direct niet.

Volgens mij komt er voorlopig helemaal niets. De 7870 XT is al een Tahiti die flink afgeknepen is.

nVidia komt waarschijnlijk met een GK104 update en een afgeknepen GK110 die door het leven zal gaan als GTX780. En de GTX770 krijgt dan de iets nieuwere (waarschijnlijk iets hoger geclockts) GK104.

Ik vraag me af wat AMD daar tegen wilt gaan doen. Die GTX770 kunnen ze nog wel hebben. Maar een afgeknepen GK110 zal waarschijnlijk 15% sneller zijn dan de 7970 GHz.

Al hoop ik toch dat we eind dit jaar nog een echte HD8xxx serie gaan zien met nieuwe chips en nieuwere architectuur.

[ArgantosNL]

Astennu schreef op vrijdag 26 april 2013 @ 07:59:

Al hoop ik toch dat we eind dit jaar nog een echte HD8xxx serie gaan zien met nieuwe chips en nieuwere architectuur.

Ik heb het idee dat ze op tsmc zitten te wachten. Met het huidige productie process lijkt het moeilijk om een sneller chip to maken zonder een chip als de Titan te maken. En het is moeilijk om een productlijn a 1000 euro per stuk goed te kunnen verkopen.

[Astennu]

ArgantosNL schreef op vrijdag 26 april 2013 @ 10:32:
[...]

Ik heb het idee dat ze op tsmc zitten te wachten. Met het huidige productie process lijkt het moeilijk om een sneller chip to maken zonder een chip als de Titan te maken. En het is moeilijk om een productlijn a 1000 euro per stuk goed te kunnen verkopen.

Ze moeten wel. 40nm is immers ook 3 generaties mee gegaan! Er komt voorlopig niets beters dan 28nm. Misschien eind 2014.

Ze zullen de chip zeker is groter moeten maken. Maar ze kunnen de architectuur ook verder optimaliseren. Daar valt ook nog wel aardig wat winst te halen. Dit is pas de eerste generatie GCN. We hebben 5 Generaties VLIW5 gehad. (6 als je de Xenos C1 ook mee telt)

[Verwijderd]

Astennu schreef op vrijdag 26 april 2013 @ 07:59:
[...]
13.4 is volgens mij gebaseerd op 13.3 beta
13.5 heeft nieuwe performance tweaks.

Dus voor de beste performance altijd de 13.5 beta ook met CF alleen dan moet je de CAP er bij installeren.

13.4 WHQL komt met een aparte CAP (13.4 CAP 1) en deze moet dus nog worden geïnstalleerd.
In de beta drivers zitten de CAPs al ingebakken en hoeven niet apart geïnstalleerd te worden. Voor 13.5 beta 2 hoef je dus geen CAP file te installeren.
De driver pakt automatisch de nieuwste profiles en zal dus in het geval van 13.5 beta 2 niets doen met 13.4 CAP1 als je deze installeert.

[Astennu]

Ik heb zelf nog nooit met CAP's gewerkt. Dus wist niet pressies hoe dat zit. Bedankt voor de toelichting.