CJ's Radeon Info & Nieuwsdiscussie - Deel 125

[Astennu]

Wat zie je dan? is het beeld gewoon soepeler?

[Help!!!!]

Ja ik vind het beeld soepeler.

Op de één of andere manier beweegt ook je muis soepeler. Dit kun je ook op de desktop makkelijk zien. Cursor en windows bewegen veel smoother. Zelfs mijn vriendin zag dat bij een blinde test.

Er zijn wel paar topics hier op got waar voor en tegenstanders het erover hebben:
kun je boven 60hz zien?
Monitor met 120mhz refresh rate
PC 3d Gaming - Aantal vraagjes

Theorie is natuurlijk simpel: Monitor refresht twee keer zo vaak.

Je hebt uiteraard wel een setup nodig die iha flink boven 60FPS moet kunnen leveren om het in games echt te laten werken. De soepelere muis merk je misschien ook ingame in bij 60FPS of lager. Hoe dat werkt kan ik niet echt verklaren.

ps:
Jij hebt blijkbaar een voorkeur voor (heel) hoge resoluties (30" monitor) bij mijn weten zijn er weinig of geen originele 120hz 30" monitoren. Bovendien is het op zo'n hoge resolutie natuurlijk moeilijker om >60FPS te genereren. Laat staan zonder CF of SLI.

[ Voor 14% gewijzigd door Help!!!! op 26-02-2013 13:18 ]

[Blastpe]

deraco96 schreef op maandag 25 februari 2013 @ 23:40:
Daarnet kaartte je dus wel het issue aan: het perfecte scenario is een GPU die in alle situaties het frame net klaar heeft als de monitor wil refreshen, sneller hoeft niet, en 'verouderde' frames zijn ook net niet ideaal.
Een test waarbij puur wordt gekeken naar bij hoeveel refreshes van een monitor de gpu een nieuw (heel) frame kan aanbieden zou dus het beste idee geven van het resultaat, de achterliggende techniek (hoeveel frames er intussen hadden kunnen worden gerenderd) is tijdens het gamen niet interessant. Nu ben ik lang niet zo veeleisend, het blijft een spelletje uiteraard en een niet geheel perfecte oplossing hoeft niet te storen.

Help!!!! schreef op dinsdag 26 februari 2013 @ 13:16:
Ja ik vind het beeld soepeler.

Op de één of andere manier beweegt ook je muis soepeler. Dit kun je ook op de desktop makkelijk zien. Cursor en windows bewegen veel smoother. Zelfs mijn vriendin zag dat bij een blinde test.

Is dit niet precies wat Lucid Virtu MVP pretendeert te doen?

[tweakertje21]

AMD heeft inmiddels meer bekend gemaakt over hun haarverzorgingsproduct TressFX:
In samenwerking met Crystal Dynamics heeft AMD er voor gezorgd dat haar nu realistischer
kan worden weergeven in games.

Helaas is de website momenteel niet meer beschikbaar dus moeten het maar doen
met google cache....

http://webcache.googleuse...&cd=1&hl=nl&ct=clnk&gl=nl

[madmaxnl]

AMD’s TressFX Hair tech unveiled: Tomb Raider used as demo

Lara Croft

Edit: te laat

[ Voor 5% gewijzigd door madmaxnl op 26-02-2013 18:55 ]

[eL_Jay]

Is dat net zoiets als physx (dat games het moeten ondersteunen)? Anders lijkt het me te weinig toevoegen zolang het geen standaard is.

[Werelds]

Werelds schreef op dinsdag 26 februari 2013 @ 10:29:
Overigens, TressFX (via Google Cache want de blog zelf is een jojo atm ):
http://webcache.googleuse...t=clnk&gl=nl&client=opera

Loopt allemaal via DirectCompute, zou in theorie ook gewoon op Nvidia moeten kunnen.

*kuch*

Werkt overigens ook gewoon op Nvidia, is inmiddels bevestigd, geen bullshit zoals PhysX

[madmaxnl]

AMD prefereert, i.t.t. nVidia, open standaarden. Daarnaast was PhysX, ongeacht of het nu ook op AMD GPUs goed had gelopen, gewoon slecht. De artikelen die dat aantonen zijn meermaals langs gekomen. Nu alle consoles AMD hardware hebben zul je niet snel meer PhysX zien. Alhoewel er ironisch genoeg wel wat Xbox360 games waren met PhysX.

[ Voor 25% gewijzigd door madmaxnl op 26-02-2013 19:53 ]

[nero355]

Als ze toch zo gezellig bezig zijn met dit soort features : Zullen we ooit weer het good old Wikipedia: TruForm zien in games ??

Kan me screenies van Rainbow Six 3 : Raven Shield herinneren waarin het toen goed te zien was !!

[madmaxnl]

AMD kan nu wel makkelijker dit soort zaken er doorheen duwen aangezien ze in alle nieuwe consoles zitten (mits de feature daar dan dus ook op werkt). Ze hebben nu gewoon een breder draagvlak voor dit soort dingen.

Die console design wins zijn echt cruciaal voor AMD. Als ze allemaal voor nVidia hadden gekozen had ik gevreesd voor het voortbestaan van AMD.

[ Voor 25% gewijzigd door madmaxnl op 26-02-2013 21:01 ]

[Sp3ci3s8472]

Help!!!! schreef op dinsdag 26 februari 2013 @ 13:16:
Je hebt uiteraard wel een setup nodig die iha flink boven 60FPS moet kunnen leveren om het in games echt te laten werken. De soepelere muis merk je misschien ook ingame in bij 60FPS of lager. Hoe dat werkt kan ik niet echt verklaren.

Dit is heel erg afhankelijk van de game engine die gebruikt wordt, vooral in oude game engines is de input van je keyboard en muis gekoppeld aan de mainloop en dus daarmee ook afhankelijk van het aantal frames per seconde (wellicht dat iemand met meer verstand hiervan het beter kan uitleggen , .oisyn misschien?).
Dat is ook de reden waarom games met vsync (zonder tripple buffering) sluggish aan kunnen voelen, ik wordt in ieder geval zeeziek als ik vsync aanzet .
Een ander voorbeeld is dat die-hard shooter fans die spellen spelen die gebruik maken van de quake 3 engine hun fps zo hoog mogelijk willen hebben omdat ze dan sommige sprongen net wel kunnen halen als ze het goed timen.

Wat ook nog kan meespelen is de dpi van de muis in verband met de refresh rate van je usb poort, als je shooters speelt dan is het ook aan te raden om de polling rate van je usb poort waarin je muis zit te verhogen naar 1mhz.

Dat haar van Lara Croft is een stuk mooier, als je ziet hoe het in de wind speelt op de screenshots . Ben benieuwd hoeveel extra het vraagt van je systeem aangezien self collision van veel haar best veel kan pakken.

/dream on modus aan
Het zou mooi zijn als er voor pc spellen een console mode aangezet zou kunnen worden als je AMD hardware gebruikt. Dat hierdoor de spellen de hardware directer kunnen aanspreken en waardoor je meer fps krijgt!
/dream on modus uit

[ Voor 8% gewijzigd door Sp3ci3s8472 op 26-02-2013 21:29 ]

[madmaxnl]

Sp3ci3s8472 schreef op dinsdag 26 februari 2013 @ 21:26:
/dream on modus aan
Het zou mooi zijn als er voor pc spellen een console mode aangezet zou kunnen worden als je AMD hardware gebruikt. Dat hierdoor de spellen de hardware directer kunnen aanspreken en waardoor je meer fps krijgt!
/dream on modus uit

Wie weet, de nieuwe Xbox loopt immers op dezelfde kernel als Windows 8.

[bwerg]

Sp3ci3s8472 schreef op dinsdag 26 februari 2013 @ 21:26:
Een ander voorbeeld is dat die-hard shooter fans die spellen spelen die gebruik maken van de quake 3 engine hun fps zo hoog mogelijk willen hebben omdat ze dan sommige sprongen net wel kunnen halen als ze het goed timen.

Naar mijn weten heeft dat er weinig mee te maken, dat komt gewoon doordat de physics "nauwkeuriger" wordt bij meer iteraties per seconde, en dat heeft invloed op het resultaat. Dat kan prima losstaan van de input en van de graphics (al doet het dat vast niet).

[Sp3ci3s8472]

bwerg schreef op dinsdag 26 februari 2013 @ 23:42:
[...]

Naar mijn weten heeft dat er weinig mee te maken, dat komt gewoon doordat de physics "nauwkeuriger" wordt bij meer iteraties per seconde, en dat heeft invloed op het resultaat. Dat kan prima losstaan van de input en van de graphics (al doet het dat vast niet).

Toch wel degelijk, stel jij neemt een sprong om over een muurtje te springen en de input is gekoppelt aan je fps. Op het moment dat jij je sprong maakt krijgt je pc door onbekende redenen het moeilijk, je fps zakt naar 1 per seconde (om het even te overdrijven).
Als jij met 1 fps over een muurtje wil springen dan is dat onmogelijk als de sprong normaal in een halve seconde wordt afgerond (physics gebruiken meestal een delta time hiervoor).
Maar dit is alleen met oude spellen , tegenwoordig wordt niet alles meer in de main loop afgehandelt.

Je physics worden inderdaad nauwkeuriger, je krijgt meer samples.

[Help!!!!]

Techreport blogpost over frame rate testing en PCper framecapture tool + fraps controversy

http://techreport.com/blo...ptures-crossfire-and-more


Hij vat iig een hoop vragen mooi samen en eindigt met een conclusie die mij logisch lijkt.

[ Voor 27% gewijzigd door Help!!!! op 27-02-2013 12:35 ]

[pino85]

Interessant en zelfs voor een noob als ik die van deze materie niet zo veel begrijpt omdat ik er niet veel van af weet en de discussies hier soms wat boven me petje gaan vind ik dat die scott wasson het voor mij toch wel duidelijk uitlegt,( wil niet zeggen dat jullie hier niet duidelijk zijn maar ik heb wel eens huh momentjes )
Soort van dummie uitleg zou soms handig zijn maja aan andere kant is het niet dummie.net maar tweakers.net

[ Voor 49% gewijzigd door pino85 op 27-02-2013 12:59 ]

[Astennu]

Help!!!! schreef op woensdag 27 februari 2013 @ 12:26:
Techreport blogpost over frame rate testing en PCper framecapture tool + fraps controversy

http://techreport.com/blo...ptures-crossfire-and-more


Hij vat iig een hoop vragen mooi samen en eindigt met een conclusie die mij logisch lijkt.

Mooi artiekel. Ook een mooite Titan review.
Het is duidelijk dat het laatste woord over die frame times nog niet gezegd is. Nu begint het groot schalig onderzoek. Tijd zal leren hoe je hier het beste mee om kan gaan. Maar het is beter om wel iets te testen dan alleen min - avg - max fps te testen. Want dat zegt te weinig.

[Help!!!!]

pino85 schreef op woensdag 27 februari 2013 @ 12:54:
Interessant en zelfs voor een noob als ik die van deze materie niet zo veel begrijpt omdat ik er niet veel van af weet en de discussies hier soms wat boven me petje gaan vind ik dat die scott wasson het voor mij toch wel duidelijk uitlegt,( wil niet zeggen dat jullie hier niet duidelijk zijn maar ik heb wel eens huh momentjes )
Soort van dummie uitleg zou soms handig zijn maja aan andere kant is het niet dummie.net maar tweakers.net

Denk ook dat Scott het vrij aardig uitlegt.

Je moet het eigenlijk zo zien maar dit is wel heel erg voor dummies wat jij niet bent :

Om GPU’s te beoordelen word er al sinds mensenheugenis getest met behulp van FPAPS op de Min. Gem. Max. FPS die ze kunnen genereren (op een bepaalde resolutie en IQ instelling). Maw FRAPS is DE benchmark. Tot zover niks nieuws.

Het onbevredigende was dat een redelijke groep mensen vooral bij SLI en CF maar ook single GPU’s waarnemen dat het beeld af en toe heel even lijkt te haperen. Dat noemen we meestal stuttering.

In het geval van SLI en CF werd dat meestal geweten aan de methode die door deze systemen gebruikt wordt “Altenative Frame Rendering” oftewijl AFR. Dit is zeker 1 vd oorzaken maar niet de enige.

Op een gegeven viel het ook op dat op sommige single GPU kaarten ook stuttering is waar te nemen.
Wat nu?

Alhoewel door minimaal 1 eerdere site ook al eens op dit spoor heeft gezeten was het Techreport.com begin September 2011 met hun inmiddels befaamde artikel “ Inside the second” die op het idee kwam om “binnen de seconde” te gaan kijken ipv zoals Fraps “per seconde”.

http://techreport.com/rev...look-at-game-benchmarking

Dus als een GPU op een bepaald moment 50 FPS genereert, keken zij hoeveel tijd elke frame binnen die seconde eigenlijk in beslag neemt (Dit kun je ook met FRAPS meten). Ze kwamen erachter dat sommige van die 50 frames heel veel tijd in beslag nemen (spikes) en anderen heel weinig.
Deze spikes bleken de stutters heel aardig / zeer goed te verklaren.

Het blijkt zelfs zo te zijn dat een single GPU met bijv. continu 80FPS een schokkender beeld kan geven dan één met continu 50FPS. Dit vanwege de spikes dus. Zie filmpje hierboven ergens.

Hierna zijn veel meer sites hierop gedoken want de meesten zijn er wel achter dat de traditionele methode (FPS meten) onvoldoende in staat is om het hele plaatje te schetsen / verklaren.

Dus dit zijn allemaal goede ontwikkelingen. Het vervelende is echter dat hiermee pandora’s box geopend is. Waarom? Omdat men zich nu eigenlijk pas echt ging afvragen hoe het nu zit en waar bottlenecks kunnen optreden die significant zijn. En hoe dat te meten en vervolgens te presenteren.

Omdat te kunnen beantwoorden moet je eigenlijk het hele traject (van game engines, DirectX, GPU / GPU memory management, vsync, mouseinput / inputlag, monitor refreshrate tot menselijk oog en misschien nog wel meer) in kaart gaan brengen en de wisselwerking ertussen begrijpen.

En dat is nogal ingewikkeld, blijkt.

En hoe ga je één of een paar datasets presenteren zodat het voor de lezers ook duidelijk is ?

Wat belangrijk is aan Scott’s conclusie, is dat tot zoverre Frame Rate meten binnen de seconde wellicht niet alle antwoorden geeft maar dat het desondanks tot nu toe wel een goede voorspeller van de onprettige dingen die we zien is gebleken.

Dus om jou als lezer een goed advies te geven is het, totdat e.e.a. door iemand goed uitgekristalliseert en uitgelegd is, al redelijk afdoende dat we nu dus Frame Rate Meten binnen de seconde hebben. Een concept dat voor velen ook al vrij contra intuitief en lastig is.

Persoonlijk vind ik het dan heel interessant dat men hier nu mee bezig is. Ik zou wel graag willen begrijpen hoe die hele keten nu echt werkt.

Astennu schreef op woensdag 27 februari 2013 @ 13:14:
[...]


Mooi artiekel. Ook een mooite Titan review.
Het is duidelijk dat het laatste woord over die frame times nog niet gezegd is. Nu begint het groot schalig onderzoek. Tijd zal leren hoe je hier het beste mee om kan gaan. Maar het is beter om wel iets te testen dan alleen min - avg - max fps te testen. Want dat zegt te weinig.

Zeker. Wat mij ook aanspreekt bij Scott/techreport dat hij wel wat genuanceerder is dan Ryan/Pcper.

Alhoewel de laatste hele interessante dingen aan het doen is, vind ik het wel ver gaan om Crossfire zo hard aan de schandpaal te nagelen. Wat mij betreft moet hij eerst zijn research afmaken en posten. Daarna zou het goed zijn als e.e.a. ook aan peerreview en kritiek blootstaat waarna je een betere basis hebt voor zulke methoden.

Ik ben er wel van overtuigd dat er iets niet helemaal lekker zit bij AMD met zowel CF als single GPU’s. AMD erkent dit en is er ook mee bezig.
De werkelijkheid is imho waarschijnlijk ook weer niet zo slecht dat het zulk hard “hakwerk” van Pcper al rechtvaardigt.

[ Voor 13% gewijzigd door Help!!!! op 27-02-2013 14:15 ]

[pino85]

Hele duidelijke uitleg, en nee wellicht ben ik geen dummie maar ik vind het moeilijke materie maar wel erg interessant al moet ik zeggen dat ik het nu op grote lijnen door heb.
Ja wat dat betreft is het goed dat dit nu door veel meer sites word omarmd en er meer onderzoek naar word gedaan wat nu de beste manier is en op welke manieren zaken verbeterd kunnen worden maar ik denk dat het nog wel een tijdje gaat duren tot dat de perfecte manier is ontwikkeld, dus veel onderzoek moet worden gedaan denk ik, dit is dus eigenlijk een hele grote verandering/stap in benchmark land.
Ook kan bv AMD met deze kennis weer aan de gang gaan om zaken te verbeteren.

[ Voor 30% gewijzigd door pino85 op 27-02-2013 13:57 ]

[Help!!!!]

^
Ik vind het ook moeilijke materie net als veel anderen. Als het niet moelijk was dan had één of andere techsite allang het "onbetwistbare" complete finale verhaal opgeschreven.

Een ander lastig ding voor mij:
Stel dat frame X een plaatje is dat heel veel rekenkracht vereist omdat er vanalles gebeurt op dat moment en frame Y is bijv. een volledig zwart plaatje. Is het dan niet logisch dat X veel meer tijd kost
En hoe zorg je ervoor dat als X en Y elkaar afwisselen dat het toch vloeiend wordt

[ Voor 48% gewijzigd door Help!!!! op 27-02-2013 14:30 ]

[pino85]

Ik zou ook zeggen dat wat je zegt zeer logisch klinkt, maar hoe je zorgt dat ze elkaar afwisselen zodat het vloeiend word? i dont know!

[Olaf van der Spek]

Help!!!! schreef op woensdag 27 februari 2013 @ 14:26:
En hoe zorg je ervoor dat als X en Y elkaar afwisselen dat het toch vloeiend wordt

Bijhouden hoeveel tijd je nodig hebt voor het zwaarste frame en je framerate verlagen zodat ie en constant is en je genoeg tijd hebt, zelfs voor de zwaarste frames.

[ Voor 10% gewijzigd door Olaf van der Spek op 28-02-2013 00:15 ]

[Fid3lity]

Olaf van der Spek schreef op donderdag 28 februari 2013 @ 00:09:
[...]

Bijhouden hoeveel tijd je nodig hebt voor het zwaarste frame en je framerate verlagen zodat ie en constant is en je genoeg tijd hebt, zelfs voor de zwaarste frames.

Ja, en hoe bereken je dat vantevoren? En wat nou als er "1 frame" mogelijk extreem zwaar zou kunnen zijn, moet de hele game (rendering daarvan) dan aangepast worden?

Voor mij is veel van dit alles ook volledig nieuw, maar ik vind het absoluut interessante materie.

[Verwijderd]

Stabilisatie van de frametijd is erg lastig inderdaad, zeker in combinatie met multithreading. Als je daar achter wil komen zul je echt tot in detail uit moeten gaan zoeken hoe game-engines werken en hoe je die ontwerpt. Dat is nogal specialistische en in-depth kennis, dan ben je wel even bezig zeg maar.

Ik ben niet bepaald een engine-programmeur. Frametijd rekken is een oplossing, maar wel de minst efficiënte, niks doen is iets wat een game-engine zich over het algemeen niet kan veroorloven, dan komt je gemiddelde frametijd veel te hoog uit. Hoe je dat beter aan kunt pakken, geen flauw idee.

[ Voor 32% gewijzigd door Verwijderd op 28-02-2013 01:27 ]

[evilpin0]

Ik heb sinds kort een lastige bug met mijn 6870, als ik een film kijk klokt die eerst het geheugen van 300 mhz naar 1050 (3d mode), na een aantal minuten klokt die ook de core van 300 mhz naar 900 mhz en gaat de videokaart gpu load naar full.

Als ik dan bv trixx open of CC dan zet die direct weer de snelheid op 300/300 mhz en gaat de load weer naar normaal (0-8%). Open ik weer de film dan begint het weer na een aantal minuten, hij doet het ook bij youtube en twitch.

Helaas gaven de oude drivers (12.10) een CC error en werken deze om een of andere reden niet meer, ik hade de videokaart via Trixx ge over clocked , inclusief een lichte voltage increase. Maar zelfs na een reinstall van de drivers, zonder trixx, dus zonder enige OC doet hij het nog.

Bekend probleem? Iemand een oplossing? De ICT man van mijn werk heeft thuiswerken geinstaleerd op mijn pc, formateren is dus echt de laatste oplossing.

Edit: ik kwam via google een idle bug tegen, het zou best wel eens kunnen dat de videokaart dit eigenlijk doet zonder dat er een video wordt afgespeeld.

[ Voor 13% gewijzigd door evilpin0 op 28-02-2013 09:21 ]

[Help!!!!]

^
Ha evilpin0, durf het helaas niet te zeggen. Het hoort eigenlijk ook meer thuis in dit topic:

AMD HD6XXX ervaringen - Deel 3

Wellicht kun je het daar ook nog ns posten?

[evilpin0]

thx sorry, zie inderdaad dat dit hier niet thuis hoort

[Olaf van der Spek]

3XPER7 schreef op donderdag 28 februari 2013 @ 00:22:
Ja, en hoe bereken je dat vantevoren?

Niet

En wat nou als er "1 frame" mogelijk extreem zwaar zou kunnen zijn, moet de hele game (rendering daarvan) dan aangepast worden?

De vraag is waarom dat ene frame zoveel tijd kost. Is de scene te complex? Zijn er textures of andere resources nodig die niet beschikbaar zijn? Is de driver bezig met periodiek onderhoud ofzo?
Afhankelijk van het antwoord op die vragen kun het het probleem aanpakken.
Als het echt maar 1 frame is, kun je die ene stutter waarschijnlijk het beste negeren.

[Olaf van der Spek]

Verwijderd schreef op donderdag 28 februari 2013 @ 01:25:
dan komt je gemiddelde frametijd veel te hoog uit.

Het hele punt hier is dat het gemiddelde er eigenlijk niks toe doet.

[Astennu]

evilpin0 schreef op donderdag 28 februari 2013 @ 09:14:
Ik heb sinds kort een lastige bug met mijn 6870, als ik een film kijk klokt die eerst het geheugen van 300 mhz naar 1050 (3d mode), na een aantal minuten klokt die ook de core van 300 mhz naar 900 mhz en gaat de videokaart gpu load naar full.

Als ik dan bv trixx open of CC dan zet die direct weer de snelheid op 300/300 mhz en gaat de load weer naar normaal (0-8%). Open ik weer de film dan begint het weer na een aantal minuten, hij doet het ook bij youtube en twitch.

Helaas gaven de oude drivers (12.10) een CC error en werken deze om een of andere reden niet meer, ik hade de videokaart via Trixx ge over clocked , inclusief een lichte voltage increase. Maar zelfs na een reinstall van de drivers, zonder trixx, dus zonder enige OC doet hij het nog.

Bekend probleem? Iemand een oplossing? De ICT man van mijn werk heeft thuiswerken geinstaleerd op mijn pc, formateren is dus echt de laatste oplossing.

Edit: ik kwam via google een idle bug tegen, het zou best wel eens kunnen dat de videokaart dit eigenlijk doet zonder dat er een video wordt afgespeeld.

Hoort eigenlijk niet in dit topic thuis. Maar het zou aan de hardware versnelling van de GPU kunnen liggen. Als UVD gebruikt wordt gaat hij ook omhoog clocken. Flash maakt ook gebruik van GPU versnelling. Maar dan zou hij ook weer terug moeten clocken zodra je bv Firefox met flash helemaal afsluit. Maar anders zou het kunnen dat hij op hogere clocks blijft draaien.

UVD clocks zijn in ieder geval hoger dan 2d clocks. Als je wilt weten hoe hoog moet je je bios exporteren met GPU-Z en in RBE 1.28 inladen dan kun je daar zien wat jou UVD clocks zijn. Het kan best dat die net zo hoog zijn als 3D maar weet het niet uit mijn hooft.

[Verwijderd]

Olaf van der Spek schreef op donderdag 28 februari 2013 @ 11:37:
[...]

Het hele punt hier is dat het gemiddelde er eigenlijk niks toe doet.

Het is absoluut waar dat er veel meer dingen een rol spelen dan alleen de gemiddelde frametijd, maar als je gaat padden en je gemiddelde frametijd komt op 100 ms uit dan is je beeld niet bepaald vloeiend meer. De gemiddelde frametijd doet er dus ook nog toe.

[Sp3ci3s8472]

Verwijderd schreef op donderdag 28 februari 2013 @ 20:55:
[...]

Het is absoluut waar dat er veel meer dingen een rol spelen dan alleen de gemiddelde frametijd, maar als je gaat padden en je gemiddelde frametijd komt op 100 ms uit dan is je beeld niet bepaald vloeiend meer. De gemiddelde frametijd doet er dus ook nog toe.

Klopt dat wordt toch ook mooi gemeten met average fps .
Maar het gaat vooral om het grote verschil in frametijden die een stotterige ervaring geven.

Een gemiddelde frametijd van 16ms zonder uitschieters naar beneden of omhoog geeft een vloeiender beeld dan een gemiddelde frametijd van e.g. 12ms met hoge en lage uitschieters.

Bij een gemiddelde frametijd van 100ms is je kaart gewoon niet snel genoeg .

[Olaf van der Spek]

Verwijderd schreef op donderdag 28 februari 2013 @ 20:55:
[...]

Het is absoluut waar dat er veel meer dingen een rol spelen dan alleen de gemiddelde frametijd, maar als je gaat padden en je gemiddelde frametijd komt op 100 ms uit dan is je beeld niet bepaald vloeiend meer. De gemiddelde frametijd doet er dus ook nog toe.

Grapjas. Max frametime is dan ook 100ms dus average heb je nog steeds niet nodig.

[Sp3ci3s8472]

Olaf van der Spek schreef op donderdag 28 februari 2013 @ 22:06:
[...]

Grapjas. Max frametime is dan ook 100ms dus average heb je nog steeds niet nodig.

Nee, 50ms + 150ms is nog steeds een gemiddelde frametime van 100 ms. Als je pc heel erg traag is dan kan het best 1.5 seconde duren voordat een frame klaar is met renderen.

[Fid3lity]

Sp3ci3s8472 schreef op vrijdag 01 maart 2013 @ 00:55:
[...]


Nee, 50ms + 150ms is nog steeds een gemiddelde frametime van 100 ms. Als je pc heel erg traag is dan kan het best 1.5 seconde duren voordat een frame klaar is met renderen.

1.5 seconden voor 1 frame is wel heel erg extreem

[deraco96]

Ik heb ook maar even een testje gedraaid op Skyrim, het is natuurlijk niet echt nieuws, want mijn 5850 en Q6600 zijn niet echt nieuw meer, dit:

Nu staat er waarschijnlijk een vsync of frame limiter aan, want anders kan het bijna niet exact 60 FPS zijn, maar dit is wel ongeveer wat een 7950 ook voor patroon heeft; even slecht dus. Ík vond het overigens zeer vloeiend spelen, dus ik heb nergens last van blijkt maar weer!

[Hekking]

Zolang hij niet regelmatig richting de 60 piekt zul je er sowieso niks van merken

[pino85]

review van de titan 3 en 4 way sli bij de buren, vond hem ook hier relevant aangezien we het nu de laatste tijd veel over oa frame time hebben en ook dat hebben ze getest.

http://nl.hardware.info/r...l-5760x1080-en-frametimes

[ Voor 6% gewijzigd door pino85 op 04-03-2013 14:31 ]

[eL_Jay]

pino85 schreef op zaterdag 02 maart 2013 @ 13:12:
review van de titan 3 en 4 way sli bij de buren, vond hem ook hier releveant aangezie we het nu de laatste tijd veel over oa frame time hebben en ook dat hebben ze getest.

http://nl.hardware.info/r...l-5760x1080-en-frametimes

Volgens mij heb je per ongeluk het verkeerde topic geopend, aangezien dit het Radeon topic is
Nog steeds niets nieuws bekend over de echte 8xxx serie?

[nero355]

Ik snap die spontane hype over frame time niet echt : Een ondertussen heel erg oud spel als Battlefield 2 liet al zien hoeveel tijd er tussen de gerenderde frames zit dus waarom is dit nu pas ineens heel belangrijk

Of iemand heeft hier opeens baat bij of al die review sites weten niet meer wat ze ons moeten vertellen dus zijn ze maar iets nieuws gaan zoeken wat eigenlijk al oud is/was

[deraco96]

Als ik niet gehinderd door enige kennis van zaken mag reageren is het nu vooral dat videokaarten snel zat zijn 60FPS zelfs op de hoogste settings. Dan pik je het niet als je game nog niet soepel loopt, men denkt supersoepel te kunnen draaien en dan blijft er net dat ene stuttertje, ondanks (ik zeg maar wat) 800 euro aan videokaarten. Dat is gewoon raar, en daarom zoeken ze het uit. Juist nu omdat videokaartkracht zo keihard voorloopt op game-eisen, denk ik.

[t!n0]

Misschien heeft het meetinstrument (FRAPS in dit geval) ook negatieve invloed op de frametimes, maar hoe meet je dat dan weer

[Blastpe]

In het kader van frametime metingen zou ik graag iets ter discusie willen stellen wat ik tot nu toe nog nergens besproken heb zien worden. Het is wel een behoorlijk verhaal om mijn punt te maken en ik hoop dat jullie mij kunnen volgen.
Met de introductie van frametime ipv van FPS wordt volgens mij de defenitie van game performence opnieuw gedefineerd. Hoge FPS blijkt niet altijd een juiste indicator van een fijne/goede game "experience" te zijn.
Kort door de bocht:
Een constante frametime garandeerd vloeiend beeld.(V-sync)(33-16.6ms?/30-60Hz?)
Een lagere frametime (16.6-8.3ms?/60-120Hz?)betekend een snellere response tussen input (bv muis) en beeld.

Het gaat mij om de response tijd.
Bij een single GPU wordt er (uiteraard) frame voor frame gegenereerd.
dus:bv. muis klik ->usb delay ->genereren frame->monitor delay->ik zie schot worden gelost.
oftewel ik klik op mijn muis en 1 frame later zie ik het schot gelost worden

Bij een dual GPU kaart/opstelling met AFR gaat dit iets anders. De GPU's genereren om en om de frames. Het kost 1 GPU nog steeds evenveel tijd een frame te genereren achter ik heb nu 2 (of meer) GPU's dus 2 x zoveel frames. De tijd tussen 2 frames is pak 'm beet 2x zo kort als bij een single GPU setup.
Echter de delay tussen muis klik->schot gelost zie ik deop monitor is niet 1 maar 2 frames later.

Conclusie een dual GPU kaart/setup(Xfire/SLI) genereerd het dubbele aantal frames van een single GPU kaart met de responsiveness van een single GPU.
Dus een dual setup heeft bij First Person Shooter games geen meerwaarde.

-edit: Laatste FPS = First Person Shooter-

[ArgantosNL]

Blastpe schreef op dinsdag 05 maart 2013 @ 10:20:Bij een dual GPU kaart/opstelling met AFR gaat dit iets anders. De GPU's genereren om en om de frames. Het kost 1 GPU nog steeds evenveel tijd een frame te genereren achter ik heb nu 2 (of meer) GPU's dus 2 x zoveel frames. De tijd tussen 2 frames is pak 'm beet 2x zo kort als bij een single GPU setup.
Echter de delay tussen muis klik->schot gelost zie ik deop monitor is niet 1 maar 2 frames later.

Conclusie een dual GPU kaart/setup(Xfire/SLI) genereerd het dubbele aantal frames van een single GPU kaart met de responsiveness van een single GPU.
Dus een dual setup heeft bij FPS games geen meerwaarde.

Een dual GPU kaart kan wel zin hebben maar dat merk je pas bij lage fps. Als je uit gaat van de zelfde FPS of FPS dat hoger zit dan 30 dan heb je gelijk. Maar als met single GPU kaart 15 FPS hebt en met een dual 30 FPS dan geeft het wel zin omdat het een vloeiendere ervaring zal geven, de response tijd is misschien het zelfde maar het kijkt wel fijner dan een highspeed diashow.

[Olaf van der Spek]

Blastpe schreef op dinsdag 05 maart 2013 @ 10:20:
Dus een dual setup heeft bij First Person Shooter games geen meerwaarde.

De latency wordt niet lager, maar ik weet niet of je dus kunt concluderen dat het totaal geen meerwaarde biedt.

[Blastpe]

Olaf van der Spek schreef op dinsdag 05 maart 2013 @ 11:10:
[...]

De latency wordt niet lager, maar ik weet niet of je dus kunt concluderen dat het totaal geen meerwaarde biedt.

Ik zou verwachten dat de latency hoger wordt aangezien er extra stappen in dual setup zitten zoals frame van GPU 2 overzetten naar het framebuffer van GPU 1, of zie ik dat verkeerd?

[Olaf van der Spek]

Frame transfers zijn, als het goed is, verwaarloosbaar.
Maar CF/SLI framerate scaling is vaak < 2, dus latency zal inderdaad omhoog gaan.

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

[Blastpe]

Maar welke meerwaarde heeft een dual setup dan nog? Vloeiend beeld heb je al bij 30fps V-sync. Daar is geen hoge fps nodig alleen constante framerate (zie de legio xbox360/ps3 games). Responsiveness/latency daarintegen wordt beter/lager bij een hogere framerate. Vandaar de jacht naar een zo hoog mogelijk aantal frames.
Als de latency bij xfire/sli/dual gpu kaart hoger is dan bij een single (identieke) GPU, dan is de game-play/experience bij een single gpu setup toch beter?

[Werelds]

Jullie gooien hier twee dingen door elkaar.

Input lag slaat op monitors en dan specifiek op de vertraging tussen het ontvangen van een frame en het daadwerkelijk weergeven daarvan. Bij een beetje monitor ligt dat gewoon onder de 16ms, minder dan een frame dus.

In de engines is tegenwoordig je input niet gekoppeld aan je framerate maar loopt dit in een aparte thread (beter gezegd, het spel loopt los van de render thread). Althans, in de degelijke engines. Als jij dus klikt wordt dat altijd geregistreerd, onafhankelijk van de render thread. Je kunt dus ook best met 1 FPS rondwandelen en schieten. Het spel zal dat verwerken en als je iets raakt wordt dat ook geregistreerd. Het kan vervolgens inderdaad best zo zijn dat jij in het volgende frame je gun niet ziet schieten en dat je alleen een enemy midden in een sterf animatie ziet.

Dat 1 FPS richten erg lastig maakt is een ander verhaal natuurlijk. Dat je met 1 FPS ook overcompenseert in een race spel en dus overal tegen aan knalt is logisch. Maar het heeft verder geen effect op je input

Geloof je me niet? Start maar eens een recent spel op waarin je last van "FPS drops" (lees: uitschieters qua frametime) hebt. Als jij tijdens zo'n "drop" op een knop drukt doet het spel daar wel gewoon iets mee. Het eenvoudigst hiervoor zijn spellen waarin je prone kunt gaan, BF3 ofzo. Druk tijdens zo'n uitschieter op je prone knop en je zult zien dat als de frame tijden weer normaal worden je gewoon op de grond ligt ondanks het feit dat het spel aan het renderen was terwijl jij er op drukte en volgens de theorie hierboven er dus niets zou moeten gebeuren

[ Voor 4% gewijzigd door Werelds op 05-03-2013 13:26 ]

[Blastpe]

Werelds schreef op dinsdag 05 maart 2013 @ 13:25:
Jullie gooien hier twee dingen door elkaar.

Input lag slaat op monitors en dan specifiek op de vertraging tussen het ontvangen van een frame en het daadwerkelijk weergeven daarvan. Bij een beetje monitor ligt dat gewoon onder de 16ms, minder dan een frame dus.

In de engines is tegenwoordig je input niet gekoppeld aan je framerate maar loopt dit in een aparte thread (beter gezegd, het spel loopt los van de render thread). Althans, in de degelijke engines. Als jij dus klikt wordt dat altijd geregistreerd, onafhankelijk van de render thread. Je kunt dus ook best met 1 FPS rondwandelen en schieten. Het spel zal dat verwerken en als je iets raakt wordt dat ook geregistreerd. Het kan vervolgens inderdaad best zo zijn dat jij in het volgende frame je gun niet ziet schieten en dat je alleen een enemy midden in een sterf animatie ziet.

Dat 1 FPS richten erg lastig maakt is een ander verhaal natuurlijk. Dat je met 1 FPS ook overcompenseert in een race spel en dus overal tegen aan knalt is logisch. Maar het heeft verder geen effect op je input

Geloof je me niet? Start maar eens een recent spel op waarin je last van "FPS drops" (lees: uitschieters qua frametime) hebt. Als jij tijdens zo'n "drop" op een knop drukt doet het spel daar wel gewoon iets mee. Het eenvoudigst hiervoor zijn spellen waarin je prone kunt gaan, BF3 ofzo. Druk tijdens zo'n uitschieter op je prone knop en je zult zien dat als de frame tijden weer normaal worden je gewoon op de grond ligt ondanks het feit dat het spel aan het renderen was terwijl jij er op drukte en volgens de theorie hierboven er dus niets zou moeten gebeuren

Maar wat doet dit af aan mijn standpunt?
Stel ik heb een single gpu snelheid 60fps en een dual gpu snelheid 100fps. Bij de dual gpu produceerd elke gpu dus 50 fps,totaal 100. De game engine registreerd een muisklik en verwerkt dit. De grafisch gevolgen worden doorgegeven aan de gpu. Om een image te generen kost dit bij de single gpu 16.6ms en bij de dual gpu 20ms voordat deze frame in de framebuffer zit.
Bij een single gpu staat het dus eerder op mijn scherm en zal dus meer responsive aanvoelen dan een dual gpu.

Edit,
Ik zie dat ik mijn standpunt moet bijstellen:
Bij single GPU kost dit tussen 16.6 en 33 ms
Bij dual GPU kost dit tussen de 20 en 30 ms

[ Voor 4% gewijzigd door Blastpe op 05-03-2013 14:03 ]

[Olaf van der Spek]

Werelds schreef op dinsdag 05 maart 2013 @ 13:25:
Input lag slaat op monitors

Lag / latency is echt niet alleen van toepassing op monitors. Zo is er bijvoorbeeld ook de latency tussen het versturen van een update door de server, het ontvangen van deze update door de client, het zichtbaar worden van deze update op de monitor en het verwerken van deze update in de hersenen.

[Werelds]

@ Blastpe: jawel, maar dat maakt het nog geen input lag. Dat het fout aanvoelt klopt (gaf ik ook al aan), maar het spel verwerkt je input wel gewoon. Er is geen vertraging tussen jouw input en de verwerking - er worden alleen delen van je input weer gegeven, wat er vervelend uit ziet.


@ Olaf: de term input lag echter wel. Ik had het niet over lag en latency in het algemeen, ik had het specifiek over input lag. Nu heb je ook wel vertraging vanuit de muis, door de kabel, stekker, poort, moederbord, USB controller, driver, (enz), maar dat loopt in de microseconden. Dat zou je nog onder de noemer "input lag" kunnen stoppen. In dit geval is er echter gewoon geen vertraging in het opnemen en verwerken, alleen vertraging in het weergeven van het resultaat. Het is eerder output lag dan iets anders.


Feit is dat een lage framerate geen invloed heeft (of zou moeten hebben) op het verwerken van jouw input. Dat het vervolgens slechts delen van jouw input weer geeft is een ander verhaal. Er zijn wel wat games en engines waar het dus fout gedaan wordt - GoldSrc en Tech 3 zijn twee hele bekende voorbeelden natuurlijk (waarbij ALLES in dezelfde thread zit, incl. netcode). Nogmaals, speel een spel dat niet lekker loopt en druk fijn op knopjes tijdens "drops". Alles wordt gewoon geregistreerd. Dat jij niet elke input verandering ziet kan best, maar niets van jouw input wordt VERTRAAGD en dat is waar het om gaat. Lag betekent per definitie dat jouw input wel binnenkomt maar dat er niets mee gedaan wordt. Dat is dus niet het geval, jij ziet alleen moment opnamen van de verwerking.

Vergelijk het voor mijn part met een auto die langsrijdt. Als die er 10 seconden over doet en jij maakt elke seconde een foto, betekent dat niet dat tussen twee foto's die auto niet rijdt - dit is precies hetzelfde, want jij beweegt met je muis, de engine verwerkt dat ook fijn maar helaas kan hij slechts af en toe de huidige stand van zaken laten zien


Edit: mijn punt is vooral dat je de term input lag hier niet moet gebruiken, want de input is er wel en wordt meteen verwerkt - wat bij een slechte monitor dus niet het geval is. Noem het render lag, output lag, maar geen input lag

[ Voor 11% gewijzigd door Werelds op 05-03-2013 15:42 ]

[Olaf van der Spek]

Werelds schreef op dinsdag 05 maart 2013 @ 15:37:
@ Olaf: de term input lag echter wel.

Volgens welke definitie?

Werelds schreef op dinsdag 05 maart 2013 @ 15:37:
Nu heb je ook wel vertraging vanuit de muis, door de kabel, stekker, poort, moederbord, USB controller, driver, (enz), maar dat loopt in de microseconden.

Is de standaard USB polling rate niet 125Hz? Latency daar kan dus zomaar 8ms zijn.

[ Voor 48% gewijzigd door Olaf van der Spek op 05-03-2013 16:08 ]

[Blastpe]

@werelds
Blijkbaar heb ik niet duidelijk verwoord wat ik bedoel. Waar ik het niet over heb is inputlag zoals jij het omschrijft. Overigens heb ik het ook nergens over inputlag gehad. Ik zal nog een keer proberen te omschrijven wat ik bedoel.
Stel ik heb een grafische kaart die 1 frame per seconde kan renderen/weergeven. Dan betekent dat wat ik op mijn scherm te zien krijg minimaal 1 seconde (max 2 sec) achter loopt op de game engine. Het duurt immers 1 sec om dat beeld te genereren en in die tijdloopt de game engine gewoon door. Kan mijn grafische kaart 20 frames per seconde renderen dan loopt het beeld op mijn monitor 50ms achter (max 100ms) op de game engine (ik heb het hier nog niet over muis of keyboard input gehad).
Heb ik een dual gpu welke 20 frames per seconde eruit poept (iedere GPU 10) dan loopt mijn beeld geen 50ms maar 100ms (max 150ms) achter op de game engine.
Volg je me nog

[ Voor 14% gewijzigd door Blastpe op 05-03-2013 16:27 ]

[Werelds]

Olaf van der Spek schreef op dinsdag 05 maart 2013 @ 16:06:
Volgens welke definitie?

https://www.google.nl/sea...&oe=utf-8&channel=suggest

Zo'n beetje elke definitie.

Olaf van der Spek schreef op dinsdag 05 maart 2013 @ 16:06:
Is de standaard USB polling rate niet 125Hz? Latency daar kan dus zomaar 8ms zijn.

Inderdaad, even niet bij stil gestaan en sterker nog, bij standaard polling rate *is* die latency 8ms, daar heb je helemaal gelijk in. Dat is echter nog steeds twee keer per frame bij 60 Hz/FPS, een keer bij 120 Hz/FPS. Met andere woorden, elk frame zal ten alle tijde nieuwe input beschikbaar gehad hebben. Dus wat betreft de renderer mag dat 125, 250, 500 of 1000 Hz zijn, hij neemt toch slechts wat op dat moment het nieuwste is uit de game gegevens (die het op zijn beurt uit Windows haalt, die het op zijn beurt polled ). Uiteraard is het geheel preciezer op 1000 Hz, maar je frames gaan dat nog steeds niet 100% weergeven tenzij je ook frametimes van 8/4/2/1 ms hebt


@ Blastpe: ik had je helemaal begrepen hoor. Nogmaals, ik geef het ook meerdere malen aan, maar de weergave zal inderdaad altijd iets vertraagd zijn. Je begon deze discussie echter met het praten over input lag en responsiveness en geen van beide wordt beinvloed door framerate - mits de engine dat losgekoppeld heeft zoals het hoort.

Op 120 FPS is je muis niet meer of minder accuraat dan op 1 FPS. Wel is het zo dat jij die precisie niet te zien krijgt op 1 FPS en dat dat het lastig maakt om te richten. Betekent echter niet dat jouw input vertraagd wordt, ik verwijs weer naar mijn voorbeeld met een prone knop. Waar jij echter aan zit te denken is dat jij reageert op wat je op het scherm ziet; dus dan druk je op een knop of beweeg je de muis terwijl het volgende frame al aan het renderen is en dan zal jouw input inderdaad te laat zijn. Aangezien de gemiddelde mens ergens tussen de 400 en 800 ms zit qua reactie tijd, zal dat het spelletje aanzienlijk lastiger maken


Edit: even jouw edit lezen Blastpe

Edit #2: nee, dat klopt ook niet helemaal, hoewel het wel 100ms kan zijn.

Omdat er geen communicatie is bij AFR rendert elke GPU z'n frames back-to-back omdat ze niet met elkaar kunnen communiceren (wat ook meteen het probleem van AFR is ). Dus frames 1,3,5,7,enz voor GPU #1, frames 2,4,6,7,enz voor #2.

Het is vervolgens de taak van de scheduler om die frames uit te poepen richting je scherm. Het is echter niet zo dat GPU #2 pas de opdracht voor frame 2 krijgt als GPU #1 klaar is - immers moet op dat moment GPU #1 z'n nieuwe opdracht ook krijgen. In werkelijkheid overlappen ze elkaar de hele tijd. De frametime is in werkelijkheid echter niet constant (krijgen we al natte voeten jongens?), maar als je van een ideale situatie uit gaat begint GPU #1 op T=0, GPU #2 op T=50ms, GPU #1 weer verder op 100ms...en zo gaat dat door. Telkens als een van de twee halverwege is, is de ander net klaar.

Om de voeten maar even helemaal nat te maken: helaas pindakaas, microstuttering. Frametimes zijn nooit zo constant, dus die vertraging gaat constant op en neer - waarbij het maximum ergens tussen het gemiddelde en de maximum frametijd ligt (voor multi-gpu). Als je naar het laatste stukje hierboven kijkt zie je ook meteen waar het probleem bij AFR ligt: hoe moet de scheduler in godsnaam van tevoren weten dat hij voor elk frame 100ms nodig gaat hebben en GPU #2 dus op 50ms aan het werk moet zetten?

Dit is wel hoe Nvidia en AMD aan SLI en CFX aan het sleutelen zijn; een hoop bemiddeling en gemiddeldes nemen om alles maar zo vloeiend mogelijk in te plannen. Daarmee gaan dan ook gedropte frames gepaard en wellicht zelfs dat ze dan af en toe een GPU even laten rusten (geen idee eigenlijk, is er iemand met SLI die dit eens kan bekijken?) om alles maar vloeiender te laten lijken.

[ Voor 31% gewijzigd door Werelds op 05-03-2013 17:00 ]

[Blastpe]

Werelds schreef op dinsdag 05 maart 2013 @ 16:35:

Edit #2: nee, dat klopt ook niet helemaal, hoewel het wel 100ms kan zijn.

Omdat er geen communicatie is bij AFR rendert elke GPU z'n frames back-to-back omdat ze niet met elkaar kunnen communiceren (wat ook meteen het probleem van AFR is ). Dus frames 1,3,5,7,enz voor GPU #1, frames 2,4,6,7,enz voor #2.

Het is vervolgens de taak van de scheduler om die frames uit te poepen richting je scherm. Het is echter niet zo dat GPU #2 pas de opdracht voor frame 2 krijgt als GPU #1 klaar is - immers moet op dat moment GPU #1 z'n nieuwe opdracht ook krijgen. In werkelijkheid overlappen ze elkaar de hele tijd. De frametime is in werkelijkheid echter niet constant (krijgen we al natte voeten jongens?), maar als je van een ideale situatie uit gaat begint GPU #1 op T=0, GPU #2 op T=50ms, GPU #1 weer verder op 100ms...en zo gaat dat door. Telkens als een van de twee halverwege is, is de ander net klaar.

Om de voeten maar even helemaal nat te maken: helaas pindakaas, microstuttering. Frametimes zijn nooit zo constant, dus die vertraging gaat constant op en neer - waarbij het maximum ergens tussen het gemiddelde en de maximum frametijd ligt (voor multi-gpu). Als je naar het laatste stukje hierboven kijkt zie je ook meteen waar het probleem bij AFR ligt: hoe moet de scheduler in godsnaam van tevoren weten dat hij voor elk frame 100ms nodig gaat hebben en GPU #2 dus op 50ms aan het werk moet zetten?

Dit is wel hoe Nvidia en AMD aan SLI en CFX aan het sleutelen zijn; een hoop bemiddeling en gemiddeldes nemen om alles maar zo vloeiend mogelijk in te plannen. Daarmee gaan dan ook gedropte frames gepaard en wellicht zelfs dat ze dan af en toe een GPU even laten rusten (geen idee eigenlijk, is er iemand met SLI die dit eens kan bekijken?) om alles maar vloeiender te laten lijken.

En hiermee onderschrijf je mijn standpunt dus.
Een dual GPU kaart/Xfire/SLI setup moet minimaal 1,5 x zoveel frames (continu) eruit persen om met een gelijke vertraging als een single gpu setup op de game engine achter te lopen

[Olaf van der Spek]

Werelds schreef op dinsdag 05 maart 2013 @ 16:35:
Inderdaad, even niet bij stil gestaan en sterker nog, bij standaard polling rate *is* die latency 8ms, daar heb je helemaal gelijk in. Dat is echter nog steeds twee keer per frame bij 60 Hz/FPS, een keer bij 120 Hz/FPS. Met andere woorden, elk frame zal ten alle tijde nieuwe input beschikbaar gehad hebben.

Dat is het punt toch niet? Het punt is dat je daar onnodig tot 8ms latency hebt. Met een hogere polling rate heb je gewoon minder latency en dat is onafhankelijk van de framerate.

[Sp3ci3s8472]

Olaf van der Spek schreef op dinsdag 05 maart 2013 @ 18:02:
[...]
Dat is het punt toch niet? Het punt is dat je daar onnodig tot 8ms latency hebt. Met een hogere polling rate heb je gewoon minder latency en dat is onafhankelijk van de framerate.

Nu wel, vroeger niet.

[Werelds]

Blastpe schreef op dinsdag 05 maart 2013 @ 17:56:
[...]
En hiermee onderschrijf je mijn standpunt dus.
Een dual GPU kaart/Xfire/SLI setup moet minimaal 1,5 x zoveel frames (continu) eruit persen om met een gelijke vertraging als een single gpu setup op de game engine achter te lopen

Nee, juist niet. Als de frame tijden constant zijn heb je per GPU in principe genoeg aan de helft - ze overlappen elkaar immers (na de eerste paar honderd frames zal de scheduler dit dan wel mooi plannen).

Met onregelmatige frametijden kun je tot wel 5 keer zo veel FPS hebben, het gestotter zal nog steeds vervelend zijn (hoewel in dat geval hopelijk de langzame frames gewoon gedropt worden ).

Olaf van der Spek schreef op dinsdag 05 maart 2013 @ 18:02:
[...]

Dat is het punt toch niet? Het punt is dat je daar onnodig tot 8ms latency hebt. Met een hogere polling rate heb je gewoon minder latency en dat is onafhankelijk van de framerate.

Klopt. Het maakt voor de renderer -game, Aero, video, maakt niet uit welke- echter nog steeds geen donder uit, want of die nou voor 60 Hz of 120 Hz gaat, die latency wordt nog steeds niet zichtbaar. Alleen de precisie van de vector die je muis stuurt -richting, snelheid- is minder accuraat, maar vertraagd wordt het niet en dat is wat latency is. De gegevens zijn er gewoon. Als jij naar links aan het bewegen bent en binnen die 8ms even naar rechts en weer terug naar links beweegt zal hij dat inderdaad niet als dusdanig weer geven (en bij een 60 Hz V-Sync zal hij die tweede poll sowieso overslaan); wat de PC door krijgt is een vector naar links en bij de volgende zending is het wederom een vector naar links. Op het moment dat hij de gegevens verstuurt zijn het de meest recente gegevens en wordt er dus niets vertraagd.

Ik hoop dat ik daar m'n punt duidelijk mee maak

Je hebt helemaal gelijk dat er latency is, dat kan alleen van z'n lang zal z'n leven niet zichtbaar worden.

[Olaf van der Spek]

Werelds schreef op dinsdag 05 maart 2013 @ 19:02:
Ik hoop dat ik daar m'n punt duidelijk mee maak

Niet echt.

T = -7: poll
T = -6: physical input (click / move)
T = 0: read input, update world, render, etc
T = 1: poll

De read input op T = 0 mist dus de fysieke input van T = -6, iets wat met een hogere poll rate mogelijk niet was gebeurd.

[Blastpe]

Werelds schreef op dinsdag 05 maart 2013 @ 19:02:
Nee, juist niet. Als de frame tijden constant zijn heb je per GPU in principe genoeg aan de helft - ze overlappen elkaar immers (na de eerste paar honderd frames zal de scheduler dit dan wel mooi plannen).

Met onregelmatige frametijden kun je tot wel 5 keer zo veel FPS hebben, het gestotter zal nog steeds vervelend zijn (hoewel in dat geval hopelijk de langzame frames gewoon gedropt worden ).

Jij hebt het over frametijd, ik heb het over rendertijd.
Bij een single gpu is de frame tijd (tijd tussen 2 opeen volgende frames) de rendertijd, bij een dual gpu gaat dat niet op. GPU2 is nog aan het renderen als GPU1 een frame in het framebuffer parkeerd.XFire/SLI genereerd wel 2x zoveel frames maar niet 2x zo snel.

single gpu 60fps sync
|__16.6__|__16.6__|__16.6__|__16.6__|__16.6__|__16.6__|__16.6__|
_input___|__render↑ image

tussen game engine input en image met die input verwerkt zit 16.6ms.
Het beeld op je beeldscherm loopt 16.6 ms achter op de game engine

dual gpu 100fps sync
|___20___|___20___|___20___|___20___|___20___|___20___|___20___|___20___|___20___|
____|___20___|___20___|___20___|___20___|___20___|___20___|___20___|___20___|
_____input___|_render__↑ image
tussen game engine input en image met die input verwerkt zit 20 ms. Dat er tussentijds door GPU1 ook een frame is gegenereerd is niet relevant aangezien daar de input van de game engine nog niet verwerkt was
Het beeld op je beeldscherm loopt 20 ms achter op de game engine.

Leesvoer

[Verwijderd]

@Blastpe
Dat is net iets te simpel. Je gaat er nu vanuit dat de CPU altijd maar één frame tegelijk verwerkt en er alleen over de twee GPU's geparallelliseerd wordt. Dat is sinds de introductie van multi-core CPU's zeker niet meer het geval. Zowel frames zelf (aan een nieuw frame beginnen voordat het huidige voltooid is) als taken binnen een frame worden geparallelliseerd. Daarnaast vindt niet alles één keer per frame plaats, dat kan ook één keer per x aantal frames of x keer per seconde zijn. Dat kan om input handling gaan, maar physics wordt ook vaak op die manier gedaan. Je zult parallellisatie echt mee moeten nemen als je naar de lag tussen data (input, netwerk, etc.), verwerking en output gaat kijken.

Overigens is de frametijd niet de tijd tussen twee frames, het is niet alsof de PC/console tussen twee frames even een rookpauze van 5 ms inlast. De frametijd is de tijd die het kost om het gehele frame te genereren, of liever gezegd: de gameloop één maal in zijn geheel te doorlopen.

[ Voor 39% gewijzigd door Verwijderd op 06-03-2013 07:13 . Reden: overbodige quote verwijderd ]

[Blastpe]

Verwijderd schreef op woensdag 06 maart 2013 @ 07:13:
@Blastpe
Dat is net iets te simpel. Je gaat er nu vanuit dat de CPU altijd maar één frame tegelijk verwerkt en er alleen over de twee GPU's geparallelliseerd wordt. Dat is sinds de introductie van multi-core CPU's zeker niet meer het geval. Zowel frames zelf (aan een nieuw frame beginnen voordat het huidige voltooid is) als taken binnen een frame worden geparallelliseerd. Daarnaast vindt niet alles één keer per frame plaats, dat kan ook één keer per x aantal frames of x keer per seconde zijn. Dat kan om input handling gaan, maar physics wordt ook vaak op die manier gedaan. Je zult parallellisatie echt mee moeten nemen als je naar de lag tussen data (input, netwerk, etc.), verwerking en output gaat kijken.

Goed ik begrijp dat mijn punt niet overkomt.
Ik zal het simpel zeggen zonder technische zaken.
Mijn stelling is dat een systeem met een dual GPU waar een game draait op 100fps minder responsive is dan dat zelfde systeem zelfde game met een single GPU op 60fps.

Overigens is de frametijd niet de tijd tussen twee frames, het is niet alsof de PC/console tussen twee frames even een rookpauze van 5 ms inlast. De frametijd is de tijd die het kost om het gehele frame te genereren, of liever gezegd: de gameloop één maal in zijn geheel te doorlopen.

frametime

[Werelds]

Ik zal later nog een langere reply typen als ik tijd heb (druk met werk momenteel) maar die definitie is onjuist. Het is juist andersom, FPS is afhankelijk van de gemiddelde frametime gedurende een seconde. 60 frames van 16,67ms is 60 FPS, maar 30 frames van 8ms en 30 frames van 25,33ms is ook 60 FPS. Die laatste zal echter stotteren.

@ Olaf: klopt wel tot op zekere hoogte. Echter, "read input, update world" zou hier al op T=-7 plaats vinden, nogmaals, dat draait los van de render thread. Daarnaast staan kliks er helemaal los van, die komen *altijd* door. Het enige waar voor "gepolled" wordt (klopt niet helemaal, want het is de muis die juist stuurt) is de beweging. Afhankelijk van hoe de engine die input op vangt (zijn meerdere manieren voor in C++) is dat of een vector, waarbij hij dus aanneemt dat de vector van T=-7 nog steeds actief is of harde coordinaten. In dat eerste geval, wat de meeste engines doen, wordt het niet zichtbaar omdat op 8ms tijd die vector niet dusdanig veranderd kan zijn dat hij ineens de andere kant op staat. Jij kunt niet binnen 8ms de beweging van je muis veranderen (daarom had ik ook dat overdreven voorbeeld eerder)

[Olaf van der Spek]

Werelds schreef op woensdag 06 maart 2013 @ 10:35:
@ Olaf: klopt wel tot op zekere hoogte. Echter, "read input, update world" zou hier al op T=-7 plaats vinden, nogmaals, dat draait los van de render thread.

Maar niet op 1000Hz, toch? En ook niet in sync met USB polling.

Daarnaast staan kliks er helemaal los van, die komen *altijd* door.

Oh, wist ik niet. Heb je daar een referentie voor?

Het enige waar voor "gepolled" wordt (klopt niet helemaal, want het is de muis die juist stuurt) is de beweging. Afhankelijk van hoe de engine die input op vangt (zijn meerdere manieren voor in C++) is dat of een vector, waarbij hij dus aanneemt dat de vector van T=-7 nog steeds actief is of harde coordinaten. In dat eerste geval, wat de meeste engines doen, wordt het niet zichtbaar omdat op 8ms tijd die vector niet dusdanig veranderd kan zijn dat hij ineens de andere kant op staat. Jij kunt niet binnen 8ms de beweging van je muis veranderen (daarom had ik ook dat overdreven voorbeeld eerder)

De input zal inderdaad niet ineens tegengesteld zijn, maar de input kan nog steeds afwijken.

[Werelds]

Olaf van der Spek schreef op woensdag 06 maart 2013 @ 11:21:
Maar niet op 1000Hz, toch? En ook niet in sync met USB polling.

Jawel. Wij noemen het wel "USB polling" of "Mouse polling" maar in feite gaat het andersom. De muis stuurt die vector elke 8/4/2/1 ms naar de PC. Windows "luistert" naar die events, zodra dat binnenkomt reageert hij er op en vervolgens wordt er een event gebroadcast naar de WinApi. Dus elke update komt vrijwel acuut binnen bij de game engine; het is niet dat hij pollt, maar hij reageert op die events.

Oh, wist ik niet. Heb je daar een referentie voor?

Zo 1-2-3 niet, maar als je programmeer ervaring hebt hoef je maar even te zoeken op "mouse winapi" en dan vind je het vast wel. Let wel dat er twee events zijn: een gefilterde (zet de vector om naar coördinaten, standaard WinApi) en een ongefilterde. Die eerste voert al wat interpolation enzo uit.

Heel simpel te doen in C# ook, of als je Javascript kent is het in feite niets meer dan de muis/keyboard events aldaar. Is ook logisch, hoe kan Windows "pollen" of de knop is ingedrukt?

De input zal inderdaad niet ineens tegengesteld zijn, maar de input kan nog steeds afwijken.

Jawel, maar dat komt weer terug op wat ik zei. Bij een hogere rate krijg je meer signalen binnen waardoor het geheel wat accurater wordt, het is niet zo dat er vooraf iets vertraagd wordt. Die 125 Hz hebben ze heel bewust gekozen, omdat je dan twee updates per "standaard" frame hebt en voor 99% van de wereldbevolking is dat zat. Jouw ouders zullen het verschil tussen 125 en 1000 niet merken

[Olaf van der Spek]

Werelds schreef op woensdag 06 maart 2013 @ 13:23:
Jawel. Wij noemen het wel "USB polling" of "Mouse polling" maar in feite gaat het andersom. De muis stuurt die vector elke 8/4/2/1 ms naar de PC.

Dan nog heb je tot 8ms latency, toch?

Zo 1-2-3 niet, maar als je programmeer ervaring hebt hoef je maar even te zoeken op "mouse winapi" en dan vind je het vast wel. Let wel dat er twee events zijn: een gefilterde (zet de vector om naar coördinaten, standaard WinApi) en een ongefilterde. Die eerste voert al wat interpolation enzo uit.

Heel simpel te doen in C# ook, of als je Javascript kent is het in feite niets meer dan de muis/keyboard events aldaar. Is ook logisch, hoe kan Windows "pollen" of de knop is ingedrukt?

Windows: "Muis, heb je updates voor mij?"
Muis: "Ja Windows, die heb ik. Mijn linkerknop is momenteel ingedrukt."

Die 125 Hz hebben ze heel bewust gekozen, omdat je dan twee updates per "standaard" frame hebt

Heb je daar wel een bron voor of is dit ook speculatie (achteraf)?
Als de video refresh rate 85 of 120Hz is, heb je helemaal geen twee updates per 'frame'.

[Sp3ci3s8472]

Blastpe schreef op woensdag 06 maart 2013 @ 09:09:
[...]


Goed ik begrijp dat mijn punt niet overkomt.
Ik zal het simpel zeggen zonder technische zaken.
Mijn stelling is dat een systeem met een dual GPU waar een game draait op 100fps minder responsive is dan dat zelfde systeem zelfde game met een single GPU op 60fps.

[...]

frametime

Hij doelt op iets anders. In game engines draait niet elk component (netwerk/input/AI/physics) op dezelfde snelheid, dingen zoals AI en physics draaien vaak op een lagere frame rate. In dat geval zul je geen verschil merken tussen 100fsp dual gpu of 60fps single gpu, omdat sommige informatie op maar 30fps wordt verwerkt. Dus in feite laat je 2x dezelfde scene zien.
Ik overdrijf nu in dit geval.

Ik snap je punt trouwens wel dat het minder responsief kan aanvoelen, vroeger was dit erger. Tegenwoordig kan je in de driver aangeven hoeveel frames er vooruit worden gerendered (Nvidia had dit sowieso, bij AMD moet je misschien een tool gebruiken).
Zelfs bij single GPU opstellingen worden soms meerdere frames vooruit gerendered (3 frames dacht ik standaard). Stel dat je dit limiteerd op maximaal 2 frames vooruit renderen dan zal een dual GPU opstelling met 100fps soepeler aanvoelen dan een single GPU opstelling met 60fps.

[AMD_Aero]

Nu het toch zéér actueel is in dit topic op het moment:

De tweede test van HWI is er:
http://nl.hardware.info/r...660-ti-frame-times-review

Dat nVidia wint vind ik niet echt terecht. Ik zou het meer gelijkspel noemen AMD beter in BF3, nVidia beter in Hitman: Absolution.

Jammer dat Crysis 3 niet mee getest is.

[spNk]

Helemaal mee eens, maar het is algemeen bekend dat HWI een voorkeur heeft voor nvidia.

[Sp3ci3s8472]

AMD_Aero schreef op donderdag 07 maart 2013 @ 17:09:
Nu het toch zéér actueel is in dit topic op het moment:

De tweede test van HWI is er:
http://nl.hardware.info/r...660-ti-frame-times-review

Dat nVidia wint vind ik niet echt terecht. Ik zou het meer gelijkspel noemen AMD beter in BF3, nVidia beter in Hitman: Absolution.

Jammer dat Crysis 3 niet mee getest is.

Mee eens zeker omdat een spel zoals BF3 toch wel populairder is dan Hitman: Absolution, hier ga ik in dit geval even voor het gemak van uit .

Edit:
Misschien wel leuk omdat Nvidia op het moment van de dam schreeuwt dat ze met de Titan monitoren kunnen overclocken. Wij kunnen dat natuurlijk ook als AMD bezitters . Het kost iets meer moeite maar als je weet hoe regedit werkt dan kan je het zonder problemen proberen.
http://hardforum.com/showthread.php?t=1605511

Wat ik me bij zo'n overclock wel afvraag is of de componenten in je monitor hier erg onder lijden.

[ Voor 25% gewijzigd door Sp3ci3s8472 op 07-03-2013 17:44 . Reden: Overclock ]

[AMD_Aero]

Sp3ci3s8472 schreef op donderdag 07 maart 2013 @ 17:39:
Edit:
Misschien wel leuk omdat Nvidia op het moment van de dam schreeuwt dat ze met de Titan monitoren kunnen overclocken. Wij kunnen dat natuurlijk ook als AMD bezitters . Het kost iets meer moeite maar als je weet hoe regedit werkt dan kan je het zonder problemen proberen.
http://hardforum.com/showthread.php?t=1605511

Wat ik me bij zo'n overclock wel afvraag is of de componenten in je monitor hier erg onder lijden.

Als ik me niet vergis kan het zoals elke OC wel eens fout gaan. Vooral de PCB gaat eronder lijden...
Ik weet nog dat het vooral doeltreffend was met Koreanse PCB's sommige waren instaat om van 60 naar 120Hz te gaan.

Als je er echt in geïnteresseerd ben zou ik het eens proberen. Er zijn veel mensen die zeggen dat ze het verschil zien van 60Hz naar 75Hz. Er zijn ook monitors die niet eens 61Hz halen (artifacts).

Ik geloof er eigenlijk niet echt in, maar als je natuurlijk "snelle" ogen hebt dan kan het misschien wel eens interessant zijn.

Maar eigenlijk meer ontopic:
Ik heb me eigenlijk altijd af hoe ze drivers optimaliseren. Ik heb hier met veel interesse het verhaal over frametimes gelezen. Maar soms vraag ik me af hoe gaat AMD dat nu klaarspellen om "pieken" weg te krijgen zodanig dat alles vloeiender is. Het is vaak ook zéér verschillend per engine zie de test van Hwi hier over.

[madmaxnl]

spNk schreef op donderdag 07 maart 2013 @ 17:38:
Helemaal mee eens, maar het is algemeen bekend dat HWI een voorkeur heeft voor nvidia.

Lulkoek. Het zijn rare paters daar bij HWI en hun test en de daarbij behorende conclusies zijn... uuuh, tja... Enfin, ze zijn i.i.g. niet partijdig.

[spNk]

http://semiaccurate.com/2...-gpus-hit-the-intertubes/
Als de compute performance een indicatie is voor de game performance ziet het er goed uit, zeker als het om een mobile kaart.

Had deze al per ongeluk in het verkeerde topic geplaatst .

[Verwijderd]

AMD_Aero schreef op donderdag 07 maart 2013 @ 17:09:

Dat nVidia wint vind ik niet echt terecht. Ik zou het meer gelijkspel noemen AMD beter in BF3, nVidia beter in Hitman: Absolution.

Je vergeet FC3 in dit rijtje, en daar scoort de HD7950 welliswaar een fractie beter qua fps (op max settings), maar qua ms loopt de GTX660 Ti wel een stuk beter en speelt het soepeler.
Het hele ms verhaal is hier leidend, dus dan is het toch niet heel vreemd dat ze de GTX660 Ti hier een klein voordeel geven in de conclusie?

[Tomas Hochstenbach]

Ik heb een weekendje een Ares II liggen. Ik heb morgen de hele dag de tijd om te testen. Iemand tests die niet te veel tijd kosten maar toch interessant zijn om te draaien op zo'n kaart? Ik wil sowieso één of twee games met frametimes testen, maar alle input is welkom .

[Astennu]

spNk schreef op vrijdag 08 maart 2013 @ 08:43:
http://semiaccurate.com/2...-gpus-hit-the-intertubes/
Als de compute performance een indicatie is voor de game performance ziet het er goed uit, zeker als het om een mobile kaart.

Had deze al per ongeluk in het verkeerde topic geplaatst .

Ik moet zeggen dat ik het tegen vind vallen gezien de clockspeeds.
Hij heeft meer dan 10% meer instructie units. En ook nog iets hogere clocks. En daarbij zou hij ook architectuur verbeteringen moeten hebben.

Dus ik had zelf toch een beetje op 15-20% gehoopt. Maar goed het zijn early leaks/hoaxes. Dus het zegt niets.

[tomcatha]

voor de zelfde geld zorgen de tweaks alleen voor hogere yields...

[Astennu]

tomcatha schreef op dinsdag 12 maart 2013 @ 12:49:
voor de zelfde geld zorgen de tweaks alleen voor hogere yields...

Dat betekend 2 jaar lang stilstand. En dat zou heel dom zijn. Want nVidia staat zeker niet stil die ontwikkelen vol op door. AMD is nu goed op weg met GCN en je kan mij ook niet vertellen dat er niets beter kan want er kan heel wat beter. Het is geen slechte chip maar het is nu tijd om net als met VLIW5 de boel te optimaliseren.

Maar laten we het allemaal maar even afwachten. Dit zijn toch allemaal maar geruchten.

[Olaf van der Spek]

Astennu schreef op dinsdag 12 maart 2013 @ 15:37:
Dat betekend 2 jaar lang stilstand.

Zonder niet productieproces gaat vooruitgang niet snel, wen er maar alvast aan.

[Astennu]

Daar ben ik het niet helemaal mee eens. Je kan op meer manieren dingen verbeteren.
Als je de chip helemaal niet groter wilt maken wordt het inderdaad lastig. Maar dan is het nog steeds mogelijk om behoorlijke winst te behalen door de architectuur te optimaliseren.

Maar het klopt we zitten nog wel even aan 28nm vast. Zou me niets verbazen als we eind 2014 pas een opvolger voor 28nm hebben die voor GPU's gebruikt gaat worden.

[ArgantosNL]

Ik hoop dat ze voor die tijd nog met een echte nieuwe serie komen. Ik weet niet hoe lang mijn huidige videokaart het nog gaat overleven.

[Olaf van der Spek]

Astennu schreef op woensdag 13 maart 2013 @ 08:59:
Daar ben ik het niet helemaal mee eens. Je kan op meer manieren dingen verbeteren.
Als je de chip helemaal niet groter wilt maken wordt het inderdaad lastig.

De chips zijn al aardig groot en groter maken is aardig duur.

Maar dan is het nog steeds mogelijk om behoorlijke winst te behalen door de architectuur te optimaliseren.

Misschien, maar die truc kun je ook maar een paar keer uithalen. En dan ga je er eigenlijk van uit dat de architectuur erg suboptimaal was, iets wat me ook sterk lijkt.

[Astennu]

Olaf van der Spek schreef op woensdag 13 maart 2013 @ 10:32:
[...]

De chips zijn al aardig groot en groter maken is aardig duur.

[...]

Misschien, maar die truc kun je ook maar een paar keer uithalen. En dan ga je er eigenlijk van uit dat de architectuur erg suboptimaal was, iets wat me ook sterk lijkt.

Klopt. Maar de GK110 is ook heel erg groot. In dat opzicht is Tahiti maar klein. dus iets groter kan opzich nog wel.

Dat is zeker zo. Je kan het 1/2x doen dan houd het toch wel een beetje op. GCN is nieuw dus er valt dan nog veel te verbeteren. zie ook VLIW5 en wat daar aan verbeterd is.

Bij de stap van HD2900 naar HD3870 een verkleining en optimalisatie aan de memory controller kant. Vervolgens bij de HD4870 serie kleinere shaders waardoor er ineens geen 320 maar 800 in een core gestopt konden worden. Dan HD5870 nog meer shaders die meer konden doen en DX11 aan konden. En de laatste stap HD6870 verdere optimalisatie van de verhoudingen shaders/TMU's/ROPs waardoor de chip efficiënter is geworden.

Als ze een HD69xx hadden gemaakt op basis van Barts dus met 2x 1120 shaders. Had je echt een indrukwekkende GPU gehad qua gaming prestaties. (HD69xx was iets meer gericht op GPGPU dan de voorgangers lang niet zo veel als GCN maar al wel meer dan VLIW5 in de HD58 en HD68 serie)

Dus ik gok dat ze met een minimaal grotere Die en even veel shaders als de 7970 nu best 10-15% winst kunnen boeken door GCN te optimaliseren. En als je ook beter gaat uitbalanceren is er wellicht nog meer mogelijk. De toekomst zal het leren. Maar ik gok dat GCN nog wel een aantal jaar mee zal moeten.

[ Voor 10% gewijzigd door Astennu op 13-03-2013 12:02 ]

[Verwijderd]

Die grote is ook altijd wat. Toen nvidia met de gf100 en gf110 kwamen was hij te groot toen AMD kwam met de tahiti was hij te groot. Nu de titan ook al te groot. Het maakt allemaal niets uit voor de gewone consument als hij maar snel zat is. Verbruik word in veel gevallen ook niet naar gekeken, geld speelt dan wel weer een belangrijke rol.

[Olaf van der Spek]

Astennu schreef op woensdag 13 maart 2013 @ 12:01:
Dus ik gok dat ze met een minimaal grotere Die en even veel shaders als de 7970 nu best 10-15% winst kunnen boeken door GCN te optimaliseren.

15% winst is niet behoorlijk, dat is minimaal.

[tomcatha]

Verwijderd schreef op woensdag 13 maart 2013 @ 12:20:
Die grote is ook altijd wat. Toen nvidia met de gf100 en gf110 kwamen was hij te groot toen AMD kwam met de tahiti was hij te groot. Nu de titan ook al te groot. Het maakt allemaal niets uit voor de gewone consument als hij maar snel zat is. Verbruik word in veel gevallen ook niet naar gekeken, geld speelt dan wel weer een belangrijke rol.

de grote van de die heeft invloed op de prijs erg veel invloed zelfs.

[Verwijderd]

Dat is helemaal waar, maar ja daar voor krijg je ook weer meer prestaties.
Hoe groter hoe meer het uit verhouding gaat liggen, prijs prestatie, maar wetende dat de gemiddelde consument ook niet tot de doelgroep behoort, en dat is vaak de groep die er het meest over klagen vaak.
Helaas kan het niet ander dan dit, meer prestaties komt uit een grotere die met als gevolg een flinke meer prijs en meer verbruik, al vind ik het verbruik van de titan nog aardig mee vallen. Alleen die prijs vind ik te veel voor die prestaties, maar ik behoor niet tot die doel groep dus ik kan wel meer willen.

[Verwijderd]

http://nl.hardware.info/n...ara-croft-met-amd-tressfx

Deze nieuwe fuctie van AMD Tress FX met directcompute vind ik echt een mooie toevoeging in games.
Hoepljk komt dit veel meer terug in games. Die nvidia variant ziet er ook niet verkeerd uit, haar met tesselation ofzo, maar ik denk dat daar weer physx achter zal zitten.

[eL_Jay]

Verwijderd schreef op maandag 18 maart 2013 @ 14:58:
http://nl.hardware.info/n...ara-croft-met-amd-tressfx

Deze nieuwe fuctie van AMD Tress FX met directcompute vind ik echt een mooie toevoeging in games.
Hoepljk komt dit veel meer terug in games. Die nvidia variant ziet er ook niet verkeerd uit, haar met tesselation ofzo, maar ik denk dat daar weer physx achter zal zitten.

Hopelijk komt dat niet terug, afaik is TressFX AMDs physx tegenhanger. Maw developpers moeten ervoor gaan programmeren. Hoeveel games zijn er dit jaar uitgekomen met Physx? (m.a.w. nog meer versplintering zie ik niet zitten. Houd het lekker bij DirectX,OpenGL in plaats van dat je dadelijk voor ieder merk weer een eigen laag gaat toevoegen (die natuurlijk alleen lekker werkt op high-end))

[Sp3ci3s8472]

eL_Jay schreef op maandag 18 maart 2013 @ 15:03:
[...]

Hopelijk komt dat niet terug, afaik is TressFX AMDs physx tegenhanger. Maw developpers moeten ervoor gaan programmeren. Hoeveel games zijn er dit jaar uitgekomen met Physx? (m.a.w. nog meer versplintering zie ik niet zitten. Houd het lekker bij DirectX,OpenGL in plaats van dat je dadelijk voor ieder merk weer een eigen laag gaat toevoegen (die natuurlijk alleen lekker werkt op high-end))

Als het vergelijkbaar is dan hoop ik juist dat het terug komt. Dan kunnen bedrijven ook meteen stoppen met physics omdat dit op AMD en Nvidia wordt ondersteunt zover ik weet.

Maar volgens mij is het niet veel meer dan tesselation op het haar en wat extra self collision checks/wind dat gewoon door de game engine wordt afgehandelt.

[Verwijderd]

Het is niet te vergelijken want het werkt via directcompute wat net zo goed op nvdia kan werken maar nvidia onderhoud directcompute niet goed geloof ik. Na de driver update werkt het iig heel goed op nvidia kaarten. Nog wel beter op amd kaarten dat wel maar dat is met de meeste amd gaming evolved games zo.
Er komt suport voor physx in de nieuwe ps3, hopelijk word het hier door ook voor pc's met amd kaarten
mogelijk gemaakt in de toekomst zo dat nvidia en amd toch meer gaan samen wekren.

[ Voor 39% gewijzigd door Verwijderd op 18-03-2013 20:03 ]

[madmaxnl]

AMD gaat PhysX in zijn huidige vorm i.i.g. niet ondersteunen. nVidia zou dat graag willen, maar AMD weet wel beter.

AMD heeft namelijk geen enkele invloed op PhysX. nVidia kan er dus voor zorgen dat PhysX beter werkt op een nVidia kaart dan op een AMD kaart. Bijvoorbeeld door het kreupel maken van de software om zo AMD kaarten, maar ook eigen kaarten onderuit te halen (waarbij de AMD kaarten relatief veel harder achteruit gaan). Dit heeft nVidia bijvoorbeeld ook bij Crysis 2 gedaan met de tesselation.

nVidia heeft in dit geval namelijk de mogelijkheid om de software mooi te laten aansluiten op de hardware en vice versa. AMD heeft die mogelijkheid niet in dit geval en zal daardoor dus altijd achter de feiten aanlopen. AMD kan alleen zijn hardware optimaliseren voor de software. Probleem hierbij is, dat wanneer AMD zijn hardware voor PhysX geoptimaliseerd heeft dat nVidia het met zijn software over een andere boeg heen kan gooie en AMD geen fluit heeft aan zijn optimalisaties.

Dit risico heb je bij OpenCL, C+ AMP en DirectCompute niet. Daar hebben nVidia en AMD beiden geen invloed op en kunnen ze alleen aan de hardware kant sleutelen alhoewel ze beiden wel zo hun eigen voorkeur hebben: Stream en CUDA.

[ Voor 3% gewijzigd door madmaxnl op 19-03-2013 10:23 ]

[spNk]

Ik moest even je laatste zin een paar keer lezen voor ik hem begreep, ik gok dat er een "r" mist in steam?

[Verwijderd]

madmaxnl schreef op maandag 18 maart 2013 @ 21:15:
AMD gaat PhysX in zijn huidige vorm i.i.g. niet ondersteunen. nVidia zou dat graag willen, maar AMD weet wel beter.

AMD heeft namelijk geen enkele invloed op PhysX. nVidia kan er dus voor zorgen dat PhysX beter werkt op een nVidia kaart dan op een AMD kaart. Bijvoorbeeld door het kreupel maken van de software om zo AMD kaarten, maar ook eigen kaarten onderuit te halen (waarbij de AMD kaarten relatief veel harder achteruit gaan). Dit heeft nVidia bijvoorbeeld ook bij Crysis 2 gedaan met de tesselation.

PS4 krijgt ondersteuning voor physx, maar zal dan wel via de cpu gaan lopen?
http://nl.hardware.info/n...teuning-voor-nvidia-physx

Aii, dat zelfde doet AMD ook met extreme SSAA in games, ze halen zo hun eigen kaarten een klein beetje onderuit en nvidia kaarten gaan nog harder onderuit. Dit zie je bij nvidia en AMD, dat is niets nieuws.
Sleeping dogs, tombraider en sniper elite v2.

[eL_Jay]

Sp3ci3s8472 schreef op maandag 18 maart 2013 @ 15:38:
[...]


Als het vergelijkbaar is dan hoop ik juist dat het terug komt. Dan kunnen bedrijven ook meteen stoppen met physics omdat dit op AMD en Nvidia wordt ondersteunt zover ik weet.

Zie liever physics dan Physx Heb liever eenheidsworst waarbij AMD en Nvidia zich enkel kunnen differentiëren door de hardware en drivers en niet allemaal van die kleine dingetjes die het allemaal net niet worden. 1 standaard voor multi-display en 3d, 1 standaard voor Physx/TressFX. Zou het liefst zelfs 1 programma zien a la CCC wat voor beide fabrikanten zou werken.

[Sp3ci3s8472]

eL_Jay schreef op dinsdag 19 maart 2013 @ 14:18:
[...]

Zie liever physics dan Physx .

Wat een slechte tikfout aan mijn kant .

Physx daarentegen zal op de ps4 inderdaad via de cpu gaan. Ik kan mij niet voorstellen dat AMD zich ineens gaat aanpassen voor de Sony/de PS4 om physx te draaien.

[bwerg]

Sp3ci3s8472 schreef op dinsdag 19 maart 2013 @ 17:46:
Physx daarentegen zal op de ps4 inderdaad via de cpu gaan. Ik kan mij niet voorstellen dat AMD zich ineens gaat aanpassen voor de Sony/de PS4 om physx te draaien.

Waarom zou NVidia dat doen, volgens de CPU zou het toch altijd zo ontzettend slechte performance geven?

Ik vind het eigenlijk wel jammer. Ik hoop nog altijd dat ze PhysX gewoon laten varen.

[Werelds]

Sp3ci3s8472 schreef op dinsdag 19 maart 2013 @ 17:46:
[...]


Wat een slechte tikfout aan mijn kant .

Physx daarentegen zal op de ps4 inderdaad via de cpu gaan. Ik kan mij niet voorstellen dat AMD zich ineens gaat aanpassen voor de Sony/de PS4 om physx te draaien.

AMD zou dat vast wel willen doen, het is Nvidia die dat niet toe laat. PhysX werkt alleen via CUDA dus hoe graag AMD ook zou willen, het kan gewoon niet.

[Verwijderd]

Voor de goede orde, PhysX is een physics engine zoals er vele zijn, zoals bijvoorbeeld Bullet, ODE en Box2D. PhysX heeft als speciale feature dat het een deel van de berekeningen op de GPU uit kan voeren ipv de CPU, maar het feit dat de engine de PS4 gaat ondersteunen wil absoluut niet zeggen dat die feature ook ondersteund gaat worden. Nvidia heeft daar niets over gezegd.

PhysX wordt als physics engine redelijk veel gebruikt, het zou raar geweest zijn als zo'n veelgebruikte engine een groot platform als de PS4 niet zou ondersteunen. Ondersteuning van een console met AMD GPU is niets nieuws, de 360, Wii en Wii U worden ook door PhysX ondersteund. Zo lang Nvidia niet expliciet naar buiten brengt dat PhysX op de PS4 de GPU gaat gebruiken kun je er rustig vanuit gaan dat dat niet het geval is.

[ Voor 20% gewijzigd door Verwijderd op 20-03-2013 22:01 ]