'DirectX 10.1 toepassen is triviaal voor ontwikkelaars'

Ja, nogal wiedes: het aantal polygonen gaat omhoog! Er wordt meer werk gedaan, en dan duurt dat langer. Bij OpenGL is het proces dus GPU-bound, de kaart wordt optimaal ingezet. Dat is precies waar deze paper over gaat.

MIsschien moet je de paper iets duidelijker lezen.
Bij OpenGL zie je bv deze twee uitersten:
150.000 batches/sec bij 10 triangles/batch
110.000 batches/sec bij 200 triangles/batch

Even uitrekenen:
respectievelijk 1.500.000 tris/sec en 22.000.000 tris/sec.
Ook bij OpenGL zit er dus een enorm verschil in throughput aan de hand van de batchgrootte. Er zit dus bijna een factor 15 verschil tussen throughput van 10 tris/batch en 200 tris/batch.
En jij wil beweren dat de GPU optimaal ingezet wordt? Nee, OpenGL is bij kleine batches slechts marginaal beter.
De geteste GPU is een GeForce4 Ti4600, deze kan theoretisch 136Mtri/sec, dus OpenGL zit in het geval van 22MTris/sec nog steeds ruim een factor 6 van het optimale af.
GPU-bound? Absoluut niet dus.

Ok... Waarom kom je er dan mee als voorbeeld? Hij was dus wel geldig toen je dacht dat hij jouw viewpoint ondersteunde, en nu dat niet zo blijkt te zijn is hij plotseling te oud? Lekkere manier van discussieren, dat...

Hij ondersteunt mijn punt juist wel. Ik geef alleen aan dat dit probleem al heel lang speelt, en GPUs nu nog veel hogere theoretische throughput hebben, dus het probleem nog veel erger is geworden (zoals de paper ook al uitlegt).

Het kan net zo goed gestegen zijn tot vele malen hoger dan het nivo van DirectX, maar zonder het te meten gaan we het niet weten. Dus je speculatie gaat helemaal nergens over.

Dat zou niet logisch zijn. De bottleneck is de CPU, en de kloof tussen CPU en GPU is nu nog veel groter dan 4 jaar geleden.

Ik vermoed, maar ik kan het natuurlijk verkeerd hebben, dat ik er veel en veel meer van weet dan jij.

Dat denk ik wel ja.
Ik heb er een hekel aan om een CV te moeten gaan posten... Maar omdat jij me weinig keus laat...
Ik heb onder andere een visualisatie-module geschreven voor een deel van het CAD-pakket Hydroman van Paro Engineering (in OpenGL):
http://www.paro-nl.com/hydromansoftware.html
Verder heb ik voor mijn master aan de TU Delft een caustic raytracer geschreven in Java:
http://scali.scali.eu.org/caustic/demo.html
Ik heb een software-rendered 3d engine in Java geschreven voor de demoscene (compleet met oa texture filtering, multitexturing, per pixel lighting, shadowmapping en skinning):
http://www.pouet.net/prod.php?which=10808
En ik experimenteer in m'n vrije tijd nog weleens wat met Direct3D, waarvan ik wat resultaten post op een forumpje van Bohemiq:
http://bohemiq.scali.eu.org/forum/viewforum.php?f=4
Intussen is die engine ongeveer uitgegroeid tot de mogelijkheden van een Doom3 of FarCry (flexibele material-support, volledig shader-gebaseerd, support voor stencil shadows en shadowmaps, vertex skinning, realtime reflecties etc, en nog wat extra effectjes zoals CSG en isosurface rendering), en ben ik nu de overgang naar DX10 aan het voorbereiden.

Geheel onervaren ben ik dus niet, waar het OpenGL, Direct3D, software rasterizing danwel raytracing aangaat.
Verder heb ik goede contacten met oa de game-industrie vanwege mijn demoscene-verleden. Oa Mikko Kallinen, de lead-programmeur van FutureMark is een goede vriend van mij (we gaan terug tot het Amiga-tijdperk in de scene), en hij heeft me veel bijgebracht over Direct3D. Mijn skinned stencilshadows werken dan ook volgens dezelfde GPU-based methode die 3DMark03 ook gebruikt, en is daarom veel minder CPU-heavy dan Doom3.

