I'm working on a VR version - early alpha

[duzenko]

Yes, but the structure has implications for both. For example, the backend spends a noticable amount of time binding vertex buffers, which the BFG edition doesn't have to, afaict. As such, I believe that the BFG version lowers costs for both frontend and backend, which is exactly what we'd need at this point.

If only someone could just switch our system to one big vertex buffer...

[nbohr1more]

Time to test this once more with uncapped FPS:

 

http://bugs.thedarkmod.com/view.php?id=3234

 

?

[cabalistic]

The link in that report is dead, do you have another source? Might like to look at the changes they did...

[nbohr1more]

Original:

 

https://pastebin.com/rHrwP0nA

 

Revelator's first relay of it:

 

http://forums.thedarkmod.com/topic/15178-tdm-engine-development-page/page-25?p=358097&do=findComment&comment=358097

 

he also has a hybrid BFG\Vanilla with some of these changes:

 

https://github.com/revelator/Revelation

 

Pat Raynor's hybrid BFG\Vanilla version also uses mapBufferRange:

 

https://github.com/raynorpat/Doom3

[cabalistic]

Thanks! I may have a look at it.

[cabalistic]

@nbohr1more: I was now able to reproduce the visual artifacts you reported on an older PC with an older Nvidia card

Unfortunately, I don't normally have access to this PC, so unless I accidentally find the root cause tonight, it's still going to be tricky to debug this since it's just not happening on my primary dev machine.

 

Evidently, this needs more testing. I'd really appreciate some more people try out the build (you don't need a VR device) and report any problems along with their hardware. There are clearly some issues left.

[duzenko]

@nbohr1more: I was now able to reproduce the visual artifacts you reported on an older PC with an older Nvidia card

Unfortunately, I don't normally have access to this PC, so unless I accidentally find the root cause tonight, it's still going to be tricky to debug this since it's just not happening on my primary dev machine.

 

Evidently, this needs more testing. I'd really appreciate some more people try out the build (you don't need a VR device) and report any problems along with their hardware. There are clearly some issues left.

You should now have full svn access?

Could you add a switch to toggle SMP on and off?

[cabalistic]

No I don't. Or if I do, nobody told me.

Either way, working on this in SVN isn't helpful, because I need people to actually *test* it. Until the SVN assets are publically accessible, that means tests can only happen with my 2.05 build

[nbohr1more]

To my knowledge, you should now have full SVN access.

 

I understand that it's not your preferred workflow but the "TDM team" does test changes in SVN and then when the 2.06 beta begins

the assets will be made available to "beta testers". (We could possibly consider a 2.06 alpha as well to gather more testers.)

 

Don't get me wrong, I wholly agree that we should offer assets to accompany our read-only developer SVN access so

that outside developers can more easily integrate their work.

 

I think it's time to start another big internal argument about that soonish...

[duzenko]

Added the r_smp cvar.

My wild guess about the glitch some have with smp could be related to vertex buffer use on a thread? If so we need to switch to permanent VB data pointer that must be safer in terms of thread sync.

[cabalistic]

I was able to make the Problem disappear by ensuring that Frontend and Backend run after one another, but still in separate threads. So the use of vbo on the other thread is not in itself a Problem. It appears there is still a genuine race condition, with the Frontend manipulating something that is used in the back. Just wondering why I can't reproduce it on my dev machine.

 

I do habe a work laptop with a 960M, I'll try if it happens there.

[AluminumHaste]

 

 

Thank you. I'm not sure if logging is on. Perhaps you can tell by the contents of my log file, which are as follows:

 

[game\DarkModGlobals.cpp ( 362):INI (INIT) FR: 0] LogFile created at 2017.08.08 21:03:23

[game\DarkModGlobals.cpp ( 365):INI (INIT) FR: 0] DLL last cleaned and rebuilt on Jul 23 2017 11:13:21

[game\DarkModGlobals.cpp ( 367):INI (INIT) FR: 0] The Dark Mod 2.05, code revision 6757

[game\DarkModGlobals.cpp ( 408):FRC (FORCE) FR: 0] LogBegin: 0

[game\DarkModGlobals.cpp ( 408):FRC (FORCE) FR: 0] LogEnd: 0

[game\DarkModGlobals.cpp ( 408):FRC (FORCE) FR: 0] LogInfo: 0

[game\DarkModGlobals.cpp ( 408):FRC (FORCE) FR: 0] LogDebug: 0

[game\DarkModGlobals.cpp ( 408):FRC (FORCE) FR: 0] LogWarning: 0

