CJ's Radeon Info & Nieuwsdiscussie - Deel 125

[Sp3ci3s8472]

Verwijderd schreef op woensdag 20 maart 2013 @ 21:57:
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.

Inderdaad, maar volgens mij kunnen meerdere engines ondertussen physics berekeningen doen op de GPU. Misschien de reden dat dit niet gebeurt is omdat het niet loont (Havok stopgezet)? Kan ook dat de engines minder vaak worden gebruikt/bekend zijn (Bullet via OpenCL).

[Werelds]

Verwijderd schreef op woensdag 20 maart 2013 @ 21:57:
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.

De "ondersteuning" is je reinste onzin. AGEIA had dat in hun oorspronkelijke versie al, het loopt alleen voor geen meter. GPU ondersteuning gaat er niet komen, Nvidia wil dat op CUDA houden als marketing tool.

Havok en Bullet kunnen tegenwoordig allebei even veel op de GPU uit voeren als PhysX kan, alleen gaat dat via OpenCL en is het dus niet gebonden aan CUDA. Sterker nog, als je kijkt naar de PhysX versies die gebruikt worden, is er vrijwel geen voordeel voor PhysX. Alles onder 2.8.2 draait nagenoeg alles op de CPU behalve particles, fluids en cloth. Vanaf 2.8.4 heeft Nvidia eindelijk delen van soft body physics via de GPU lopen en vanaf 2.8.6 + APEX 1.2 kan ook een deel rigid body physics via de GPU. Rigid body is wat het meest interessant is, want dat zijn de daadwerkelijke physics. Er zijn echter nog geen handvol games die zo up to date zijn, afgezien van het feit dat 2.8.6 en APEX 1.2 samen gebruikt moeten worden om dit te doen, wat een hoop extra tijd kost.

Op de PS4 zullen we gewoon CPU PhysX zien, hopelijk wel minimaal 3.0 en geen 2.8.x rotzooi meer. Want PhysX voor 3.0 -dat momenteel amper gebruikt wordt- is als dikke stront door een trechter op de CPU en bij lange na niet vergelijkbaar met Havok. 3.0 en hoger worden momenteel gebruikt in ARMA 3 (spel is nog niet uit), Natural Selection 2, Planetside 2 (sinds vorige maand). Alle andere games (en voordat iemand het aan durft, Borderlands 2 is gewoon 2.8.6) draaien het merendeel van de PhysX op de CPU. En juist omdat PhysX dan zo traag is gebruiken de meeste van die games PhysX puur voor juist die paar dingen die via de GPU *kunnen* - met de zak geld natuurlijk.

Havok is daarnaast veel meer gebruikt dan PhysX, ik geloof niet dat de meeste beseffen hoe populair Havok precies is. Source engine? Volledig Havok; met een hoop verbeteringen van Valve, die Intel vervolgens standaard in Havok heeft geport (dit in tegenstelling tot Nvidia die pas na 3 jaar en vele negatieve berichten iets aan PhysX deed). Frostbite 1, 1.5 en 2.0? Allemaal Havok. Red Faction: Guerrila, de game met nog steeds de leukste *echte* physics? Havok. Skyrim, Darksiders, Bioshock, Timeshift? Allemaal Havok - ragdolls in de meeste van deze komen ook uit Havok en de physics in veel van deze games zijn veel boeiender (omdat ze invloed op de gameplay hebben) dan de particles waar PhysX zo bekend om staat. Het grote verschil is dat Intel met Havok geen full-screen logo wilt, een vermelding tussen alle andere credits is al genoeg; wel kost het licentie kosten uiteraard, waar Nvidia juist graag een zak geld dropt. Ze mogen wellicht niet zo overduidelijk aanwezig zijn als Nvidia, Havok heb je al vaker in actie gezien dan je denkt - meer dan PhysX en zonder de gigantische performance hit. De enige game op Havok die echt zwaar is, is RF: Guerrilla, maar de physics in die game steken dan ook ver boven alle andere uit.


Ik heb wat met PhysX 3.1 gespeeld en dat komt eindelijk in de buurt van Havok qua prestaties (nogmaals, ik heb het hier over de CPU, CUDA is gewoon niet boeiend omdat het slechts een deel van de markt betreft). Hopelijk is 3.2 de versie (is al beschikbaar, nog niet mee kunnen spelen) die PhysX tot een waardevolle toevoeging maakt - belangrijker, hopelijk sterft in elk geval 2.8.x een snelle en pijnlijke dood, want ik wil dat stuk stront nooit meer in een game zien

[ArgantosNL]

Volgensmij is het ook vrij bekent dat de enige reden dat PhysX (voornamelijk de oude) zo slecht draaid op de CPU is omdat er 0 optimalisatie gedaan is, waarschijnlijk is dit ook bewust zo gehouden. NV weet dat bij goede optimalisatie van PhysX voor de CPU de CPU betere preformace zou geven dan CUDA kan. Dat dit aan het verbeteren is komt waarschijnlijk omdat ze als het zo door gaat uit de markt gedrukt worden want er zijn voldoende andere PhysX engines aanwezig die het ook of zelfs beter kunnen.

Ik heb PhysX al een tijdje niet meer bekeken maar als ik Werelds zo hoor zijn ze het eindelijk aan het aanpassen. Werd tijd want de monopoly positie hebben ze al jaren niet meer.

[madmaxnl]

PhysX op een CPU laten lopen kan prima, alleen moet de software dan wel geoptimaliseerd worden en dus niet maar één core belasten.

[Astennu]

Physics bewerkingen lenen zich perfect voor Multi cores. Alleen de engine moet er mee om kunnen gaan.
Ik denk dat dat ook een van de redenen is dat de nieuwe consoles 8 low power cores gebruiken.

[Werelds]

ArgantosNL schreef op donderdag 21 maart 2013 @ 11:44:
Ik heb PhysX al een tijdje niet meer bekeken maar als ik Werelds zo hoor zijn ze het eindelijk aan het aanpassen. Werd tijd want de monopoly positie hebben ze al jaren niet meer.

Ja, ze zijn na de shitstorm in 2010-2011 eindelijk echt aan de slag gegaan, na drie jaar op hun gat te hebben gezeten.

Natuurkundige berekeningen zijn per definitie heel goed te multithreaden en in parallel uit te voeren (vandaar dat een GPU er zo veel sneller doorheen kan blazen) omdat het kleine, korte berekeningen zijn met vaak relatief kleine getallen - er zijn er alleen heel veel van. Dus ja, ook op een CPU kan dat behoorlijk snel, en met extensies zoals SSE kun je heel veel shortcuts nemen waardoor je het gat tussen CPU en GPU voor een groot deel kan dichten.

Echter is PhysX voor 2.8 niet eens in staat tot multithreading en gebruiken ze geen SSE extensies (onder andere); 2.8.x kan wel multithreaded draaien, maar verplicht de developer dit allemaal handmatig uit te voeren. Dan is dus het hele punt van middleware voor de physics gebruiken weg, dus dat doen de meeste devs simpelweg niet. Eind resultaat is zoals ik al vaker dan eens heb aangegeven dat PhysX op de CPU zo traag wordt - zoals madmaxnl al aangeeft gebruikt het maximaal 1 core en dan ook nog eens zonder gebruik te maken van de optimalisaties in de x86/x86-64 instructie sets. Havok daarentegen kan al jaren volledig automatisch multithreaden met al die optimalisaties ernaast, zoals het hoort.

3.0 was de eerste echte versie voor x86(-64). 3.1 verbeterde de multithreading gigantisch en wat ik gelezen heb van 3.2 is dat vooral algoritmische optimalisaties. Allemaal goed dus, alleen heeft het veel te lang geduurd en wordt 3.0+ nog niet echt gebruikt.

[madmaxnl]

Ja inderdaad er is al meermaals langs gekomen dat andere physics engines prima kunnen functioneren zonder GPU al dan niet met scripted events. In Half-Life 2 heb je die brug die instort, dat is z'n scripted event, maar je kunt je afvragen of dat een probleem is m.b.t. de spel ervaring.

[eL_Jay]

Werelds schreef op donderdag 21 maart 2013 @ 10:40:
[...]
Red Faction: Guerrila, de game met nog steeds de leukste *echte* physics

Nooit gespeeld, wel Armageddon, en de physics/destructo/black-hole-generator zijn geweldig.
Is RF:guerilla hier nog beter in?

[Werelds]

madmaxnl schreef op donderdag 21 maart 2013 @ 14:47:
Ja inderdaad er is al meermaals langs gekomen dat andere physics engines prima kunnen functioneren zonder GPU al dan niet met scripted events. In Half-Life 2 heb je die brug die instort, dat is z'n scripted event, maar je kunt je afvragen of dat een probleem is m.b.t. de spel ervaring.

Nou sterker nog, kun je je de mini puzzel in HL2 herinneren met die wip, waar je met bakstenen je eigen gewicht moet matchen? Simpel voorbeeld, maar dat vind ik persoonlijk toch echt leuker dan een betonnen pilaar die onrealistisch uit elkaar spat door een 9mm (Mafia 2)

offtopic:
Guerrilla doet het naar mijn mening boeiender omdat je in de buitenwereld zit. Hele hoop hoge gebouwen die dan gezellig in elkaar donderen..en andere gebouwen mee nemen

[pino85]

AMD 7790 review bij de buren inclusief frametimes:
Heb ook wat andere sites erbij.

http://nl.hardware.info/r...90-review-incl-frametimes
http://www.tomshardware.c...ire-performance,3462.html
http://www.anandtech.com/...first-desktop-sea-islands
http://www.guru3d.com/art...0_review_benchmark,1.html
http://www.computerbase.d...d-radeon-hd-7790-im-test/

[ Voor 58% gewijzigd door pino85 op 22-03-2013 07:33 ]

[Tomas Hochstenbach]

En mijn review:
http://www.bouweenpc.nl/r...amd-radeon-hd-7790-review

Met Batman: AC, Aliens vs. Predator en Tomb Raider inclusief frametimes. Ik kreeg btw een GV-R779OC-1GD van Gigabyte, de benchmarks zijn natuurlijk op stock gemaakt.

[Astennu]

pino85 schreef op vrijdag 22 maart 2013 @ 07:31:
AMD 7790 review bij de buren inclusief frametimes:
Heb ook wat andere sites erbij.

http://nl.hardware.info/r...90-review-incl-frametimes
http://www.tomshardware.c...ire-performance,3462.html
http://www.anandtech.com/...first-desktop-sea-islands
http://www.guru3d.com/art...0_review_benchmark,1.html
http://www.computerbase.d...d-radeon-hd-7790-im-test/

Mooi kaartje! verbeterde performance per watt. Hij is duidelijk efficiënter:
http://www.techpowerup.co...re/HD_7790_Dual-X/27.html

Qua performance per mm2 is het niet veel beter geworden. De nieuwe chip is 20% sneller en 23% groter. Maar dit is natuurlijk geen slechte prestatie zeker als je ziet dat de performance per watt zo veel beter geworden is.

Ik denk dat het heel interessant zou zijn om een dubbele Bonaire te zien. Dus 28 CU, 32 ROP's met 4 geometry engines en 256 Bit bus. Ik denk dat zo'n chip met +- 320-349mm2 de 7950 Boost wel kan verslaan en de 7970 met een beetje geluk ook wel. Want je ziet al hoe ver Pitcrain komt. Daarnaast zou zo'n chip veel meer tesselation performance hebben en een betere performance per watt.

De HD7970 zal nog wel sneller zijn met Compute maar bij games is het een ander verhaal. Qua kosten zou het geen gek idee zijn. Je prijst de HD7950, 7970 en 7970 GHz dan wel uit de markt maar die nieuwe chip kan het beter tegen de GTX680 opnemen qua productie kosten en prestaties.

Ik ben erg benieuwd of we zo'n kaart in de toekomst gaan zien. Of nog beter een nog verder opgeschaalde versie als opvolger van Tahiti met nog meer shaders (bv 2688 @ 480mm2 als ze 3x bonaire aan elkaar zouden plakken)

Dit is wel erg veel speculatie en droom mode maar ik zie wel mogelijkheden voor chips die groter zijn maar dezelfde soort efficientie hebben als Bonaire.

[Astennu]

Ik zie hier trouwens: http://nl.hardware.info/r...---1920x1080-+-frametimes

Dat de frametimes van de 7790 regelmatig beter zijn dan die van de HD7870 GHz! Terwijl die laatste veel sneller is. Het lijkt er op dat AMD weer een stapje verder gekomen is met het oplossen van dit probleem.

De 7790 gebruikt nieuwere drivers. HWI noemt ze cat 13.3 maar volgens mij is dat niet juist. Anandtech noemt een nummer: "AMD’s 12.101.2 press drivers"

Het zou mij niet verbazen als deze verbeteringen ook naar de huidige kaarten zouden gaan komen.

Met AA en vs de GF 650 TI gaat het af en toe niet zo goed maar dat komt denk ik doordat zowel de HD78xx als de GF 650 TI 2GB aan boord hadden. HWI had geen 650 TI 1GB om te testen. Dus dit is dan niet zo'n eerlijke vergelijking. 1GB is vandaag de dag niet altijd genoeg meer. Ik denk dat 7790 2GB's straks interessanter zullen zijn als je er een paar jaar mee wilt doen.

[Verwijderd]

De vergelijking is gewoon eerlijk als de kaarten rond de zelfe prijs liggen.

[Astennu]

Verwijderd schreef op vrijdag 22 maart 2013 @ 09:14:
De vergelijking is gewoon eerlijk als de kaarten rond de zelfe prijs liggen.

Nja laat ik het dan zo stellen het is niet handig om een frame buffer bottelnek te hebben om te testen of de frame times door drivers verbeterd zijn. Dan krijg je gewoon een vertekend beeld te zien. Zodra je dan meer memory nodig hebt krijg je giga spikes.

[Verwijderd]

Maar die test is ook niet bedoelt om te laten zien of de drivers verbeterd zijn. Gewoon laten zien wat ze ook nog met AA kunnen en daa laten ze het helaas wat afweten, dus best een reë'l beeld. Vind ik wel erg handig om te weten want dan weet ik nat ik niet voor zo'n kaart moet gaan als ik met AA game.
Zo word er ook getest zonder AA dus voor ieders wat wils.

Komt er op neer dat deze kaart niet erg instressant is om op te gamen met AA aan vanaf 1920x1080
AMD had er beter 2GB op kunnen zetten.

[ Voor 16% gewijzigd door Verwijderd op 22-03-2013 10:04 ]

[Tomas Hochstenbach]

De persdriver voor de HD 7790 werkt niet op andere videokaarten.

[Astennu]