De OpenGL versie was significant sneller dan de DirectX versie, hoewel de applicatie an sich hetzelfde gebleven was.

Dat kan ja. OpenGL is dan ook de Visual Basic van de 3D-APIs.
Omdat het op zo'n hoog niveau werkt, kunnen mensen met weinig kennis er relatief goede code mee schrijven.
Direct3D staat dichter bij de hardware, wat betekent dat je zelf veel meer verantwoordelijk bent voor batching, efficient configureren van resources etc.
Als het significant sneller is, betekent dat simpelweg dat de Direct3D-code niet goed op de hardware aansloot. Er zijn genoeg games en andere benchmarks die bewijzen dat de API op zich weinig of geen invloed heeft op de prestaties van de hardware, mits goed gebruikt.

Als ik zie hoe weinig jij begrijpt van het batching-probleem, en blijkbaar niet eens kunt narekenen hoe inefficient OpenGL in dit geval is, kan ik niets anders dan concluderen dat jij niet echt zicht hebt op hoe de hardware werkt. Ik ben veel meer lowlevel ingesteld, net als veel van mijn demoscene/game-ontwikkel-collega's. Zal wel de jarenlange ervaring zijn. Velen van ons gaan terug tot de begintijd van 3d-graphics op personal/homecomputers, en schreven al 3d-engines in software op Amiga of 386/486.

1. Developers stappen niet massaal over op DX10. Er is nog geen enkel stuk DX10 software aangekondigd. Hoogstens hebben DX<lager> spellen een codepath erbij om wat DX10 effecten op het scherm te toveren. Developers zouden tenslotte wel gek zijn om ineens 95% van de PC markt buiten te sluiten, daar gaat dan ook 95% van hun inkomsten.

Met overstappen bedoel ik natuurlijk niet dat ze DX9 en lager negeren (dat zou commercieel gezien niet slim zijn). Ik bedoel dat ze ook de nieuwe technologie van DX10 gebruiken, in plaats van bij DX9 blijven, danwel overstappen naar OpenGL.

2. Developers hebben uiteraard al een lange investering in een bepaalde codebase, en die willen ze natuurlijk niet 1-2-3 omgooien. Dat is een volkomen legitieme reden, en daar sta ik ook helemaal achter. Dat zegt echter niets over de vermeende superioriteit van de onderliggende API's.

Ware het niet dat game-engines altijd 'wegwerp-engines' zijn. Ze worden eenmalig ontwikkeld, en daarna wordt bijna from scratch een nieuwe engine ontwikkeld. Meestal wordt hier dan ook de overstap gemaakt naar een nieuwere API (iedere D3D-ontwikkelaar kan je vertellen dat de overgang van de ene D3D-versie naar de andere nogal wat voeten in de aarde heeft, een overstap van D3D naar OpenGL zou niet moeilijker worden, en zelfs meer continuiteit garanderen, omdat OpenGL qua API ongewijzigd blijft. Slechts nieuwe extensies dienen zich aan).

3. De keuzes van mensen, zeker in groepen, is vaak meer gebaseerd op wat de kudde doet dan op wat verstandig is.

Behalve dan dat de game-industrie een miljarden-industrie is, waarin de creme de la creme van ontwikkelaars werkt. Dat is even wat anders dan een bedrijfje dat een website klust. Keuzes worden dan ook veel beter doordacht en verantwoord.
De kern van de industrie is ook niet zo heel groot. Er is maar een handvol toonaangevende engines. De kleinere ontwikkelaars nemen gewoon een licentie.
Sprake van kuddegedrag bij de kern van de industrie is er dan ook niet.

Let's face it, OpenGL is gewoon een erg goede API die heel veel problemen van heel veel mensen zou oplossen als ze het zouden gebruiken.

Dat zeer zeker. Maar hetzelfde kan gezegd worden van DX10.

[Reactie gewijzigd door ddbruijn op woensdag 15 augustus 2007 09:26]