Testers and reviewers wanted: BFG-style vertex cache

[duzenko 563]

Still getting crashes after a quickload.

If I die and load a savegame AFTER the death there's no crash at all.

Try com_smp 0

[nbohr1more 1887]

Still getting crashes after a quickload.

If I die and load a savegame AFTER the death there's no crash at all.

I'll try to get the latest binaries up at moddb this evening.

[nbohr1more 1887]

Latest binaries are up:

 

https://www.moddb.com/mods/the-dark-mod/downloads/tdm-206-vertex-buffer-beta

[stgatilov 651]

The doubling algorithm creates a problem in Inn Business mission.

After player starts, he usually turns around, which causes two or three noticeable freezes because VBO reallocates.

[cabalistic 384]

Freezes? That's odd, I haven't seen that at all. At most you should see some missing models for a frame, but other than that it just creates a new buffer. There's nothing that should freeze.

 

In any case, you can increase the initial allocation for the buffers by setting r_frameVertexMemory and r_frameIndexMemory. The higher the value, the less likely a resize is going to happen. The tradeoff, though, is that you'll waste VRAM on many missions. Although, if you have a dedicated card with 2+ GB RAM, that shouldn't be an issue.

[duzenko 563]

Quick question.

We used to have a cvar controlling if we want indexes to be buffered - is that gone now?

[nbohr1more 1887]

Do the frame memory values also have an effect on ambient cache misses?

 

If not, perhaps we need a smidge of latency and some more graceful fallback?

 

I wonder if there is a way to prime or bias VBO cache with predictive operations.

[nbohr1more 1887]

Update 4 is up.

 

Major fix for collision issues with player movement.

 

https://www.moddb.com/mods/the-dark-mod/downloads/tdm-206-vertex-buffer-beta

[cabalistic 384]

@duzenko: Yeah, that cvar is gone.

 

@nbohr1more: If the cache memory is exceeded for a frame, then some cache entries will probably be invalid, so that would trigger those messages. But it's not the core of the issue.

 

What do you mean with priming? Figuring out a good initial value for the frame-temporary buffer sizes? That might be possible, but I see no easy way to do it.

[stgatilov 651]

What do you mean with priming? Figuring out a good initial value for the frame-temporary buffer sizes? That might be possible, but I see no easy way to do it.

One possible thing would be to rotate player's view direction around before starting game.

It won't save you from resizes during game, but will probably remove them at the very beginning.

 

More reliable solutions are more complicated, i.e. allocate VBO in chunks instead of single array.

[duzenko 563]

One possible thing would be to rotate player's view direction around before starting game.

It won't save you from resizes during game, but will probably remove them at the very beginning.

 

More reliable solutions are more complicated, i.e. allocate VBO in chunks instead of single array.

Do we still pass geometry to backend when we can't upload geometry to VBO in front end? If so, it will trigger spam in the console and annoy people even if they don't notice missing geometry on the render itself.

[cabalistic 384]

Allocating VBO in chunks would bring us right back to where we started. The very core idea of the BFG style cache is *not* to do that. Let's just fine-tune the initial value; I set it fairly low right now.

[stgatilov 651]

Allocating VBO in chunks would bring us right back to where we started. The very core idea of the BFG style cache is *not* to do that. Let's just fine-tune the initial value; I set it fairly low right now.

Why?

Is it too bad to allocate VBO memory in chunks? For instance, with increasing sizes: 1 MB, 2MB, 4MB, 8MB, 16MB, ...

With the old way, each geometry was living in a separate VBO, and we wanted to avoid that.

The problem is that it would be a bit more complicated with chunks, since you have to handle end of VBO and move to the next one, and maybe even allocate it. But it is not too hard: just check if current chunk has enough memory for allocation request, and if it does not, move to the next chunk (making the remains of current chunk unavailable for current frame).

 

Now initially allocated memory is 12 MB for both vertex and index buffers, i.e. 24 MB in total.

Given that only 0.58% of steam users have less than 512 MB VRAM, we can bump it.

On Inn Business, 20 MB is allocated for vertices, and 10 MB is allocated for indices. This is 90MB in total.

If you set 32 MB initial size for both buffers, that would be 192 GB --- is it acceptable today?