[game\DarkModGlobals.cpp ( 408):FRC (FORCE) FR: 0] LogError: 0

[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_FRAME: 0

[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_SYSTEM: 0

[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_MISC: 0

[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_FROBBING: 0

[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_AI: 0

[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_SOUND: 0

[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_FUNCTION: 0

[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_ENTITY: 0

[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_INVENTORY: 0

[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_LIGHT: 0

[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_WEAPON: 0

[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_MATH: 0

[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_MOVEMENT: 0

[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_STIM_RESPONSE: 0

[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_OBJECTIVES: 0

[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_DIFFICULTY: 0

[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_CONVERSATION: 0

[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_MAINMENU: 0

[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_LOCKPICK: 0

[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_AAS: 0

[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_STATE: 0

 

 

For system crashes, turn 0's to 1's since I'm not sure what's causing your crash.

It might make TDM run slower, but this is only temporary. Once the game crashes, post the darkmod.log file here.

Sorry for the late reply.

[AluminumHaste]

I was able to make the Problem disappear by ensuring that Frontend and Backend run after one another, but still in separate threads. So the use of vbo on the other thread is not in itself a Problem. It appears there is still a genuine race condition, with the Frontend manipulating something that is used in the back. Just wondering why I can't reproduce it on my dev machine.

 

I do habe a work laptop with a 960M, I'll try if it happens there.

 

LOL you and John Carmack

 

 

John Carmack - This was explicitly to support dual processor systems. It worked well on my dev system, but it never seemed stable enough in broad use, so we backed off from it. Interestingly, we only just found out last year why it was problematic (the same thing applied to Rage’s r_useSMP option, which we had to disable on the PC) – on windows, OpenGL can only safely draw to a window that was created by the same thread. We created the window on the launch thread, but then did all the rendering on a separate render thread. It would be nice if doing this just failed with a clear error, but instead it works on some systems and randomly fails on others for no apparent reason.

[cabalistic]

Heh, yeah, that's pretty mich every developer's Problem

This issue is different from Carmack's, though. It should be entirely fixable once I've understood the root cause.

[cabalistic]

Ok, so I can also reproduce the issue on my laptop, so I do have a device to debug with.

Also, in fullscreen at an increased resolution, I finally managed to see a glimpse of the issue also on my dev machine. Only for a second or so, but it was there. So this is definitely a general issue, which is a relief. For some reason, the GTX1070 is much more stable against it than the GTX960, but still.

Unfortunately, concurrent race conditions are still tricky to debug, but hopefully I can track it down now that I've seen it for myself.

 

@nbohr1more: I did not receive any credentials for SVN. So even if there exists an account for me with access, I still can't access it

Edited August 14, 2017 by cabalistic

[nbohr1more]

I'll ping the crew with regards to the credentials.

[cabalistic]

@nbohr1more: I think I fixed the problem. Can you try the new build? https://github.com/fholger/thedarkmodvr/releases/tag/v0.1.2

The problem was that the GL buffers filled in the frontend thread needed to be synced properly before the backend attempts to render them. Doing a glFlush (as I did) is not sufficient and can lead to the very artifacts we observed, depending on how fast the GPU is compared to the CPU.

 

The fix is to either use a full glFinish (which is expensive, takes a lot of time), or use a fence sync. However, the latter is only available in OpenGL 3.2 (which is 8 years old, give or take). I don't know where The Dark Mod stands on backwards compatibility? What is your intended minimum specs?

If we want to modernize the engine further (which I very much would like to attempt to help with), it's probably good to decide the targeted OpenGL version upfront.

 

In any case, I've decided to put development of the VR mod on hold for now. I feel the engine still needs another significant performance improvement for VR to truly be viable, so I'd like to concentrate on that first. There are some obvious candidates for improvements we should backport from Doom3 BFG, namely glMapBuffer, GPU skinning and others. I don't know how feasible it is or how much work it actually requires, but I'm willing to give it a shot. But these changes really need to happen to the SVN version, so that's why I'm abandoning my VR branch for now.

[nbohr1more]

Thank you.

 

I will test this tonight!

[duzenko]

@nbohr1more: I think I fixed the problem. Can you try the new build? https://github.com/fholger/thedarkmodvr/releases/tag/v0.1.2

The problem was that the GL buffers filled in the frontend thread needed to be synced properly before the backend attempts to render them. Doing a glFlush (as I did) is not sufficient and can lead to the very artifacts we observed, depending on how fast the GPU is compared to the CPU.

 

The fix is to either use a full glFinish (which is expensive, takes a lot of time), or use a fence sync. However, the latter is only available in OpenGL 3.2 (which is 8 years old, give or take). I don't know where The Dark Mod stands on backwards compatibility? What is your intended minimum specs?

If we want to modernize the engine further (which I very much would like to attempt to help with), it's probably good to decide the targeted OpenGL version upfront.

 

In any case, I've decided to put development of the VR mod on hold for now. I feel the engine still needs another significant performance improvement for VR to truly be viable, so I'd like to concentrate on that first. There are some obvious candidates for improvements we should backport from Doom3 BFG, namely glMapBuffer, GPU skinning and others. I don't know how feasible it is or how much work it actually requires, but I'm willing to give it a shot. But these changes really need to happen to the SVN version, so that's why I'm abandoning my VR branch for now.

I would try glMapBuffer + ring pointer writes

Configurable buffer size would allow for 3+ frames of geometry.

[cabalistic]

But you have to unmap it for the backend to actually render it. I think the BFG approach of having two buffers and swapping them between each frame is the more viable approach.

 

In any case, this only works for the frame-allocated buffers. Currently, the engine also creates a lot of static objects dynamically in the frontend, which BFG got rid of. That might be a more substantial rewrite, though.

[nbohr1more]

Hmm. I guess if you want to go older than OpenGL 3.2, ATI\AMD support NV_fence going back to Radeon 9200

 

http://feedback.wildfiregames.com/report/opengl/feature/GL_NV_fence

 

https://www.khronos.org/registry/OpenGL/extensions/NV/NV_fence.txt

 

Or do a GL version check and do either depending...

[nbohr1more]

@nbohr1more: I think I fixed the problem. Can you try the new build? https://github.com/fholger/thedarkmodvr/releases/tag/v0.1.2

The problem was that the GL buffers filled in the frontend thread needed to be synced properly before the backend attempts to render them. Doing a glFlush (as I did) is not sufficient and can lead to the very artifacts we observed, depending on how fast the GPU is compared to the CPU.

 

The fix is to either use a full glFinish (which is expensive, takes a lot of time), or use a fence sync. However, the latter is only available in OpenGL 3.2 (which is 8 years old, give or take). I don't know where The Dark Mod stands on backwards compatibility? What is your intended minimum specs?

If we want to modernize the engine further (which I very much would like to attempt to help with), it's probably good to decide the targeted OpenGL version upfront.

 

In any case, I've decided to put development of the VR mod on hold for now. I feel the engine still needs another significant performance improvement for VR to truly be viable, so I'd like to concentrate on that first. There are some obvious candidates for improvements we should backport from Doom3 BFG, namely glMapBuffer, GPU skinning and others. I don't know how feasible it is or how much work it actually requires, but I'm willing to give it a shot. But these changes really need to happen to the SVN version, so that's why I'm abandoning my VR branch for now.

 

Yes, this build has solved the problem!

 

I can now max out tdm_lg_split and tdm_lg_interleave and really open up the FPS here.

 

Edit:

 

Well... 99%of the problem. The skybox in Briarwood Manor flickers when I set tdm_lg_interleave > 1. tdm_lg_split 1 still works though.

[cabalistic]

Grrr. Well, at least I can reproduce that one easily enough

[stgatilov]

The fix is to either use a full glFinish (which is expensive, takes a lot of time), or use a fence sync. However, the latter is only available in OpenGL 3.2 (which is 8 years old, give or take). I don't know where The Dark Mod stands on backwards compatibility? What is your intended minimum specs?

If we want to modernize the engine further (which I very much would like to attempt to help with), it's probably good to decide the targeted OpenGL version upfront.

 

I think the current approach with OpenGL is: we use something very old like version 2.1, and we enable extensions for anything relatively modern (like e.g. framebuffer).

If you need a fence, there is no problem in using it via GL extension.

Just make sure that when cvar for multithreaded rendering is disabled (I hope it is already present in the code?), this extension is not required. In such case people with old video card can still play the game without issues.

[duzenko]

 

I think the current approach with OpenGL is: we use something very old like version 2.1, and we enable extensions for anything relatively modern (like e.g. framebuffer).

If you need a fence, there is no problem in using it via GL extension.

Just make sure that when cvar for multithreaded rendering is disabled (I hope it is already present in the code?), this extension is not required. In such case people with old video card can still play the game without issues.

Can't see why support 2.1 when everyone is on DX10 hardware these days: http://store.steampowered.com/hwsurvey/videocard/.