GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Projects that have specifically been abandoned or considered "dead" get moved here, so people will quit bumping them. If your project has wound up here and it should not be, contact a moderator to have it moved back to the land of the living.

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby ZZYZX » Sun Dec 15, 2019 6:00 pm

I'm pretty sure this is a release build. Yes, also noticed that it's a bit slower, but it was not quite apparent for me if it's caused by me switching Windows version, or the actual binary.
(It's actually a merge of two things, OGL renderer and WINE/Linux compatibility)

The code is on slimgl_merge branch.. you may try to build a debug/release version to check this.
User avatar
ZZYZX
le chat du rabbin
 
 
 
Joined: 14 Oct 2012
Location: Ukraine
Discord: ZZYZX#1394
Github ID: jewalky

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby ZZYZX » Sun Dec 15, 2019 6:14 pm

Btw: Boris, do you have the lower info panel (with selected object details) shown? I generally disable it because it causes flickering and FPS stutter in visual mode... not sure if your "dx and ogl are equally bad" relates to this.
User avatar
ZZYZX
le chat du rabbin
 
 
 
Joined: 14 Oct 2012
Location: Ukraine
Discord: ZZYZX#1394
Github ID: jewalky

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby boris » Sun Dec 15, 2019 6:23 pm

I recorded a short video first the DirectX version, the OpenGL: https://streamable.com/o41pi

Unfortunately the beginning of the dragging in the DirectX version is a bit butchered, but the speed difference is quite obvious.

ZZYZX wrote:Btw: Boris, do you have the lower info panel (with selected object details) shown? I generally disable it because it causes flickering and FPS stutter in visual mode... not sure if your "dx and ogl are equally bad" relates to this.

I do have that enabled. Disabling it doesn't seem to make much of a difference for me, but without an fps counter or proper benchmark it's hard to tell.

I'll try to update my GPU drivers tomorrow, and I'll also check out the branch.
boris
I post less than Manc and Hobo
 
Joined: 15 Jul 2003

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby ZZYZX » Sun Dec 15, 2019 6:43 pm

So I loaded Frozen Time (I don't have whatever wad you showed and too lazy to search) and indeed noticed massive FPS drop in 2D mode.
There is also FPS drop in 3D mode, but it's barely noticeable compared to 2D. Will research.

As for resource loading, it may be caused by additional syncing for texture loading. Not entirely sure though.

I can somewhat understand why this happened.
The main problem here is that while 3D mode is almost unchanged, 2D mode was done in a software renderer in original GZDB, and was rewritten for OpenGL.
Not sure, I may try to return the software renderer (looking at these massive lags I can guess why it was done) but then again there is probably a better way to fix it.
User avatar
ZZYZX
le chat du rabbin
 
 
 
Joined: 14 Oct 2012
Location: Ukraine
Discord: ZZYZX#1394
Github ID: jewalky

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby dpJudas » Sun Dec 15, 2019 6:59 pm

One possible candidate for speed difference in 2D mode is that I'm updating the texture sampler values each time the texture is bound (see the glTexParameteri calls in RenderDevice::ApplyTextures in RenderDevice.cpp). I recall Graf mentioning elsewhere that not using a GL sampler object for this drags down performance considerably.

That's just a guess though. Lots of other possible candidates.

About the GPU version of the plotter - it *should* outperform the software version, in theory at least. Especially on high resolution monitors. I wouldn't sack the GPU version here unless you're absolutely sure it is the source of the speed regression. :)
dpJudas
 
 
 
Joined: 28 May 2016

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby axredneck » Sun Dec 15, 2019 7:04 pm

Linux/Mac(WINE)

Spoiler:

GZDB-GL 32-bit, Arch Linux, Nvidia, installed dotnet472 into the same wineprefix i use for regular GZDB-BF.
User avatar
axredneck
excuse me for my bad English
 
Joined: 11 Dec 2017
Location: Russia
Github ID: axredneck
Operating System: Other Linux 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby axredneck » Sun Dec 15, 2019 7:07 pm

edit:
You do not have the required permissions to view the files attached to this post.
User avatar
axredneck
excuse me for my bad English
 
Joined: 11 Dec 2017
Location: Russia
Github ID: axredneck
Operating System: Other Linux 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby ZZYZX » Sun Dec 15, 2019 7:14 pm

dpJudas wrote:One possible candidate for speed difference in 2D mode is that I'm updating the texture sampler values each time the texture is bound (see the glTexParameteri calls in RenderDevice::ApplyTextures in RenderDevice.cpp). I recall Graf mentioning elsewhere that not using a GL sampler object for this drags down performance considerably.

That's just a guess though. Lots of other possible candidates.

About the GPU version of the plotter - it *should* outperform the software version, in theory at least. Especially on high resolution monitors. I wouldn't sack the GPU version here unless you're absolutely sure it is the source of the speed regression. :)

It looks like adding vertices takes 30ms each frame. Just adding vertices. Not even drawing yet ;)
Just to say, Frozen Time has 1003932 vertices. Roughly 16% are duplicates, but it seems that's still a bit too much.

