GZDoom 3.7.0 Released

News about ZDoom, its child ports, or any closely related projects.
[ZDoom Home] [Documentation (Wiki)] [Official News] [Downloads] [Discord]
[🔎 Google This Site]

[Tap Here for Mobile-Friendly Forums]

Moderator: GZDoom Developers

Re: GZDoom 3.7.0 Released

Postby Dark Pulse » Thu Dec 27, 2018 7:07 pm

Graf Zahl wrote:Don't expect any miracles from Vulkan. It cannot overcome the main problem of the renderer, i.e. that major parts of it need to be run in sequence. The entire renderer has two barriers where each side can run independently of each other. I was able to multithread one of these barriers, the second one will be a lot harder. In OpenGL it can only be done by using GL 4.5 features plus one extension.
And it's this second barrier where Vulkan would come in and allow more efficient handling - but even so, this won't result in a magical speed up but more likely increase performance by 15-20% at best, maybe.

That's really the limit with how Doom levels are being processed by the renderer.
Well, no normal Doom level will ever tank me that much. It's mostly ridiculous torture tests like NUTS or some Chillax maps that can really drown it to something insane, or running with "heavy" mods on top perhaps. (I remember filing a bug report of how torturous the rendering was some years ago on a certain map using DoomRPG and Chillax.)

On the whole though, no sane level should ever tank it - only the ones really huge, really packed, or both.
User avatar
Dark Pulse
Should I be happy or miserable that I enjoyed SNES Doom? What about PS1 Hexen?
 
Joined: 21 Nov 2014

Re: GZDoom 3.7.0 Released

Postby Graf Zahl » Fri Dec 28, 2018 2:23 am

