CJ's Radeon Nieuwsdiscussietopic - Deel 121

[Xenomorphh]

Hyperz schreef op vrijdag 15 april 2011 @ 15:19:
55nm - 40nm = 15
40nm - 28nm = 12

Is het realistisch om aan te nemen dat we een minder grote sprong in performance gaan zien dan 4870 -> 5870? Of valt dat niet te vergelijken op die manier?

Das een beetje kort door de bocht, je hebt met te maken met architecturale verbeteringen. Ook kunnen ze er voor kiezen om de die iets groter te maken waardoor die dus wel weer een stuk krachtiger kan zijn.

[Anoniem: 303530]

NitroX infinity schreef op vrijdag 15 april 2011 @ 15:23:
In procenten is de laatste beter;

40 / 55 * 100 = 72,73%
28 / 40 * 100 = 70,00%

Je doet het verkeerd, de groote in nanometers slaat op een een dimensionale schaal, dat wil zeggen:

55nm = 3025nm²
40nm = 1600nm² (=53% van 55nm)
28nm = 784nm² (=49% van 40nm)

Bij elke overstap word een transistor (plusminus) 2x zo klein, ofwel:
2x zoveel transistors op eenzelfde oppervlak
Of:
Een chip die maar half zo groot is. (en half zo duur)

Dit is ook de reden dat iedereen zo snel mogelijk over wil stappen op een kleiner flashprocede: de kosten dalen met de helft zodra het procede is ingeburgerd. Je krijgt immers 2x zoveel chips uit een wafer.

[ Voor 15% gewijzigd door Anoniem: 303530 op 15-04-2011 15:37 ]

[haarbal]

en ik zit hier nog met 2 65nm bakbeesten

maar zijn ze niet ook iets efficienter clock/clock en minder energie nodig op zelfde clock?

[ Voor 52% gewijzigd door haarbal op 15-04-2011 15:42 ]

[Hyperz]

Xenomorphh schreef op vrijdag 15 april 2011 @ 15:28:
Ook kunnen ze er voor kiezen om de die iets groter te maken waardoor die dus wel weer een stuk krachtiger kan zijn.

Ik denk dat dit de meest interessante unknown is. Vanaf de 38xx is de die opnieuw steeds groter geworden. De vraag is dan, hoeveel groter zijn ze nog bereid te gaan? 389mm² voor Cayman komt toch weer in de buurt van de r600. Dus ze zullen op een gegeven moment moeten stoppen met steeds grotere dies te maken, of er zal een tweede rv670 moeten komen met weinig performance improvements over de vorige generatie.

[Depep]

Hyperz schreef op vrijdag 15 april 2011 @ 16:00:
[...]


Ik denk dat dit de meest interessante unknown is. Vanaf de 38xx is de die opnieuw steeds groter geworden. De vraag is dan, hoeveel groter zijn ze nog bereid te gaan? 389mm² voor Cayman komt toch weer in de buurt van de r600. Dus ze zullen op een gegeven moment moeten stoppen met steeds grotere dies te maken, of er zal een tweede rv670 moeten komen met weinig performance improvements over de vorige generatie.

Ik verwacht dat de 7-serie dat wordt. Cayman is weer een overstap naar een nieuwe architectuur, net als de HD2900XT dat was. Ook Cayman is weer op een groter proces geproduceerd dan gepland. Waarschijnlijk wordt de 7-serie Cayman zoals deze bedoeld was. Een die shrink + optimalisaties, net als HD2900XT -> HD3870.

[Hyperz]

Die kans zit er idd in. Alhoewel, kijkende naar wat nVidia aan het doen is, is het misschien ook niet de beste optie. Want in dat geval zullen ze weer op een grote achterstand komen op performance gebied waardoor ze marktaandeel zullen verliezen. Tenzij nVidia hetzelfde doet. Als je ziet hoeveel drama er was met de introductie van de HD 68xx en toen duidelijk werd dat Cayman dan toch niet de GTX 580 kon bijbenen... Misschien is het tijd om hun strategie te herzien.

Het wordt weer lekker spannend .

[ Voor 5% gewijzigd door Hyperz op 15-04-2011 16:30 ]

[Xenomorphh]

Depep schreef op vrijdag 15 april 2011 @ 16:12:
[...]


Ik verwacht dat de 7-serie dat wordt. Cayman is weer een overstap naar een nieuwe architectuur, net als de HD2900XT dat was. Ook Cayman is weer op een groter proces geproduceerd dan gepland. Waarschijnlijk wordt de 7-serie Cayman zoals deze bedoeld was. Een die shrink + optimalisaties, net als HD2900XT -> HD3870.

Met Cayman is niks mis ook met de architectuur niet. Deze zullen ze schriken plus meer shaders en noem maar op. Op die manier krijg je wel weer een stuk krachtigere chip.

Ik verwacht dat SI high end chip ~75% sneller is als cayman.

[Bullus]

AMD Catalyst 11.4 (8.841 April 5) Win7/Vista/XP x86/x64

[bwerg]

Depep schreef op vrijdag 15 april 2011 @ 14:33:
[...]


Volgens mij deed de HD5870 het best aardig tegen de HD4870X2. Net als de HD4870 tegen de HD3870X2. Niet zo heel onrealistisch...

Dat kwam omdat de chips gewoon steeds groter werden. Dat trucje hou je niet eeuwig vol. Dat zie je al bij de HD6000-serie, iedereen klaagt dat de extra performance t.o.v. de HD5000-serie niet genoeg is, maar als ze de lijn HD3000 - HD4000 - HD5000 willen doorzetten dan komen ze binnenkort op een onhoudbaar verbruik uit. De winst van de HD7000 zal dus enkel van de procedéverkleining moeten komen (en architecturale verbeteringen, maar dat zal geen verschil van dag en nacht zijn). 'T zal wel weer een stuk beter worden hoor, maar steeds dubbel zoveel als de vorige series gaat hem nooit worden.

Want realistisch gezien gaat de performance/watt bij GPUs ook niet zo hard vooruit als je op basis van pure performance misschien zou verwachten. Een HD5870 is wel veel sneller dan een HD3870, maar het TDP ligt dan ook ongeveer dubbel zo hoog. Bij de HD3000 hadden ze echt de strategie van een kleine GPU, terwijl de HD6970 eigenlijk heel lomp is. Nogal wiedes dat je performance dan met sprongen vooruit gaat.

[ Voor 5% gewijzigd door bwerg op 15-04-2011 21:17 ]

[Xenomorphh]

bwerg schreef op vrijdag 15 april 2011 @ 21:14:
[...]

Dat kwam omdat de chips gewoon steeds groter werden. Dat trucje hou je niet eeuwig vol. Dat zie je al bij de HD6000-serie, iedereen klaagt dat de extra performance t.o.v. de HD5000-serie niet genoeg is, maar als ze de lijn HD3000 - HD4000 - HD5000 willen doorzetten dan komen ze binnenkort op een onhoudbaar verbruik uit. De winst van de HD7000 zal dus enkel van de procedéverkleining moeten komen (en architecturale verbeteringen, maar dat zal geen verschil van dag en nacht zijn). 'T zal wel weer een stuk beter worden hoor, maar steeds dubbel zoveel als de vorige series gaat hem nooit worden.

Want realistisch gezien gaat de performance/watt bij GPUs ook niet zo hard vooruit als je op basis van pure performance misschien zou verwachten. Een HD5870 is wel veel sneller dan een HD3870, maar het TDP ligt dan ook ongeveer dubbel zo hoog. Bij de HD3000 hadden ze echt de strategie van een kleine GPU, terwijl de HD6970 eigenlijk heel lomp is. Nogal wiedes dat je performance dan met sprongen vooruit gaat.

HD6xxx en HD5xxx zijn dan ook allebei op 40nm gebakken dus dan is het ook lastig om heel veel sneller te worden zonder de die groter te maken. Nu ze overstappen op 28nm heb je een kleinere die (er van uitgaande dat de 6970 alleen verkleint wordt) En heb je dus nog genoeg ruimte over om meer shaders toe te voegen zodat je dezelfde die grote krijgt als die van de HD6970. Je die hoeft dus niet groter te worden en hoeft het TDP ook niet drastisch omhoog.

[Anoniem: 245699]

Het is natuurlijk wel zo dat wanneer ze de chip niet vergroten qua mm² en dus gewoon overstappen naar 28nm ze er wel weer iets van een miljard extra transistors op kunnen plempen en als je ziet dat de huidige Cayman 2,64 miljard transistors heeft zou die verhoging i.c.m. verdere verbetering in de architectuur zeker 50% extra performance moeten kunnen opleveren. En vooral verbeteringen in de architectuur gaat altijd door en ze zullen altijd weer nieuwe dingen vinden, dus de de performance verbetering per mm² wordt bij de HD7xxx serie natuurlijk een stuk groter dan bij de overgang van HD5xxx naar HD6xxxx.

[Hyperz]

Ik hoop in ieder geval dat ze eindelijk eens werk maken van hun relatief trage AA performance. Nu ken ik niet veel van GPU architecturen maar het lijkt me toch dat er nog ergens een bottleneck zit op dat gebied. Beste voorbeeld hiervan is wss Bad Company 2. Vanaf dat je AA boven 2x zet en er veel smoke moet gerendeerd worden stort de performance totaal in (met een 6950 @ 1680x1050 2x AA gaat de framerate van 80 naar 30-40 fps). Had exact hetzelfde fenomeen met een 4870. nVidia kaartjes schijnen daar geen last van te hebben.

[winwiz]

Bullus schreef op vrijdag 15 april 2011 @ 20:35:
AMD Catalyst 11.4 (8.841 April 5) Win7/Vista/XP x86/x64

Mooi, het 99% GPU gebruik is opgelost

[Milmoor]

