GZDoom benchmark info needed
-
Kappes Buur
-
- Posts: 4201
- Joined: Thu Jul 17, 2003 12:19 am
- Graphics Processor: nVidia (Legacy GZDoom)
- Location: British Columbia, Canada
- Contact:
Re: GZDoom benchmark info needed
Same thing with PAR.wad and zdoom_vox.zip as Blue Shadow.
- Attachments
-
- gzdoom_1-8-06-benchmarks.txt
- (10.8 KiB) Downloaded 39 times
-
- gzdoom_bench-benchmarks1.txt
- (10.78 KiB) Downloaded 33 times
-
Kappes Buur
-
- Posts: 4201
- Joined: Thu Jul 17, 2003 12:19 am
- Graphics Processor: nVidia (Legacy GZDoom)
- Location: British Columbia, Canada
- Contact:
Re: GZDoom benchmark info needed
After renaming the map to MAP01, I did the tests for zdoom_vox.zip with the opening view:
Spoiler:
- Attachments
-
- gzdoom_bench-zdoom_vox-benchmarks.txt
- (10.77 KiB) Downloaded 37 times
-
- gzdoom_1-8-06-zdoom_vox-benchmarks.txt
- (10.8 KiB) Downloaded 36 times
-
Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49252
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: GZDoom benchmark info needed
@BlueShadow: What driver version are you using? It looks a bit outdated to me. AMD should have GL 4.4 by now and you are missing one crucial extension for the test build to work well. You are falling back to the 3.x render path which seems to slow things down a lot. And it's utterly amazing how efficient AMD is at destroying all their card's power with bad drivers. Their drivers create some insane overhead in places where NVidia is lightning fast.
Well, anyway, that's precisely what I feared. The core profile in 3.x is useless for doing highly dynamic stuff because there's just no good method to upload large amounts of small geometry quickly enough to the hardware. The feature to do this well (persistently mapped buffers) was only added in 4.4 with an extension for older hardware - but you are missing this extension. Nothing else I tried so far comes even close to the performance of the trusty old immediate mode that everybody claims to be obsolete.
On my Geforce 550Ti the test build is 20% faster, btw. The values I get resemble those of Kappes Buur, although I got a significantly faster CPU and a somewhat weaker GPU.
The entire things is utterly frustrating. If I fully migrate to 3.x I'd have to use a compatibility profile to keep things efficient - which means that the MacOS port gets cut off because Apple has 3.x only as core profile. Stupid crApple...
I'll upload another test build later that will allow a few more options (like being able to start in both compatiblity and core profile.) and fixed savegames.
Well, anyway, that's precisely what I feared. The core profile in 3.x is useless for doing highly dynamic stuff because there's just no good method to upload large amounts of small geometry quickly enough to the hardware. The feature to do this well (persistently mapped buffers) was only added in 4.4 with an extension for older hardware - but you are missing this extension. Nothing else I tried so far comes even close to the performance of the trusty old immediate mode that everybody claims to be obsolete.
On my Geforce 550Ti the test build is 20% faster, btw. The values I get resemble those of Kappes Buur, although I got a significantly faster CPU and a somewhat weaker GPU.
The entire things is utterly frustrating. If I fully migrate to 3.x I'd have to use a compatibility profile to keep things efficient - which means that the MacOS port gets cut off because Apple has 3.x only as core profile. Stupid crApple...
I'll upload another test build later that will allow a few more options (like being able to start in both compatiblity and core profile.) and fixed savegames.
-
Blue Shadow
- Posts: 5046
- Joined: Sun Nov 14, 2010 12:59 am
Re: GZDoom benchmark info needed
According to DxDiag, the driver version is 13.151.0.0 and is dated 4/1/2014. Though, these are Windows drivers(?), WDDM or whatever they're called. I'm not really sure.Graf Zahl wrote:What driver version are you using?
Spoiler:There are still no new drivers from the manufacturer's site of my laptop. Generic drivers are incompatible, so I can't go that way.
-
Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49252
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: GZDoom benchmark info needed
OK, so much for that. Too bad that you are basically screwed. Your laptop manufacturer must be some lazy ass. This driver is almost a year old. (And a very clear indicator for: Never buy stuff that won't work with a generic driver. You WILL be screwed over with such hardware.)
Re: GZDoom benchmark info needed
I'm worried... will this eventually mean that less players are going to be able to use GZDoom? :(
-
GFD
- Posts: 347
- Joined: Mon May 31, 2010 7:42 pm
- Preferred Pronouns: He/Him
- Location: Canada
- Contact:
Re: GZDoom benchmark info needed
The way I see it, hopefully more players will start getting some modern hardware. Including me, frankly.
-
NeuralStunner
-
- Posts: 12328
- Joined: Tue Jul 21, 2009 12:04 pm
- Preferred Pronouns: No Preference
- Operating System Version (Optional): Windows 11
- Graphics Processor: nVidia with Vulkan support
- Location: capital N, capital S, no space
- Contact:
Re: GZDoom benchmark info needed
Which for laptop users would mean "new computer entirely". For the most part, they're non-upgradable.gamefreakdude wrote:The way I see it, hopefully more players will start getting some modern hardware.
-
Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49252
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: GZDoom benchmark info needed
I intend to keep a minimum requirement of OpenGL 3.0. That was the first GL version with a good shading language so for what I need it will remain sufficient.Nash wrote:I'm worried... will this eventually mean that less players are going to be able to use GZDoom?
Yes, it might mean that some die-hard-upgrade refusers will be left out, but last time I checked Steam's hardware survey these were less than 3% of all users that participated.
Do not forget that this will concern NVidia and ATI cards 8 years and older (and long abandoned by their manufacturers with a market share close to zero already) and some bottom of the barrel Intel integrated chipsets.
None of these users would benefit from further engine enhancements which will inevitably rely on shaders so ultimately not much will be lost. This hardware is so weak that it'd cause serious performance issues with maps like P:AR already - and for plain vanilla maps, the current 1.8.6 will remain good enough for many years to come.
This benchmark was primarily about seeing how a pure core profile implementation would perform without persistently mapped buffers. Not surprisingly, the answer was 'like shit'.
So, obviously I'll go back to the compatibility profile where I still have the highly efficient
(at least for this particular usage scenario) immediate mode and things will be faster, and I also can reinstate some other stuff that'd require expensive shader additions to work as intended with a core profile.
Re: GZDoom benchmark info needed
Try the leshcat drivers, They're "specific" for notebooks with intel and amd gpus (and well, they're the only one that works here :s)Blue Shadow wrote:According to DxDiag, the driver version is 13.151.0.0 and is dated 4/1/2014. Though, these are Windows drivers(?), WDDM or whatever they're called. I'm not really sure.Graf Zahl wrote:What driver version are you using?Spoiler:There are still no new drivers from the manufacturer's site of my laptop. Generic drivers are incompatible, so I can't go that way.
http://leshcatlabs.net/
Re: GZDoom benchmark info needed
I was able to test Glew_Version_For_Real branch on OS X 10.9, OpenGL 4.1. Turned off my old OpenGL 2.1 stuff and with minor fixes in shaders (texture2D -> texture), it shows the picture finally. Advanced features are still untested, I just loaded MAP01Graf Zahl wrote:The entire things is utterly frustrating. If I fully migrate to 3.x I'd have to use a compatibility profile to keep things efficient - which means that the MacOS port gets cut off because Apple has 3.x only as core profile. Stupid crApple...
However, there is a lot of things left to do to make it ready for end users.
-
Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49252
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: GZDoom benchmark info needed
What ab out performance?
The biggest problem was to deal with the large amount of buffer updates. And they can be slow.
The biggest problem was to deal with the large amount of buffer updates. And they can be slow.
Re: GZDoom benchmark info needed
Results for Frozen Time, everything be default, 'bench' three times in a row.Graf Zahl wrote:What ab out performance?
The biggest problem was to deal with the large amount of buffer updates. And they can be slow.
Classic is the original GZDoom from master branch. Modern is the same but from Glew_Version_For_Real.
Spoiler: Classic Renderer
Spoiler: Modern RendererThe game didn't see the saved game for P:AR. The saved game for Voxels didn't load with 'Expected to extract a compressed file'. I'll check them later.
-
Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49252
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: GZDoom benchmark info needed
Sorry for the delayed response, I was in vacation for the last few days.
I find it strange that the PAR savegame isn't found. Are you loading it with 'doom.wad' or 'doomu.wad'? On my system it gets displayed properly, using 'doom.wad'.
I'll upload a new test version shortly but I can already lay out the testing procedure.
I added a CVAR to enable different render methods with buffers to see which one is fastest on different hardware.
Like last time there's the same WADs - the voxel mod has been changed so that the savegame can load.
I need the following tests:
Frozen Time
PAR without lights
PAR with lights
Voxel test map
with both the latests official version or dev build, and this test build. The test build has a new CVAR, called gl_rendermethod. This can have values from 0-3. I need to have this test run with all 4 values.
Last but not least: If your graphics driver reports OpenGL version 4.4, don't bother to run the test. I know it's fine on modern hardware, I just need some info what to optimize in the fallback code for older GPUs.
I find it strange that the PAR savegame isn't found. Are you loading it with 'doom.wad' or 'doomu.wad'? On my system it gets displayed properly, using 'doom.wad'.
I'll upload a new test version shortly but I can already lay out the testing procedure.
I added a CVAR to enable different render methods with buffers to see which one is fastest on different hardware.
Like last time there's the same WADs - the voxel mod has been changed so that the savegame can load.
I need the following tests:
Frozen Time
PAR without lights
PAR with lights
Voxel test map
with both the latests official version or dev build, and this test build. The test build has a new CVAR, called gl_rendermethod. This can have values from 0-3. I need to have this test run with all 4 values.
Last but not least: If your graphics driver reports OpenGL version 4.4, don't bother to run the test. I know it's fine on modern hardware, I just need some info what to optimize in the fallback code for older GPUs.
Re: GZDoom benchmark info needed
When you post the test build I will test it on my gtx260 which is 3.3