BFeely wrote:If GL 3.3 is good enough to run a Modern build (assuming SSE2 isn't needed in the CPU) then "ye olde chugger" could get a GeForce GS 8400, PCI model to get that support.


non-SSE2 support had been removed over a year ago. Such ancient systems are virtually non-existent these days and since the software true color drawers need SSE2 to be fast, it became too much of a hassle to handle fallbacks for a quasi-zero user share.

Dark Pulse wrote:Well, no normal Doom level will ever tank me that much. It's mostly ridiculous torture tests like NUTS or some Chillax maps that can really drown it to something insane, or running with "heavy" mods on top perhaps. (I remember filing a bug report of how torturous the rendering was some years ago on a certain map using DoomRPG and Chillax.)

On the whole though, no sane level should ever tank it - only the ones really huge, really packed, or both.


It depends on what you define "normal". Do you consider "Struggle - Antaresian Legacy" normal? That mod contains maps that bring weaker systems to their knees, even with the software renderer, and MAP28 is a good stress test even for my own system which, despite being 6 years old is still at the higher end of what's available. Or what about Frozen Time? People owning good computers are actually making such maps, and the number is increasing.

We have to be realistic here: Just because a new release drops support for the lowest end does not mean that people owning such systems are suddenly left without a choice. All old GZDoom versions back to 0.9.0 are still available for download. If you just want to play vanilla or compatible mods because your computer is too weak to handle more, any 5-6 year old GZDoom version might be a better choice than 3.7. Even though there still is a vintage build we shouldn't forget that it's mainly a stripped down GL 3.3 renderer that isn't optimized for such old hardware. GZDoom 1.x was designed for GL 2.1 and that can really make a difference in performance. Of course, that old renderer will be slower on modern hardware, especially on multi-core systems that can use the new multithreaded render path.
User avatar
Graf Zahl
Lead GZDoom Developer
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: GZDoom 3.7.0 Released

Postby fakemai » Fri Dec 28, 2018 7:46 am

The JIT compiler actually made for a dramatic performance improvement on my system since a lot of mods I play bottleneck on scripting stuff before visuals (which is terrifying considering it's about the lowest spec graphics card you can even run the engine with). So a big thank you for ending it on a high note if it is indeed the final version that has the vintage build.
User avatar
fakemai
 
Joined: 12 Feb 2018
Location: Australia

Re: GZDoom 3.7.0 Released

Postby Master O » Fri Dec 28, 2018 10:02 am

Graf Zahl wrote:The problem with GL 2 is not primarily the performance but that these cards have very poor shader support and simply miss many features the modern renderer depends on. Trying to support these while moving forward is simply not possible. It's either old or new, but not both.

GL 3.3 is the baseline feature set that can properly handle all current features with the exception of shadow maps. Newer hardware adds features that allow some optimizations, but it isn't like GL 2, where the lack of features meant that the render path couldn't be modernized at all.

Vulkan is actually probably thus my best way to get a framerate boost, but eventually I know this system needs to go and a whole new one up in its place.


Don't expect any miracles from Vulkan. It cannot overcome the main problem of the renderer, i.e. that major parts of it need to be run in sequence. The entire renderer has two barriers where each side can run independently of each other. I was able to multithread one of these barriers, the second one will be a lot harder. In OpenGL it can only be done by using GL 4.5 features plus one extension.
And it's this second barrier where Vulkan would come in and allow more efficient handling - but even so, this won't result in a magical speed up but more likely increase performance by 15-20% at best, maybe.

That's really the limit with how Doom levels are being processed by the renderer.


So there's no way to have those major parts of the renderer to run in parallel?
User avatar
Master O
 
Joined: 14 Feb 2015

Re: GZDoom 3.7.0 Released

Postby Graf Zahl » Fri Dec 28, 2018 10:18 am

It currently runs the BSP traversal and the render list generation in parallel, because these two things only need to communicate through a single queue where the BSP traverser adds elements and the render list generator consumes elements. What cannot be done efficiently is to split the render list generation into multiple threads. This would necessitate explicit synchronization between these threads for shared resources and effectively neutralize all potential advantage. It'd hit the mutexes far too often.

There is a third stage for the renderer, i.e. making render instructions from the render lists. This can theoretically be parallelized as well, but there's two caveats preventing it:

1. OpenGL has no concept of real render queues. And on top of that wants to get all things done in the same thread. So there is no way parallelizing the processing of the separate render lists.
2. Up until OpenGL 4.2 there were no persistently mappable buffers. This means that at one point in time you can either prepare your buffer data or render, but you cannot let one thread prepare data and the other render the previously generated data. And with roughly one third of our users still having hardware this old it is a blocking factor.

On Vulkan compatible hardware even OpenGL provides some means to better optimize but it will require a completely different rendering approach. The good thing is, this approach is mostly the same as Vulkan so it makes sense to do it in OpenGL first because all the backend to test it is already there and once it is complete port it to Vulkan.
User avatar
Graf Zahl
Lead GZDoom Developer
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: GZDoom 3.7.0 Released

Postby Apeirogon » Fri Dec 28, 2018 11:23 am

JIT turn on by default, right?! Can I turn it off?
Because I try nuts with this and previous version several times with stat vm and think commands and result slightly confuse me.
In previous version it shows "think 18ms, actions 8ms, vm calls 18ms", while in current release "think 22ms, actions 8ms, vm calls 30ms". But framerate after first 5000 monsters die in new version is much more smoother than in previous, it even smoother from the beginning when I only trigger all monsters, while numbers run up. :|
Apeirogon
I have a strange sense of humour
 
Joined: 12 Jun 2017

Re: GZDoom 3.7.0 Released

Postby Graf Zahl » Fri Dec 28, 2018 11:28 am

The VM calls timer is no longer reliable with the JIT compiler. Previously it stopped counting for each native function call. Now, with direct native functions, that no longer happens, so the number goes up, naturally.

If you want to turn it off, add +vm_jit 0 to the command line. It cannot be switched off live and will require a restart.
User avatar
Graf Zahl
Lead GZDoom Developer
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: GZDoom 3.7.0 Released

Postby Apeirogon » Fri Dec 28, 2018 11:32 am

Hmmmm, so there are no ways to check how fast my code runs by gzdoom with JIT turn on? Only good old "identify by eye"?
Apeirogon
I have a strange sense of humour
 
Joined: 12 Jun 2017

Re: GZDoom 3.7.0 Released

Postby Rachael » Fri Dec 28, 2018 11:53 am

Windows builds for the legacy branch uploaded.

Note that due to the addition of JIT in GZDoom, we are offering a 64-bit build this time around, since the JIT will not work in 32-bit.
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle

Re: GZDoom 3.7.0 Released

Postby Blzut3 » Fri Dec 28, 2018 9:22 pm

I really need to get wake on lan setup on my desktop. For some reason I explicitly decided to leave it off even though I knew this release was coming. So Linux builds will come after the 6th.

The signed Mac binaries will come soon though.
Blzut3
Pronounced: B-l-zut
 
 
 
Joined: 24 Nov 2004

Re: GZDoom 3.7.0 Released

Postby Rachael » Fri Dec 28, 2018 9:48 pm

It would be easy to deploy two Ubuntu 14.04 server setups with nothing more than a SSH server and apt. I can do the Linux builds, but I'd still have to give them to you in order to get them signed and put in the DRD Team repo.
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle

Re: GZDoom 3.7.0 Released

Postby Blzut3 » Fri Dec 28, 2018 10:46 pm

And that wouldn't help since the signing key and the apt repo config is on the computer that's off. So even if my build environment was remade I still can't do anything. :P
Blzut3
Pronounced: B-l-zut
 
 
 
Joined: 24 Nov 2004

Re: GZDoom 3.7.0 Released

Postby Rachael » Fri Dec 28, 2018 11:52 pm

Then the DRD Team repo is just going to have to lag behind for about a week. ;) You don't need signed packages to use "dpkg -i", which for most Ubuntu desktops is the default association for directly downloaded packages anyhow.

If you decide to make your own packages anyhow, though, I'll happily replace them with your's, instead.

Oh, and on that note: I couldn't get 14.04's netboot to work since the netboot repos for 14.04 are apparently now closed. So I went with two 16.04's and they are both presently compiling the legacy version - one for i686 and the other for amd64. 14.04's death knell is coming in 4 months anyhow, though.
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle

Re: GZDoom 3.7.0 Released

Postby Blzut3 » Sat Dec 29, 2018 2:05 am

Weird, I would have expected the net boot to just use the same repos as the final install. Especially now that Canonical has the extended security maintenance program so even the 12.04 repos are still on the main archive. In any case there's not really a reason to install an actual 14.04 system unless you're looking to actually test the binary. I just use debootstrap and make a chroot. These days you could use docker to make even that easier.
Blzut3
Pronounced: B-l-zut
 
 
 
Joined: 24 Nov 2004

Re: GZDoom 3.7.0 Released

Postby Rachael » Sat Dec 29, 2018 4:30 am

Mac and Linux builds are available.

I (think) I got the packages built correctly for Linux but I'll need some willing guinea pigs to help me test them. Please let me know if you have any problems!
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle

PreviousNext

Return to ZDoom (and related) News

Who is online

Users browsing this forum: No registered users and 1 guest