[Survey] How many of you CANNOT run GZDoom's OpenGL renderer

[Nash]

Can we expect to see some performance improvements to the model rendering now that GZDoom is ditching old OpenGL support? Or any additional features like alpha on model textures?

Or is this entire endeavour purely under the hood and won't be noticable for most users... ?

[Graf Zahl]

Can we expect to see some performance improvements to the model rendering now that GZDoom is ditching old OpenGL support? Or any additional features like alpha on model textures?

Some optimization benefits may be noticable. But do not expect miracles. Alpha is not tricky because the hardware cannot do it but because sorting the geometry is too costly. This hasn't changed.

The test build has its own load of problems, for example, it requires those modern features to work, which for an actual release is out of the question. It was a good means, though, to see, what features are useful and what aren't.
I can't speak for AMD and Intel but on NVidia one thing became obvious immediately: only 1% of the entire time was spent dispatching draw calls, so optimizing this for reduction - which would severely affect how the engine has to work - has become low priority. After having transitioned I have to see how I can reduce CPU-side processing time. Optimizing the batches would probably cost more in CPU maintenance than it saves in draw call dispatching.

As for why:

The relatively recent GL_ARB_buffer_storage and GL_ARB_shader storage_buffer_object are the first time that GL offers some decent means to transfer larger amounts of data between CPU and GPU without getting stalled by the driver. I already tested with glBufferSubData and temporarily mapped buffers but both methods have such insane overhead that they completely fail in GZDoom's usage scenario. Immediate mode is always faster - on my Geforce it's significanlty faster. With persistently mapped buffers (GL_ARB_buffer_storage) and larger buffers (Shader storage objects can be magnitudes larger than uniform buffers) it suddenly becomes feasible to rewrite the engine to ditch immediate mode if they are supported. Of course, since both features require modern hardware, the immediate mode code still needs to be kept around.

But I decided to remove shader support for pre GL3.x hardware. Keeping shader support here would require so many compromises on more modern hardware that it's not worth bothering with anymore. This will lead to minor compromises. The fullscreen colormaps like invulnerability will be done with simpler means, like just inverting the screen without desaturating the color and the very rarely used desaturation has been disabled on these old cards. Both features could be made to work but are severely polluting the lighting code. So with them out it allowed me to make some significant simplifications to the lighting code which will certainly add some flexibility. For example, it's no longer necessary to disable brightmaps in fog which was only necessary because the lighting for the shader based rendering had the same limitations as the fixed function code.


@ibm5155:

Concerning AMD:
I didn't know that 'readonly' requires enabling another extension. My Geforce didn't complain. You can quickly fix this yourself by removing the keyword in 'shaderdefs.i'. I'll investigate whether it makes sense to keep it in. I just thought that declaring it readonly may lead to performance gains.

Concerning Intel:
Your driver doesn't seem to be the latest. HD 4000 should have GL 4.0. I still wouldn't expect it to work, so far I got no confirmation that the two extensions are supported on that hardware.
The final version will not require them, though. This was merely a test build to see how it handes performance.

[ibm5155]

well, the amd driver version is:04/25/2014, 14.100.0.0000 and the intel driver version is the:10.18.10.3574

Hmm It looks like intel isn't the latest driver, but I'm afraid to touch it, since the notebook shares both gpu, and let's say they're not best friends, I tried to install amd drivers a long time and it failed to run '-'...
The only working drivers that I found was that guys:http://leshcatlabs.net/2014/05/11/leshc ... nifl-v1-3/

nop, acording to intel, it's the latest ivy bridge driver...

EDIT: just for informations

EDIT 2:
I think who can run that gzdoom version will be able to run this
https://www.youtube.com/watch?v=lwFVlNytq0Q

[Graf Zahl]

The AMD just complains about using a feature without requiring an extension that it deems necessary. If you remove the 'readonly' keyword it should be ok.
Which is strange. The 'readonly' keyword is clearly mentioned in the GL_ARB_shader_storage_buffer extension. Seems AMD missed that. I think this is a driver bug.

[ibm5155]

yup, AMD opengl drivers sucks, sometimes Intel opengl driver works better than amd one O_o

[ibm5155]

Well, I remvoed the readonly and It loaded, but I got a fatal error '-'
here's the edited code

Code: Select all

layout(std430, binding = 2) buffer AttribBuffer
{
	Attr Attribs[];
};

layout(std430, binding = 3) buffer ParameterBuffer
{
	vec4 Parameters[];
};

[Gez]

How can that be 4x as slow as my Core i7?

Turns out it was because the laptop was in energy savings mode. Since I seldom play levels as complex as Frozen Time, I didn't really notice. On "Entertainment" setting, FPS are doubled.

Code: Select all

Map MAP01: "entryway",
x = 4676.2854, y = 5956.6655, z = 369.0000, angle = 90.3790, pitch = -1.3348
Walls: 14600 (0 splits, 2007 t-splits, 197291 vertices)
Flats: 537 (24549 primitives, 108130 vertices)
Sprites: 708, Decals=0, Portals: 1
W: Render=6.277, Split = 0.000, Setup=4.396, Clip=5.159
F: Render=2.431, Setup=0.132
S: Render=0.230, Setup=1.510
All=49.578, Render=13.021, Setup=16.125, BSP = 4.927, Portal=0.117, Finish=20.371
DLight - Walls: 0 processed, 0 rendered - Flats: 0 processed, 0 rendered
Missing textures: 0 upper, 0 lower, 0.000 ms
20 fps

[StrikerMan780]

