cabalistic

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

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: 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.

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

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.

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.

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: 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.

It's worth pointing out that this is for Doom3 BFG, not the original Doom3 code. So that's going to make any porting attempt even trickier.

Thanks! I may have a look at it.

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

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.

Not good. I patallelized some aspects of the frontend which scored high in the profiler, but in situations where it matters the backend takes just as much CPU time. So it doesnt help at all. The bottleneck in the backend seems to be animated models and the constant update of their vertex buffers. To get past that, I believe we would have to port the vertex cache optimizations and hardware skinning from Bfg, but that is a major undertaking...

Yep, idStr must not use idBlockAlloc, or this whole thing does not work. There's a define to disable it which is set in my VR version. I did not observe any other allocation problems so far. Debug renderings could be tricky, because some of them seem to not be designed for the split between frontend and backend.

So... have you ever though about truly opening development (including assets) and put everything on e.g. Github? I know that surrendering control is scary, but even if I had svn access, I'd still be in a dilemma. I can't really develop my VR version against svn if nobody besides the dev team can test that version. But developing against 2.05 is not ideal either, because it means essentially doing some of the work twice. When I tested the fixed tic rate, the results were not so great (on 2.05). Generally, since the tic rate cannot truly run parallel to the frontend, it still matters what tic rate you choose vs the targeted refresh rate. A tic rate of 60 means that for the VR version at 90 Hz, every third frame will not calculate a tic, but the other two will. Maybe it's not that noticable, but it might make physics calculations seem strange. So, for VR, a tic rate of 90 is better. Alternatively, you could lower it to 45 or 30. 30 is the only one that fits both 60 Hz and 90 Hz refresh rates, but I don't know if that might be too low? In any case, you certainly don't have to adopt the 90 Hz game tic, it's specific to VR I originally introduced it to gain access to FBO functions in GL, which are not covered by qgl (at 2.05). Then, when I created the second context, I used the MX version because technically the GL functions are specific to the context, so you'd have to fetch them for both contexts separately. In practice, however, modern graphics drivers apparently always return the same function pointers, so this isn't really an issue. But since I had some problems initially, I wanted to rule out that source of error. In any case, you don't have to use glew on the svn version, it was just easier for me to use at the beginning of my developments I think what he meant was always use the separation (i.e. frontend always uses f.e.geo, backend always uses b.e.geo), but make an option that runs the backend after the frontend, anyway.

Not sure what you are comparing it to, but I based it on the 2.05 source download from the website... http://www.thedarkmod.com/sources/thedarkmod.2.05.src.7z

No, it's still entirely CPU bound, my GPU is bored to death (says SteamVR). But it is now bound in the backend, where parallelization is very difficult.

So, some bad news. This weekend, I experimented with further parallelizing some parts of the frontend renderer (specifically, finding lights and adding interactions), which were especially prominent in the profiler. However, it made no difference at all, at least not in places where extra performance would have been needed. It appears that in cases where the frontend takes long, then the backend also takes long, so cutting down calculation times on the frontend didn't help anything, because the backend then becomes the bottleneck. So this means further threading does not currently help, as the primary bottleneck is now actually the rendering. So to get more performance, I think there is now little choice but to port the vertexcache changes from Doom3 BFG, which would be a major undertaking...