Xenomorphh schreef op zaterdag 16 april 2011 @ 12:55:

offtopic:
aanvulling voor je signature:
There are 10 kinds of people in the world — those who understand binary and those who don't.
There are 10 kinds of people in the world — those who understand trinary, those who don't understand trinary and those who mistake it for binary.

[maratropa]

Hi Radeon hippies! Zouden sommige van jullie mij kunnen helpen? Ik probeer wat kaarten te vergelijken voor workstation gebruik, zo ben ik benieuwd naar Cinebench 11.5 opengl scores, maar die zijn niet altijd makkelijk te vinden voor recente kaarten zoals de HD 6950. Als iemand tijd heeft zou hij dan deze benchmark eens kunnen laten draaien? (ik ben ook wel benieuwd naar andere dan de 6950)

http://www.maxon.net/downloads/cinebench/cinebench-115.html

(Ik kan wel wat vinden maar daar staat alleen bij 6900 -series, dus niet specifiek de 50,70 etc)

[ Voor 4% gewijzigd door maratropa op 17-04-2011 11:11 ]

[Fid3lity]

maratropa schreef op zondag 17 april 2011 @ 11:10:
Hi Radeon hippies! Zouden sommige van jullie mij kunnen helpen? Ik probeer wat kaarten te vergelijken voor workstation gebruik, zo ben ik benieuwd naar Cinebench 11.5 opengl scores, maar die zijn niet altijd makkelijk te vinden voor recente kaarten zoals de HD 6950. Als iemand tijd heeft zou hij dan deze benchmark eens kunnen laten draaien? (ik ben ook wel benieuwd naar andere dan de 6950)

http://www.maxon.net/downloads/cinebench/cinebench-115.html

(Ik kan wel wat vinden maar daar staat alleen bij 6900 -series, dus niet specifiek de 50,70 etc)

Het is niet echt nieuws, maar ik zal Cinebench zo wel even voor je willen draaien. Eventueel doe ik dat ook nog op de 6950

edit:
Cinebench 11.5 - 63.80 fps average bij de OpenGL test @ HD6970 flash.

[ Voor 5% gewijzigd door Fid3lity op 17-04-2011 11:21 ]

[maratropa]

Oh sorry ik dacht dat het wel aansluit bij dit topic, maar je hebt natuurlijk ook een "algemeen" radeon topic dan?

iig, thanx!

[Fid3lity]

maratropa schreef op zondag 17 april 2011 @ 11:24:
Oh sorry ik dacht dat het wel aansluit bij dit topic, maar je hebt natuurlijk ook een "algemeen" radeon topic dan?

iig, thanx!

We hebben een Ervaringen-topic, is te vinden via de search rechtsboven

[Help!!!!]

Behardware: Crysis 2 - performance across 45 graphics cards!

Let’s finish off with a few remarks on CrossFire X and more particularly the fact that there’s still no Crysis 2 support one week after release.
While we imagine that AMD won’t delay much longer, it’s incomprehensible that users of this technology, or bi-GPU cards, have to wait so long to enjoy a hit such as Crysis 2 on their hardware. If relationships with one developer or another don’t always allow the preparation of a profile in advance, AMD should be working all out in such cases to get a solution into place as quickly as possible, even if only in beta version at first.
This seems far from impossible to us, especially as renaming the executable file to use the profile of another game sorts out the problem to a great extent!
Unfortunately, barely a few weeks after the release of the Radeon HD 6990, AMD has once again highlighted the weak point of its multi-GPU solutions…

Moet zeggen dat ik het hier zeker mee eens ben.
Alhoewel bijv. renamen voor sommige mensen werkt, werkt het bij mij niet. Heb van alles geprobeerd, renamen allerlei caps, whql en previewdrivers maar krijg CF niet flickervrij.

[Anoniem: 304087]

Ook niet zonder de crysis 2 advanced graphic options Help?
Want met die opties aan heb ik ook flickeringen

[Help!!!!]

Anoniem: 304087 schreef op maandag 18 april 2011 @ 11:17:
Ook niet zonder de crysis 2 advanced graphic options Help?
Want met die opties aan heb ik ook flickeringen

Je bedoeld de third party tool?

Met en zonder heb ik flikkeringen.

[Astennu]

HD6670 en HD6570 review van Anandtech:

http://www.anandtech.com/...on-hd-6670-radeon-hd-6570

Iets sneller dan afgelopen generatie. Maar vooral lekker zuinig in 2D mode.

[rabor]

maratropa schreef op zondag 17 april 2011 @ 11:10:
Hi Radeon hippies! Zouden sommige van jullie mij kunnen helpen? Ik probeer wat kaarten te vergelijken voor workstation gebruik, zo ben ik benieuwd naar Cinebench 11.5 opengl scores, maar die zijn niet altijd makkelijk te vinden voor recente kaarten zoals de HD 6950. Als iemand tijd heeft zou hij dan deze benchmark eens kunnen laten draaien? (ik ben ook wel benieuwd naar andere dan de 6950)

http://www.maxon.net/downloads/cinebench/cinebench-115.html

(Ik kan wel wat vinden maar daar staat alleen bij 6900 -series, dus niet specifiek de 50,70 etc)

[Edmin]

Astennu schreef op dinsdag 19 april 2011 @ 11:45:
HD6670 en HD6570 review van Anandtech:

http://www.anandtech.com/...on-hd-6670-radeon-hd-6570

Iets sneller dan afgelopen generatie. Maar vooral lekker zuinig in 2D mode.

Ik begrijp werkelijk waar niet waarom Anandtech die kaarten met 4xAA test. Dit soort kaarten zijn imho vooral interessant voor wie de mogelijkheid wil hebben om met zijn basis pc, HTPC of workstation af en toe een spelletje te spelen. Daar is 4xAA helemaal niet van toepassing. Ik had liever 1680 en 1920 zonder AA gezien.

[edward2]

Help!!!! schreef op maandag 18 april 2011 @ 10:48:
Behardware: Crysis 2 - performance across 45 graphics cards!


[...]


Moet zeggen dat ik het hier zeker mee eens ben.
Alhoewel bijv. renamen voor sommige mensen werkt, werkt het bij mij niet. Heb van alles geprobeerd, renamen allerlei caps, whql en previewdrivers maar krijg CF niet flickervrij.

Je moet even opnieuw de laatste CAP3 downen, die is onlangs weer vernieuwd en met deze presteert Crysis2 inmiddels naar behoren en heeft zelfs een iets hogere framerate dan renamen naar Fear of Bioshock.

[NitroX infinity]

Edmin schreef op dinsdag 19 april 2011 @ 13:06:
[...]

Ik begrijp werkelijk waar niet waarom Anandtech die kaarten met 4xAA test. Dit soort kaarten zijn imho vooral interessant voor wie de mogelijkheid wil hebben om met zijn basis pc, HTPC of workstation af en toe een spelletje te spelen. Daar is 4xAA helemaal niet van toepassing. Ik had liever 1680 en 1920 zonder AA gezien.

Ik vind 4x AA helemaal niet zo gek. Helemaal bij de wat oudere spellen geeft het wat extra's. High-end gaming mag dan niet besteed zijn aan deze kaarten maar de oudere spellen die vroeger high-end waren kun je er prima mee spelen zelfs met AA.

[Astennu]

Edmin schreef op dinsdag 19 april 2011 @ 13:06:
[...]

Ik begrijp werkelijk waar niet waarom Anandtech die kaarten met 4xAA test. Dit soort kaarten zijn imho vooral interessant voor wie de mogelijkheid wil hebben om met zijn basis pc, HTPC of workstation af en toe een spelletje te spelen. Daar is 4xAA helemaal niet van toepassing. Ik had liever 1680 en 1920 zonder AA gezien.

True al vind ik het wel interessant om te zien dat de nieuwe architectuur het in verhouding iets beter doet met AA dan de vorige generatie. Al zal het niet super nuttig zijn. AA is echt iets voor de HD68xx en de GT56x of hoger.

[Help!!!!]

edward2 schreef op dinsdag 19 april 2011 @ 13:45:
[...]


Je moet even opnieuw de laatste CAP3 downen, die is onlangs weer vernieuwd en met deze presteert Crysis2 inmiddels naar behoren en heeft zelfs een iets hogere framerate dan renamen naar Fear of Bioshock.

Dank je. Helaas werkt dat ook niet. Ik wacht nog wel ff. Ben gelukkig toch bezig met een ander spel.

[Fid3lity]

Edmin schreef op dinsdag 19 april 2011 @ 13:06:
[...]

Ik begrijp werkelijk waar niet waarom Anandtech die kaarten met 4xAA test. Dit soort kaarten zijn imho vooral interessant voor wie de mogelijkheid wil hebben om met zijn basis pc, HTPC of workstation af en toe een spelletje te spelen. Daar is 4xAA helemaal niet van toepassing. Ik had liever 1680 en 1920 zonder AA gezien.

Regel voor mij een kaartje en ik wil wel testen op 1680 x 1050 zonder AA met een paar leuke, simpele, doch populaire titels

[spNk]

Met mijn 4850 kan ik toch nog redelijk wat games vol open draaien op 1920x1200 met 2 - 4x AA hoor. Toegegeven ik speel geen crysis, maar MoH 2010 speelt wel aardig weg met 2xAA.

[Astennu]

spNk schreef op dinsdag 19 april 2011 @ 21:24:
Met mijn 4850 kan ik toch nog redelijk wat games vol open draaien op 1920x1200 met 2 - 4x AA hoor. Toegegeven ik speel geen crysis, maar MoH 2010 speelt wel aardig weg met 2xAA.

Ik heb een 4850 512MB overclocked en die kan na genoeg geen games goed spelen zelfs niet zonder AA. En over goed heb ik het over zeker 40+ FPS. Er zijn genoeg games die met max settings daar onder komen.

