Jump to content

Recommended Posts

Posted

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.

Posted

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.

  • Like 2
Posted

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.

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Posted

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

Posted

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.

Posted

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.

Posted

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.

Posted

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% ?...

Posted

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.

  • Like 3
Posted

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

Posted

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

  • Like 1

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Posted

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.

  • Like 1

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Posted

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?

  • Like 1

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recent Status Updates

    • JackFarmer

      "The Year of the Rat." 
      😄

      Al Stewart must be proud of you!
      Happy testing!
      @MirceaKitsune
      · 1 reply
    • datiswous

      I posted about it before, but I think the default tdm logo video looks outdated. For a (i.m.o.) better looking version, you can download the pk4 attached to this post and plonk it in your tdm root folder. Every mission that starts with the tdm logo then starts with the better looking one. Try for example mission COS1 Pearls and Swine.
      tdm_logo_video.pk4
      · 2 replies
    • JackFarmer

      Kill the bots! (see the "Who is online" bar)
      · 3 replies
    • STiFU

      I finished DOOM - The Dark Ages the other day. It is a decent shooter, but not as great as its predecessors, especially because of the soundtrack.
      · 5 replies
    • JackFarmer

      What do you know about a 40 degree day?
      @demagogue
      · 4 replies
×
×
  • Create New...