GZDoom benchmark info needed

Discuss anything ZDoom-related that doesn't fall into one of the other categories.
Post Reply
_mental_
 
 
Posts: 3820
Joined: Sun Aug 07, 2011 4:32 am

Re: GZDoom benchmark info needed

Post by _mental_ »

My mistake, I loaded GZDoom with doom2.wad :(
Results for P:AR from the same GeForce 650M on OS X 10.9:
Spoiler: Classic Renderer, OpenGL 2.1
Spoiler: Modern Renderer, OpenGL 4.1
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49252
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: GZDoom benchmark info needed

Post by Graf Zahl »

Here's the link for the new test build:

http://www6.zippyshare.com/v/41974177/file.html

@mental: Thanks. It's really too bad that Apple skipped OpenGL 3.0. All my tests show that without persistently mapped buffers, immediate mode is still the fastest way to render stuff that consists of large amounts of low-vertex-count draw calls.
The new test build offers different methods:

- immediate mode (obviously not on MacOSX due to lack of compatibility profile)
- uniform arrays (that's what the last test build had)
- buffer uploads for each draw call
- map/unmap buffer for each draw call

After I have the results from the next round of tests I hopefully get some ideas how to optimize this for better performance on GL 3.x hardware.
User avatar
Enjay
 
 
Posts: 27397
Joined: Tue Jul 15, 2003 4:58 pm
Location: Scotland
Contact:

Re: GZDoom benchmark info needed

Post by Enjay »

For info, the download doesn't include the GLEW32.DLL file.

Here are my test results. I noticed that you left your ini in the zip so, other than changing screen mode/resolution, I used your settings.

FrozenT
Spoiler:
PAR
Spoiler:
Computer specs as before (with the GTX 760).
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49252
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: GZDoom benchmark info needed

Post by Graf Zahl »

Well, didn't I say that I don't need GL 4.x results? You essentially tested the 'good' render path 3 times. What I need is the tests for the 'bad' render path for older hardware.

BTW, you left vsync on making the results mostly useless. The left-in .ini was an accident. Please ignore.
User avatar
Enjay
 
 
Posts: 27397
Joined: Tue Jul 15, 2003 4:58 pm
Location: Scotland
Contact:

Re: GZDoom benchmark info needed

Post by Enjay »

I did wonder if vsync was left on or not (especially when I saw the PAR results) but didn't actually check. Given that you don't need my results though, I'll not bother re-running the tests (although on a quick check I'm getting around 245 fps with the PAR save).
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49252
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: GZDoom benchmark info needed

Post by Graf Zahl »

Yes, that sounds more like it. Your results don't help me because they very closely mirror my own setup. What I need is info from different hardware. Currently most important are:

- first and second generation GL 3.x cards from NVidia (Geforce 8xxx, 9xxx or GTX 2xx)
- first and second generation GL 3.x cards from AMD (Radeon 4xxx and 5xxx, if I'm not mistaken)
- Intel GMA 3000.

Before going on I need to know how the different render methods perform on these systems.
User avatar
VGA
Posts: 506
Joined: Mon Mar 28, 2011 1:56 am

Re: GZDoom benchmark info needed

Post by VGA »

Here it is on my c2d e8400 @ 3.3ghz, gtx260, 4gb RAM
Nvidia driver version is 337.88
I used default settings at my native resolution of 1680x1050

Here are the bench results for gl_rendermethod at 0,1,2,3:
Frozen Time save:
Spoiler:
Voxel map save:
Spoiler:
On the voxel map everything got distorted at values 2 and 3, here are some screenshots:
Spoiler:
Spoiler:
I don't see a savegame for P:AR so I didn't test that one.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49252
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: GZDoom benchmark info needed

Post by Graf Zahl »

What IWAD did you load it with? doom.wad or doomu.wad. The savegame requires doom.wad, if you use doomu.wad it won't work.

As for the voxel map visual problems, I'll wait with an investigation until I get results from other systems. By now it seems to be clear that both methods are too slow, at least on NVidia hardware.
User avatar
VGA
Posts: 506
Joined: Mon Mar 28, 2011 1:56 am

Re: GZDoom benchmark info needed

Post by VGA »

Oops i was trying with doom2.wad. My Ultimate Doom is doom.wad, but no probs.

First with loading only PAR.wad:
Spoiler:
Then with lights.pk3 and brightmaps.pk3 and PAR.wad:
Spoiler:
Blue Shadow
Posts: 5046
Joined: Sun Nov 14, 2010 12:59 am

Re: GZDoom benchmark info needed

Post by Blue Shadow »

Going by VGA's results, the two new rendering methods seem to be ridiculously slow when compared with the other two. The "immediate" method is significantly better.

Interestingly, the two new methods are performing relatively better in the voxel test than in FrozenT and PAR.
User avatar
VGA
Posts: 506
Joined: Mon Mar 28, 2011 1:56 am

Re: GZDoom benchmark info needed

Post by VGA »

Maybe because the rendering ... broke!
User avatar
GFD
Posts: 347
Joined: Mon May 31, 2010 7:42 pm
Preferred Pronouns: He/Him
Location: Canada
Contact:

Re: GZDoom benchmark info needed

Post by GFD »

Here's a whole bunch more benchmarks from my GeForce 9200. Hopefully they're useful. Just used default settings again (except not in fullscreen).

Bench's startup log
FrozenT: latest dev, rendermethod O, 1, 2, 3
PAR: latest dev, rendermethod O, 1, 2, 3
PAR (lights): latest dev, rendermethod O, 1, 2, 3
zdoom_vox: latest dev, rendermethod O, 1, 2, 3

For some reason, putting URL tags around a 0 changes the 0 into the URL?? Whatever.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49252
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: GZDoom benchmark info needed

Post by Graf Zahl »

Blue Shadow wrote:Going by VGA's results, the two new rendering methods seem to be ridiculously slow when compared with the other two. The "immediate" method is significantly better.

Interestingly, the two new methods are performing relatively better in the voxel test than in FrozenT and PAR.

Those new methods are what is supposed to be the way things should be done in GL 3.x, i.e. using buffers to store the vertices.

This is truly insane. GZDoom has such a low vertex to drawcall ratio and at the same time a relatively high amount of draw calls plus an unstable set of vertices that it's hopelessly inefficient to transition 1:1. I already knew that the current implementation is useless at least on NVidia, but before moving on I really need some data for AMD and Intel to decide how to proceed.
Does nobody here use AMD and Intel? I already got all the numbers I need for NVidia but none for the other two.

The reason it has such a lower impact on the voxel map is that voxels, as they are models, can be stored in a static vertex buffer (let's disregard for now that there's a bug somewhere in there) which do not break down with buffer upload delays. But even there with the low amount of map geometry it clearly shows its problems.

@gamefreakdude:

I have to admit that these numbers really do bother me. It means that even under best circumstances the new version is slower on such old hardware than the old one. Arrrgghhh.
_mental_
 
 
Posts: 3820
Joined: Sun Aug 07, 2011 4:32 am

Re: GZDoom benchmark info needed

Post by _mental_ »

I just wanted to do a quick check, but the latest benchmark fails on fragment shader compilation.
Spoiler: Important part of the log
Drivers are very old, I know. But because of crappy switchable graphics I cannot update them. Actually, these drivers are the latest available from vendor.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49252
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: GZDoom benchmark info needed

Post by Graf Zahl »

WTF!?!

Since when does full openGL need a precision qualifier? I thought they were solely for GLES. I know that my driver would fail to compile if I added them, I already experienced that with work stuff.
Also no idea where the 'varying' comes from. None of the shader sources still contains that word.
Post Reply

Return to “General”