1680x1050 begint zelf al krap te worden. BV Starcraft 2 draait niet helemaal soepel. Stop je in diezelfde pc een 5850 is het ineens super smooth. Het kan aan mij liggen maar ik vind een 4850 veel te traag voor 1920x1200. Maar ik stel dan ook hoge eisen en ik heb het ook niet over oude games maar toch de wat recentere. DOWII is ook geen pretje op 1920x1200 max quality.

[meljor]

ben ik het wel mee eens, echter kan je met een 4870 1gb, 4890 of een gtx260 wel nog nagenoeg ieder spel op die settings spelen (extremen zoals metro niet, maar die krijgt alles op de knietjes).

1920x1200 is wel een pittige resolutie, zelfs voor snellere kaarten. mijn htpc heeft een q9550@3,2 met een 5850 en dat speelt nog weer een stuk soepeler dan mijn i7@3,6 met 5870 puur en alleen omdat mijn tv 720p heeft als res. en mijn monitor 1920x1200....

dus allemaal terug naar een 19inch 4:3 monitor en de hardware kan nog jaaaaaren mee

[Help!!!!]

Globalfoundries construction factory tour:

http://www.hardocp.com/ar...s_fab_8_construction_tour

[ Voor 5% gewijzigd door Help!!!! op 19-04-2011 23:06 ]

[superwashandje]

wel leuk om te zien ik werk bijna dagelijks in een cleanroom maar toch niet zo'n schone en grote als deze

[Anoniem: 303530]

Notebookcheck heeft de GT485m SLI tegenover de HD6970m CF gezet:

http://www.notebookcheck....-HD-6970M-CF.51253.0.html
De nvidia is iets sneller, maar daarbij dient te worden opgemerkt dat het TDP van de crossfire configuratie iets lager is.

Opvallender is echter de prijs: het testexemplaar is standaard uitgerust met een GTX460m. Voor een upgrade naar een dubbele HD6970 moet €471 worden betaald, de SLI GTX485m maakt de buidel echter 1133 keiharde euro's armer.

Ik snap overigens geen reet van hun conclusie:

Despite its markedly lower price, the Radeon HD 6970M CF comes amazingly close to its Nvidia counterpart; the GeForce GTX 485M SLI is only around 6% faster across all the benchmarks (1920 x 1080, ultra settings). So in terms of price-to-performance ratio, the Radeon HD 6970M CF is clearly the better choice, but the GeForce GTX 460M [Ik neem aan dat ze hier 485M bedoelen] SLI offers somewhat more consistent performance, a lower error rate, more mature drivers and superior image quality. It also has more additional features.

Fijn dat ze daar wat over zeggen in het artikel!

[Help!!!!]

AMD Catalyst Application Profile - 11.3 CAP5 - 4/21/2011 (Release Notes)
New profiles added with this release:

•Shift 2 – Crossfire off
•Deus Ex: Human Revolution – Improves CrossFire performance
•Test Drive Unlimited – resolves negative CrossFire scaling
•Need For Speed Hot Pursuit – resolves negative CrossFire scaling
•Gothic III – resolves negative CrossFire scaling


http://www.rage3d.com/cap/

[Cobiwan]

CatalystCreator Andrew D
Mouse cursor issue is still being looked at - won't be in Catalyst 11.4 release - but we're trying

[Redblader]

Anoniem: 303530 schreef op vrijdag 22 april 2011 @ 02:14:
Notebookcheck heeft de GT485m SLI tegenover de HD6970m CF gezet:

http://www.notebookcheck....-HD-6970M-CF.51253.0.html
De nvidia is iets sneller, maar daarbij dient te worden opgemerkt dat het TDP van de crossfire configuratie iets lager is.

Opvallender is echter de prijs: het testexemplaar is standaard uitgerust met een GTX460m. Voor een upgrade naar een dubbele HD6970 moet €471 worden betaald, de SLI GTX485m maakt de buidel echter 1133 keiharde euro's armer.

Ik snap overigens geen reet van hun conclusie:

[...]

Fijn dat ze daar wat over zeggen in het artikel!

Als je alleen kijkt bij de shift 2 benchmark dan is GTX485M SLI 90% sneller wat het gemiddelde natuurlijk een stuk omhoog haalt, vraag me dus af of de performance niet nog een stuk gaat verbeteren met nieuwe AMD drivers.

[Anoniem: 303530]

Ik vermoed dat er voor die game nog geen crossfire profiel bestaat. Dus inderdaad, wacht op de drivers.

[Redblader]

''AMD Catalyst Application Profile - 11.3 CAP5 - 4/21/2011 (Release Notes)
New profiles added with this release:

•Shift 2 – Crossfire off''

Dus inderdaad, crossfire werkt nog niet bij Shift 2.

[Springstof]

Help!!!! schreef op vrijdag 22 april 2011 @ 08:57:
AMD Catalyst Application Profile - 11.3 CAP5 - 4/21/2011 (Release Notes)
New profiles added with this release:

•Shift 2 – Crossfire off
•Deus Ex: Human Revolution – Improves CrossFire performance
•Test Drive Unlimited – resolves negative CrossFire scaling
•Need For Speed Hot Pursuit – resolves negative CrossFire scaling
•Gothic III – resolves negative CrossFire scaling


http://www.rage3d.com/cap/

Jammer dat crossfire nog steeds dergelijke problemen kent. Het is en blijft daarom wmb een afrader. Negative crossfire scaling? kom. op. zeg.

[Redblader]

Springstof schreef op vrijdag 22 april 2011 @ 17:06:
[...]

Jammer dat crossfire nog steeds zo deze problemen kent. Het is en blijft daarom wmb een afrader. Negative crossfire scaling? kom. op. zeg.

Ook SLI kent problemen, als je bij de notebookcheck review kijkt zie je dat de 3dmark11 score ook belabberd is omdat SLI waarschijnlijk niet werkt.
(Dit is dan wel een benchmark en geen game, maar even om aan te geven dat dit soort problemen bij crossfire&SLI beide voorkomen).

Je blijft met dual-GPU's jammer genoeg nog altijd heel erg afhankelijk van goede drivers..

[ Voor 8% gewijzigd door Redblader op 22-04-2011 17:09 ]

[madmaxnl]

Springstof schreef op vrijdag 22 april 2011 @ 17:06:
[...]

Jammer dat crossfire nog steeds dergelijke problemen kent. Het is en blijft daarom wmb een afrader. Negative crossfire scaling? kom. op. zeg.

AMD vermeld het tenminste.

[Humma Kavula]

Specs 7970/7990 bekend?

http://bouweenpc.nl/nieuws/3400

[madmaxnl]

Nep.

[Anoniem: 303530]

7xxx zou toch nog niet op 28nm verschijnen, maar alleen een aantal kaarten als de 7870, net als bij de 4xxx generatie?

[Tomas Hochstenbach]

madmaxnl schreef op vrijdag 22 april 2011 @ 17:28:
Nep.

Goeie motivatie . Het productieprocedé gaat van 40nm naar 28nm, met dezelfde grootte GPU's passen er veel meer shaders erin. Die specificaties zouden best wel eens kunnen kloppen. Het komt van een PR-medewerker van AMD, dus dat zou wel redelijk betrouwbaar zijn. Ook de klokfrequenties staan er niet bij, en die staan ook nog niet vast. Als die vermeld zouden staan, zou het nep zijn.

[Anoniem: 395810]

Gaan zeker duur kosten ofniet?

[Humma Kavula]

Dan toch zeker de codenamen voor Southern Islands?

According to HWiNFO32 v3.73's changelog, the (likely 28nm) GPUs in question are named Tahiti, New Zealand, Thames and Lombok. Unfortunately that's about it on the Southern Islands front, hopefully more leaks are incoming.

Bron

[madmaxnl]

TomasH schreef op vrijdag 22 april 2011 @ 17:39:
[...]

Goeie motivatie . Het productieprocedé gaat van 40nm naar 28nm, met dezelfde grootte GPU's passen er veel meer shaders erin. Die specificaties zouden best wel eens kunnen kloppen. Het komt van een PR-medewerker van AMD, dus dat zou wel redelijk betrouwbaar zijn. Ook de klokfrequenties staan er niet bij, en die staan ook nog niet vast. Als die vermeld zouden staan, zou het nep zijn.

3200 shaders op één chip ? Zelfs als je uitgaat van de Barts chip op 40nm kom je voor een 3200 shaders op 28nm. Kom je uit op een ongekende grote die size en laat dat nu net niet in het straatje van AMD small die strategie passen.

[Anoniem: 303530]

Ik heb ook het idee dat ze hun kruit redelijk verschieten als ze nu meteen een chip uitbrengen die in de buurt komt van de PCI spec... Als dat gebeurt hoeven we van de 8xxx en 9xxx lijn niet veel te verwachten.

[frankknopers]

madmaxnl schreef op vrijdag 22 april 2011 @ 17:49:
[...]


3200 shaders op één chip ? Zelfs als je uitgaat van de Barts chip op 40nm kom je voor een 3200 shaders op 28nm. Kom je uit op een ongekende grote die size en laat dat nu net niet in het straatje van AMD small die strategie passen.

Ik vind het sowieso een merkwaardige keus. Dacht dat AMD juist was overgestapt op de VLIW4 architectuur omdat dat efficiënter was bij de huidige generatie games (de special function unit werd zelden gebruikt). Ook biedt deze nieuwe architectuur aanzienlijk betere tesselation performance. Ik denk niet dat AMD die nieuwe architectuur van de Radeon HD 6900 nu opeens weer gaat ditchen.

Vooralsnog is mijn mening dus dat het nep is.

[ Voor 3% gewijzigd door frankknopers op 22-04-2011 19:09 ]

[Marc Rademaker]