Verwijderd schreef op vrijdag 22 maart 2013 @ 10:00:
Maar die test is ook niet bedoelt om te laten zien of de drivers verbeterd zijn. Gewoon laten zien wat ze ook nog met AA kunnen en daa laten ze het helaas wat afweten, dus best een reë'l beeld. Vind ik wel erg handig om te weten want dan weet ik nat ik niet voor zo'n kaart moet gaan als ik met AA game.
Zo word er ook getest zonder AA dus voor ieders wat wils.

Komt er op neer dat deze kaart niet erg instressant is om op te gamen met AA aan vanaf 1920x1080
AMD had er beter 2GB op kunnen zetten.

AA op een kaart in die classe is sowieso niet rieel....
Ik zou met een HD7870 nog geen AA willen gebruiken op 1920x1080p omdat dit te zwaar is. Dat wordt pas interessant met HD79xx en GTX660+ kaarten.

TomasH schreef op vrijdag 22 maart 2013 @ 10:15:
De persdriver voor de HD 7790 werkt niet op andere videokaarten.

Dat wist ik al anders hadden ze die wel gebruikt. Maar die zullen wel gaan komen. De vraag is alleen wanneer.

[ Voor 14% gewijzigd door Astennu op 22-03-2013 10:57 ]

[rapture]

	7790	7850	GTX 670	Double Bonaire	7970
Shader Units	896	1024	1344	1792	2048
Core Clock	1000 MHz	860 MHz	915 MHz	1000 MHz	925 MHz
ROPs	16	32	32	32	32
Transistors	2080M	2800M	3540M	4160M	4310 M
Die Size	160 mm²	212 mm²	294 mm²	320 mm²	365 mm2
Memory Bus	128 bit	256 bit	256 bit	256 bit	384 bit
Memory Clock	1500 MHz	1200 MHz	1502 MHz	1500 MHz	1375 MHz
Memory Bandwidth	96 GB/s	154 GB/s	192 GB/s	192 GB/s	264 GB/s
Performance HD	95 %	119 %	180 %	190 %	189 %
Peak game Power	78 W	96 W	152 W	156 W	189 W

7790 levert 80% van de 7850 performance op 1920*1200 resolutie met 75% van de die size. Niet slecht als je de ROP's (Bepaalt het aantal pixels per seconde dat een kaart naar de monitor kan sturen ongeacht hoe laag de grafische instellingen staan. Hogere resolutie vraagt meer pixels per seconde.) en geheugenbus halveert. Het printplaatje van de grafische kaart, de kleine die size van de GPU, de weinige geheugenchipjes,... zitten netjes in het goedkoop te produceren low end.

Zoals door Astennu aangehaald is, dubbel Bonaire is interessant. Het kost 9% meer die size dan GTX 670 om tussen 670 en 680 te zitten met een gelijkaardig verbruik. Of 88% van de 7970 die size, 83% van het verbruik, 2/3 van de geheugenbus,... voor gelijkaardige performance. Het printplaatje van de grafische kaart, aantal geheugenchips,... is in termen van productiekosten mid end.

Tripel Bonaire zou een GTX Titan kunnen neerhalen naar een 500 euro prijskaartje met 8% voorsprong in performance (op 1920*1200 en gelijkaardig op hogere resoluties), gelijkaardig verbruik en 86% die size.

Zoals met elke grote architectuur wijziging, wisten ze in het begin niet goed in welke verhouding de interne onderdelen van de GPU ontworpen moesten worden. Eenmaal het released is en er kan met games erop getest worden, dan zien ze waar het overbodige ballast zit dat ze eruit kunnen snijden en de intensief gebruikte onderdelen boosten. De refresh zonder die shrink is nog altijd nodig om met Kepler mee te kunnen.

nVidia en partners hebben een tijdje genoten van grafische kaarten produceren met de kosten van een 200 à 250 euro kaart en verkopen voor 400 à 500 euro. AMD zal kunnen antwoorden met een dubbel Bonaire met de kosten van een 200 à 250 euro kaart. Na een jaar stilstaan met de GPU-prijzen wordt het tijd voor wat beweging. 50 tot 100 euro korting op een GeForce GTX 670 zie ik wel zitten. Mijn 4830 is oud aan het worden.

[-The_Mask-]

Je kan beter naar gemiddeld verbruik kijken, je kijkt toch ook niet naar max fps?

[catfish]

-The_Mask- schreef op zaterdag 23 maart 2013 @ 19:47:
Je kan beter naar gemiddeld verbruik kijken, je kijkt toch ook niet naar max fps?

[afbeelding]

ik vraag mij meer af hoe juist dergelijke grafieken zijn
de verschillen tussen websites zijn soms vrij groot

bij verbruik vind ik het maximale verbruik echter veel belangrijker dan het gemiddelde, de voeding moet dit namelijk aankunnen, bij framerates kijk ik eerder naar de minimale waarde (framedrops komen meestal voor wanneer je het niet kan gebruiken)

[-The_Mask-]

Het gaat hier niet om wat de voeding aan kan maar de performance per watt van een videokaart. Overigens is het piekverbruik ook bij een voeding niet interessant, een goede voeding kan die piek prima opvangen.

[ Voor 38% gewijzigd door -The_Mask- op 23-03-2013 23:44 ]

[Verwijderd]

Astennu schreef op vrijdag 22 maart 2013 @ 08:50:
Ik zie hier trouwens: http://nl.hardware.info/r...---1920x1080-+-frametimes

Dat de frametimes van de 7790 regelmatig beter zijn dan die van de HD7870 GHz! Terwijl die laatste veel sneller is. Het lijkt er op dat AMD weer een stapje verder gekomen is met het oplossen van dit probleem.

De 7790 gebruikt nieuwere drivers. HWI noemt ze cat 13.3 maar volgens mij is dat niet juist. Anandtech noemt een nummer: "AMD’s 12.101.2 press drivers"

Het zou mij niet verbazen als deze verbeteringen ook naar de huidige kaarten zouden gaan komen.

Met AA en vs de GF 650 TI gaat het af en toe niet zo goed maar dat komt denk ik doordat zowel de HD78xx als de GF 650 TI 2GB aan boord hadden. HWI had geen 650 TI 1GB om te testen. Dus dit is dan niet zo'n eerlijke vergelijking. 1GB is vandaag de dag niet altijd genoeg meer. Ik denk dat 7790 2GB's straks interessanter zullen zijn als je er een paar jaar mee wilt doen.

Frame times boven de 30ms begint echt iritant te worden. Het valt mij ook erg op dat
meer gpu's een betere frame time geven. Bij mij is dat In veel games zo'n 12-15 ms met SLI
Helaas moet ik nog bij nvidia blijven omdat ik physx nog regelmatig gebruik anders was het echt AMD geworden vanwege de prijs.

[ Voor 4% gewijzigd door Verwijderd op 24-03-2013 11:16 ]

[SG]

Werelds schreef op donderdag 21 maart 2013 @ 10:40:
[...]

De "ondersteuning" is je reinste onzin. AGEIA had dat in hun oorspronkelijke versie al, het loopt alleen voor geen meter. GPU ondersteuning gaat er niet komen, Nvidia wil dat op CUDA houden als marketing tool.

Loopt voor geen meter? Met wat vergelijkje het. Met GTx580 dedicated?! Ten eerste is Ageia PhysX 1 een pre G80 kaartje toen nV nog niks met cuda deed. Gpgpu achterliep op ATI. Maar R520 al phhysics demo deed nog voordat PPU uit was. En PPU nog voordat het uitkwam al concurentie in zicht had.
En tov de toen single en nieuwe dual cores een breed verschil gaf. En dan moet je niet naar paar 100 botsende doosjes kijken maar physics zoals fluid en clothing in de MIX. Wat altijd disabled is op cpu only. Dan zijn er later zooi nextgen GPU gekomen van af G80 waar deze PPU naast liep op zeer oude procede ook voor zijn release en een tweede gen maar niet kwam. Zelf hands on ervaring met PPU en het werkte toen. Ook benches laten zien dat dedicated PPU met dikke CPU en dikke GPU zin had. De UT3 physX mod benches. Waar de toen al oude PPU aardig mee deed.

Havok en Bullet kunnen tegenwoordig allebei even veel op de GPU uit voeren als PhysX kan, alleen gaat dat via OpenCL en is het dus niet gebonden aan CUDA. Sterker nog, als je kijkt naar de PhysX versies die gebruikt worden, is er vrijwel geen voordeel voor PhysX. Alles onder 2.8.2 draait nagenoeg alles op de CPU behalve particles, fluids en cloth. Vanaf 2.8.4 heeft Nvidia eindelijk delen van soft body physics via de GPU lopen en vanaf 2.8.6 + APEX 1.2 kan ook een deel rigid body physics via de GPU. Rigid body is wat het meest interessant is, want dat zijn de daadwerkelijke physics. Er zijn echter nog geen handvol games die zo up to date zijn, afgezien van het feit dat 2.8.6 en APEX 1.2 samen gebruikt moeten worden om dit te doen, wat een hoop extra tijd kost.

Havok doet niks met GPU sinds iNtel dat heefd overgenomen in de strijd van CPU intel vs GpGPU nV. Die ook aan modder gooien waren en Larabee nog ver van release was. Havok onafhankelijk was al erg ver met gPGPU de module Havok FX. Maar iNtel KILLED dat. De game markt genaait en dus wij gamers door intel. Nv tegen zet was physx sdk overnemen door ageia over te nemen. En deze pu war heeft de hele gpgpu physics gedoe gestalled. Zodat ATI en nV games geen GPGPU physics kunnen doen met markt leidende physics middleware Havok. PhysX is nu al een poos een grote tweede. De derde en de rest staan daar zo ver vanaf dat ze nu nog niet toedoen. Er is een game die iets doet met AMD en dat is tomb raider. Nog zeldzamer dan cuda physX games.

Op de PS4 zullen we gewoon CPU PhysX zien, hopelijk wel minimaal 3.0 en geen 2.8.x rotzooi meer. Want PhysX voor 3.0 -dat momenteel amper gebruikt wordt- is als dikke stront door een trechter op de CPU en bij lange na niet vergelijkbaar met Havok. 3.0 en hoger worden momenteel gebruikt in ARMA 3 (spel is nog niet uit), Natural Selection 2, Planetside 2 (sinds vorige maand). Alle andere games (en voordat iemand het aan durft, Borderlands 2 is gewoon 2.8.6) draaien het merendeel van de PhysX op de CPU. En juist omdat PhysX dan zo traag is gebruiken de meeste van die games PhysX puur voor juist die paar dingen die via de GPU *kunnen* - met de zak geld natuurlijk.

nV tegen naaistreek is door CPU op hun GPGPu platformen slechter meer generft te ondersteunen. Dus amper smp en compileren voor oude cpu waar de latere SSE extenties dus niet gebruikt worden. Hoe de huidige stand is weet ik niet maar diverse site hebben dat getest. Ten eerste de CPU physics load is vaak gericht op lowet dominator de low end mainstream en deze physics load is vaak fixed load en dus lichte load en gameplay physx. Consoles en hun devkit krijgen mogelijk appart gecompileerde binaries. Die niet gesaboteerd zijn. Misschien dat de strijdbijl begraven is, en men CPU nu wel goed met ondersteunen anders verliezen ze klanten. Mischien hebben grote klanten gedreigd over te stappen als nV CPU op de handrem laat lopen. En tijd heeld wonden.

Havok is daarnaast veel meer gebruikt dan PhysX, ik geloof niet dat de meeste beseffen hoe populair Havok precies is. Source engine? Volledig Havok; met een hoop verbeteringen van Valve, die Intel vervolgens standaard in Havok heeft geport (dit in tegenstelling tot Nvidia die pas na 3 jaar en vele negatieve berichten iets aan PhysX deed). Frostbite 1, 1.5 en 2.0? Allemaal Havok. Red Faction: Guerrila, de game met nog steeds de leukste *echte* physics? Havok. Skyrim, Darksiders, Bioshock, Timeshift? Allemaal Havok - ragdolls in de meeste van deze komen ook uit Havok en de physics in veel van deze games zijn veel boeiender (omdat ze invloed op de gameplay hebben) dan de particles waar PhysX zo bekend om staat. Het grote verschil is dat Intel met Havok geen full-screen logo wilt, een vermelding tussen alle andere credits is al genoeg; wel kost het licentie kosten uiteraard, waar Nvidia juist graag een zak geld dropt. Ze mogen wellicht niet zo overduidelijk aanwezig zijn als Nvidia, Havok heb je al vaker in actie gezien dan je denkt - meer dan PhysX en zonder de gigantische performance hit. De enige game op Havok die echt zwaar is, is RF: Guerrilla, maar de physics in die game steken dan ook ver boven alle andere uit.

Havok en PhysX hebben beide 100den games onder zich het zijn beide gezamelijk markt leiders. Er is helaas geen derde grote onafhankelijke.

Ik heb wat met PhysX 3.1 gespeeld en dat komt eindelijk in de buurt van Havok qua prestaties (nogmaals, ik heb het hier over de CPU, CUDA is gewoon niet boeiend omdat het slechts een deel van de markt betreft). Hopelijk is 3.2 de versie (is al beschikbaar, nog niet mee kunnen spelen) die PhysX tot een waardevolle toevoeging maakt - belangrijker, hopelijk sterft in elk geval 2.8.x een snelle en pijnlijke dood, want ik wil dat stuk stront nooit meer in een game zien

Nou Ghost recon warfighter gebruikte Havok en PhYsX dus havok op CPU voor gameplay physics en PHysx op ageia PPu. Graw 2 was puur PHysX. Je kan dus de bete voor cpu deel middleware gebruiken en iets andrs voor gpgpu gebruik.

Daarnaast kan je zelf doormiddel van eigen libaries dmv OpenCL of zelfs de toegankelijkere AMP C++ elke merk GPU benutten die ondersteund wordt. Alleen geen middelware maar do it yourself ware. Of die derde speler Bullit.

Middleware is fijn, bied breed featureset is geoptimaliseerd door vele jaren manwerk eran wat je inhouse niet kan halen. Alleen de party poeper is dat PU firmas van de twee markt leidende physics middleware ervan de eigenaar zijn en de middleware voor hun kar spannen en de concurentie dwars bomen. Wat vooruitgang dwars zit.

Nou ik zou havok voor standaard CPU physics doen. Sequentiele physics wat slecht concurent is loopt daar beter. Cpu is daar bter in. En physX voor GpGpu nou nee het gebruikt alleen cuda. Dus ik zou dan wel voor OpenCL GPGPu alternatief gaan. En veel zelf implementeren via AMP c++ niet alleen voor physics ook voor andre zeer concurent taken. Zoals AI soms ook zeer concurent kan zijn.

Game engine bouwers er zijn 10 tal grote, zouden zelf een GPGPU physics component deel implementeren zonder merk beperkingen.

