Snelheid van de Software Z-buffer

Gebruiker

Offline

Berichten: 34

[Gepost op:]

Hallo allemaal,

Zoals jullie weten heb ik een software Z-buffer gemaakt, die in staat is 3D te tekenen.
De normale versie tekent alleen maar volledig gevulde driehoeken. Nu heb ik ook een wireframe versie gemaakt. (wireframe ziet er zo uit):

In mijn Z-buffer demo zit een kubus en met de wireframe versie laat ik dezelfde kubus zien.
Alleen wat blijkt: wireframe gaat maar een klein beetje sneller.
Ik heb een i5 6200U (en kloksnelheid was 2.2 GHz tijdens testen) en kreeg de volgende resultaten:
-volledige Z-buffer: 4 FPS
-Wireframe: 7 FPS
-Wireframe (zonder z-buffer): 7 FPS

Dit zijn niet de resultaten die ik had verwacht.
De wireframe versie gaat letterlijk alleen de lijnen tekenen en heeft dus 90~80% minder pixels om af te gaan. Ook zijn er minder variabelen nodig.
Het raarste is toen ik alle Z-buffer calls weghaalde en merkte dat de FPS niet verbeterde.
Ik zou denken dat de Z-buffer calls naar het RAM (en ik doe er zelfs twee) een groot verschil maken...

Ik vraag me dus behoorlijk af hoe dit mogelijk is.
Ik vermoed dat GML misschien restricties legt op resources, of dat draw_pixel_color limieten brengt.

Gebruiker


Offline

Berichten: 3512

[Antwoord #1 Gepost op:]

draw_pixel is sowieso heel langzaam. Per-pixel operaties zijn juist iets waar de GPU heel goed in is, en de CPU veel minder goed.

Daarnaast is de GM8 runner ook niet echt snel. Wat je zou kunnen doen om te achterhalen waar het probleem zit, is de high resolution timer gebruiken om delen van je code te timen. Dan kan je vergelijken in welk deel de meeste tijd wordt gebruikt.

Gebruiker

Offline

Berichten: 34

[Antwoord #2 Gepost op:]

draw_pixel is sowieso heel langzaam. Per-pixel operaties zijn juist iets waar de GPU heel goed in is, en de CPU veel minder goed.

Heh je laat het klinken alsof een CPU wel goed is in het tekenen van grote blokken (draw_rectangle)  .
Nee in mijn code maakt het verschil CPU/GPU niet uit.
Zelfs al zou ik de GPU kunnen aanroepen, kan de GPU niets in parallel uitvoeren, de code is namelijk niet parallel.

Off-topic: Ik heb een texture variant gemaakt met draw_get_pixel. Je kan je wel voorstellen dat die 0.1 FPS gaat.

Daarnaast is de GM8 runner ook niet echt snel. Wat je zou kunnen doen om te achterhalen waar het probleem zit, is de high resolution timer gebruiken om delen van je code te timen. Dan kan je vergelijken in welk deel de meeste tijd wordt gebruikt.

Wat bedoel je met niet echt snel? Slechte compiler?
Ik zie nu dat GML interpreted is. Zou dit het probleem zijn?
Trouwens, ik heb alle draw code in de endstep staan. Maakt dit uit?
De tests die ik draaide, leek het er niet op...

Ik ga nog wel naar die timer kijken.

Gebruiker


Offline

Berichten: 3512

[Antwoord #3 Gepost op:]

Nee in mijn code maakt het verschil CPU/GPU niet uit.
Zelfs al zou ik de GPU kunnen aanroepen, kan de GPU niets in parallel uitvoeren, de code is namelijk niet parallel.

Zou je het scherm niet kunnen opsplitsen in kleine stukken, en ieder van die stukken apart berekenen? (Denk niet dat dat in GM gaat lukken, maar in theorie zou je dan met een 4-core CPU het 4x zo snel kunnen doen)

Wat bedoel je met niet echt snel? Slechte compiler?
Ik zie nu dat GML interpreted is. Zou dit het probleem zijn?

Dat is zeken een deel van het probleem. Daarbovenop gaat GM8 ook nog eens heel slecht om met geheugen (code wordt gerepresenteert als een reusachtige boomstructuur, dus weg is je cache locality). En dan zijn er ook nog dingen als dit:

GML:

var a;
a[0,0] = 5
a -= 1

Dat is volledig correcte GML, en betekent dus dat GM er nooit vanuit kan gaan dat als je "a -=" schrijft, die "a" dan ook een getal is.

Trouwens, ik heb alle draw code in de endstep staan. Maakt dit uit?
De tests die ik draaide, leek het er niet op...

Voor GM8 maakt het iig niet uit waar je je draw-code zet. In GM:Studio wel.