Tuurlijk is het nep. Alsof een amd-medewerker dat tegenover bouweenpc gaat bevestigen. Lachwekkend gewoon. Het gros van de amd-medewerkers weet niet eens de specs van de nieuwe gpu's.

Alleen de codenamen zijn vziw 'echt'.

[-The_Mask-]

TomasH schreef op vrijdag 22 april 2011 @ 17:39:
. Als die vermeld zouden staan, zou het nep zijn.

Je gelooft echt zelf dat iemand van AMD het even serieus bevestigt aan jouw?

[bladerash]

madmaxnl schreef op vrijdag 22 april 2011 @ 17:49:
[...]


3200 shaders op één chip ? Zelfs als je uitgaat van de Barts chip op 40nm kom je voor een 3200 shaders op 28nm. Kom je uit op een ongekende grote die size en laat dat nu net niet in het straatje van AMD small die strategie passen.

Euh.. niet echt. Op 28nm zou het ongeveer uitkomen op dezelfde die size als een HD6970.
Ze hebben al hun billen gebrand aan de HD6990. Met de volgende single die chip willen ze deze performance minstens kunnen benaderen. Dan kan je niet meer klein gaan doen.
Ik ben het met je eens dat het fake is dat een medewerker van AMD dit gelekt heeft. Maar de specs zoals 3200 shaders kunnen alsnog gewoon waar zijn want het zit gewoon in lijn met de verwachtingen. Deze specs duiken echter pas veel later op??

[Xenomorphh]

frankknopers schreef op vrijdag 22 april 2011 @ 19:09:
[...]

Ik vind het sowieso een merkwaardige keus. Dacht dat AMD juist was overgestapt op de VLIW4 architectuur omdat dat efficiënter was bij de huidige generatie games (de special function unit werd zelden gebruikt). Ook biedt deze nieuwe architectuur aanzienlijk betere tesselation performance. Ik denk niet dat AMD die nieuwe architectuur van de Radeon HD 6900 nu opeens weer gaat ditchen.

Vooralsnog is mijn mening dus dat het nep is.

3200 cores zou toch prima kunnen passen in de VLIW4 architectuur?

Desalniettemin denk ik ook dat dit wel heel erg nep is en dit gewoon gaat om klikjes op hun website..

[Anoniem: 304087]

Redblader schreef op vrijdag 22 april 2011 @ 17:08:
[...]


Ook SLI kent problemen, als je bij de notebookcheck review kijkt zie je dat de 3dmark11 score ook belabberd is omdat SLI waarschijnlijk niet werkt.
(Dit is dan wel een benchmark en geen game, maar even om aan te geven dat dit soort problemen bij crossfire&SLI beide voorkomen).

Je blijft met dual-GPU's jammer genoeg nog altijd heel erg afhankelijk van goede drivers..

En dan er nog bij was het eerder een stuk erger met de schaling. Ik vind het tegenwoordig wel wat waard eingelijk omdat 9 van de 10 games wel gewoon goed schalen met cf of sli. Het is gewoon even wachten op een profiel voor nieuwe games die net uit zijn want voor iedere game word natuurlijk niet gelijk een nieuwe driver vrijgegeven. Soms duurt het wat langer maar so be it want AMD en nvidia kan niet overal gelijk bij zijn zo werkt dat niet en je kunt heel makkkelijk even cf of sli uit zetten binnen 10 seconden.

[bwerg]

madmaxnl schreef op vrijdag 22 april 2011 @ 17:49:
Kom je uit op een ongekende grote die size en laat dat nu net niet in het straatje van AMD small die strategie passen.

Je bedoelt dat straatje de strategie die ze ten tijden van de HD3000 en de HD4000 hadden? De laatste twee series is dat concept toch al helemaal overboord gegooid. Ja, NVidia heeft nòg grotere chips maar cayman is ook een lomp ding hoor.

Overigens wil ik daarmee niet zeggen dat deze specs kloppen. Bij de HD5870 zou die met zijn kleinere procedé ook wel even over de vorige generatie dual-chip (HD4870x2) heen gaan en dat is ook niet gelukt, maar het is natuurlijk mogelijk.

[dahakon]

bwerg schreef op zaterdag 23 april 2011 @ 13:13:
[...]

Je bedoelt dat straatje de strategie die ze ten tijden van de HD3000 en de HD4000 hadden? De laatste twee series is dat concept toch al helemaal overboord gegooid. Ja, NVidia heeft nòg grotere chips maar cayman is ook een lomp ding hoor.

Nee, die strategie is niet overboord gegooid, al is dat wel meerdere malen overwogen. HD4k was de eerste echte small die strategy chip. HD38xx was niets meer dan een verbetering van HD29xx, waarbij met alle onnodige rotzooi wegsneed en de chip op een kleiner proces bakte.

Er is bij Cypress wel gedacht aan het overboord gooien van de small die strategy, maar daar heeft men toentertijd toch van af gezien. Dit is ook terug te zien in ontbrekende zaken als sideport etc. Anandtech heeft er ooit een mooi artikel over geschreven. De chip viel wel groter uit dan RV770, maar is nog altijd veel kleiner dan oudere chips. Bovendien viel Cypress uiteindelijk groter uit, doordat het 40nm proces niet zonder fouten was. De dubbel uitgevoerde Via's en het rekening houden met grotere variaties in de transistors waren daar vooral de schuld van. Het is dan ook waarschijnlijk dat Cypress eigenlijk sub 300mm² had moeten zijn.

Cayman was oorspronkelijk ontwikkeld voor het 32nm proces en zou daarmee zo'n 64% van zijn huidige omvang hebben, waarmee hij met ~249mm² fractioneel kleiner zou zijn dan de RV770. Ze hebben uiteindelijk besloten om die chip onveranderd op 40nm te laten bakken, wat zijn omvang en stroomverbruik natuurlijk geen goed heeft gedaan. Op 32nm hadden we waarschijnlijk gewoon Cypress als HD6870 gekend en was de huidige HD6990 waarschijnlijk opgebouwd uit 2 volledige chips, die op volledige snelheid zouden lopen en nog steeds binnen de 300Watt zou blijven.

Wat een logisch vervolg zou zijn voor een 28nm chip, is om ergens rond de 280mm² te gaan zitten, waarmee je waarschijnlijk zo'n ~2200 SPU's in 4D shaderarchitectuur zou kunnen verwachten. Bij 3200 SPU's zou de small die strategy in ieder geval overboord gegooid worden.

[ Voor 7% gewijzigd door dahakon op 23-04-2011 15:29 ]

[RuddyMysterious]

De evolutie is eigenlijk niet erg hard aan het gaan. Twee jaar geleden kocht ik een HD4770 voor ongeveer €100. Ik kan nu bijlange geen nieuwe GPU kopen die maar zoveel kost, en dubbel zo snel is. In de laatste tien jaar zijn zulke sprongen (verdubbeling prestaties voor dezelfde prijs of zelfs lager) schering en inslag geweest, maar nu zitten ze blijkbaar lichtjes vast. Sterker nog, ik denk dat de prijs/prestaties nog maar amper is gedaald sinds de HD4000-reeks. Ja, ze hebben telkens snellere modellen uitgebracht, maar dat kwam ten koste van verbruik en prijs. Opvolgers binnen hetzelfde marktsegment met een noemenswaardige snelheidsverbetering, ho maar!

Om maar te zeggen dat ik nog altijd blij ben met mijn HD4770, en pas zal upgraden als ik voor €100 het dubbele aan prestaties kan krijgen. Nog een tijdje dus.

@astennu: dat je niks kan spelen met die HD4850 is nogal overdreven. Ikzelf speel elke game op 1920x1200. Dat moet daarom niet op maximum kwaliteit zijn. Als je op schokkerigheid stuit, dan zijn er twee mogelijkheden: je geeft geld uit aan een sterkere GPU, of je haalt de settings wat omlaag tot alles weer prima loopt. Ik ben nogal voorstander van optie twee, aangezien grafische kwaliteit lichtjes overroepen is als het gaat tussen 4xAA of geen AA. Dat is mij geen honderd euro waard, en zeker niet nog meer dan dat.

[ Voor 24% gewijzigd door RuddyMysterious op 23-04-2011 22:54 ]

[bladerash]

DevilsProphet schreef op zaterdag 23 april 2011 @ 22:52:
De evolutie is eigenlijk niet erg hard aan het gaan. Twee jaar geleden kocht ik een HD4770 voor ongeveer €100. Ik kan nu bijlange geen nieuwe GPU kopen die maar zoveel kost, en dubbel zo snel is. In de laatste tien jaar zijn zulke sprongen (verdubbeling prestaties voor dezelfde prijs of zelfs lager) schering en inslag geweest, maar nu zitten ze blijkbaar lichtjes vast. Sterker nog, ik denk dat de prijs/prestaties nog maar amper is gedaald sinds de HD4000-reeks. Ja, ze hebben telkens snellere modellen uitgebracht, maar dat kwam ten koste van verbruik en prijs. Opvolgers binnen hetzelfde marktsegment met een noemenswaardige snelheidsverbetering, ho maar!

Om maar te zeggen dat ik nog altijd blij ben met mijn HD4770, en pas zal upgraden als ik voor €100 het dubbele aan prestaties kan krijgen. Nog een tijdje dus.

@astennu: dat je niks kan spelen met die HD4850 is nogal overdreven. Ikzelf speel elke game op 1920x1200. Dat moet daarom niet op maximum kwaliteit zijn. Als je op schokkerigheid stuit, dan zijn er twee mogelijkheden: je geeft geld uit aan een sterkere GPU, of je haalt de settings wat omlaag tot alles weer prima loopt. Ik ben nogal voorstander van optie twee, aangezien grafische kwaliteit lichtjes overroepen is als het gaat tussen 4xAA of geen AA. Dat is mij geen honderd euro waard, en zeker niet nog meer dan dat.