Texture sampler values are improbable because 3D mode is not affected.

(PlotVertex is a class type I created for comparison instead of struct type FlatVertex — helped a bit, but not much)
Code: Select allExpand view
        private void AddVertex(PrimitiveType t, PlotVertex v)
        {
            plotSw.Start();
            if (Lists.Count == 0 || Lists[Lists.Count-1].PrimitiveType != t)
            {
                PlotVertexList vxlist = new PlotVertexList();
                vxlist.PrimitiveType = t;
                vxlist.Vertices = new List<PlotVertex>();
                Lists.Add(vxlist);
            }

            Lists[Lists.Count - 1].Vertices.Add(v);
            plotSw.Stop();
        }
User avatar
ZZYZX
le chat du rabbin
 
 
 
Joined: 14 Oct 2012
Location: Ukraine
Discord: ZZYZX#1394
Github ID: jewalky

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby dpJudas » Sun Dec 15, 2019 7:18 pm

Ah so you did profile it. The drawing part isn't the problem because the GPU laughs at your pathetic 1 million vertices and says HA I can do that at 500+ fps. :)

I wonder why it takes it so long to add the vertices. I would have expected it to be faster than actually drawing them in software (afair the vertices are done as a fill rect in the software version). Maybe because they are so small they are just one pixel or smt?

Edit: could also be because the collection classes in C# I used for it doesn't scale well with 1 million entries.
dpJudas
 
 
 
Joined: 28 May 2016

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby ZZYZX » Sun Dec 15, 2019 7:24 pm

There is also a chance that the profiling is not precise (because occasionally, it also shows 4-8ms instead of 30-100)
Though commenting out all of AddVertex causes huge performance improvement.

I tried changing it to a plain array of large size, didn't really help.

Why is it slow? Easy: 32 mb allocation multiple times in a frame...
I'm going to try to use an index list or something, not yet sure.

The main idea is that we could cache the array and not regenerate it from scratch (Clear()) every time. Otherwise it's sure terrible.

https://i.imgur.com/AmfKc4k.png
Caching does not help, btw.
Last edited by ZZYZX on Sun Dec 15, 2019 7:31 pm, edited 1 time in total.
User avatar
ZZYZX
le chat du rabbin
 
 
 
Joined: 14 Oct 2012
Location: Ukraine
Discord: ZZYZX#1394
Github ID: jewalky

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby dpJudas » Sun Dec 15, 2019 7:29 pm

Ah yes, it totally needs an array that stays put. And also hopefully it won't make a copy of it when it does the P/Invoke. :)
dpJudas
 
 
 
Joined: 28 May 2016

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby SanyaWaffles » Sun Dec 15, 2019 7:52 pm

For me on 64-bit Windows 16GB memory, on a 8GB GTX 1080, the OpenGL build runs much faster than the SlimDX version in both 2D and 3D mode.

In SlimDX I constantly had a stutter with my project in 3D mode where I literally couldn't move much without the 3D mode stuttering and chugging along. This problem never was addressed in previous builds much, but suddenly with the OpenGL Version it's resolved.

The main difference is my project has huge hi-res sprites that might have been dragging the renderer down. Now it works fine.
User avatar
SanyaWaffles
Wouldn't be an epic gamer if I didn't commit a few war crimes.
 
Joined: 25 Apr 2013
Location: Eastern Ohio
Discord: SanyaWaffles#5095
Twitch ID: sanyawaffles
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby ZZYZX » Sun Dec 15, 2019 8:04 pm

Returning the software renderer (without rendering to texture yet) helped with performance.
edit: made it write to texture. Still way better with performance.

I guess now we know why CodeImp did it ;)

Though, SlimDX is still faster. Supposedly, using PBO instead of glTexSubImage2D may help.
User avatar
ZZYZX
le chat du rabbin
 
 
 
Joined: 14 Oct 2012
Location: Ukraine
Discord: ZZYZX#1394
Github ID: jewalky

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby dpJudas » Sun Dec 15, 2019 8:39 pm

The big catch with the software way is that you effectively put an upper limit on the fps somewhere around 45 when running GZDB maximized with a 4K monitor. Filling over 30 megabytes with black takes its toll.

I'm going to make one more test with the GPU version next time I have some time. I'm a bit curious about some performance aspects of C# and P/Invoke which may explain some things.
dpJudas
 
 
 
Joined: 28 May 2016

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby ZZYZX » Sun Dec 15, 2019 8:50 pm

dpJudas wrote:The big catch with the software way is that you effectively put an upper limit on the fps somewhere around 45 when running GZDB maximized with a 4K monitor. Filling over 30 megabytes with black takes its toll.

Scaling. No one really needs that huge canvas... downscale to regular 1920x1080, and that's it.
User avatar
ZZYZX
le chat du rabbin
 
 
 
Joined: 14 Oct 2012
Location: Ukraine
Discord: ZZYZX#1394
Github ID: jewalky

PreviousNext

Return to Abandoned/Dead Projects

Who is online

Users browsing this forum: No registered users and 0 guests