Niet zoals UE engine gewoon physx sdk intergreerd een hele popu engine dus ook heel veel games aan physX

[Verwijderd]

Physx is wel nice opzich zeker omdat het nog altijd gebruikt word en games er mooier uit laat zien. Vooral de explosies zijn net echt, genzie alles een eigen weg heeft en realistisch is. Vergelijk het maar met katsen van 2 ronde ballen die een natuurlijke weg nemen zoals het in het echt ook gaat.
Nvidia kan trouwens haar mooier laten bewegen en er uit laten zien dan AMD.

[Werelds]

SG schreef op zondag 24 maart 2013 @ 14:23:
[...]
Loopt voor geen meter? Met wat vergelijkje het. Met GTx580 dedicated?!

Nee, ik vergelijk het met Havok of nu met PhysX 3.x. Feit blijft dat AGEIA geen reden had om voor de CPU iets te verbeteren -en even voor de duidelijkheid, multithreading en SSE waren er toen ook al- en dat Nvidia hier fijn mee verder is gegaan. Ik begrijp het helemaal vanuit zakelijk standpunt, maar als consument heb ik er geen respect voor en vermindert het m'n interesse gigantisch.

Havok doet niks met GPU sinds iNtel dat heefd overgenomen in de strijd van CPU intel vs GpGPU nV.

Nee hoor, het is nooit weggegaan. Intel heeft het OpenCL deel juist altijd willen pushen, maar dat is er nooit van gekomen om meerdere redenen. Ten eerste is OpenCL 1.0 nu net iets meer dan 4 jaar oud, maar was 1.0 tegelijkertijd ook geen geweldig product. Veel beperkingen, performance was behoorlijk slecht; met name op Nvidia, wederom omdat Nvidia er geen heil in zag hun eigen product te laten zakken. OpenCL 1.1 verbeterde dit aanzienlijk, maar ook hier was Nvidia weer vervelend, het duurde maar liefst een jaar voordat 1.1 echt ondersteund werd. En daar hebben we dan ook nog met name Apple voor te danken ook, wat gewoon hilarisch is. Anderhalf jaar geleden kregen we 1.2, wat met name een feature release was (hoewel er ook aardig wat performance verbeteringen in zitten). Nu mag jij eens raden welke van alle fabrikanten weer geen zin heeft en dat is niet omdat er geen vraag naar is.

Nvidia is letterlijk de enige die niet mee wil doen, maar helaas hebben ze een aardig marktaandeel. Intel ondersteunt 1.2, AMD ondersteunt het, Qualcomm ondersteunt het in Adreno 3 en IT ondersteunt het zelfs in de oude 5XT series. IT was zelfs eerder met 1.0 ondersteuning dan zowel Nvidia als AMD.


Dus nee, ook al is 3.x zo veel beter en eindelijk waar het 3-4 jaar geleden had moeten zijn, PhysX mag wat mij betreft gewoon oprotten. Al is het maar omdat mij het risico te groot is dat Nvidia weer vervelende dingen gaat uithalen. En dat mag sommigen hier niets uitmaken omdat ze toch altijd bij Nvidia blijven, ik weet niet of m'n volgende kaart weer Nvidia wordt. Ik heb liever wat vrijheid in m'n keuze, zonder dat ik daarbij gelimiteerd wordt door softwarematige beperkingen die in het leven zijn geroepen om pure marketing redenen.

offtopic:
Raar hoofdletter gebruik heb je trouwens

[Verwijderd]