pricewatch: Sapphire HD5850 Xtreme

[-The_Mask-]

Een HD6850 is niet heel veel meer dan 100 euro, maar zo vreemd is het natuurlijk niet ze zijn beide op 40nm gebakken.

[Anoniem: 172410]

Je vergeet even dat de HD4770 de aller allereerst verkrijgbare kaart was op 40nm. Daar zitten we nu nog steeds op. Alle vooruitgang moet dus komen uit optimalisaties. Die zijn er wel degelijk, getuige de sterk verbeterde Crossfireschaling en prestaties van de 68xx series ten opzichte van de 58xx (zelfde architectuur, veel minder onderdelen, nagenoeg gelijke prestaties). Echter kan je echt grote stappen pas weer verwachten bij een kleiner proces en als jij net de allereerste kaart van het huidige proces hebt gekocht kan je dus lang wachten.

De enige vooruitgang zit in betere yields, optimalisaties en eventueel een revolutionaire nieuwe architectuur, maar dat is allemaal veel minder rekbaar of makkelijk dan een nieuw proces.

Jammer genoeg heeft mijn HD4770 waarschijnlijk het loodje gelegd (niet geheel zijn eigen schuld ). Best een lekker kaartje voor die 89 euro die hij mij gekost heeft, al had ik er graag wat langer mee gedaan.

[ Voor 6% gewijzigd door Anoniem: 172410 op 23-04-2011 22:59 ]

[meljor]

upgraden vanaf een 4770 voor weinig geld?
leg een paar tientjes toe en koop een 2e hands 4890! een geweldige kaart nog steeds (zeker op 1920).

op die resolutie kon ik de overstap vanaf een 4870 512mb destijds al aardig merken, voornamelijk vanwege de 1gb die op die res. goed gebruikt wordt.
in reviews valt het niet altijd op vanwege het meten van max. fps maar geloof me, de minimum fps gaat behoorlijk omhoog en speelt dus veel soepeler, zeker vanaf een 4770.

[Springstof]

meljor schreef op zondag 24 april 2011 @ 10:05:
in reviews valt het niet altijd op vanwege het meten van max. fps maar geloof me

Wat is dit nou weer voor flauwekul. Zelfs hier op tweakers wordt dat niet gedaan.

[dahakon]

Springstof schreef op zondag 24 april 2011 @ 10:41:
[...]

Wat is dit nou weer voor flauwekul. Zelfs hier op tweakers wordt dat niet gedaan.

Ik denk dat hij gemiddelde/max bedoelde, een combinatie die vaak voor komt. Max alleen inderdaad niet. Maar ook bij gemiddelden zie je niet was de minimum FPS' zijn, waardoor een verschil tussen 512MB en 1024MB wellicht niet altijd goed naar voren komt.

Enfin, dit is meer voor een ervaringentopic of een bbg/tweedehandse kaartjes handel-topic.

[meljor]

juist,thanx.

veel te weinig sites laten de minimum fps zien, terwijl die juist zo belangrijk zijn. ook bij cpu reviews.
max fps ging bij 5770cf behoorlijk omhoog met een i7 vanaf een q6600, maar juist de constantere framerate en wat hogere min. fps maakte een waar verschil (bij single gpu nu minder, heb beide systemen nog)

[Fid3lity]

meljor schreef op zondag 24 april 2011 @ 21:50:
juist,thanx.

veel te weinig sites laten de minimum fps zien, terwijl die juist zo belangrijk zijn. ook bij cpu reviews.
max fps ging bij 5770cf behoorlijk omhoog met een i7 vanaf een q6600, maar juist de constantere framerate en wat hogere min. fps maakte een waar verschil (bij single gpu nu minder, heb beide systemen nog)

Weetje wat de grap daarachter is? Minimum fps zijn slecht te meten. Een enkele hapering kan al resulteren in een minimum van 2 fps. Reden echter dat ik zelf ook besloten heb geen minimum fps weer te geven was dat dat getal feitelijk zit op 1 fps. Dat is in alle gevallen het minimum, lager kom je niet

[bladerash]

Blue-Tiger schreef op zondag 24 april 2011 @ 22:20:
[...]


Weetje wat de grap daarachter is? Minimum fps zijn slecht te meten. Een enkele hapering kan al resulteren in een minimum van 2 fps. Reden echter dat ik zelf ook besloten heb geen minimum fps weer te geven was dat dat getal feitelijk zit op 1 fps. Dat is in alle gevallen het minimum, lager kom je niet

Of je beeld staat 5 seconde vast en dan heb je een fps van 0,2.

[dahakon]

Daarom heeft een site als HardOPC ook altijd een mooi grafiekje, waarbij je kunt zien hoe vaak/lang de minimum FPS plaatsvindt. Zo kun je snel vaststellen of het gewoon om een enkele hickup gaat, of om een serieus lage minimum FPS.

[Fid3lity]

bladerash schreef op zondag 24 april 2011 @ 22:25:
[...]

Of je beeld staat 5 seconde vast en dan heb je een fps van 0,2.

Not, want je ziet datzelfde frame gewoon 5 seconden lang. In feite is het gewoon 5x hetzelfde frame wat je ziet, maar in een tijdspanne die ook 5x zo groot is

[superwashandje]

huh? waarom is het dan in feite gewoon 5x hetzelfde frame? het kan toch ook gewoon zo zijn dat je inderdaad maar 1 frame in de 5 seconden te zien krijgt? waar komt het idee vandaan dat je elke seconde minstens 1 frame te zien krijgt?

qua min fps: HardOCP laat het inderdaad altijd erg goed zien dmv zo'n grafiekje, een balkje met min fps en het gemiddelde laat ook echter al best veel zien itt gemiddelde en max en alleen max. Hoe dichter de min fps en gemiddelde fps op elkaar zitten hoe erger de "framedrops" en spelervaring zullen zijn.

[madmaxnl]

Blue-Tiger is aan het grappen

Maar hoe kunnen ze microstuttering meten want conventioneel meten hoeveel frames per seconden en zijn is juist wat niet werkt.

[Dooievriend]

madmaxnl schreef op maandag 25 april 2011 @ 01:12:
Maar hoe kunnen ze microstuttering meten want conventioneel meten hoeveel frames per seconden en zijn is juist wat niet werkt.

Je meet wat de tijd tussen frames is, en telt het aantal keer dat je boven een grenswaarde komt. Stel bijvoorbeeld de grenswaarde op 1/30s (~30FPS), en als je hier veel boven zit heb je duidelijk last van microstuttering. De truc ligt dan wel in het vinden van een goede grenswaarde, maar desnoods meet je alle tussentijden, en maak je er een histogram met hoge resolutie van. Bij microstuttering maar hoge FPS zal je merken dat er veel frames met hoge tussentijden zijn (=stuttering), maar ook veel frames met erg lage stuttering (zo krijg je toch een hoge gemiddelde FPS).

Als er iemand ooit een datasheet met de tijd tussen frames te pakken krijgt, wil ik er nog wel een data-analyse op uitvoeren. Helaas meten programma's tegenwoordig vooral FPS...

edit: je wil natuurlijk weten hoeveel keer je boven de grenswaarde zit. Als je eronder zit, heb je immers goede FPS...

[ Voor 15% gewijzigd door Dooievriend op 25-04-2011 02:18 ]

[Fid3lity]

superwashandje schreef op maandag 25 april 2011 @ 00:55:
huh? waarom is het dan in feite gewoon 5x hetzelfde frame? het kan toch ook gewoon zo zijn dat je inderdaad maar 1 frame in de 5 seconden te zien krijgt? waar komt het idee vandaan dat je elke seconde minstens 1 frame te zien krijgt?

Dan moeten we maar een nieuwe term gaan gebruiken: SPF. Want, ja, een beweging weergeven kan alleen met meerdere frames Dus zul je elke keer minimaal 1 frame nodig hebben om iets van motie te kunnen waarnemen. 5 seconden nodig hebben voor 1 frame zou dus in theorie leiden tot 5 SPF, en 0.2 FPS slaat imho nergens op

madmaxnl schreef op maandag 25 april 2011 @ 01:12:
Blue-Tiger is aan het grappen

In eerste instantie niet, maar ik had mezelf beter moeten verwoorden

[madmaxnl]

AMD Partners Look To Leverage Cost-Effective, Low-End Radeon 6000 GPUs

Dooievriend schreef op maandag 25 april 2011 @ 01:26:
[...]

Je meet wat de tijd tussen frames is, en telt het aantal keer dat je onder een grenswaarde komt. Stel bijvoorbeeld de grenswaarde op 1/30s (~30FPS), en als je hier veel onder zit heb je duidelijk last van microstuttering. De truc ligt dan wel in het vinden van een goede grenswaarde, maar desnoods meet je alle tussentijden, en maak je er een histogram met hoge resolutie van. Bij microstuttering maar hoge FPS zal je merken dat er veel frames met hoge tussentijden zijn (=stuttering), maar ook veel frames met erg lage stuttering (zo krijg je toch een hoge gemiddelde FPS).

Als er iemand ooit een datasheet met de tijd tussen frames te pakken krijgt, wil ik er nog wel een data-analyse op uitvoeren. Helaas meten programma's tegenwoordig vooral FPS...

Ik weet niet of het haalbaar is maar mij lijkt frames per milliseconden beter om microstuttering te meten.
Immers is microstuttering een fikse onregelmatigheid in frames binnen één seconden. Ter illustratie wat ik bedoel:

Eerste 900 milliseconden één frame en de laatste 100 milliseconden 40 frames.

Hierdoor geeft de FPS counter leuk 41 FPS aan maar lijkt het beeld wel lekker te haperen. Dit is natuurlijk een overdreven voorbeeld maar het gaat zich om het princiepen.