There is no thing like swap for VRAM, so even if you don't use these 192 GB, they are still unavailable for textures.

 

 

BTW, size of index buffer should be 2x larger than size of vertex buffer, since a typical triangular mesh has about twice as many triangles as it has vertices.

However, in the Inn Business mission at least, I see reverse thing: the size of vertex buffer is twice as large as the size of index buffer.

Doesn't it mean that converting some assets into indexed form can reduce VRAM footprint by 50% ?...

[cabalistic 384]

The problem is that filling the vertex cache happens on the frontend, and the frontend cannot just switch buffers or allocate them on the fly. This would require an active GL context, and one of the purposes of the BFG vertexcache is to get rid of the shared GL context on the frontend. It is potentially fragile, and it introduces sync overhead which is costly.

In effect, this means that providing the buffers to the frontend has to be done by the backend, or rather in-between frames. But this means that you need to know in advance how much memory you are going to provide. And that's why we are where we are now

 

As for size of vertex vs index buffer: You are comparing number of elements, not size! The size of each entry in the vertex buffer is significantly larger than for the index buffer. Indexes are just 16-bit integers, whereas the vertex at the very least has a position (3x float) and probably also a normal and UV coordinates. So vertex buffer is very likely going to need more memory.

[stgatilov 651]

The problem is that filling the vertex cache happens on the frontend, and the frontend cannot just switch buffers or allocate them on the fly. This would require an active GL context, and one of the purposes of the BFG vertexcache is to get rid of the shared GL context on the frontend. It is potentially fragile, and it introduces sync overhead which is costly.

Ok.

As for size of vertex vs index buffer: You are comparing number of elements, not size! The size of each entry in the vertex buffer is significantly larger than for the index buffer. Indexes are just 16-bit integers, whereas the vertex at the very least has a position (3x float) and probably also a normal and UV coordinates. So vertex buffer is very likely going to need more memory.

I checked it.

Indices are 32-bit, and vertices are always idDrawVert, which includes texture coordinates and a coordinate system. So it is 12 bytes per triangle vs 60 bytes per vertex, giving a ratio 24 : 60 = 2 : 5.

This explains everything

[nbohr1more 1887]

Update 5 is up.

 

https://www.moddb.com/mods/the-dark-mod/downloads/tdm-206-vertex-buffer-beta

 

Fix for some quicksave \ quickload scenarios.

[lowenz 498]

Update 5 is up.

 

https://www.moddb.com/mods/the-dark-mod/downloads/tdm-206-vertex-buffer-beta

 

Fix for some quicksave \ quickload scenarios.

Thanks!

[nbohr1more 1887]

Update 6 is up:

 

https://www.moddb.com/mods/the-dark-mod/downloads/tdm-206-vertex-buffer-beta

 

Fix for the "Click to Start" screen.

[nbohr1more 1887]

Anyone encounter a crash when trying the mission "New Job"? (or any other mission, but New Job is the one of interest)

 

I haven't encountered any crashes on this build but grayman just reported one.

[nbohr1more 1887]

Crashes appear to be for CPU's without AVX support.

 

To fix, please try:

 

com_tempAllowAVX 0

[nbohr1more 1887]

Update 7 is up:

 

https://www.moddb.com/mods/the-dark-mod/downloads/tdm-206-vertex-buffer-beta

 

It should fix the above crash for some users.

 

(I have an affected CPU generation "Sandy Bridge" and yet never experienced this crash...)

[nbohr1more 1887]

Update 8 is up:

 

https://www.moddb.com/mods/the-dark-mod/downloads/tdm-206-vertex-buffer-beta

 

Major fix for AI or animated objects flickering in close range.

[duzenko 563]

Do soft particles work for you when you start TDM with AA on?

[nbohr1more 1887]

After some more testing, the last place I can reliably trigger AI flickering is the end area of Lords and Legacy where LOD popping is very extreme. In most maps we'd never see this amount of close range LOD transitioning but it might be worthwhile to consider some routine to trigger buffer changes along with LOD transitions. It would probably be easier if LOD management were moved to the backend.

[cabalistic 384]

I doubt that. The backend is not responsible for making decisions about what to render, that's the frontend's job.

 

Do you have a savegame or video for me, so that I can actually see what you are talking about?