I can run the OpenGL renderer perfectly fine. Runs fast for the most part, the only time I get a real performance dive is when there's a lot of 3D Floor abuse... hopefully some optimization can be made on that front someday. Another framerate killer is having a lot of models being rendered in the scene, even if they are very low-poly. (I was told the cause of this at one point, but I cannot recall right how, but I heard it is also fixable.)

That's one of the things that I hate opengl

OpenGL in and of itself is actually quite damn good, there's just a lot of exterior factors that have kept it from being all it can be. I personally I think OpenGL, being an open API can potentially be many times better than the locked down, proprietary Direct3D, It's just a shame that It has been handled poorly in the past by the many organizations involved. AMD really half-asses their drivers even when it comes to baseline, standards-compliant stuff. NVidia isn't without fault either, having released many proprietary and non-standards-compliant OpenGL extensions, leading ATI to make proprietary extensions of their own, and vice versa over the years leading to a major clusterfuck. Then there's the prematurity and initial horrible-ness of GLSL, and all sorts of other things at the time. (good explanation is here: http://programmers.stackexchange.com/qu ... er-windows)

Intel on the other hand, had taken their sweet time to catch up in supporting newer OpenGL versions (I have a laptop from 2011 that still only supports OpenGL 1.4).

There also aren't enough AAA-level developers supporting it more often to motivate everyone to improve their support of it I find. There's a lot of people still developing for Direct3D for the sake of immediate convenience (I heard it was slightly easier to work with), and they don't really look at the benefit of having cross-platform compatibility, and the lack of needing to rewrite everything again for OpenGL-supporting platforms like Linux, PS3/4, Wii/Wii U, etc.

This is also a good read that touches on those points: http://blog.wolfire.com/2010/01/Why-you ... ot-DirectX

[ibm5155]

well, I did some tests with overclocking/underclocking things and I got a bad result =/
if I change my gpu clock and gpu memory, there's not a single 1fps drop or increase '-'
if I change my processor clock then I got a huge increase or decrease of fps...

Comon, we are on the software era? because every game that I droped 600MHz from my gpu decreased 20 or more fps, but not in gzdoom, it didn't even droped a single fps...

So, I really don't know what does the gpu do, it say it's using 100% of it, but, it doesn't looks like...

So basically you need a good processor to run gzdoom, and a simple video card, (that may explain too why people with i3 had a much lower fps compared to my i7 with the same integrated gpu...)

also, the test I made was using an intel core i7 3635QM and an AMD HD8870m
i7 was downclocked to 1,2GHz and max clock to 3,4GHz, while on amd the min was 325 and the max 800MHz

EDIT:
and to compare, I got 24fps on frozen time, with the integrated gpu and the

EDIT2:
ok I compared with the intel hd 4000 on the same notebook, but the difference was short, almost 20 fps lower than the 8870m, but the result is weird because it may not be running it at the max processor frequency since that gpu only works on safe energy mode that decrease the processor clock D:

[Graf Zahl]

GZDoom is completely CPU limited right now so your results are not surprising. Modern graphics cards are significantly faster than what the rendering code can give them. Unlike modern games it needs to do a lot of processing to ultimately render a relatively small amount of geometry.

[ETTiNGRiNDER]

Depends on what it's running. The original levels are fine, but load in something like Cheogsh 2 and some parts get laggy enough to border on unplayable.

[ibm5155]

GZDoom is completely CPU limited right now so your results are not surprising. Modern graphics cards are significantly faster than what the rendering code can give them. Unlike modern games it needs to do a lot of processing to ultimately render a relatively small amount of geometry.

=/ hm, any plans to "fix" it on the future?

and here's the actual map that I was testing (also I tested others like hocus pocus? and some maps that I did)

---

Graf, any plans to make a 3D floor with the top reflective? it's a cool effect, but, it's not "officialy" supported

---

This is a bad hack to make a 3D reflective floor, and it's too limited D:, basically, it's a transfer height as water, a 3D floor as the floor from swimming pool, and the floor of the swimming pool is reflective, so it transfers the reflective effect to the top of the water, while the 3d floor block the reflection inside the swimming pool...

[DaMan]

=/ hm, any plans to "fix" it on the future?

The Mantle port will be done shortly after HL3's release⸮

[Hellser]

=/ hm, any plans to "fix" it on the future?

The Mantle port will be done shortly after HL3's release⸮

Lets not talk about AMD's failure of an attempt to replace DirectX and redeem their shitty drivers.

Also. What you're experiencing ibm51 is what we call "CPU Bottlenecking" - where your video card is doing what it's told to do with no stress, but the CPU is chugging along slowly. One has to wait for the other. Guess which one has to wait.

[Graf Zahl]

Also. What you're experiencing ibm51 is what we call "CPU Bottlenecking" - where your video card is doing what it's told to do with no stress, but the CPU is chugging along slowly. One has to wait for the other. Guess which one has to wait.

Indeed. The 'problem' with Doom is that it generates very little stuff to render in relation to the code that needs to be executed for it. There are no high-polygon models or complex lighting setups or other things that might put on some GPU-load. In case of Frozen Time, half of the processing time on my system isn't even spent creating geometry but running the BSP-traversal, and that stuff is very, very hard to optimize because it can't be multithreaded. It has to be done in serial order.


Obviously such a situation also shows very clearly how well written the graphics driver is. Inefficiencies in the Draw... function tend to be a huge problem with it.

If you have followed development you might have seen the GLEW_Version branch. In that I am implementing a persistently mapped buffer. So far that has brought a performance increase of 20% overall, that's approximately 1/3 of the entire rendering code.