Blue-Tiger schreef op maandag 25 april 2011 @ 01:29:
In eerste instantie niet, maar ik had mezelf beter moeten verwoorden

[ Voor 19% gewijzigd door madmaxnl op 25-04-2011 01:45 ]

[Dooievriend]

madmaxnl schreef op maandag 25 april 2011 @ 01:35:
Ik weet niet of het haalbaar is maar mij lijkt frames per milliseconden beter om microstuttering te meten.
Immers is microstuttering een fikse onregelmatigheid in frames binnen één seconden. Ter illustratie wat ik bedoel:

Eerste 900 milliseconden één frame en de laatste 100 milliseconden 40 frames.

Hierdoor geeft de FPS counter leuk 41 FPS aan maar lijkt het beeld wel lekker te haperen. Dit is natuurlijk een overdreven voorbeeld maar het gaat zich om het princiepen.

Frames per milliseconde = FPS/1000. Je verandert niets aan de grootheid, enkel wat aan de eenheid.

Even ruw uitgedrukt is gemiddelde FPS meten simpelweg de tijd meten waarin je programma draait, en het aantal frames dat gegenereerd wordt. Of je dit nu per milliseconde of seconde uitdrukt maakt niet uit.

Je voorbeeld is wel correct, maar wat je dan moet meten is de tijd tussen de frames: 900 ms in jouw geval, wat ruim boven de 1/30s (~33 ms) zit.

Minimum FPS is ook zoiets vreemds: dit wordt heel sterk beïnvloedt door de lengte van je meting: meet je 1 seconde lang, en middel je uit, dan ga je idd geen microstuttering ontdekken. Eigenlijk zou je om de correcte minimale FPS te berekenen simpelweg de langste tijd tussen twee frames moeten nemen, en hiervan de inverse. Is dit dus 900 ms, dan krijg je 1frame/0,9sec = ~1,1 FPS. Maar zo werken de programma's van vandaag dus jammergenoeg

Blue-Tiger schreef op maandag 25 april 2011 @ 01:29:
0.2 FPS slaat imho nergens op

Lol, dus dan geloof je ook niet in complexe getallen, negatieve bankrekeningen en snelheden lager dan 1m/s? Het is gewoon een abstracte term, die weergeeft dat er gemiddeld pas elke 5 seconden een frame gegenereerd wordt. Een ander voorbeeldje: stel ik wil weten hoeveel appels gemiddeld per seconde van een boom vallen, en er valt om de 4 seconden één appel. Dan heb ik gemiddeld 0,25 appels per seconde (APS). Dat er niet effectief elke seconde exact een kwart appel naar beneden dendert doet er niet toe, bij 30 FPS wordt er ook niet elke seconde exact 30 frames gegenereerd.

edit: nu ik erover nadenk, er is wel een goeie reden waarom SPF geïntroduceerd moet worden, maar niet omwille van de gemiddelde SPF, wel omwille van de maximale SPF. Die is equivalent aan de minimale FPS, maar dan correct gemeten (zoals hierboven uitgelegd). Als deze erg afwijkt van de gemiddelde FPS, dan heb je last van microstuttering. Is die bijvoorbeeld 0,1s, dan heeft je beeld effectief een halve seconde lang stilgestaan. Om te verhinderen dat een enkele uitschieter roet in het eten gooit, kan je tellen hoeveel keer je beeld minstens 0,x seconden heeft stilgestaan, wat equivalent is met de hierboven beschreven ondergrens voor tussentijden.

[ Voor 37% gewijzigd door Dooievriend op 25-04-2011 02:16 ]

[madmaxnl]

Dooievriend schreef op maandag 25 april 2011 @ 01:55:
Frames per milliseconde = FPS/1000. Je verandert niets aan de grootheid, enkel wat aan de eenheid.

Even ruw uitgedrukt is gemiddelde FPS meten simpelweg de tijd meten waarin je programma draait, en het aantal frames dat gegenereerd wordt. Of je dit nu per milliseconde of seconde uitdrukt maakt niet uit.

Maar als je frames per milliseconden meet ga je als je dat uitzet in een lijn grafiek toch wel micostuttering ziet ?
Jou methode werkt i.i.g.

[Fid3lity]

Dooievriend schreef op maandag 25 april 2011 @ 01:55:
[...]
Lol, dus dan geloof je ook niet in complexe getallen, negatieve bankrekeningen en snelheden lager dan 1m/s? Het is gewoon een abstracte term, die weergeeft dat er gemiddeld pas elke 5 seconden een frame gegenereerd wordt. Een ander voorbeeldje: stel ik wil weten hoeveel appels gemiddeld per seconde van een boom vallen, en er valt om de 4 seconden één appel. Dan heb ik gemiddeld 0,25 appels per seconde (APS). Dat er niet effectief elke seconde exact een kwart appel naar beneden dendert doet er niet toe, bij 30 FPS wordt er ook niet elke seconde exact 30 frames gegenereerd.

Je voorbeeld van snelheid was niet het beste voorbeeld dat je kon geven, aangezien je ook gewoon een halve meter per seconde kan maken. Daarbij moet je wel opmerken dat je exacte beweging altijd wel zult waarnemen he Je andere voorbeelden zijn wel leuk, en daar ben ik het wel mee eens, maar hebben niet echt iets te maken met waarneming zoals ik het in FPS bedoel...

Om motie / beweging waar te nemen moet je dus echt het verschil van een compleet frame kunnen zien, 0.2 frames neem je dus niet waar. Daarom vind ik de aanduiding van 0.2 FPS gewoon lelijk, al zou die wellicht wel kunnen kloppen. In dat geval klopt SPF sowieso, en geeft ook prima aan wat merkbaar is. 5 SPF voldoet dan gewoon prima aan de eis dat je minstens een verschil van 1 FPS moet kunnen waarnemen

edit: nu ik erover nadenk, er is wel een goeie reden waarom SPF geïntroduceerd moet worden, maar niet omwille van de gemiddelde SPF, wel omwille van de maximale SPF. Die is equivalent aan de minimale FPS, maar dan correct gemeten (zoals hierboven uitgelegd). Als deze erg afwijkt van de gemiddelde FPS, dan heb je last van microstuttering. Is die bijvoorbeeld 0,1s, dan heeft je beeld effectief een halve seconde lang stilgestaan. Om te verhinderen dat een enkele uitschieter roet in het eten gooit, kan je tellen hoeveel keer je beeld minstens 0,x seconden heeft stilgestaan, wat equivalent is met de hierboven beschreven ondergrens voor tussentijden.

Precies, DM me desnoods even voor overleg dan brengen we dat begrip de wereld in

[Cheezus]

Blue-Tiger schreef op maandag 25 april 2011 @ 11:01:


Om motie / beweging waar te nemen moet je dus echt het verschil van een compleet frame kunnen zien, 0.2 frames neem je dus niet waar. Daarom vind ik de aanduiding van 0.2 FPS gewoon lelijk, al zou die wellicht wel kunnen kloppen. In dat geval klopt SPF sowieso, en geeft ook prima aan wat merkbaar is. 5 SPF voldoet dan gewoon prima aan de eis dat je minstens een verschil van 1 FPS moet kunnen waarnemen

0,2 FPS of 5 SFP is exact hetzelfde, wat het hele verhaal met waarneembaarheid te maken heeft snap ik dus niet?
Dat is net zoiets als zeggen dat verbruik van 0,5 KWh niet mogelijk is maar 2hKW wel kan..

[Fid3lity]

primusz schreef op maandag 25 april 2011 @ 11:23:
[...]


0,2 FPS of 5 SFP is exact hetzelfde, wat het hele verhaal met waarneembaarheid te maken heeft snap ik dus niet?

Het is ook exact hetzelfde, maar in dat geval vind ik de aanduiding in fps gewoon minder... En zou idd SPF ook goed microstuttering kunnen laten zien

[Anoniem: 303530]

Het probleem met FPS is dat het over een termijn van 1 seconde word gemeten, als er bij wijze van spreken een frame uitvalt zie je dat niet terug in de framerate, wel als je een grafiek plot met telkens de SPF (en dus niet gemiddelde SPF).

[Werelds]

Jullie hebben het gewoon over de render time per frame, en dat kan net zo onduidelijk worden als je puur getallen gebruikt. Om het echt goed te doen moet je een heel stuk verder gaan; sowieso moet je al niet naar hele seconden gaan kijken, dat is een veel te grote eenheid. Als ik een seconde neem en vervolgens zeg dat de min/avg/max rendertimes 8/16/333 ms waren weet je nog steeds geen donder (dat is respectievelijk trouwens 125 FPS, 62.5 FPS en 3 FPS). De frequentie is hier bij ook van belang. Twee keer 333ms, 1 keer 8ms en de rest met 16ms is toch echt iets anders dan 1x333ms, 20x8ms en de rest met 16ms. In "ouderwetse" FPS is dit respectievelijk ongeveer 23 FPS en 53 FPS; wat zou dat in jullie SPF zijn? In beide gevallen heb je te maken met (micro-)stuttering; het eerste geval iets pittiger dan het tweede, maar ze zijn het wel allebei.

Nee, jullie vatten dit iets te makkelijk op. De enige manier om een goed beeld te krijgen is met behulp van een grafiek. Dit is gewoon niet uit te drukken in 1 of zelfs 3 getallen

[RuddyMysterious]

meljor schreef op zondag 24 april 2011 @ 10:05:
upgraden vanaf een 4770 voor weinig geld?
leg een paar tientjes toe en koop een 2e hands 4890! een geweldige kaart nog steeds (zeker op 1920).

op die resolutie kon ik de overstap vanaf een 4870 512mb destijds al aardig merken, voornamelijk vanwege de 1gb die op die res. goed gebruikt wordt.
in reviews valt het niet altijd op vanwege het meten van max. fps maar geloof me, de minimum fps gaat behoorlijk omhoog en speelt dus veel soepeler, zeker vanaf een 4770.