Welkom in hardware land waar alle bedrijven vui streken uit halen, gelukkig hebben de consumenten er niet erg veel last (behalve de fanboy's want die kunnen het niet hebben), maar de normale mensen kunnen nog gewoon goed hun game spelen, phyxs zal ook nooit weg gaan gelukkig want het voegt bij sommige games heel wat moois toe. Physx mag van mij niet oprotten want ik heb er veel aan zoals mee rdan de helft van de gamers.

[ Voor 5% gewijzigd door Verwijderd op 24-03-2013 15:01 ]

[Verwijderd]

Verwijderd schreef op zondag 24 maart 2013 @ 15:00:
Welkom in hardware land waar alle bedrijven vui streken uit halen, gelukkig hebben de consumenten er niet erg veel last (behalve de fanboy's want die kunnen het niet hebben), maar de normale mensen kunnen nog gewoon goed hun game spelen, phyxs zal ook nooit weg gaan gelukkig want het voegt bij sommige games heel wat moois toe. Physx mag van mij niet oprotten want ik heb er veel aan zoals mee rdan de helft van de gamers.

Het is triest dat je tot die conclusie komt , PhysX is bedoelt om exclusiviteit te creëren, het is zelfs lachwekkend dat men dit associeert met gameplay theoretisch maakt het niet uit welke processor het uitrekent , maar dat werkt natuurlijk niet zo.

DirectX is platform afhankelijk , OpenCL is dit niet. Onder DirectX wordt dus dat TressFX gedaan niets vuile truukjes ....

PhysX werkt net zo goed of slecht als de portemonnee van Nvidia dik is.

[dcm360]

PhysX werkt net zo goed of slecht als de agenda van nVidia dik is. Als nVidia het dusdanig opengooit dat AMD en Intel het ook op hun GPU's kunnen laten werken, is nVidia gewoon een verkoopargument voor hun videokaarten kwijt.

[nero355]

dcm360 schreef op zondag 24 maart 2013 @ 15:22:
PhysX werkt net zo goed of slecht als de agenda van nVidia dik is. Als nVidia het dusdanig opengooit dat AMD en Intel het ook op hun GPU's kunnen laten werken, is nVidia gewoon een verkoopargument voor hun videokaarten kwijt.

Ja, want je moet maar net die 8 games of zo interessant genoeg vinden die PhysX support hebben die daadwerkelijk iets toevoegt en daar ook nog FPS voor op willen offeren, want een videokaart kan niet beiden doen helaas zonder één van de twee te benadelen !! Sorry, maar ik zie liever lekker veel FPS dan een of andere wapperend doekje ingame waar je amper tijd voor hebt, omdat je van alle kanten wordt beschoten om maar wat te noemen

[Verwijderd]

dcm360 schreef op zondag 24 maart 2013 @ 15:22:
PhysX werkt net zo goed of slecht als de agenda van nVidia dik is. Als nVidia het dusdanig opengooit dat AMD en Intel het ook op hun GPU's kunnen laten werken, is nVidia gewoon een verkoopargument voor hun videokaarten kwijt.

En terecht want alle bedrijven doen precies het zelfde, ook AMD alleen dan weer op een andere mannier.
Physx wertk vooral veel op de CPU tegenwoordig dus het werkt ook voor mensen met een AMD kaart in hun pc, maar dat er ook games zijn die alleen via de gpu physx laat werken is gewoon eerlijk. En physx is wel wat meer dan enkel wapperende vlaggen, explosies die echt zijn, muren die echt uit elkaar vallen, die kogels waar je het over hebt die om je heen vliegen exc.
Zoals ik al zij het zijn fanboy's die er altijd negatief over zijn omdat ze liever een AMD videokaart hebben maar wel gebruik willen maken vn physx.

En wat maakt dat fps opofferen nu zo erg, gezien in die games al 200 fps word gehaald en met physx aan
je nog 190 fps over houd. Als je overgens de physx over de cpu laat werken dan heb je in bepaalde games juist minder fps dan als het over de gpu word gedaan. TFX eet anders ook heel wat van je fps weg die reactie slaat kant nog wal.

Alsof AMD zo heilig is, kom op haal die plaat voor je hasses weg
Sleeping dogs sniper elite v2 enzv AMD betaald een hoop geld voor SSAA zodat het slechter op nvidia kaarten werkt en maar een beetje slechter op AMD kaarten.

[ Voor 27% gewijzigd door Verwijderd op 24-03-2013 19:21 ]

[Werelds]

Verwijderd schreef op zondag 24 maart 2013 @ 19:05:
En terecht want alle bedrijven doen precies het zelfde, ook AMD alleen dan weer op een andere mannier.
Physx wertk vooral veel op de CPU tegenwoordig dus het werkt ook voor mensen met een AMD kaart in hun pc, maar dat er ook games zijn die alleen via de gpu physx laat werken is gewoon eerlijk.

Het heeft altijd via de CPU gewerkt. Dat is het probleem ook niet. Het probleem is dat het op de CPU niet zo lekker loopt als het zou moeten, in tegenstelling tot grote concurrent Havok, dat puur op de CPU meer klaar krijgt gespeeld dan PhysX vaak zelfs op de GPU.

En physx is wel wat meer dan enkel wapperende vlaggen, explosies die echt zijn, muren die echt uit elkaar vallen, die kogels waar je het over hebt die om je heen vliegen exc.

Kogels die om je heen vliegen dankzij PhysX?

Explosies en destruction zitten ook in Havok en zoals gezegd, loopt het dan niet als dikke stront door een trechter.

Disclaimer: ik heb het uiteraard wederom over PhysX 2.x

Zoals ik al zij het zijn fanboy's die er altijd negatief over zijn omdat ze liever een AMD videokaart hebben maar wel gebruik willen maken vn physx.

Ja, so what? Sommigen onder ons hebben geen gekleurde bril op en maakt het dus geen donder uit of we Nvidia of AMD hebben. Wij willen graag de beste waar voor ons geld en dat is niet altijd Nvidia; sterker nog, de vorige twee generaties, was AMD dat met afstand. Dat betekent ook dat wij regelmatig tussen de twee fabrikanten wisselen. En dan wil ik niet dat ik een game die voorheen gewoon lekker liep ineens niet kan spelen omdat Nvidia een zak geld heeft gedropt zonder dat het iets toevoegt dat niet met andere middleware had gekund.

Sleeping dogs sniper elite v2 enzv AMD betaald een hoop geld voor SSAA zodat het slechter op nvidia kaarten werkt en maar een beetje slechter op AMD kaarten.

Wat?

Volgens mij verzin je daar problemen die niet bestaan

[SG]

Werelds schreef op zondag 24 maart 2013 @ 14:52:
[...]

Nee, ik vergelijk het met Havok of nu met PhysX 3.x. Feit blijft dat AGEIA geen reden had om voor de CPU iets te verbeteren -en even voor de duidelijkheid, multithreading en SSE waren er toen ook al- en dat Nvidia hier fijn mee verder is gegaan. Ik begrijp het helemaal vanuit zakelijk standpunt, maar als consument heb ik er geen respect voor en vermindert het m'n interesse gigantisch.

Waar slaat dit nou op. We discussieren op verschillende punten.
De soap tussen twee bedrijfen het verleden en de huidige stand van zaken.

PPU nr 1 is eenchip die twee jaar mee moest lopen, dus wat er toen was aan GPU R520 en later de g80 dat waren de concurerende producten. PPU nextgen is doordat nV ageia heefd overgenomen en zelf chips heefd die het ook kunnen, dmv de cuda cores.de algehele dx10 product lijn van nV als dedicated physX kaart kan je een nv G kaart misbruiken. Dus.
Crysis1 liep op een 8600GT + PhysX one // de one and only pure PPU
GTX285 plus 8600GT // " als nextgen dedicated Physx "P"PU. " "
GTX580 maar geen plaats voor GTX285 of de GTX560ti 2GB // 3 de 4 de gen.

Cuda GPGPU physX komt niet for free. Games zijn overwegend GPU rendering intensief. Die extra fine grain effects physics doet dit.
1 de CPU moet meer werk delegeren
2 cuda physx gebruikt cuda cores die al belast zijn met renderen
3 effect physx is meer GFX maakt die load nog tuk zwaarder.

Dus dedicated physx heefd zijn meerwaarde, maar pas als je de effecten ook zwaar gaat toepassen.

[...]

Nee hoor, het is nooit weggegaan. Intel heeft het OpenCL deel juist altijd willen pushen, maar dat is er nooit van gekomen om meerdere redenen. Ten eerste is OpenCL 1.0 nu net iets meer dan 4 jaar oud, maar was 1.0 tegelijkertijd ook geen geweldig product. Veel beperkingen, performance was behoorlijk slecht; met name op Nvidia, wederom omdat Nvidia er geen heil in zag hun eigen product te laten zakken. OpenCL 1.1 verbeterde dit aanzienlijk, maar ook hier was Nvidia weer vervelend, het duurde maar liefst een jaar voordat 1.1 echt ondersteund werd. En daar hebben we dan ook nog met name Apple voor te danken ook, wat gewoon hilarisch is. Anderhalf jaar geleden kregen we 1.2, wat met name een feature release was (hoewel er ook aardig wat performance verbeteringen in zitten). Nu mag jij eens raden welke van alle fabrikanten weer geen zin heeft en dat is niet omdat er geen vraag naar is.

OpenCL is veel breeder toe pasbaar buiten de home computers. Zelfs over clusters en super computers maar ook embedded en naast CPU en GPU ook DSP.

NV richt zich met PHysx op een specifieke doelgroep. En handeld die generieke overhead al af op driver niveau. Daarnaast liepen nV drivers achter op OpenCL want die bleven lang plakken bij 1.0.

En probleem in de game markt is dit.
De basis mainstream CPU load is een hele lichte gameplay physics load.
De cuda effect physX load is juist vele malen zwaarder. Het loont dus wel om met OpenCL iets op in te leveren. Maar daarmee wel alle GPU ondersteund en er geen lichte CPU physics nood loop nodig is. Maar iets hogere GPU eis. En veel meer dev zullen berijd zijn op gpgpu physics toe te passen. De basis fix load schiet een grote stap vooruit.

Nvidia is letterlijk de enige die niet mee wil doen, maar helaas hebben ze een aardig marktaandeel. Intel ondersteunt 1.2, AMD ondersteunt het, Qualcomm ondersteunt het in Adreno 3 en IT ondersteunt het zelfs in de oude 5XT series. IT was zelfs eerder met 1.0 ondersteuning dan zowel Nvidia als AMD.

Om de simpele reden dt ze hun eigen GPU hun core bussness ermee willen pushen. Maar daar hebben wij consumnten in de game markt geen boodscap aan. Het belemmerd de bereidheid van gross van de dev om het toe te passen.

Dus nee, ook al is 3.x zo veel beter en eindelijk waar het 3-4 jaar geleden had moeten zijn, PhysX mag wat mij betreft gewoon oprotten. Al is het maar omdat mij het risico te groot is dat Nvidia weer vervelende dingen gaat uithalen. En dat mag sommigen hier niets uitmaken omdat ze toch altijd bij Nvidia blijven, ik weet niet of m'n volgende kaart weer Nvidia wordt. Ik heb liever wat vrijheid in m'n keuze, zonder dat ik daarbij gelimiteerd wordt door softwarematige beperkingen die in het leven zijn geroepen om pure marketing redenen.

Vind ik ook, maar ja als je Amp c++ en OpenCL wilt gebruiken en nV opencl nerf heb je ook cuda path nodig en daarmee hun hardware.
En met Amp C++ ook een APU steempje.

[t!n0]

En ik maar denken dat dit een Radeon nieuwsdiscussie topic is
Zal wel aan het gebrek aan nieuws liggen...

[Werelds]

@ t!n0: mag dan niet direct op Radeon gericht zijn, maar is weldegelijk discussie waardig
Met een beetje geluk krijgen we namelijk met de next-gen consoles een engine van Havok die OpenCL gewoon gebruikt, ook al loopt Nvidia daar dan mee achter. Dat is goed nieuws voor Radeon eigenaren


@ SG: je hebt met het eerste stuk alsnog mijn punt gemist. Mijn punt is dat de delen van PhysX die op de CPU moeten lopen (en dat is nog steeds een groot deel, zelfs in 3.0) en niet op de GPU kunnen tergend langzaam lopen pre-3.0 (of beter gezegd, langzamer dan Havok het kan op de CPU). Als je dan ook nog geen Nvidia kaart hebt om de GPU delen op te vangen, wordt de CPU load veel hoger dan hij hoeft te zijn. Nogmaals, als het CPU gedeelte van PhysX fatsoenlijk liep had ik er niet zo'n moeite mee dat het dan met Nvidia in je PC beter loopt. Dat is echter niet het geval, wat betekent dat de meeste games met PhysX tot nu toe het dan ook niet uit eigen keuze hebben gebruikt maar eerder vanwege een donatie van Nvidia.

[Verwijderd]

Maar de ps4 gaat dus physx ondersteunen maar vast ook havok.
Verder snap ik niet dat je er bij komt dat physx als stront door een trechter loopt.
Zoals de meeste physx games loopt het soepel en kost het niet veel extra fps
Ik ben het er wel mee eens dat het niet 100% eerlijk is voor mensen met een AMD kaart,
zoals de physx die in borderlands zit geven wel weer allemaal effecten tijdens explosies en
spetters die van inslaande kogels af vliegen. Het was beter geweest dat nvidia
er voor zorgde dat het zowel over de CPU werkt als de GPU.
Zo had AMD er voor moeten zorgen dat er meerdere AA ondersteunung zit in
amd gaming evolved, en niet alleen de extreem zware SSAA die erg op de geheugenbus leunt
waar nvidia kaarten dan erg in kakken en AMD kaarten het prima kunnen draaien.

[Toettoetdaan]

Het aantal beweringen zonder bronnen lopen pijnlijk hard op hier...

[Verwijderd]

Die bewering van mij kun je gewoon met nadenken na gaan. Als je weet hoe zwaar SSAA is en er verder geen andere AA opties in zitten dan zit je met AA aan met een nvidia kaart met de gebakken peren.
Bij de game opstarten staat er ook niet voor niets AMD gaming evolved, is het zelfde als nvidia its mean to be played. Maar goed dit soort fratsen doen dus zowel nvidia als AMD en bijde kuur ik niet goed. Maar
waar ik mij aan stoor is dat het van AMD nog al hard word tegengspoken als of ze heilig zijn en nvidia
alleen maar dit soort streken uit haalt.

[ Voor 5% gewijzigd door Verwijderd op 25-03-2013 12:11 ]

[Toettoetdaan]

Verwijderd schreef op maandag 25 maart 2013 @ 12:10:
Die bewering van mij kun je gewoon met nadenken na gaan. Als je weet hoe zwaar SSAA is en er verder geen andere AA opties in zitten dan zit je met AA aan met een nvidia kaart met de gebakken peren.
Bij de game opstarten staat er ook niet voor niets AMD gaming evolved, is het zelfde als nvidia its mean to be played. Maar goed dit soort fratsen doen dus zowel nvidia als AMD en bijde kuur ik niet goed. Maar
waar ik mij aan stoor is dat het van AMD nog al hard word tegengspoken als of ze heilig zijn en nvidia
alleen maar dit soort streken uit haalt.

Oke, dus met dat 'gewoon nadenken' kun je ook tot de conclusie komen dat nVidia CUDA en PhysX voor zichzelf houd omdat ze op die manier een verkoop argument hebben?

En dat 'gewoon nadenken' lijd ook tot de conclusie dat 'normale' consumenten er niet veel last van hebben dat er geen uniform physics systeem breed wordt geaccepteerd.

Maar vooral helpt dat 'gewoon nadenken' met beslissen dat SSAA slecht loop op nVidia kaarten omdat dat heel zwaar is en de geheugenbus van AMD groter is dan die van nVidia!

Ik doe liever 'gewoon nadenken' over benchmark resultaten en uitspraken/beweringen/onderzoeken van betrouwbare bronnen... Misschien klink ik een beetje kinderachtig, maar er staat alleen op deze pagina al een hoop onzin.

[Verwijderd]

Klopt, er staat ook een hoop onzin wat hier niet hoort en wat alleen sterk op trolls lijkt.
Je hebt helemaal gelijk dat nvidia physx heeft om als verkoop argument te gebruiken maar dat is
eingelijk ook wel terecht gezien nvidia het gekocht heeft en het van hun nu is en dat het wat toe voegt in games. Alleen wat ik niet snap
is dat nivdia er niet meer aan wil verdienen, want dat doen ze als het een standaard word voor
andere merken GPU's zoals AMD dan word het veel meer in games gebruikt. Of zal nvidia er ook geld aan verdienen door het via de CPU te laten lopen zodat het als nog werkt op verschillende systemen?

Over SSAA wat trouwens een erg zware AA is maar ook mooi zoals MSAA is gewoon heel erg zwaar.
Het leunt erg op de geheugen bus en gaat ook met meer dan 2SSAA makkelijk over de 2GB geugen heen.
"Ik denk dat je nu wel begrijpt waar ik heen wil gaan" want nvidia heeft bijna geen kaarten die meer dan 2Gb geheugen hebben waar door instellingen niet mogelijk worden op de meeste nvidia kaarten.

[ Voor 24% gewijzigd door Verwijderd op 25-03-2013 13:11 ]

[Werelds]

Welke game heeft alleen SSAA dan?

Laatste game die SSAA ingebakken had was TR en daar zat toch ook MLAA in?

[Verwijderd]

Sniper elite V2 en Sleeping dogs maar Tomb raider heeft er FXAA bij in zitten.
En dirt 3 is ook brak voor nvidia geoptimaliceerd omdat nvidia telkens pas later die code's krijgen om de game voor hun hardware te optimaliseren. Zo heeft nvidia nog steeds geen code gekregen voor Tombraider als ik het goed heb? Tomb raider draait nu verder wel goed met FXAA maar met SSAA aan komen er rare effecten in het haar en dropt de fps richting de 40fps en er word extreem veel videomemory gebruikt.

[ Voor 22% gewijzigd door Verwijderd op 25-03-2013 13:26 ]

[Toettoetdaan]

Mijn vorige post was 90% sarcasme, misschien had ik dat even moeten vermelden. Maar deze vraag van jou vind ik wel leuk, dus daar zal ik even normaal op in gaan

Verwijderd schreef op maandag 25 maart 2013 @ 13:06:
Alleen wat ik niet snap is dat nivdia er niet meer aan wil verdienen, want dat doen ze als het een standaard word voor andere merken GPU's zoals AMD dan word het veel meer in games gebruikt. Of zal nvidia er ook geld aan verdienen door het via de CPU te laten lopen zodat het als nog werkt op verschillende systemen?

nVidia wil dat juist heel graag, het zijn AMD en Intel die dat niet zien zitten, omdat CUDA en PhysX 'propriëtaire software' software is en dus geen niet open beschikbaar zoals bijvoorbeeld OpenCL.

AMD en Intel zitten er niet op te wachten dat ze licentie geld moetten betalen om CUDA en/of PhysX te ondersteunen terwijl ze geen volledige toegang tot de code hebben, of zelf geen verbeteringen mogen aandragen. In dat geval zouden ze betalen voor het ondersteunen van een product wat nooit zo goed draait op eigen hardware als bij nVidia zelf.
En daarom is CUDA en PhysX op de GPU nVidia only. Niet omdat nVidia speciale hardware heeft of omdat ze het voor zichzelf willen houden.
Bron: http://www.xbitlabs.com/n...ia_s_CUDA_Technology.html

Sterker nog nVidia heeft zelfs een hacker geholpen om PhysX draaiend te krijgen op de HD4800 serie, nadat hij het werkend kreeg op de HD3000 serie.
Bron: http://www.tomshardware.com/news/nvidia-physx-ati,5764.html
Bron2: http://www.tgdaily.com/ha...hysx-effort-on-ati-radeon

En daarom loont het om zo nu en dan een bron op te zoeken

[Sp3ci3s8472]

Verwijderd schreef op maandag 25 maart 2013 @ 13:23:
Sniper elite V2 en Sleeping dogs maar Tomb raider heeft er FXAA bij in zitten.
En dirt 3 is ook brak voor nvidia geoptimaliceerd omdat nvidia telkens pas later die code's krijgen om de game voor hun hardware te optimaliseren. Zo heeft nvidia nog steeds geen code gekregen voor Tombraider als ik het goed heb? Tomb raider draait nu verder wel goed met FXAA maar met SSAA aan komen er rare effecten in het haar en dropt de fps richting de 40fps en er word extreem veel videomemory gebruikt.

Als je je inleest wat SSAA doet dan snap je ook waarom dit zo memory intensief is, waarom zou je AMD nu de schuld gaan geven dat dit niet goed loopt op Nvidia kaarten doordat die te weinig geheugenbandbreedte en geheugen hebben? Dat is gewoon een design beslissing van Nvidia om een midend kaart tot highend kaart te kronen (GTX670/680). Het zou mij niks verbazen als het op de Titan wel goed loopt wat de eigenlijke highend had moeten zijn.

Jij wijst wel lekker naar AMD maar het feit is gewoon dat Nvidia veel vaker zulke streken uithaalt (Crysis 2 tesselation op water onder de kaart en anti aliasing met een vendor check disablen in Batman Dark Asylum). Dus tenzij jij met goede bronnen blijf ik er van uit gaan dat AMD eerder een heilig engeltje is dan Nvidia om het zo maar even te zeggen.
Dit is gewoon een feit, als je deze topics lang genoeg volgt dan zie je die dingen gewoon steeds terug komen. Vroegah heeft AMD volgens mij wel een keer gecheat met 3dmark 2001?, maar dit is ook meer dan x aantal jaar geleden en sindsdien hebben ze een redelijke schone lei in tegenstelling tot Nvidia.

Sowieso is het gebruikelijk dat als je iets beweert dat je met goede bronnen komt in plaats van dat je van ons verwacht dat wij het tegendeel bewijzen, dus bij deze ga op zoek .

[Werelds]

Verwijderd schreef op maandag 25 maart 2013 @ 13:23:
Sniper elite V2

FXAA voor DX9/10 kaarten, MLAA voor DX11. Klopt dus niet.

Sleeping dogs

FXAA.


Verder is het inderdaad nog steeds niet hetzelfde dat AMD SSAA in games wil zien NAAST bestaande, goed werkende AA methodes. Je krijgt als Nvidia klant namelijk wel de keuze, je hardware kan het dan alleen niet helemaal behapstukken. Bij PhysX is dat anders, want de hardware zou het weldegelijk kunnen behapstukken als het uberhaupt ondersteund werd. Sterker nog, het beetje CPU ondersteuning dat er is kan al vele malen beter.

Zijn toch echt twee totaal verschillende situaties hoor.


En nee, ATI was zeker niet altijd een heilig boontje (Quack 3 ). Echter sinds ze AMD zijn geworden is er alleen het AF quality vs. performance verhaal (stond standaard op Performance in CCC , terwijl Nvidia juist Quality had) - ik kom in elk geval even nergens anders op zo 1-2-3. Intussen kan ik verwijzen naar de zak geld op de stoep van Rocksteady (zie hierboven), het AF "probleem" in Crysis, de LoD "foutjes" in Trackmania, enzovoort...

[Verwijderd]

Sp3ci3s8472 schreef op maandag 25 maart 2013 @ 13:56:
[...]


Als je je inleest wat SSAA doet dan snap je ook waarom dit zo memory intensief is, waarom zou je AMD nu de schuld gaan geven dat dit niet goed loopt op Nvidia kaarten doordat die te weinig geheugenbandbreedte en geheugen hebben? Dat is gewoon een design beslissing van Nvidia om een midend kaart tot highend kaart te kronen (GTX670/680). Het zou mij niks verbazen als het op de Titan wel goed loopt wat de eigenlijke highend had moeten zijn.

Jij wijst wel lekker naar AMD maar het feit is gewoon dat Nvidia veel vaker zulke streken uithaalt (Crysis 2 tesselation op water onder de kaart en anti aliasing met een vendor check disablen in Batman Dark Asylum). Dus tenzij jij met goede bronnen blijf ik er van uit gaan dat AMD eerder een heilig engeltje is dan Nvidia om het zo maar even te zeggen.
Dit is gewoon een feit, als je deze topics lang genoeg volgt dan zie je die dingen gewoon steeds terug komen. Vroegah heeft AMD volgens mij wel een keer gecheat met 3dmark 2001?, maar dit is ook meer dan x aantal jaar geleden en sindsdien hebben ze een redelijke schone lei in tegenstelling tot Nvidia.

Sowieso is het gebruikelijk dat als je iets beweert dat je met goede bronnen komt in plaats van dat je van ons verwacht dat wij het tegendeel bewijzen, dus bij deze ga op zoek .

De games zelf zijn de bronnen. Maar met logisch nadenken kun je er wel van uit gaan dat AMD SSAA er in gooit om zo beter in benchnark uit te komen want AMD weet dat nvidia kaarten niet goed om gaan met SSAA.. Plus punt is dat er FXAA in de game van tombraider zit onder dx11. Die andere games geven mij mij alleen de SSAA optie weer, of ik kijk ergens over heen?

Nvidia haalde zo ook rot streken uit met tesselation, omdat de AMD kaarten toen nog niet goed om konden gaan met tesselation, hd5000 series. Maar later was dat probleem ook weg toen AMD met de 6000 seties kwam. Ik kan er verder niets aan doen, maar krijg gewoon het gevoel hier dat AMD de shit is waat iedereen het mee moet doen is en NVIDIA zou een leugenaar zijn met veel fuile treken die je beter links kunt laten liggen. Daar stooor ik mij hier dus vooral aan. Maar goed ik wil geen flame war uitlokken en ook niet trollen
het gaa tmij hier vooral om eerlijkheid.

[ Voor 8% gewijzigd door Verwijderd op 25-03-2013 14:58 ]

[Sp3ci3s8472]

Verwijderd schreef op maandag 25 maart 2013 @ 14:55:
[...]


De games zelf zijn de bronnen. Maar met logisch nadenken kun je er wel van uit gaan dat AMD SSAA er in gooit om zo beter in benchnark uit te komen want AMD weet dat nvidia kaarten niet goed om gaan met SSAA.. Plus punt is dat er FXAA in de game van tombraider zit onder dx11. Die andere games geven mij mij alleen de SSAA optie weer, of ik kijk ergens over heen?

Nvidia haalde zo ook rot streken uit met tesselation, omdat de AMD kaarten toen nog niet goed om konden gaan met tesselation, hd5000 series. Maar later was dat probleem ook weg toen AMD met de 6000 seties kwam. Ik kan er verder niets aan doen, maar krijg gewoon het gevoel hier dat AMD de shit is waat iedereen het mee moet doen is en NVIDIA zou een leugenaar zijn met veel fuile treken die je beter links kunt laten liggen. Daar stooor ik mij hier dus vooral aan. Maar goed ik wil geen flame war uitlokken en ook niet trollen
het gaa tmij hier vooral om eerlijkheid.

Je snapt mijn punt niet, waarom zou AMD SSAA er in stoppen om er beter uit te komen bij de benchmarks? Dat is gewoon niet logisch, SSAA is een gimmick die alleen de snelste kaarten kunnen draaien. Mijn oude kaart kan dit ook niet in de genoemde titels zonder flinke framedrop het is gewoon alleen weggelegt voor de HD7970, de Titan en SLI/Crossfire setups.
Zowel Nvidia als AMD krijgen tenminste de optie, dat is bij physx niet zo (gpu versnelde).
Ik heb de games zelf trouwens niet dus als bepaalde opties wel aan of uit kunnen dan weet ik dat niet, dus schiet me daar niet op af .

Dat van de tesselation klopt niet helemaal, als jij een vierkante steen tot in de 32x tesseleerd dan gaat niemand dat zien dat is gewoon express de concurentie pesten. Dit gebeurde in Crysis 2, AMD heeft destijds uitgezocht hoeveel tesselation nodig is om het er goed uit te laten zien. Als je meerdere vertices hebt op een pixel dan ben je gewoon dom bezig en is het niet goed geimplementeerd.
AMD heeft al tijden een hardarematige tesselation unit op de gpu zitten (sinds de HD2xxx serie, daarvoor hadden ze TruForm), bij de HD6k serie zijn dat er 2 geworden. Nvidia doet dit via de shader units (cuda cores whatever), bij Crysis 2 is de tesselation gewoon zo hoog dat het net de tesselator van AMD bottlenecked op de 5k serie dat is gewoon vies spelen .

[Werelds]

Verwijderd schreef op maandag 25 maart 2013 @ 14:55:
Die andere games geven mij mij alleen de SSAA optie weer, of ik kijk ergens over heen?

Sniper Elite V2 heeft standaard FXAA aan staan. Het is echter ook FXAA, dus geweldig werkt het niet. Daarnaast kun je MLAA aanzetten door (en dit moet ik even uit het geheugen doen, moet je dus even naar zoeken) door iets van Compute Shaders aan te zetten, dan draait hij MLAA via DC.

Sleeping Dogs = High = FXAA, alleen de hoogste is FXAA + SSAA. Staat er gewoon bij in de tooltip.

Wil je eerlijk zijn dan mag je eens een feature opnoemen die niet werkt op Nvidia ondanks het feit dat de hardware het wel zou kunnen. TressFX werkt gewoon, op exact dezelfde manier als op AMD kaarten. Eyefinity/HD3D en Surround/3D tel ik hier niet in mee omdat in beide gevallen er geen duidelijke standaard is waar eender zich aan kan houden (passief vs. actief alleen al).

Sp3ci3s8472 schreef op maandag 25 maart 2013 @ 15:40:
Nvidia doet dit via de shader units (cuda cores whatever)

Nope. De polymorph engine bevat een tessellator, 1 per SM(X). Voor GF100/GF110 zijn dat er dus 16, voor GK104 zijn dat er 8 (die wel twee maal zo snel zijn geworden. Ze zijn een stuk kleiner dan die van AMD, maar ook minder krachtig per stuk. Over het geheel genomen kan Nvidia echter wel nog steeds meer tessellation hebben dan AMD

[Toettoetdaan]

Verwijderd schreef op maandag 25 maart 2013 @ 14:55:
[...]
De games zelf zijn de bronnen. Maar met logisch nadenken kun je er wel van uit gaan dat AMD SSAA er in gooit om zo beter in benchnark uit te komen want AMD weet dat nvidia kaarten niet goed om gaan met SSAA..

Hier verwijzen we naar een bron met een URL. Dus kappen met dat 'logisch nadenken' van je en gewoon even een bron hier plaatsen van een fatsoenlijke site.

Zeggen dat AMD SSAA in games stopt om beter uit de benchmarks te komen slaat echt nergens op. Ook slaat het nergens op om te zeggen dat nVidia kaarten niet goed om gaan met SSAA/

Als ik bijvoorbeeld zoek op "nVidia SSAA benchmark" zijn de eerste drie reviews:
1: http://www.anandtech.com/...x-670-review-feat-evga/10

At this point it’s not entirely clear why the GTX 600 series does so well here (both AMD and NV use SGSSAA), especially given the fact that the Radeons have a memory bandwidth advantage.

2: http://www.hardocp.com/ar...ard_review/6#.UVBl-hxRWZI

The new GeForce GTX 680 is able to also play at 8X MSAA plus FXAA at 2560x1600. However, it is able to go one step further. We were able to turn on NVIDIA's 4X Transparency Supersampling and still experience an average framerate above 60 FPS, even outperforming the HD 7970 which isn't using SSAA at all.

3: http://www.computerbase.d...vidia-geforce-gtx-680/14/
Ook hier zie je plus nummers voor nVidia, +5% +13% +13% en -14% tegenover een HD7970.

Dit zijn niet eens goede bronnen, een test die de focus legt op anti-aliasing technieken zou mooi zijn. Maar het is in ieder geval wat. Dus tenzij je bronnen hebt die het tegendeel bewijzen kun je beter stoppen met het posten van die beweringen die dit topic alleen maar vervuilen.

[nero355]

Werelds schreef op maandag 25 maart 2013 @ 14:33:
En nee, ATI was zeker niet altijd een heilig boontje (Quack 3 ).

Zo... dat is een oude uit de sloot halen Maar ik moest wel effe lachen omdat ik weet wat je bedoelt !! Thnx!

[Verwijderd]

Werelds schreef op maandag 25 maart 2013 @ 15:59:
[...]

Sniper Elite V2 heeft standaard FXAA aan staan. Het is echter ook FXAA, dus geweldig werkt het niet. Daarnaast kun je MLAA aanzetten door (en dit moet ik even uit het geheugen doen, moet je dus even naar zoeken) door iets van Compute Shaders aan te zetten, dan draait hij MLAA via DC.

Sleeping Dogs = High = FXAA, alleen de hoogste is FXAA + SSAA. Staat er gewoon bij in de tooltip.

Wil je eerlijk zijn dan mag je eens een feature opnoemen die niet werkt op Nvidia ondanks het feit dat de hardware het wel zou kunnen. TressFX werkt gewoon, op exact dezelfde manier als op AMD kaarten. Eyefinity/HD3D en Surround/3D tel ik hier niet in mee omdat in beide gevallen er geen duidelijke standaard is waar eender zich aan kan houden (passief vs. actief alleen al).

Jij hebt helemaal gelijk, het is indd FXAA met SSAA in sleeping dogs, en merk dat dat eingelijk meer voor sli of cf is die extreme SSAA in sleeping dogs.

Ik ben eerlijk en weet dat alle features wel op nvidia werkt alleen wel met het doel soms om nvidia kaarten te bottlenekken ook al is het een gimick want zo zijn AMD en nvidia, om elkaar de loef af te steken met instellingen die op de ander weer minder goed draaien.

Voorbeelden waar nvidia vaak sneller in kakt dan AMD zal ik zo laten zien.
Het zijn dan wel de AMD logo games.

Hier krijgt nvidia hard klappen vanwege SSAA in sleeping dogs
http://www.hardocp.com/ar...y_performance_iq_review/5

[ Voor 9% gewijzigd door Verwijderd op 25-03-2013 17:16 ]

[Werelds]

nero355 schreef op maandag 25 maart 2013 @ 17:02:
Zo... dat is een oude uit de sloot halen Maar ik moest wel effe lachen omdat ik weet wat je bedoelt !! Thnx!

Iedereen die niet acuut weet wat ik hier mee bedoel draait duidelijk nog niet lang genoeg mee of boeit het niet genoeg

Verwijderd schreef op maandag 25 maart 2013 @ 17:09:
Voorbeelden waar nvidia vaak sneller in kakt dan AMD zal ik zo laten zien.
Het zijn dan wel de AMD logo games.

Niemand van ons zegt dat AMD niet graag dingen als SSAA in games op het moment dat Nvidia dat niet aan kan. Het punt is echter dat SSAA een hele algemene techniek is die al jaren bestaat en dat het dus puur een performance issue is. Bij PhysX is dat gewoon niet zo omdat het gewoon sowieso al niet werkt vanwege software beperkingen (en dus te fixen) - sterker nog, ik denk dat AMD's VLIW5 structuur uitzonderlijk geschikt geweest zou zijn, omdat ze toch altijd capaciteit over hadden.

[SG]

Toettoetdaan schreef op maandag 25 maart 2013 @ 13:44:
Mijn vorige post was 90% sarcasme, misschien had ik dat even moeten vermelden. Maar deze vraag van jou vind ik wel leuk, dus daar zal ik even normaal op in gaan

[...]

nVidia wil dat juist heel graag, het zijn AMD en Intel die dat niet zien zitten, omdat CUDA en PhysX 'propriëtaire software' software is en dus geen niet open beschikbaar zoals bijvoorbeeld OpenCL.

AMD en Intel zitten er niet op te wachten dat ze licentie geld moetten betalen om CUDA en/of PhysX te ondersteunen terwijl ze geen volledige toegang tot de code hebben, of zelf geen verbeteringen mogen aandragen. In dat geval zouden ze betalen voor het ondersteunen van een product wat nooit zo goed draait op eigen hardware als bij nVidia zelf.
En daarom is CUDA en PhysX op de GPU nVidia only. Niet omdat nVidia speciale hardware heeft of omdat ze het voor zichzelf willen houden.
Bron: http://www.xbitlabs.com/n...ia_s_CUDA_Technology.html

Sterker nog nVidia heeft zelfs een hacker geholpen om PhysX draaiend te krijgen op de HD4800 serie, nadat hij het werkend kreeg op de HD3000 serie.
Bron: http://www.tomshardware.com/news/nvidia-physx-ati,5764.html
Bron2: http://www.tgdaily.com/ha...hysx-effort-on-ati-radeon

En daarom loont het om zo nu en dan een bron op te zoeken

Ja en je doet nu alsof ATI AMD de dwars ligger is. Maar je bronnen is ouwe 2008 Soap tussen iNtel war vs nV. Dat is 5 jaar terug.
NV zag toen, "de vijand van mijn godzilla vijand is mijn vriendje", en in die tijd was AMD ATI aan aankloten met R600 en was de G80 huge sucses en stond nV open voor breede GPGPU front tegen intel. En de larabee dreiging was er toen ook.

Dat is nu anders AMD heef enkele jaren zwaar nV geconcureerd op GPU gebied iNtel larabee geflopt. De situatie is nu heel anders. Dus beide moeten niks van mekaar hebben. Maar AMD gaat wel voor OpenCL.

Het verschil is dat ATI lam is onder AMD met hun vooruit sukkelende CPU tak. En dus niet wildt middleware kunnen op kopen. Ook niet agressief devs overhalen. Vooral niet met grote zakken geld. En niet zoon geld put kunnen aanhouden. Wat nV met cuda ontwikkelingen wel doet. Die investeren aanzienlijk.

Ten eerste is nV met hun agressieve twimtbp begonnen en AMD moest daar te laat ook mee beginnen met gitg.

Als je alle games optimaal wilt spelen moet je gewoon een intel cpu en PC met AMD en ander met nV.
De partijen kunnen per game nogal extreem reageren op gpu merk.

[Verwijderd]

Verwijderd schreef op maandag 25 maart 2013 @ 17:09:
[...]

Hier krijgt nvidia hard klappen vanwege SSAA in sleeping dogs
http://www.hardocp.com/ar...y_performance_iq_review/5

Je overdrijft en het is gewoon schattig dat je dat blijft doen. Als het waar is wat je zegt dan zou er geen enkel spel meer zijn waar AMD verliest met benchmarks maar je hebt er precies 1 (en op belachelijk hoge specs) kunnen vinden en met een revisie of 3 van de Nvidia drivers zal dat gat ook wel redelijk gedicht worden.

[VictordeHolland]

Krijg toch de indruk dat het wel erg offtopic gaat en weer richting het standaard Nvidia vs. AMD trolfestijn gaat .

Zijn er geen sappig geruchten over de 8xxx serie?

[SG]

Nou er is een discussie, en het is meer 8... Oem rebranding danmdatner wat nieuws is.
Gpgpu is de toekomst cpu en gpu worden nog extremer afhankelijk van concurent software algoritmes en software problemen op die manier op te lossen. SMP wordt een must. Ook APU de AMD GPU die redelijk mee kan doen op het gamers vlak. Bied nog meer mogelijk heden voor gpgpu als er ook een dedicated Gkaart in zit.

Je kan namelijk die on cpu GPU zien als een optie om dedicated gpgpu taken mee te doen terwijl de dedicated gkaart GPU puur het renderen doet.
De tools gaan ook die kant op het wordt toegankelijker en zeer transparant om voor GpGpu te programeren.
C++ AMP gebruikt de C++ taal en is standaard geintergreerd in MSV studio 2012. Geen gedoe met Excotische C like varianten. Die je met speciale libaries en methoden moet benaderen.

Het is jammer dat iNtel en nV de GPGPU revolutie op physc middleware om zeep hebben geholpen. Door het voor hun kar te spannen of het dwars te zitten. Jammer.

Ik mis HavokFX dat ook AMD GPU ondersteende maar is dood door iNtel. Rust in piece 2008

Sommigen misgeinformeerden meenden dat nV GPU een PPU on board hadden. Dat is niet zo. Het zijn de cuda cores die dat werk doen. De PPU is kwa architektuur opzet zeer lijkende op de CELL.
Je kan een APU dus zien als een CPU met een multi concurent deel dat je als schijnbare hardware bullit accelerator kan zien. Maar ja het zijn gewoon die unified shaders die het doen.

Kwa ontwikkeltools ziet het er wel goed uit op de lange termijn. Maar oo korte termijn blijven we met door iNtel en nV beheersde middelware zitten.

Als je als dev nu de tech voor games aanzienlijk wilt pushen inclusief een eigen inhouse game engine. Dan maak je gebruik van GPGPU voor je eigen inhouse developed physics en AI engine dmv OpenCL direct compute of C++ AMP.

Wat je dan krijgt is de physics load hoefd geen CPU mainstream load fallback noodloop te hebben. En waarbij massive concurent physics features disable zijn. Maar kan standaard een pool van shaders reserveren voor physics en daarmee de basis load voor physics een niveau hoger zetten. Ook kan wat nu beperkt is tot effect physics wel geimplementeerd worden als gameplay physics. De GPU eisen worden dan iets hoger. Want ook een misvatting GPGPU computing komt niet gratis. Wat rust op de misvatting van ppu on die fabeltjes.

De kern is dit Unified shaders doen dit. Niet en, maar of.
Vertecs of pixel of geo of generalpurpouse.
Dat laaste daar valt physics onder.
Een GPU thread manager verdeeld deze taken over de shader pools. En concureerd elke taak voor voor shaders.

Misschien dat GPGPU wat beter op gang komt nu de nextgen consoles beide een APU van AMD hebben.

[Astennu]

Verwijderd schreef op maandag 25 maart 2013 @ 10:46:
Maar de ps4 gaat dus physx ondersteunen maar vast ook havok.
Verder snap ik niet dat je er bij komt dat physx als stront door een trechter loopt.
Zoals de meeste physx games loopt het soepel en kost het niet veel extra fps
Ik ben het er wel mee eens dat het niet 100% eerlijk is voor mensen met een AMD kaart,
zoals de physx die in borderlands zit geven wel weer allemaal effecten tijdens explosies en
spetters die van inslaande kogels af vliegen. Het was beter geweest dat nvidia
er voor zorgde dat het zowel over de CPU werkt als de GPU.
Zo had AMD er voor moeten zorgen dat er meerdere AA ondersteunung zit in
amd gaming evolved, en niet alleen de extreem zware SSAA die erg op de geheugenbus leunt
waar nvidia kaarten dan erg in kakken en AMD kaarten het prima kunnen draaien.

Ik had bij borderlands 2 op mijn AMD kaart dezelfde PhysX als mensen met een nVidia kaart door een simpele config file hack. En het liep nog prima ook. PhysX werd dan gewoon op de CPU gedaan doe meer dan genoeg power over heeft.
nVidia wilt wel doen alsof het alleen maar met CUDA kan en snel genoeg is maar dat is niet waar.

Laten we AUB niet beginnen over wat AMD bij een game heeft gedaan. Als we de lijst van nVidia er bij gaan halen zijn we vandaag nog niet klaar.
Als er iemand is die open standaarden pushed is het AMD SSAA is gewoon iets wat nVidia ook prima kan.
Wat pas echt naai is is DX10.1 support uit een game laten slopen omdat nVidia zelf geen DX10.1 kaart had. Assasins creed liep ook prima op DX10 kaarten maar het had wat extra voordelen op DX10.1 kaarten. Dat was ook het hele doel van DX10.1: Een aantal dingen beter en efficiënter doen.

Verwijderd schreef op maandag 25 maart 2013 @ 13:23:
Sniper elite V2 en Sleeping dogs maar Tomb raider heeft er FXAA bij in zitten.
En dirt 3 is ook brak voor nvidia geoptimaliceerd omdat nvidia telkens pas later die code's krijgen om de game voor hun hardware te optimaliseren. Zo heeft nvidia nog steeds geen code gekregen voor Tombraider als ik het goed heb? Tomb raider draait nu verder wel goed met FXAA maar met SSAA aan komen er rare effecten in het haar en dropt de fps richting de 40fps en er word extreem veel videomemory gebruikt.

Je doet net of AMD hier nooit last van heeft. Bij 9 van de 10 games is het andersom omdat die TWIMTBP zijn.
Ik zou maar eens met echt goede argumenten en daarbij ook bewijs komen om je stellingen kracht bij te zetten. Want op deze manier kom je niet echt geloofwaardig over.

[ Voor 25% gewijzigd door Astennu op 26-03-2013 08:09 ]

[Atrevir]

Anandtech heeft een mooi artikel over de stutter problemen en hoe ze frame-times opmeten.
http://www.anandtech.com/...sues-driver-roadmap-fraps

[Toettoetdaan]

Atrevir schreef op dinsdag 26 maart 2013 @ 09:24:
Anandtech heeft een mooi artikel over de stutter problemen en hoe ze frame-times opmeten.
http://www.anandtech.com/...sues-driver-roadmap-fraps

Heel erg interessant artikel, ik ben nu ook wel benieuwd hoe Anand frame-times gaat testen.

[Verwijderd]

Astennu schreef op dinsdag 26 maart 2013 @ 08:04:
[...]


Ik had bij borderlands 2 op mijn AMD kaart dezelfde PhysX als mensen met een nVidia kaart door een simpele config file hack. En het liep nog prima ook. PhysX werd dan gewoon op de CPU gedaan doe meer dan genoeg power over heeft.
nVidia wilt wel doen alsof het alleen maar met CUDA kan en snel genoeg is maar dat is niet waar.

Laten we AUB niet beginnen over wat AMD bij een game heeft gedaan. Als we de lijst van nVidia er bij gaan halen zijn we vandaag nog niet klaar.
Als er iemand is die open standaarden pushed is het AMD SSAA is gewoon iets wat nVidia ook prima kan.
Wat pas echt naai is is DX10.1 support uit een game laten slopen omdat nVidia zelf geen DX10.1 kaart had. Assasins creed liep ook prima op DX10 kaarten maar het had wat extra voordelen op DX10.1 kaarten. Dat was ook het hele doel van DX10.1: Een aantal dingen beter en efficiënter doen.

Dat was toch een hack dat het over de cpu loopt maar dan lang niet zo goed als op de cpu vanwede de code?

Het gaat me er verder niet om wat amd en nvidia doen maar dat het altijd nvidia is hier en daar bala ik altijd een beetje van. Vingertjes weizen tewel de tegenpartij altijd het zelfde doet. Zelf ben ik iemand die naar alle 2 bedrijven met mijn vinger naar toe wijst, de een is dus niet beter vriendelijker dan de ander.

Misschien krijgen we wel met dx11.1 wel het zelfde weer omdat dat ook niet op nvidia kaarten zit hardwarematig, maar det betekent niet dat nvidia alleen maar dit soort gemene truukt uit halen.

Verwijderd schreef op dinsdag 26 maart 2013 @ 01:19:
[...]


Je overdrijft en het is gewoon schattig dat je dat blijft doen. Als het waar is wat je zegt dan zou er geen enkel spel meer zijn waar AMD verliest met benchmarks maar je hebt er precies 1 (en op belachelijk hoge specs) kunnen vinden en met een revisie of 3 van de Nvidia drivers zal dat gat ook wel redelijk gedicht worden.

Nee je mist gewoon mijn punt en er zijn meer maar moet ik dan gelijk alles op zoeken en SSAA zit niet in de meeste games.

[ Voor 21% gewijzigd door Verwijderd op 26-03-2013 11:30 ]

[Astennu]

Atrevir schreef op dinsdag 26 maart 2013 @ 09:24:
Anandtech heeft een mooi artikel over de stutter problemen en hoe ze frame-times opmeten.
http://www.anandtech.com/...sues-driver-roadmap-fraps

Extreem goed artikel! ik ben nog niet helemaal klaar maar ik heb nu al veel interessante dingen gelezen zoals dat fraps voor in de pipeline meet en dan heb je natuurlijk geen goed beeld. Dan kan het zijn dat fraps zegt dat alles er prima uit ziet en die frames later toch nog dusdanig vertragen dat je stutters krijgt. (nVidia is net als AMD van mening dat FRAPS geen goede tool is om Frame Latency te meten)

Ik vind het ook goed van AMD dat ze er over in gesprek zijn gegaan met Anandtech. Ik houd wel van bedrijven die open zijn naar goede websites en daar antwoorden geven op vragen en delen hoe zij tegen bepaalde dingen aankijken.

[ Voor 5% gewijzigd door Astennu op 26-03-2013 11:43 ]

[Atrevir]

Astennu schreef op dinsdag 26 maart 2013 @ 11:41:
[...]


Extreem goed artikel! ik ben nog niet helemaal klaar maar ik heb nu al veel interessante dingen gelezen zoals dat fraps voor in de pipeline meet en dan heb je natuurlijk geen goed beeld. Dan kan het zijn dat fraps zegt dat alles er prima uit ziet en die frames later toch nog dusdanig vertragen dat je stutters krijgt.

Ik vind het ook goed van AMD dat ze er over in gesprek zijn gegaan met Anandtech. Ik houd wel van bedrijven die open zijn naar goede websites en daar antwoorden geven op vragen en delen hoe zij tegen bepaalde dingen aankijken.

Jah dat zeker wel. Ik vind het wel mooi als een bedrijf gewoon in opengesprek gaat, en toegeeft waar het fout ging en zo. Vooral met een site zoals Anandtech. Heel erg interessant in ieder geval. Ik vond die frametime gebeuren toch al erg rommelig worden onderhand.

[Astennu]

Verwijderd schreef op dinsdag 26 maart 2013 @ 11:25:
[...]

Dat was toch een hack dat het over de cpu loopt maar dan lang niet zo goed als op de cpu vanwede de code?

Het gaat me er verder niet om wat amd en nvidia doen maar dat het altijd nvidia is hier en daar bala ik altijd een beetje van. Vingertjes weizen tewel de tegenpartij altijd het zelfde doet. Zelf ben ik iemand die naar alle 2 bedrijven met mijn vinger naar toe wijst, de een is dus niet beter vriendelijker dan de ander.

Misschien krijgen we wel met dx11.1 wel het zelfde weer omdat dat ook niet op nvidia kaarten zit hardwarematig, maar det betekent niet dat nvidia alleen maar dit soort gemene truukt uit halen.


[...]


Nee je mist gewoon mijn punt en er zijn meer maar moet ik dan gelijk alles op zoeken en SSAA zit niet in de meeste games.

Het zal best dat het een hack is. En eerlijk gezegd zou het zo maar kunnen dat het volledig op de CPU draait ipv op de GPU. Maar waar het om ging is dat de effecten identiek waren aan de nVidia CUDA versie en het presteerde ook prima. Kortom er was eigenlijk geen meerwaarde nVidia had het alleen uitgeschakeld zodat het leek alsof je bij BL2 alleen met nVidia kaarten dat soort effecten op het beeld kon krijgen en dat is dus niet waar.

Ze doen beide dingen of hebben dingen gedaan die niet netjes zijn. Alleen nVidia wat meer en recenter dan AMD. En dat zijn allemaal dingen waar met een simpele google search bronnen voor te vinden zijn.
Die SSAA van jou heb ik nog niet eerder gehoord en ben dus wel erg benieuwd naar je bron voordat ik het geloof. Zoals je hierboven kan lezen zijn er ook bronnen van dingen die ATi in het verleden gedaan heeft bronnen te vinden.

[Astennu]

Atrevir schreef op dinsdag 26 maart 2013 @ 11:43:
[...]


Jah dat zeker wel. Ik vind het wel mooi als een bedrijf gewoon in opengesprek gaat, en toegeeft waar het fout ging en zo. Vooral met een site zoals Anandtech. Heel erg interessant in ieder geval. Ik vond die frametime gebeuren toch al erg rommelig worden onderhand.

Inderdaad. Dit is een mooi stukje wat veel samenvat:

For our part, when we first went into our meeting with AMD we were expecting something a little more standoffish on the matter of FRAPS. Instead what we found was that we were in agreement on the same issues for the same reasons. As you, our readers are quick to point out, we do not currently do frame interval measurements. We do not do that because we do not currently have any meaningful tools to do so beyond FRAPS, for which we have known for years now about how it works and its limitations. There are tools in development that will change this, and this is something we’re hopefully going to be able to talk about soon. But in the meantime what we will tell you is the same thing AMD and NVIDIA will tell you: FRAPS is not the best way to measure frame intervals. There is a better way.

Finally, though we’ve just spent a great deal of time talking about FRAPS’ shortfalls when it comes to measuring frame intervals, we’re not going to dismiss it entirely. FRAPS may be a coarse tool, but even a coarse tool is going to catch big problems. And this is exactly what Scott Wasson and other reviewers have seen. At the very start of this odyssey AMD’s single-GPU frame interval problem was so bad that even FRAPS could see it. FRAPS did in fact “bust” AMD as it were, and for that AMD is even grateful. But as AMD resolves their problems and moves on to finer grained problems, the tools need to become finer grained too. And FRAPS as it currently is cannot make that jump.

While we’ve spent most of our discussion on tools discussing FRAPS and why both AMD and NVIDIA find it insufficient, there are other tools out there. AMD and NVIDIA of course have access to far better tools than we do, and people with the knowledge to use them. This includes their internal tools, tools that are part of their respective SDKs, and other 3rd party tools.

AMD’s tool of choice here actually comes from Microsoft, and it’s called GPUView.

Ik ben het er mee eens dat we nu op een punt zijn dat je FRAPS niet meer moet gebruiken. De grote problemen zijn weg en nu moet je andere tools hebben voordat je echt kan zeggen waar de fout zit en of de AMD of nVidia kaart het beter doet qua frametimes.

[ Voor 9% gewijzigd door Astennu op 26-03-2013 11:53 ]

[Toettoetdaan]

Verwijderd schreef op dinsdag 26 maart 2013 @ 11:25:
[...]

Dat was toch een hack dat het over de cpu loopt maar dan lang niet zo goed als op de cpu vanwede de code?

Nope, volgens mij is het sinds PhysX 3.0(Ik zou dat moeten nazoeken) dat het niet meer over de GPU hoeft, de performance is dan wel wat minder, maar als je 4core's of meer hebt is het vaak gewoon goed speelbaar. Op youtube zijn er best een aantal voorbeelden te vinden zoals deze: YouTube: Borderlands 2 - PhysX on AMD (Opgenomen op een HD6850 met een i5 2500k)

Hier heeft iemand CPU PhysX vs GPU PhysX getest op een i7 2600K en een GTX580:

Bron: http://physxinfo.com/news...ndling-the-physx-effects/
Low/medium is gewoon goed speelbaar, maar voor high heb je wel echt een GPU nodig.

Het gaat me er verder niet om wat amd en nvidia doen maar dat het altijd nvidia is hier en daar bala ik altijd een beetje van. Vingertjes weizen tewel de tegenpartij altijd het zelfde doet. Zelf ben ik iemand die naar alle 2 bedrijven met mijn vinger naar toe wijst, de een is dus niet beter vriendelijker dan de ander.

Misschien krijgen we wel met dx11.1 wel het zelfde weer omdat dat ook niet op nvidia kaarten zit hardwarematig, maar det betekent niet dat nvidia alleen maar dit soort gemene truukt uit halen.

Haha wat dacht je dan, dat dit het nVidia lovers topic is?

Maar even serieus, als je alles gaat opsommen, dan kun je twee conclusies trekken: Of AMD verbergt sommige dingen beter, óf nVidia doet af en toe gekke dingen.

[...]

Nee je mist gewoon mijn punt en er zijn meer maar moet ik dan gelijk alles op zoeken en SSAA zit niet in de meeste games.

Nope, jij haalt een benchmark aan waar de reviewer de hoogste setting van de game op 2560x1600 of fullHD test.

This is the highest setting the game is capable of

Dat slaat al nergens op en daarbij zie je niet ineens de performance van de nVidia kaart opvallend omhoog gaan bij tests waar SSAA lager staat.
Ook ondersteund de game gewoon FXAA dus dat "AMD alleen SSAA in games stopt" ondersteun je ook niet met deze bron...

(En maak je post eens gewoon in één keer af, nu had ik twee keer andere quotes staan dan dat je uiteindelijk gepost hebt )

[Werelds]

Toettoetdaan schreef op dinsdag 26 maart 2013 @ 12:01:
Nope, volgens mij is het sinds PhysX 3.0(Ik zou dat moeten nazoeken) dat het niet meer over de GPU hoeft, de performance is dan wel wat minder, maar als je 4core's of meer hebt is het vaak gewoon goed speelbaar.

Het heeft nooit en te nimmer over de GPU en/of PPU *gemoeten*. Het heeft altijd op de CPU gekund, alleen liet Nvidia dat met veel effecten niet toe - . Belangrijker nog, zoals ik nu al tig keer heb aangegeven, is pas sinds 2.8.6 + APEX 1.2 (waar een deel optimalisaties uit 3.0+ zitten) de CPU performance een beetje acceptabel. BL2 heeft toevallig juist die combinatie, dus vandaar dat het bij Astennu wel aardig loopt.

Met Sandy/Ivy (waar je de laatste tijd dit veel op ziet en dan met name ook op de 4C/8T varianten ) zijn de < 2.8.6/APEX 1.2 dingen ook nog wel te behapstukken, maar de CPU load is zelfs in BL2 nog hoger dan het zou hoeven te zijn.

En voordat er iemand begint: er zijn pas 2 games echt uit met PhysX 3.0 of hoger. Dat is Planetside 2 - afgelopen maand terug ingebouwd, nadat ze het uit de beta hadden gehaald vanwege bugs en performance issues. Daarnaast is er Natural Selection 2, dat ook de nodige problemen heeft gehad. Alle andere games zijn in beta of aangekondigd, maar nog niet uit.

[ Voor 15% gewijzigd door Werelds op 26-03-2013 12:19 ]

[Toettoetdaan]

Werelds schreef op dinsdag 26 maart 2013 @ 12:15:
[...]

Het heeft nooit en te nimmer over de GPU en/of PPU *gemoeten*. Het heeft altijd op de CPU gekund, alleen liet Nvidia dat met veel effecten niet toe - . Belangrijker nog, zoals ik nu al tig keer heb aangegeven, is pas sinds 2.8.6 + APEX 1.2 (waar een deel optimalisaties uit 3.0+ zitten) de CPU performance een beetje acceptabel. BL2 heeft toevallig juist die combinatie, dus vandaar dat het bij Astennu wel aardig loopt.

Met Sandy/Ivy (waar je de laatste tijd dit veel op ziet en dan met name ook op de 4C/8T varianten ) zijn de < 2.8.6/APEX 1.2 dingen ook nog wel te behapstukken, maar de CPU load is zelfs in BL2 nog hoger dan het zou hoeven te zijn.

Nope, een CPU is een alleskunner dus daar heeft de beperking nooit gezeten

Maar ik dacht dat multi-core ondersteuning pas in PhysX 3.0 zal, of hebben ze die al in 2.8.6 ingevoerd?
En dan heb je natuurlijk nog het hele instructieset verhaal... Maar misschien is dat meer voor een ander topic.

[Verwijderd]

Toettoetdaan schreef op dinsdag 26 maart 2013 @ 12:01:
[...]


(En maak je post eens gewoon in één keer af, nu had ik twee keer andere quotes staan dan dat je uiteindelijk gepost hebt )

Ik probeer dat altijd wel maar ik krijg later altijd weer nieuwe ideën er bij of ik vergeet weer wat.
Gelukkig bestaat er daar voor quote, ik zal er zeker geen misbruik van maken.

Ik hou verder op over die SSAA want ik heb daar geen bronen voor.

Kortom physx moet gewoon altijd over de CPU want dat kan makkelijk en dan is het ook eerlijker voor
de mensen met een AMD kaart.

[ Voor 18% gewijzigd door Verwijderd op 26-03-2013 12:35 ]

[Toettoetdaan]

Verwijderd schreef op dinsdag 26 maart 2013 @ 12:33:
[...]


Ik probeer dat altijd wel maar ik krijg later altijd weer nieuwe ideën er bij of ik vergeet weer wat.
Gelukkig bestaat er daar voor quote, ik zal er zeker geen misbruik van maken.

Ik denk dat alle technische mensen daar een beetje last van hebben

Kortom physx moet gewoon altijd over de CPU want dat kan makkelijk en dan is het ook eerlijker voor
de mensen met een AMD kaart.

Nou, sommige dingen zijn kunnen behoorlijk profiteren van GPU acceleration, maar in der daad, persoonlijk denk ik dat PhysX en vergelijkbare zaken voornamelijk op de CPU zou moeten draaien en dat de onderdelen die kunnen profiteren van de GPU door de GPU wordt uitgevoerd.

[Werelds]

Toettoetdaan schreef op dinsdag 26 maart 2013 @ 12:21:
[...]

Nope, een CPU is een alleskunner dus daar heeft de beperking nooit gezeten

Maar ik dacht dat multi-core ondersteuning pas in PhysX 3.0 zal, of hebben ze die al in 2.8.6 ingevoerd?
En dan heb je natuurlijk nog het hele instructieset verhaal... Maar misschien is dat meer voor een ander topic.

Nou technisch gezien kan PhysX < 2.x ook multithreading doen, alleen moeten de developers dat dan expliciet in programmeren, wat dus het hele punt van middleware gebruiken tegen gaat, want dan kost het je nog bijna even veel tijd. 2.8.4.6 + APEX 1.2 (let op, deze combinatie is heel belangrijk, want APEX 1.2 bevat enkele PhysX 3.x modules die backwards compatible zijn) gebruikt wel eindelijk SSE instructies, hoewel het nog steeds niet loopt zoals het kan. Multithreading is wel pas automatisch in 3.x helaas

In PS2 loopt het allemaal wel aardig nu (was in de beta wel anders, ze hadden 3.1 echt nodig ) en als dit nu de standaard wordt kan ik er wel mee leven als er wat TWIMTBP titels blijven. Het is nog steeds geen Havok, maar het is op z'n minst diarree door een trechter in plaats van dikke stront

Ik blijf er echter bij dat ik Havok nu een grote opmars zie gaan maken, want ik kan me niet voorstellen dat ze nu met de nieuwe consoles achter willen blijven. Ze hebben al meer dan eens laten zien dat ze met OpenCL heel goed uit de voeten kunnen en aangezien alles (nou ja, Nvidia niet, maar die volgen wel als de rest het wel kan) OpenCL 1.2 gaat ondersteunen met alle features daarin, ben ik er vrij zeker van dat ze HavokFX (waarvan SG denkt dat het dood is, hoewel het op consoles gebruikt wordt) nu nieuw leven in blazen. Het hoeft niet allemaal op de CPU en het hoeft ook niet identieke performance te hebben op Nvidia en AMD, dat kan gewoon niet. Maar met OpenCL en/of DirectCompute kun je in elk geval aan beide kanten een flinke boost krijgen door de GPU te gebruiken en dat gaat met PhysX simpelweg niet gebeuren

[ Voor 7% gewijzigd door Werelds op 26-03-2013 13:10 ]

[Help!!!!]

Astennu schreef op dinsdag 26 maart 2013 @ 11:41:
[...]


Extreem goed artikel! ik ben nog niet helemaal klaar maar ik heb nu al veel interessante dingen gelezen zoals dat fraps voor in de pipeline meet en dan heb je natuurlijk geen goed beeld. Dan kan het zijn dat fraps zegt dat alles er prima uit ziet en die frames later toch nog dusdanig vertragen dat je stutters krijgt. (nVidia is net als AMD van mening dat FRAPS geen goede tool is om Frame Latency te meten)

Ik vind het ook goed van AMD dat ze er over in gesprek zijn gegaan met Anandtech. Ik houd wel van bedrijven die open zijn naar goede websites en daar antwoorden geven op vragen en delen hoe zij tegen bepaalde dingen aankijken.

Helemaal eens!

Heb het inmiddels uit en het maakt een hoop complexe zaken ook behoorlijk duidelijk voor de niet-technische lezer. We wisten natuurlijk al dat e.e.a. complexer was en fraps waarschijnlijk zijn beperkingen had maar zo is het begrijpelijker.

Het is mooi om te zien dat reviewsites er voor zorgen dat de userexperience beter wordt.

Ook kan ik me AMD's frustratie, dat ze dit gemist hebben terwijl nvidia dit wel doorhad, en dat ze éasy performance winst tijdenlang hebben laten liggen, goed voorstellen!!!!

Het spreekt voor AMD dat ze hier open over zijn. Toch ook verbazingwekkend dat AMD het niet doorhad

[Astennu]

Help!!!! schreef op dinsdag 26 maart 2013 @ 13:22:
[...]

Helemaal eens!

Heb het inmiddels uit en het maakt een hoop complexe zaken ook behoorlijk duidelijk voor de niet-technische lezer. We wisten natuurlijk al dat e.e.a. complexer was en fraps waarschijnlijk zijn beperkingen had maar zo is het begrijpelijker.

Het is mooi om te zien dat reviewsites er voor zorgen dat de userexperience beter wordt.

Ook kan ik me AMD's frustratie, dat ze dit gemist hebben terwijl nvidia dit wel doorhad, en dat ze éasy performance winst tijdenlang hebben laten liggen, goed voorstellen!!!!

Het spreekt voor AMD dat ze hier open over zijn. Toch ook verbazingwekkend dat AMD het niet doorhad

Inderdaad! Petje af voor AMD voor de openheid en het toegeven. Het is heel wat voor een bedrijf om toe te geven dat je er een tijd flink naast hebt gezeten en belangrijke dingen over het hooft gezien hebt.
Maar ze zijn ook goed opweg met het oplossen er van.

Daarnaast is het stukje over MultiGPU ook heel interessant. Aangezien AMD het probleem probeert op te lossen op een manier waardoor het bij FRAPS lijkt dat het erger wordt. En waar ze nu de gebruikers dus de optie willen geven om te switchen tussen de twee mogelijke manieren voor het oplossen van het probleem. En dat vind ik een nog veel betere zaak!

Dan kun je gewoon zelf kijken wat je prettiger vind en ga je dat gebruiken. Ik ben ook benieuwd naar de nieuwe tools die nu in ontwikkeling zijn. Zodra die er zijn moeten we snel van fraps af gaan stappen want het laat nu geen volledig beeld zien.

Maar een erg mooi artikel waar je met basis kennis toch snapt waar iedereen het nu over heeft en waar het probleem vandaan komt. (omdat het goed uitgelegd wordt).

[Verwijderd]

Kunnen frame times niet getest worden via een soort van opname via een film met een camera, dan zit je ok niet met software die misschien wel een vertekend beeld laat zien. Met msi afterburner kun je de frame times ook zien maar dat is ook weer een programma die op de achtergrond draaid.

[Cobiwan]

Help!!!! schreef op dinsdag 26 maart 2013 @ 13:22:
[...]

Helemaal eens!

Heb het inmiddels uit en het maakt een hoop complexe zaken ook behoorlijk duidelijk voor de niet-technische lezer. We wisten natuurlijk al dat e.e.a. complexer was en fraps waarschijnlijk zijn beperkingen had maar zo is het begrijpelijker.

Het is mooi om te zien dat reviewsites er voor zorgen dat de userexperience beter wordt.

Ook kan ik me AMD's frustratie, dat ze dit gemist hebben terwijl nvidia dit wel doorhad, en dat ze éasy performance winst tijdenlang hebben laten liggen, goed voorstellen!!!!

Het spreekt voor AMD dat ze hier open over zijn. Toch ook verbazingwekkend dat AMD het niet doorhad

Hopen dat ze die easy performance winst nu wel snel gaan benutten...

[dcm360]

Verwijderd schreef op dinsdag 26 maart 2013 @ 14:32:
Kunnen frame times niet getest worden via een soort van opname via een film met een camera, dan zit je ok niet met software die misschien wel een vertekend beeld laat zien. Met msi afterburner kun je de frame times ook zien maar dat is ook weer een programma die op de achtergrond draaid.

Daar ga je het niet op kunnen zien, schermen doen altijd aan een vaste refreshrate.

[Verwijderd]

Verwijderd schreef op dinsdag 26 maart 2013 @ 11:25:
[...]

SSAA zit niet in de meeste games.

En jij mist de mijne , het maakt geen bal uit hoe je een framebuffer functie onderbouwd en of dat nou sneller gaat of niet, je blijft gewoon doorgaan op iets wat geen issue is.

Dit is jou standpunt , ik heb Nvidia en Nvidia moet de snelste zijn.

Als iets onnozels als sleeping dog sneller is nou dan heeft AMD er geld voor betaalt en het verschil 7 frames per second on average.

Je pretendeert dat het wat uitmaakt of dat het belangrijk is en dat is het niet

Now we wanted to run the single-GPU GeForce GTX 680 and Radeon HD 7970 GHz Edition at 1080p but with the "Extreme" AA Quality setting. We wanted to know if at this lower resolution these video cards would give us a playable experience.


The graph above shows that it certainly does not. The GTX 680 is averaging below 30 FPS, and the HD 7970 GHZ Edition is averaging 35 FPS. Both were not playable at all, even at 1080p using the "Extreme" AA Quality setting.


This really goes to show it is going to take a powerful next generation video card to make this game playable at "Extreme" setting

en om het gegeven te laten zien dat je er gewoon helemaal naast zit gedeelte in vetgedrukt speciaal voor jou.

[Verwijderd]

Nee hoor nvidia hoeft helemaal niet voor mij het snelste te zijn zolang ik maar normaal mijn games kan spelen vind ik het geen punt, sneller is niet altijd beter ook. In mijn geval heb ik een reldelijk hoge resolutie en dat probleem ligt dan ook bij mij. Niet zo happen want dat maakt je niet mooi zo

dcm360 schreef op dinsdag 26 maart 2013 @ 14:55:
[...]

Daar ga je het niet op kunnen zien, schermen doen altijd aan een vaste refreshrate.

Jammer, zou wel willen weten met wat voor technieken het wel kan.

[ Voor 39% gewijzigd door Verwijderd op 26-03-2013 16:31 ]

[Sp3ci3s8472]

dcm360 schreef op dinsdag 26 maart 2013 @ 14:55:
[...]

Daar ga je het niet op kunnen zien, schermen doen altijd aan een vaste refreshrate.

Je kan dit misschien hacken met een custom resolutie die een refreshrate heeft van 200 hertz. Dit sluit je aan een non existent monitor (capture apparatuur).

Maar deed een van de reviewers dat niet ene Scott Wason van techreport?

Artikel van Anandtech is echt heel goed, een aanrader . Maakt ook meteen duidelijk waarom fraps geen goede tool is om microstuttering te meten.
Ik zou het mooi vinden als AMD de user de keus laat tussen microstuttering of input lag, ik heb liever wat meer microstuttering dan input lag maar dat is natuurlijk een persoonlijke preferentie en ook de reden waarom ik nooit met vsync speel .

[Help!!!!]

^
Fraps is niet perse een slechte tool. Het heeft immers ook de recente issues aan het licht gebracht.
Het issue is dat alleen aan de "voorkant" gemeten wordt. Dat kan een goede voorspeller zijn maar je weet het niet zeker als je niet ook aan de "achterkant" meet....

[Sp3ci3s8472]

Help!!!! schreef op dinsdag 26 maart 2013 @ 19:11:
^
Fraps is niet perse een slechte tool. Het heeft immers de recente issues aan het licht gebracht.
Het issue is dat alleen aan de "voorkant" gemeten wordt. Dat kan een goede voorspeller zijn maar je weet het niet zeker als je niet ook aan de "achterkant" meet....

Ik bedoelde ook niet dat het een slechte tool is, maar voor een meer diepgaande analyse van microstuttering is het nutteloos. Je kan hooguit een voorspelling maken wanneer je microstuttering zal krijgen.

[Verwijderd]

Is het crossfire de frame times ook beter dan bij een enkele kaart?
Het lijkt namelijk ook erg van de fps afhankelijk te zijn. Hogere fps geven minder frame times.
Tenminste bij mij wel. Zonde sli heb ik rond de 20ms en met sli 13 ms in battlefield 3 met
afterburner

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

[AquaSheep]

Bij PC Perspective lijken ze een andere manier te hebben gevonden om frame intervals te kunnen meten. Het verschil is dat de meting plaats vindt aan de output kant van de GPU.

[dcm360]

Sp3ci3s8472 schreef op dinsdag 26 maart 2013 @ 18:01:
[...]


Je kan dit misschien hacken met een custom resolutie die een refreshrate heeft van 200 hertz. Dit sluit je aan een non existent monitor (capture apparatuur).

Dat is nog steeds naar. Stel je haalt 199 frames per seconde op jouw virtuele 200Hz monitor, dan zal je 1 frame meten met een dubbel zo lange rendertijd vergeleken met de andere 198 frames. Je wil dus geen vast meetinterval, maar een meting doen precies op het moment dat een frame klaar is.

[deraco96]

Wat is het probleem met meten vanaf een monitor? Voor een eindgebruiker is dat ideaal, wat ík wil is namelijk gewoon een zo stabiel mogelijke stroom frames, of die nou 10ms of 1ms komen voor mijn monitor klaarstaat maakt dan in feite weinig uit. Voor AMD's techneuten is waarschijnlijk wel meer kennis nodig.

[Toettoetdaan]

Verwijderd schreef op dinsdag 26 maart 2013 @ 19:37:
Is het crossfire de frame times ook beter dan bij een enkele kaart?
Het lijkt namelijk ook erg van de fps afhankelijk te zijn. Hogere fps geven minder frame times.
Tenminste bij mij wel. Zonde sli heb ik rond de 20ms en met sli 13 ms in battlefield 3 met
afterburner

Frame-time is de tijd die nodig is om een frame te renderen tussen frames, dus het is in der daad fps afhankelijk

Zo had jij zonder SLI 50FPS en met SLI 77FPS in BF3.
(1000 milliseconde / frame-time in milliseconde = frames per seconde)

[ Voor 1% gewijzigd door Toettoetdaan op 27-03-2013 00:05 . Reden: Dank aan Werelds ]

[dcm360]

deraco96 schreef op dinsdag 26 maart 2013 @ 20:53:
Wat is het probleem met meten vanaf een monitor? Voor een eindgebruiker is dat ideaal, wat ík wil is namelijk gewoon een zo stabiel mogelijke stroom frames, of die nou 10ms of 1ms komen voor mijn monitor klaarstaat maakt dan in feite weinig uit. Voor AMD's techneuten is waarschijnlijk wel meer kennis nodig.

Wat je wil hebben, is dat de hardware een constante stroom frames kan aanleveren.

Om mijn voorbeeld met 199f/s op een 200Hz scherm er nog even bij te pakken.
Je meet dat 1 frame 2 keer getoond wordt. Dat is vervelend. Je wil weten of dit komt doordat de hardware er 1 keer niet in geslaagd is om in dezelfde tijd als de andere 198 frames een frame te renderen, of dat de rendertijd wel hetzelfde is maar door de beperking van de interface naar het scherm het frame net niet op tijd was. Het eerste wijst op problemen, het 2e is meer een geval van pech hebben. Je kan echter niet vaststellen welke van de 2 situaties er speelt, want je weet met deze meetmethode niet hoe lang de videokaart over de frames rekent.

Anders verwoord: Je kan wel naar de gevolgen gaan kijken, maar daar leg je de oorzaak van het probleem niet mee bloot.

[Werelds]

Toettoetdaan schreef op dinsdag 26 maart 2013 @ 21:08:
[...]

Frame-time is de tijd die nodig is om een frame te renderen, dus het is in der daad fps afhankelijk

Zo had jij zonder SLI 50FPS en met SLI 77FPS in BF3.
(1000 milliseconde / frame-time in milliseconde = frames per seconde)

Nope

Wat Afterburner weergeeft is de tijd tussen de frames - niet de tijd die nodig was om het frame te renderen!

Bij Crossfire en SLI neemt elke GPU onafhankelijk van de ander een frame voor z'n rekening. Voor zover die GPU weet draait hij dus gewoon single. De twee GPU's in zo'n opstelling zijn ook niet sneller dan een enkele GPU apart, dus ze *kunnen* niet sneller renderen. Wel is het zo dat als de een klaar is, de ander al bezig is, dus de frames volgen elkaar sneller op.

Dus waar No pain no gain 20ms nodig heeft om een frame te renderen, is dat met SLI nog steeds zo. Alleen is op het moment dat die 20ms om zijn, het volgende frame alweer half klaar. Je ziet nu ook meteen dat er een aardige overhead zit, in een ideaal geval zou Afterburner 10ms weergeven; dat is immers de perfecte overlapping. In plaats daarvan zit er een extra 3ms in

Onthoudt bij deze dingen heel goed dat voor zover het de GPU's betreft, een multi-GPU opstelling geen flikker uitmaakt wat betreft het renderen. Ze zijn zich simpelweg niet van elkaar bewust en doen onafhankelijk van elkaar hun werk. Je kunt de frames alleen parallel renderen waardoor je er meer frames per seconde uit kunt poepen, maar de GPU's renderen nog steeds even snel (of traag, het is maar hoe je het bekijkt ).

[pino85]

Edit:

NVM oud nieuws was al gemeld ( anandtech artikel wat hier boven werd genoemd)
Moet zeggen dat ik nu ik me meer heb ingelezen over het stotter probleem ik het wel meer lijk te merken als ik game en er dus last van heb terwijl ik dat van te voren minder had .. of ja ik dacht dit hoort zo maar dat hoort dus eigenlijk niet zo

[ Voor 205% gewijzigd door pino85 op 26-03-2013 22:20 ]

[Verwijderd]

Werelds schreef op dinsdag 26 maart 2013 @ 21:24:
[...]

Toevoeging wat er staat in afterburner.

•Added frametime graph to hardware monitoring module. The graph is displaying the maximum frame time on each sampling period and it is useful for detecting microstutters, which are invisible on averaged framerate graph.

Verder merk ik dat sli een soepelere gameplay geeft omdat ik met een enkele kaart te weining fps haal om nog soepel voor het oog te zijn. Die Frame times verschilllen ook aardig per game moet ik zeggen. Pak ik bvb battlefield 3 single player dan haal ik 5ms zonder fps lock en die 13ms was in mulipalyer met de fps gelockt op 70fps

[Astennu]

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


Toevoeging wat er staat in afterburner.

•Added frametime graph to hardware monitoring module. The graph is displaying the maximum frame time on each sampling period and it is useful for detecting microstutters, which are invisible on averaged framerate graph.

Verder merk ik dat sli een soepelere gameplay geeft omdat ik met een enkele kaart te weining fps haal om nog soepel voor het oog te zijn. Die Frame times verschilllen ook aardig per game moet ik zeggen. Pak ik bvb battlefield 3 single player dan haal ik 5ms zonder fps lock en die 13ms was in mulipalyer met de fps gelockt op 70fps

Dat is ook het idee achter SLi en CF. Maar in sommige gevallen waar je last hebt van microstuttering heb je met 80 fps geen soepel game play. En waar zelfs een 45 fps draaiende single kaart dan soepeler aan voelt. Het is niet altijd zo maar soms heb je er last van. Ook is het niet bij alle games even storend. Bij Race games merk ik het bv veel sneller dan bij RTS games.

Dit is voor mij een rede geweest om geen CF/SLI meer te gebruiken. Als ze dit probleem bijna helemaal opgelost krijgen ga ik het wel weer een keer proberen ik denk dat het wel minder gaat worden nu er zo veel aandacht aan besteed wordt.

[Cobiwan]

http://nl.hardware.info/n...kaarten-voor-cloud-gaming

AMD heeft vandaag op het Game Developers Conference 2013 de nieuwe reeks Radeon Sky videokaarten geïntroduceerd. Deze kaarten zijn specifiek bedoeld voor servers gericht op cloud gaming.

De Radeon Sky kaarten zijn gebaseerd op de Radeon HD 7000 reeks. De kaarten zijn specifiek bestemd voor rack servers. Ze zijn daarom van zichzelf passief gekoeld met een open koelblok, waardoor ze mee kunnen liften op de koeling die standaard in 2U-servers aanwezig is. De kaart zijn bedoeld voor cloud gaming: servers die games renderen en de beelden als videostream via internet doorsturen naar tablets, laptops en desktops. AMD gelooft heilig in deze hard groeiende markt van cloud gaming: door de rendering van 3D-games op een server te doen kunnen complexe games ook gespeeld worden op relatief simpele apparaten als tablets en kunnen games als service (lees: als abonnementsdienst) verkocht worden.

De Radeon Sky reeks bestaat in eerste instantie uit drie modellen. De Radeon Sky 900 is gebaseerd op twee Tahiti GPU's en heeft 3584 stream processors en 6 GB geheugen. De Radeon Sky 700 is gebaseerd op een enkele Tahiti chip met 1792 ingeschakelde stream processors en eveneens 6 GB geheugen. Het instap model is de Radeon Sky 500, gebaseerd op een Pitcairn chip met 1280 stream processors en 4GB geheugen.

Tijdens de presentatie demonstreerde AMD de cloudgaming dienst van CiiNOW, waarmee verschillende games via internet te spelen zijn. Hoewel we over de beeldkwaliteit niet erg te spreken waren - te verklaren door gebrekkige videocompressie - viel de latency juist erg mee: een game afkomstig van een server blijkt (vrijwel) net zo soepel te draaien als rechtstreeks op een PC.

[spNk]

nieuws: AMD komt met Sky Graphics voor cloudgaming

?

[Cobiwan]

Overheen gelezen

[SpankmasterC]

AMD is de prominente "Hardware Partner" voor Battlefield 4, mooi binnengesleept!
https://battlelog.battlefield.com/bf4/preorder/

[Astennu]

Daar is i weer!:



Blijft een mooie kaart
Als ze dat CF eens snel fixen wordt het nog leuk

In juni of juli kwam er een driver waar je meer controle hebt over het hele frame latency verhaal. Dus dan wordt het pas echt leuk

[Help!!!!]

Vervolg Anandtech Frame Testing met FCAT tool:

http://www.anandtech.com/...erval-benchmarking-part-1

Speaking more directly however, FCAT is quite simply the frame interval analysis tool we have long wanted. It is the tool that will enable us to analyze stuttering, micro-stuttering, and more, in a manner consistent with our benchmarking methods and core beliefs in the scientific method. It’s exceedingly rare that we say this, but we haven’t been this excited by a new benchmarking tool in a very long time.

Wrapping things up, we will be following up this article next week with part 2 in our look at FCAT. In part 2 we will go into further detail about how to analyze the results FCAT generates, and what we’re finding across a range of video cards and games, both in single-GPU and multi-GPU configurations. So until then, stay tuned.

Ben benieuwd. Hopelijk doen ze ook een compare met een oudere (amd) driver.

Ook interessante opmerkingen in de comments trouwens....

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

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

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

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

[ Voor 106% gewijzigd door Help!!!! op 27-03-2013 17:00 ]

[deraco96]

't Is ook echt een gigantisch lange kaart... Ach dat heeft ook wel weer wat, heb je er tenminste weer eens wat aan dat behuizingen 45 cm ruimte bieden hè.

[Splinter Cell]

@AMDGaming
AMD and @EA demoed #Battlefield4, powered by the AMD Radeon HD 7990 at #gdc2013 today! #AMDGDC

https://twitter.com/AMDGaming/status/316912846527160321

[Toettoetdaan]

Help!!!! schreef op woensdag 27 maart 2013 @ 15:29:
Vervolg PCPER: Frame Rating Dissected: Full Details on Capture-based Graphics Performance Testing:

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

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

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

Extreem interessant artikel! Dit laat echt het 'FRAPS probleem' zien, en ook een oplossing!
Ook briljant dat ze met 'Observet FPS' komen:


Ook wordt erg duidelijk wat het stuttering probleem van AMD is!
Jammer dat nVidia's 'metering' functionaliteit niet uit kan, zodat ze SLI en CF beter kunnen vergelijken.

[Help!!!!]

^
Inderdaad zeer interessant.

Zeker de dual GPU AMD kaarten zijn vooralsnog obv dit artikel een grote no-go helaas. Lullig voor de 7990 en erg hard voor de CF bezitters....
Wel jammer dat de tests niet met de laatste beta driver zijn maar denk niet dat die het verschil al maakt.

Qua single GPU is de 7970GE momenteel in principe de beste keus dus dat is weer positief voor AMD