As part of my work on a VR port, I have been spending some time looking at the Doom3 BFG edition code for opportunities to improve performance. A core concept in BFG is a vastly different vertex cache, which I've been working on porting to TDM for a while. I believe it is a worthwhile change and will make porting additional improvements from BFG much easier in the future.
I finally think my port is ready and would like to merge it, but given the scope of the change, I'm looking for:
- testers to rule out any unforeseen problems with the change and
- reviewers from the team to actually approve or disapprove the change.
Help with testing
For the testers, I've prepared a 64bit Windows test build which can be downloaded here: https://github.com/f...texCache_v3.zip
It requires 2.06 beta (or trunk) assets to run and should be compared to the current beta build. I'm specifically looking for:
- problems of any kind (particularly rendering artefacts or issues with custom maps) that are not present on the current beta build
- performance changes. From my own testing on a couple of different machines and a few select scenes, I found that performance stays roughly the same with a minor framerate improvement here or there. However, duzenko reported a loss of performance, so I'm looking for a wider assessment of whether this change hurts or helps.
Help with reviewing the changes
You can review the proposed changes here: https://github.com/f...od/pull/3/files
The change is based on the BFG source code, but I refactored it because the original implementation had a lot of code duplication and functionality that we don't need.
My motivations for changing the vertex cache is as follows:
- It allows us to get rid of the secondary shared GL context for the frontend. Less syncing overhead that way.
- It allows for further parallelization of the frontend. I've already experimented with this a bit, and I can indeed cut off more frontend drawing time, although the effects are currently limited in most cases because the backend then becomes the bottleneck.
- My findings suggest a minor performance improvement from the new implementation
- Although not a strict requirement, this change should make it easier to port further improvements from BFG, in particular GPU skinning, which would reduce the amount of vertex cache needed and thus further reduces unnecessary memory syncing between CPU and GPU.
There is, however, a potential drawback:
- The new approach always allocates fixed size buffers on the GPU, which has to be sufficiently large to accomodate all maps and scenes. This means that, on average, GPU memory consumption is higher. At the same time, it also places a hard upper limit on the amount of static vertex data that can be used in maps, whereas the current implementation is more flexible. Changing the upper limit requires a code change.
Finally, two open points in the review:
- I ported a function idInteraction::CreateStaticInteractions, which is supposed to offload static interactions into the static buffers to not have to (re-)generate them every frame when they are needed. It works in principle, however, when loading a savegame, these interactions are not working for some inexplicable reason. Therefore, this function is not currently called; performance-wise it didn't really make a difference, but I'm still investigating how I can get it to work with savegames.
- There is also some ported code that is supposed to create static shadow caches for models. This is commented out right now, because it just doesn't work.
In any case, I'm looking for team member opinions on whether we want this change or not.
Thanks to everyone for helping out!
Edited by cabalistic, 29 December 2017 - 01:07 PM.