Ik wil dat zowel de prijs in euros als het verbruik dat van de HD4770 niet overstijgt, wijls mij de dubbele hoeveelheid van de prestaties van de HD4770 leverende. Dus niet enkel de prijs in euros. Mijn systeem is momenteel gedimensioneerd voor relatief zuinige componenten, en ik wil dat niet uit balans brengen, of er nog meer geld in steken.

[dahakon]

DevilsProphet schreef op maandag 25 april 2011 @ 12:13:
[...]

Ik wil dat zowel de prijs in euros als het verbruik dat van de HD4770 niet overstijgt, wijls mij de dubbele hoeveelheid van de prestaties van de HD4770 leverende. Dus niet enkel de prijs in euros. Mijn systeem is momenteel gedimensioneerd voor relatief zuinige componenten, en ik wil dat niet uit balans brengen, of er nog meer geld in steken.

Dan zul je toch waarschijnlijk moeten wachten op 28nm kaarten, aangezien de HD4770 toch best een heel erg goede prestatie/verbruik neerzette, voor de eerste 40nm kaart. Sneller kan wel voor hetzelfde verbruik, maar de prijs zal toch iets hoger liggen, of je verdubbelt de prestaties, maar dan gaat het verbruik ook omhoog.

[bwerg]

@idle was de HD4770 trouwens nog niet erg zuinig, dat was toch een beetje de zwakte van de HD4000-serie. Als je het voor een laag gemiddeld verbruik doet is dat vaak toch het belangrijkste.

[Tomas Hochstenbach]

De AMD Radeon HD 6770 en HD 6750 waren al een tijdje verkrijgbaar voor OEM's als Dell, ASUS en HP, maar nu heeft XFX ook twee modellen voor de consumentenmarkt gelanceerd. Andere fabrikanten zullen vermoedelijk snel volgen. In Amerika zijn de eerste prijsvermeldingen al opgedoken, in Nederland is dat waarschijnlijk pas morgen aan de hand, aangezien het vandaag Tweede Paasdag is, en veel winkels dus dicht zijn.

De HD 6770 en HD 6750 zijn niets anders dan opgevoerde HD 5770's en HD 5750's. Het klinkt raar, maar na twee jaar is er ook geen noodzaak tot vervanging van die chips. Dat kun je de zwakke concurrentie in dat segment verwijten... We vinden dan ook geen HD 6000-technieken als UVD 3.0 terug op deze kaarten. De HD 6770 heeft de volle 800 stream processors, terwijl de HD 6750 er maar 720 heeft. De geheugenbus is in beide gevallen 128-bit. Ook hebben de HD 6770 en HD 6750 allebei 1 GB GDDR5-geheugen, al is het bij de HD 6750 wel op slechts 4600MHz (effectief) geklokt, bij de HD 6770 ligt die klokfrequentie 200MHz hoger.

Om maar even door te gaan met de kloksnelheden, draait de GPU in de HD 6770 op 850MHz. Bij de HD 6750 draait die op 720MHz. Uiteraard ondersteunen de kaarten wel gewoon DirectX 11. De HD 6770 kost bij het Amerikaanse Bestbuy.com 155 dollar, omgerekend zo'n 105 euro. De HD 6770 is met 175 dollar iets duurder, wat neerkomt op 119 euro. Doordat Sapphire de HD 5850's in de uitverkoop heeft gegooid, kosten die nog maar zo'n 110 euro, waarmee dat toch nog de beste keuze blijft.

Bron: http://bouweenpc.nl/nieuws/3405

Dat heeft lang geduurd... Ben benieuwd voor welke prijs hij nou echt in de webshops komt.

[dahakon]

Gezien de goedkoopste HD5750 voor 85 euro verkrijgbaar is en de goedkoopste HD5770 voor 90 euro (beide met 1GB geheugen), gecombineerd met het feit dat voor ~90 euro ook de HD5830 Xtreme van Sapphire te verkrijgen is, zou een prijs van 100 euro of hoger absurd zijn (temeer omdat voor ~110 euro de HD5850 Xtreme te verkrijgen is).

Hoe dan ook, spijtig dat ze de HD67xx nu ook toelaten in de gewone markt. Het is toch te hopen dat dit eenmalig gebeurt en dat ze snel verdwijnen met een 28nm product in hetzelfde markt/prijssegment.

[Toettoetdaan]

TomasH schreef op maandag 25 april 2011 @ 12:56:
[...]


Bron: http://bouweenpc.nl/nieuws/3405

Dat heeft lang geduurd... Ben benieuwd voor welke prijs hij nou echt in de webshops komt.

Sugereeren die afbeeldingen nou dat de HD6750 wel in quad-crossfire kan en de HD6770 niet???
^{Niet dat het echt wat toevoegt maar toch...}

[Dooievriend]

Werelds schreef op maandag 25 april 2011 @ 11:47:
Jullie hebben het gewoon over de render time per frame, en dat kan net zo onduidelijk worden als je puur getallen gebruikt. Om het echt goed te doen moet je een heel stuk verder gaan; sowieso moet je al niet naar hele seconden gaan kijken, dat is een veel te grote eenheid. Als ik een seconde neem en vervolgens zeg dat de min/avg/max rendertimes 8/16/333 ms waren weet je nog steeds geen donder (dat is respectievelijk trouwens 125 FPS, 62.5 FPS en 3 FPS). De frequentie is hier bij ook van belang. Twee keer 333ms, 1 keer 8ms en de rest met 16ms is toch echt iets anders dan 1x333ms, 20x8ms en de rest met 16ms. In "ouderwetse" FPS is dit respectievelijk ongeveer 23 FPS en 53 FPS; wat zou dat in jullie SPF zijn? In beide gevallen heb je te maken met (micro-)stuttering; het eerste geval iets pittiger dan het tweede, maar ze zijn het wel allebei.

Nee, jullie vatten dit iets te makkelijk op. De enige manier om een goed beeld te krijgen is met behulp van een grafiek. Dit is gewoon niet uit te drukken in 1 of zelfs 3 getallen

Je hebt gelijk dat een seconde veel te groot is. Dat is ook het probleem met de zogenaamde "minimale" FPS. Die wordt over een seconde gemeten, en is dus NIET de minimale FPS. De echte minimale FPS is de laagste FPS die op een bepaald moment (dit is een oneindig kleine tijdsspanne << 1 seconde) voorkomt. Theoretisch is dit de afgeleide van de functie die geeft hoeveel frames er gegenereerd zijn in functie van de tijd. Dit is echter geen continue functie en vereist dus moeilijker technieken dan de wiskundige kennis beschikbaar in de middelbare school. Daarom nemen de mensen de shortcut om gewoon een korte tijd (1s) te meten, en daar het gemiddelde van te nemen.
Dit is echter de verkeerde shortcut! Meet gewoon de rendertijden (SPF) en draai die om! En tel dan hoeveel keer een bepaalde grenswaarde doorbroken wordt. In jouw voorbeeld: leg de grenswaarde op 10ms (~100FPS), dan heb je dus bij het eerste geval ongeveer 42 keer (=41 keer 16ms en 1 keer 333ms) een overschrijding van je grenswaarde, en in het tweede geval 2 keer (=1 keer 16ms en 1 keer 333ms). Bij beide dus microstuttering, maar bij de tweede minder. Deze maat werkt, en hoewel een volledige distributie van de rendertijden nog beter is, is het in ieder geval al een stukken betere maat dan de "minimale" FPS die eigenlijk het minimale gemiddelde FPS over 1 seconde is.

Nogmaals een oproep aan iemand die rendertijden heeft, en wil weten of er microstuttering in voorkomt: geef me de rendertijden van je frames (in .csv formaat), en ik kan het correct voor je uitrekenen. Hell, als iemand me data geeft maak ik er een blog over: "Hoe microstuttering correct meten?".

over het meten op ms-niveau:
Het probleem met meten op 1ms is dat de gemiddelde framerate exact hetzelfde is als over 1s/1000, en de "minimale framerate" is dan altijd 0FPms, want je hebt milliseconden waarbij geen frame gegenereerd wordt, dus dan krijg je 0 frames voor de ene milliseconde.

edit: stevige fout in voorbeeld

[Werelds]

Laatste keer dat ik de bench functie in Fraps heb gebruikt kon je die mooi de frametijden uit laten kotsen als CSV, dus het is niet zo'n probleem om die data te verkrijgen. Is wel al letterlijk enkele jaren geleden, maar ik kan me niet voorstellen dat ze dat er uit hebben gesloopt

Jij focust nu wel weer op de tijd, terwijl je juist op de frames moet focussen. Ik heb nooit gezegd dat je op "FPms" moet letten, het is juist andersom. Het gaat om TPF - Time Per Frame. De eenheid die dan volgt kan nano-, milli- of voor mijn part zelfs megaseconden zijn, maakt echt geen donder uit. Nogmaals, het lastige op dit punt is dat je een grenswaarde moet vinden waarin een X aantal frames met een rendertijd >= Y binnen tijdspanne Z betekent dat je (zichtbaar) last hebt van microstuttering.

Binnen 100 frames kun je gigantisch verschillende rendertijden hebben, zonder dat zich daarbij microstuttering voor doet. Ik zou het graag eens testen, maar ik heb geen SLI of CFX (niet echt nodig met een 6950 voor 1080p ).

[ Voor 5% gewijzigd door Werelds op 26-04-2011 13:09 ]

[Dooievriend]