@nbohr1more: Interesting, I might try experimenting with the threading options. Just for the record, did you disable full screen? I am aware of Carmack's comments to their problems with multithreaded rendering, but I did a fair bit of research. My approach with using two individual render contexts for the two threads with shared lists is generally considered a sane approach and should not cause any issues. If you were using an AMD card, I might be concerned about it, but you have the same brand as I (NVIDIA), and I don't think it would miraculously work on one NVIDIA card and not the other. (Just to be clear: If you use the standard 2.05 executable on the exact same installation, you have no issues, right?) @BuckleBean: Thanks for testing! I wasn't even aware of the options to disable player bob. I'll add that to the documentation at the very least. I don't have a Rift, unfortunately, but I also would have expected it to work with OpenVR. But since you have both, how does SteamVR actually select which headset to render to? Perhaps it's getting confused there... Yeah, performance is still not good enough in some places, and that's not an easy fix. The display refresh should be irrelevant, as SteamVR handles vsync automatically. In fact, you should disable vsync in the game entirely, it might cause issues. The fixedTic option is obsolete in my build, it doesn't do anything. @stgatilov: I agree, but as mentioned, that would require substantial modifications to the VertexCache and anything interacting with it, so it would be a major effort. Worth it for sure, but I had to go with the easier option for now due to time constraints... The crash on mission reload is probably not related to that specific bug. From my investigations, it has to do with the VR resources (specifically framebuffers and render textures) which probably aren't properly recreated during the reload. That's not surprising as I haven't actually implemented that behaviour

@BuckleBean: You need to put "set vr_enable 1" in your autoexec.cfg, since VR support is disabled by default in the current build. Other than that, have fun. But watch out, no comfort options or anything, so it probably takes a strong stomach In any case, I'd be most interested in performance and possible visual artifacts you encounter (other than some shadows being inconsistent between the eyes).

Except nothing's really changed for lightgem and frontend, they are still executed after one another, just on separate threads. But it's entirely possible that the lightgem stuff influences the vertex cache in such a way that the backend renderer will feel it in the next round... Yes, the frontend still makes gl calls to generate and bind buffers. I briefly considered to go the Doom 3 BFG way, where it uses glMapBuffer to only pass standard pointers to the frontend thread, but that would have been a major rewrite of the vertex cache and everything surrounding it. So instead I created a second (shared) GL context for the frontend thread.

Atomics (or locking) won't do any good here, since the lightgem calculation isn't actually part of the threading split. The process currently looks like this: Thread 1 Thread 2 ========================================================= - Lightgem calculation - wait for Thread 1 - other pre-frame work - signal Thread 2 - render previous frame - game tics - wait for Thread 2 - prepare next frame (frontend) - signal Thread 1 So, no parallelism during lightgem calculation, at least not yet. (Thread 2 waits a couple of milliseconds for Thread 1 each frame, so that's definitely something I'd like to improve.) Still, the VertexCache is a potential suspect, but since I can't currently reproduce the problem, I'll have to understand the cause first. What happens if you disable the lightgem rendering entirely (set tdm_lg_weak 1)?

Hm, I'm not so sure games won't start using more threads soon. The way that modern parallelization is usally done is task-based, where a set of repeating code is divided into tasks which can run in parallel. These tasks are then executed on worker threads, and it doesn't really matter to the app how many worker threads you have. On a console you may have two workers, and on a PC you can easily spawn more if there are more cores available. So consoles aren't really the limiting factor here, it's more adopting the technique. @jaxa: Unfortunately, adopting the Doom 3 BFG threading model is not that simple and would be quite a significant effort. There have been a lot of changes under the hood to accomodate it. I only did a fairly simple cut between frontend and backend, and even that took me quite a while. Not to mention that it's entirely unclear if it really is stable. After all, we have at least one report with issues, so I'd really appreciate more people trying it out

@nbohr1more: Hm, that's a shame. I can't reproduce it either. May I ask what kind of hardware you are running, specifically what kind of graphics card? If we're unlucky, it's one of those issues... Or if you were running in fullscreen, could you try windowed mode? I did have some issues with fullscreen myself, will have to look into that. @wildmage: It's a long road ahead until I could even think about something like teleportation. Even with the added threading, performance might still be doubtful on many missions to actually support roomscale VR, so we'll have to see. Until then, it will be artificial locomotion only. *If* I ever get around to do something like teleportation, the simplest approach probably would be something like dash teleport, where you do small steps into a given direction where the actual movement can be blacked out.

Then try 2.05 assets