cabalistic
-
Posts
1579 -
Joined
-
Last visited
-
Days Won
47
Posts posted by cabalistic
-
-
Alright, pushed the aforementioned fix to https://github.com/fholger/thedarkmod/tree/vertexcache. It's really only that one image, far as I can tell, so this should be fine. Please give it a spin and let me know if there are any other issues I might have missed
-
1
-
-
Yeah, I'm currently trying a simple conditional check in idImage::ActuallyLoadImage which just returns if it's accessed from the frontend thread. Image loading should then be retriggered from the backend when it actually needs the image. Since this seems to be a pretty rare case, I'm hopeful this won't have too many downsides.
Getting rid of the context would indeed be great to further parallelize the frontend. Although, if we really are already approaching backend bottlenecks, I should probably compare how backend processing differs in BFG. Perhaps there are a few quick wins there, too? I'll test your scenario to see how my PC handles it
-
1
-
-
Yep, that's the infinite loop bug.
In Briarwood Manor, what happens is essentially this: eventually, one of the guards outside decides to take a leak and enters a urinating animation. This, in turn, triggers some material to be parsed, which then tries to load an image and generate a new texture (calling glGenTextures). As GL calls are no longer supposed to be possible in the frontend, it crashes.
I could reenable the GL context for the frontend, of course. However, I would like to understand why this particular image was not preloaded during level load. My rudimentary understanding of the engine is that we would normally preload all the images that we expect to need.
Does someone have any deeper insights into resource loading? Is this a potential oversight, or is there a reason that some resources should not be preloaded? Perhaps in this particular instance it's just well-hidden in some obscure animation that we just don't know about at level load?
-
So, essentially the root of the problem is that it's trying to load an image on the frontend, which in turn calls glGenTexture. However, since in my branch I removed the GL context on the frontend, the call fails (silently) and leads into that endless loop.
The image load itself is triggered by a (static) model load during animation processing. I'll need to understand why that happens; the BFG style assumes that all static models are generated during level load. So either I missed something during porting, or The Dark Mod does something that doesn't fit into this picture.
-
2
-
-
I already rebased on trunk. The issue I described above is a curious infinite loop when trying to bind an image that's not loaded. It's trying to load a compressed version of that image, during which it eventually calls bind again, which leads into the endless loop. Each call allocates some memory, until eventually there's none left. I'm currently trying to figure out why this only appears to happen on my branch and what's the right way to break it.
-
@nbohr1more: I think I finally tracked down the decal issue. The decals used memory for vertices and indexes that weren't 16-byte aligned. However, the BFG-style vertex caches expect the data to be passed in 16-byte aligned pointers, so that led to a crash.
There is one other issue I'm currently trying to track down. Occasionally, the game hangs and begins to allocate insane amounts of memory until it finally cannot allocate any more memory and crashes. I don't know what's causing it yet, but it does not appear to happen on trunk, so it's probably related to my changes in some way.
In any case, perhaps you could give the updated version another spin and verify the decal issue is gone for you, too?
-
Hey, no sweat. To be honest, I'm not exactly an expert on this stuff, either. I'm just reading through BFG code in parallel to TDM code and try to adapt as best as I can. Unfortunately, I didn't have too much time in the past few weeks, so the vertexcache adjustment is in limbo a bit. It's working in principle (and is a bit faster), but there's still the blocker found by nbohr1more and two other issues I haven't been able to properly track down, yet. I'm hoping to do that over the Christmas holidays, ideally.
That being said, I think we should be careful of moving more stuff into the backend. Even though the frontend is the current bottleneck, we don't have that much headroom on the backend, either. So instead we should try to reduce load in the frontend either by makings its operations simpler or by adding additional parallelisation. BFG does both, and I'm hoping that with the vertexcache adjustment the extra parallelisation should become simpler. If you are not in a hurry, I would suggest to wait a bit until I've had time to finalise the vertexcache. Any quick fix in the meantime is going to make merging and adjusting it more difficult.
How are things with BFG-style vertex cache anyway? Been quiet on that front for a while. I have no idea how to approach it with this linked list that controls it.However we all know that current version is cpu-limited (read frontend limited). I'm just doing what I can to lift the weight off frontend. We can certainly not control video driver when it comes to vertex uploads so our only options are map entire VB to CPU address space at frame start or move vertex uploads to backend. I'm merely doing the one I know how to do. I wish I knew how to do mapping the right way but I don't.
I can't see any fps gain so far but it paves way to worker jobs for e.g. tangent derive, etc. (Yes, I know we'd be better off with GPU skinning, but again I don't know how to approach that ATM).
EDIT
There is of course an option of moving vertex uploads to yet another thread along with derive tangents, etc.
I kinda like that even more because it's easier to control a single thread than N workers.
Back to benchmark I can see CPU mostly sitting in shadow calc (the open space in Rightful Property).
-
1
-
-
I'm reasonably certain that's the exact problem why I introduced the frontendGeo/backendGeo split in the first place.
-
1
-
-
Hm, I'm not sure doing vertex uploads on the backend is a good idea. At the very least, it will make the move to the BFG-style vertex cache virtually impossible. If you see performance issues with the current upload, you might want to try reverting the switch to glMapBuffer. In the current form I think it is inferior; it's only an advantage if the full buffer can be mapped for the frontend in advance (like BFG does it).
As far as frontendGeo/backendGeo goes, there's really only a part of the structure that needed to be replicated. But it was easier/quicker to just copy the whole structure. I don't remember the details, though, but there is a definitive race condition involved here, possibly what nbohr1more is seeing. So be careful.
-
1
-
-
Well, then we need to introduce separate renderCrops for the backend.
-
1
-
-
If it's high-poly bushes, it should tax the graphics card, but the bottleneck is still CPU. Unless it uploads all those polygons every frame... Either way, I also tested with the standard first mission, and the results are similar. Especially when you look down from the rooftops where you encounter the first two watchmen.
-
True, but my two go-to scenes are clear enough.
Btw, I have experienced a general fps drop since my last svn update. The opening scene in Briarwood Manor e.g. dropped from about 60fps to 45-53 fps (depending on settings). I'm not sure of the cause, yet. A quick checkout of an older revision suggests it's not a code change. So perhaps assets, or something messed up my local config.
Either way, in that scene, it's currently like this:
r_useGLSL 1 costs 2-3 fps.
r_shadows makes fairly little difference, I would say 1-2 fps drop with shadow maps. But even disabling shadows is not that much of a difference.
Other scenes can vary slightly. I can make a more thorough analysis if you think it would help you. But either way, the engine is still CPU bound.
-
2
-
-
I had r_shadows 2 in my autoexec on start. That should do it, shouldn't it?
-
1
-
-
I just tested a few scenes, GPU ultilization barely surpasses 40% anywhere, as measured by MSI Afterburner. And when FPS drop, then so does GPU utilization. So yeah, I think this is still strongly CPU bound. Enabling shadow maps doesn't really make a difference in that regard, although overall performance is slightly worse.
-
1
-
-
Should be fixed.
-
2
-
-
Ah, hm, oversight on my end. I didn't think about the parts of the code that run outside of the frontend/backend split.
Unfortunately, it's not as simple as checking the thread. The backend needs special logic, too, if the frontend is running. Simplest fix would be a boolean flag that gets set while frontend/backend are running. It's not exactly elegant, but it should do the trick.
-
1
-
-
Yeah, it seems to be working. I pushed it to trunk; let me know if you find any problems.
-
1
-
-
@duzenko: I went ahead and implemented the necessary indirections. It's not the nicest bit of code, but it appears to work. I haven't tested all possible cases, yet. The required changes would look like this: https://github.com/fholger/thedarkmod/pull/1/file
Basically, the Error and FatalError methods first throw an intermediate exception. On the frontend, this is caught and stored and then rethrown on the backend. In the backend, it is caught and then defers to the actual implementation of those functions. I have tested Error from the frontend, which worked fine. I still need to test using the functions on the backend, that might need an extra sync with the frontend.
Let me know if you think it's worth it. I can then push it to trunk after the additional tests.
-
3
-
-
@duzenko: Are you sure this is just a message pump issue? I added a common->Error call, and I immediately get a crash, not a freeze. Looking at the code, Common::Error tries to shut down the game by calling various methods which are decidedly not thread-safe. I don't think in its current state this method can work at all with threading enabled. Definitely not from the frontend, probably not even safely from the backend.
I had a look at the BFG version, but it's essentially the same, so probably similarly broken. Fixing this could be quite involved - you would need a way to stop executing the frontend or backend (whichever it was thrown in), then wait for the other thread, signal the error to the backend (main) thread and stop the game after the sync point. Doable, but quite a bit of effort. Is it worth it? After all, errors should be fairly rare except for development issues. You can always disable the multi-threading for debugging...
-
2
-
-
Hm, do you have a reproducible case for this? I wonder if it's even thread-safe to send messages directly, or if that might need a workaround. I'll have a look at what BFG does.
-
Thanks, but it is easy enough to reproduce it. The crash happens in the copy operation when copying decal vertices to the mapped temp vertexbuffer. It appears as if the vertexbuffer in that code path is not properly initialized; several of its parameters look way off. Strange, though, that this only surfaces in this very specific instance and not generally. After all, it's not like there are different vertexbuffers for the general scene and for decals...
So yeah, I know where the crash happens. I don't fully understand the why, yet
-
Thanks, I'll look into it.
-
2
-
-
Just to make sure: it doesn't happen with svn trunk?
-
1
-
-
Been a while, but a small update: I updated my vertexcache branch with a "fix" for the problems when loading savegames. I actually disabled the pre-generation of static interactions as it seems to be broken when loading a savegame. Not sure why, but disabling it helps and doesn't seem to have an impact on anything else. As far as I can tell, everything appears to be working now with the BFG style vertexcache. Framerate impact is minimal; it does seem to bring a few extra frames in some tight spots, but nothing really noticeable.
I'm not sure where to go from here. Should I merge it back to trunk? Initial tests look fine, but it is a significant change and might have some hidden problems or bugs I didn't spot yet. However, it is kind of an important step before porting further BFG changes, so getting it into trunk would be helpful to avoid regular merge conflicts with upstream changes.
Let me know what you think. If you want to try it out for yourself, the code is here: https://github.com/fholger/thedarkmod/tree/vertexcache
-
2
-
I'm working on a VR version - early alpha
in The Dark Mod
Posted
You're probably right, but it's worth a look, anyway
In Rightful Property, I also approach parity between frontend and backend. Would have to optimize boths of them to get any further gains... Not so sure if the backend is GPU limited, though. I'll have to do some more profiling.