Werelds schreef op dinsdag 26 april 2011 @ 13:08:
Laatste keer dat ik de bench functie in Fraps heb gebruikt kon je die mooi de frametijden uit laten kotsen als CSV, dus het is niet zo'n probleem om die data te verkrijgen. Is wel al letterlijk enkele jaren geleden, maar ik kan me niet voorstellen dat ze dat er uit hebben gesloopt

Weet niet hoe het werkt, en heb geen sli/xfire om het te testen...

Jij focust nu wel weer op de tijd, terwijl je juist op de frames moet focussen. Ik heb nooit gezegd dat je op "FPms" moet letten, het is juist andersom. Het gaat om TPF - Time Per Frame. De eenheid die dan volgt kan nano-, milli- of voor mijn part zelfs megaseconden zijn, maakt echt geen donder uit.

Hier zijn we volledig akkoord: SPF==TPF.

Nogmaals, het lastige op dit punt is dat je een grenswaarde moet vinden waarin een X aantal frames met een rendertijd >= Y binnen tijdspanne Z betekent dat je (zichtbaar) last hebt van microstuttering.

Klopt, heb enkele oplossingen in m'n hoofd, bvb. smoothness van de renderfunctie, aantal keer dat je de grenswaarde doorbreekt delen door de totale meettijd etc. Het is zeker te doen, zonder de hele grafiek te tonen.
Dus met één frame met rendertijd van 333ms heb je geen last van microstuttering?

[Werelds]

Dat weet ik niet, ik weet niet vanaf welke "traagheid" het zichtbaar wordt. 333 lijkt me al te hoog, dat is een derde van een seconde, en ik ben er vrij zeker van dat zo'n spike al zichtbaar is

Als ik moet gokken, zit die grens al ergens onder de 100ms

[RuddyMysterious]

Dooievriend schreef op dinsdag 26 april 2011 @ 12:48:
[...]

Je hebt gelijk dat een seconde veel te groot is. Dat is ook het probleem met de zogenaamde "minimale" FPS. Die wordt over een seconde gemeten, en is dus NIET de minimale FPS. De echte minimale FPS is de laagste FPS die op een bepaald moment (dit is een oneindig kleine tijdsspanne << 1 seconde) voorkomt. Theoretisch is dit de afgeleide van de functie die geeft hoeveel frames er gegenereerd zijn in functie van de tijd. Dit is echter geen continue functie en vereist dus moeilijker technieken dan de wiskundige kennis beschikbaar in de middelbare school. Daarom nemen de mensen de shortcut om gewoon een korte tijd (1s) te meten, en daar het gemiddelde van te nemen.
Dit is echter de verkeerde shortcut! Meet gewoon de rendertijden (SPF) en draai die om! En tel dan hoeveel keer een bepaalde grenswaarde doorbroken wordt. In jouw voorbeeld: leg de grenswaarde op 10ms (~100FPS), dan heb je dus bij het eerste geval ongeveer 42 keer (=41 keer 16ms en 1 keer 333ms) een overschrijding van je grenswaarde, en in het tweede geval 2 keer (=1 keer 16ms en 1 keer 333ms). Bij beide dus microstuttering, maar bij de tweede minder. Deze maat werkt, en hoewel een volledige distributie van de rendertijden nog beter is, is het in ieder geval al een stukken betere maat dan de "minimale" FPS die eigenlijk het minimale gemiddelde FPS over 1 seconde is.

Nogmaals een oproep aan iemand die rendertijden heeft, en wil weten of er microstuttering in voorkomt: geef me de rendertijden van je frames (in .csv formaat), en ik kan het correct voor je uitrekenen. Hell, als iemand me data geeft maak ik er een blog over: "Hoe microstuttering correct meten?".

over het meten op ms-niveau:
Het probleem met meten op 1ms is dat de gemiddelde framerate exact hetzelfde is als over 1s/1000, en de "minimale framerate" is dan altijd 0FPms, want je hebt milliseconden waarbij geen frame gegenereerd wordt, dus dan krijg je 0 frames voor de ene milliseconde.

edit: stevige fout in voorbeeld

Wat een uitleg om gewoon te zeggen dat visueel comfort in de vorm van vloeiendheid het best wordt uitgedrukt in een maximale tijdsduur die het weergeven van twee opeenvolgende frames scheidt, in plaats van inderdaad een gemiddelde aantal frames per seconde, op de seconde waarop het minste frames getoond zijn.

Is het niet gewoon het simpelst om een zeer constante stroom van frames te tonen, en daarbij de grootste tussentijd te noteren waarbij testpersonen de overgang tussen frames nog voldoende vloeiend vinden, en die tijd dan te gebruiken om te beslissen of er onaanvaardbare microstuttering aanwezig is?

Als de minimaal aanvaardbare tijd gelijk is aan 33ms, dan is dat een framerate van 30fps, en als er één of meer tussentijden een waarde hebben hoger dan 33ms, dat het dan als lastig kan worden beschouwd en als microstuttering worden benoemd.

[ Voor 10% gewijzigd door RuddyMysterious op 26-04-2011 19:50 ]

[Dooievriend]

DevilsProphet schreef op dinsdag 26 april 2011 @ 19:46:
[...]

Wat een uitleg om gewoon te zeggen dat visueel comfort in de vorm van vloeiendheid het best wordt uitgedrukt in een maximale tijdsduur die het weergeven van twee opeenvolgende frames scheidt, in plaats van inderdaad een gemiddelde aantal frames per seconde, op de seconde waarop het minste frames getoond zijn.

Is het niet gewoon het simpelst om een zeer constante stroom van frames te tonen, en daarbij de grootste tussentijd te noteren waarbij testpersonen de overgang tussen frames nog voldoende vloeiend vinden, en die tijd dan te gebruiken om te beslissen of er onaanvaardbare microstuttering aanwezig is?

Als de minimaal aanvaardbare tijd gelijk is aan 33ms, dan is dat een framerate van 30fps, en als er één of meer tussentijden een waarde hebben hoger dan 33ms, dat het dan als lastig kan worden beschouwd en als microstuttering worden benoemd.

[mitsumark]

Was 25fps niet de 'ideale' film//video/televisie standaard?
Dan zou je kunnen zeggen dat alles boven de 40ms rendertijd al een lichte vorm van microstuttering is (niet vloeiend beeld).
Persoonlijk denk ik dat je pas echt merkbaar last krijgt als je bv meer dan 5 frames per seconde boven de 40ms hebt, waarbij 1 per seconde boven de 100ms eigenlijk onacceptabel zou zijn (dit is in het allerergste geval 10fps)
Verschilt ook heel erg per type game natuurlijk.
Als je streefwaarde 40fps is, zou je 25ms al als maximale rendertijd kunnen beschouwen -> alles hierboven is (lichte) microstuttering.

edit: ik zeg bijna hetzelfde als de quote hierboven.

[ Voor 4% gewijzigd door mitsumark op 27-04-2011 09:18 ]

[Anoniem: 303530]

24fps. Of 23,79fps (?).

Maar ik meen dat er een aantal nieuwe films in 24fps worden uitgezonden om het ouderwetser te laten lijken, dus de gemiddelde mens zie nog steeds verschil tussen 24 en 60fps. Of dat storend is tijdens een game is nog de vraag.

[ Voor 4% gewijzigd door Anoniem: 303530 op 27-04-2011 09:27 ]

[RuddyMysterious]

Je kan verschil zien in bewegingsvlotheid bij films en bij series. Films zien er houteriger uit, en die houterigheid wordt bijvoorbeeld bij nieuwere en duurdere TV's van 100Hz terug vloeiend gemaakt door er interpolatieframes tussen te voegen, waardoor films zo "vlot" lijken als een gemiddelde opname gemaakt voor een straatinterview van het journaal.

24fps of zelfs 30fps zijn niet de beste ondergrens, aangezien ik een filmpje vloeiender zie afspelen als ik de afspeelsnelheid verhoog naar 2x. Natuurlijk beweegt alles dan veel te snel, maar ik denk dat ik het fijn zou vinden moesten films afgespeeld worden op 48fps of zelfs 60fps. En dat is voor mij ook het minimum in shootergames, omdat anders de tijd tussen de huidige en volgende frame te groot wordt, en zo neem ik een vertragingseffect waar tussen het uitvoeren van een handeling en het te zien krijgen van het resultaat van die handeling.

[Anoniem: 304087]

Tijdens een game is dat zeker storend, je beweegt je muis bvb lekker snel en het duurt voor het gevoel wel 5 sec te lang voor je op iemand richt, mijn eis is terwel je richt er ook gelijk bent. Dit gevoel begint zo'n beetje te komen als je onder de 60-70 fps raakt met een sneller shooter dan duurt het gewoon veel te lang. Ik zet daarom nooit v-sync aan en wil ik niet onder de 60pfs uitkomen met online shooters.

Edit

Ik was net te laat

[ Voor 3% gewijzigd door Anoniem: 304087 op 27-04-2011 09:35 ]

[anathema]

Dooievriend schreef op dinsdag 26 april 2011 @ 12:48:
[...]
Nogmaals een oproep aan iemand die rendertijden heeft, en wil weten of er microstuttering in voorkomt: geef me de rendertijden van je frames (in .csv formaat), en ik kan het correct voor je uitrekenen. Hell, als iemand me data geeft maak ik er een blog over: "Hoe microstuttering correct meten?".

Vorig jaar het ik in Metro2033 frametimes gemeten mbv Fraps met zowel een enkele HD5870 als HD5870 crossfire.

http://gathering.tweakers.net/forum/view_message/33976435

Ik heb daar dus de eerste 20 frames van een vergelijkbaar stukje gameplay geplot, dat liet wel duidelijk de grote variatie in frametime zien bij 2 X HD5870. Metro2033 heeft er ook nog veel last van. Bij 35 fps ongeveer was het onspeelbaar met Crossfire waar het met de single kaart vloeiend was.
Ik heb de csv files nog wel mocht je er belang bij hebben..