Testers and reviewers wanted: BFG-style vertex cache

[duzenko]

I might have found it

bool			CacheIsCurrent( const vertCacheHandle_t handle ) const {
		if( handle.isStatic ) {
			return true;
		}
		return handle.frameNumber == ( currentFrame & VERTCACHE_FRAME_MASK );
	}

If handle is all zeros (think animated models), the function returns true each 4096th frame.

Should it also check for IsValid() or something?

 

Full stack trace

>	TheDarkModNoTools.exe!idVertexCache::CacheIsCurrent(const vertCacheHandle_t handle) Line 138	C++
 	TheDarkModNoTools.exe!R_CreateAmbientCache(srfTriangles_s * tri, bool needsLighting) Line 47	C++
 	TheDarkModNoTools.exe!R_AddAmbientDrawsurfs(viewEntity_s * vEntity) Line 1228	C++
 	TheDarkModNoTools.exe!R_AddModelSurfaces() Line 1357	C++
 	TheDarkModNoTools.exe!R_RenderView(viewDef_s & parms) Line 1164	C++
 	TheDarkModNoTools.exe!idRenderWorldLocal::RenderScene(const renderView_s & renderView) Line 722	C++
 	TheDarkModNoTools.exe!idPlayerView::SingleView(idUserInterface * hud, const renderView_s * view, bool drawHUD) Line 527	C++
 	TheDarkModNoTools.exe!idPlayerView::RenderPlayerView(idUserInterface * hud) Line 833	C++
 	TheDarkModNoTools.exe!idGameLocal::Draw(int clientNum) Line 3664	C++
 	TheDarkModNoTools.exe!idSessionLocal::Draw() Line 2555	C++
 	TheDarkModNoTools.exe!idSessionLocal::DrawFrame() Line 3022	C++
 	TheDarkModNoTools.exe!idSessionLocal::FrontendThreadFunction() Line 3056	C++

[cabalistic]

That could be one issue, but I don't expect it's the entirety of the problem. The limit (frame number wrap) was much higher initially, and I only lowered it in subsequent versions to allow for an increased max cache size. But the problem with caches not being there existed before that, as well, and it didn't change in frequency, far as I can tell.

[duzenko]

That could be one issue, but I don't expect it's the entirety of the problem. The limit (frame number wrap) was much higher initially, and I only lowered it in subsequent versions to allow for an increased max cache size. But the problem with caches not being there existed before that, as well, and it didn't change in frequency, far as I can tell.

So are you going to fix this one?

It happens all the time, always.

[cabalistic]

I'm going to fix the problem, one way or another. I thought that was clear; I don't introduce bugs and then just leave them, hoping for the best Sorry if some earlier posts may have sounded like that; it was merely not the highest priority on my list because I don't really see the flickering geometry myself. (Probably because my machine is fairly powerful and I usually test without frame caps, so the relative shortness of a single frame may probably hides the issue.)

 

And yes, it is quite likely that function needs an additional check.

[duzenko]

I'm going to fix the problem, one way or another. I thought that was clear; I don't introduce bugs and then just leave them, hoping for the best Sorry if some earlier posts may have sounded like that; it was merely not the highest priority on my list because I don't really see the flickering geometry myself. (Probably because my machine is fairly powerful and I usually test without frame caps, so the relative shortness of a single frame may probably hides the issue.)

 

And yes, it is quite likely that function needs an additional check.

No problem, it's just being such a small change I could do it myself and @stgatilov can confirm if it fixes his flickering

You might of course not see the flickering at all if vsync is off and FPS is high enough.

[stgatilov]

I have changed the line locally to:

return handle.IsValid() && handle.frameNumber == ( currentFrame & VERTCACHE_FRAME_MASK );

Both flickering and warnings are gone (at least most of them).

[cabalistic]

Good to know, thanks. And good find, duzenko

 

But there are still some warnings remaining? Another possible occurence is when the cache is exceeded and must be resized. Did any of the remaining warnings coincide with a message that the vertex cache was resized?

[cabalistic]

Ok, it appears to fix all the warnings for me, as well. I committed the fix. Again, good find. I was really afraid this was going to be a much deeper issue...

 

If you do still encounter issues after this, please let me know.

[duzenko]

Do we have a cvar for initial buffer size? If not I would like to add.

[cabalistic]

Yes, we do. r_frameVertexMemory and r_frameIndexMemory. Currently both set to 16 Mb.

[duzenko]

How about vid_restart then? It crashes for me when a map is loaded.

[cabalistic]

Hm, that used to work. I'll try to track down what broke it.

[nbohr1more]

Update 9 is up:

 

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

 

Fix for VBO flicker (finally!), EFX 2.0, Envshot is fixed, reloadImages is fixed.

[duzenko]

Update 9 is up:

 

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

 

Fix for VBO flicker (finally!), EFX 2.0, Envshot is fixed, reloadImages is fixed.

Isn't the exe in your release kinda 2.07 already? Even though it's called 2.06 update?

[nbohr1more]

Yeah. The is pretty much an early 2.07 beta too.

[Bikerdude]

• Fix for VBO flicker (finally!),
• EFX 2.0,
• Envshot is fixed,

Is a change log included with the link on moddb..?

• I think I know what this is, is there a wiki article?
• What does 2.06 ship with..?
• as I would like to know how to use the ENVshot.

[nbohr1more]

Is a change log included with the link on moddb..?

• I think I know what this is, is there a wiki article?
• What does 2.06 ship with..?
• as I would like to know how to use the ENVshot.

1) Yes, moddb now has the latest executable from SVN.

 

2) Instead of defining a bunch of complex variables in your efx file you can use presets:

 

eaxreverb "streets" {
    preset mountains //you can specify number instead of name here
  }

3) TDM 2.06 does not have presets available

 

4) You already used envshot to make the mirror puzzle in The Gatehouse.

They can be used to fake reflections or interiors.

[cabalistic]

Hm, so the crash in vid_restart is caused by the vertex cache buffers not being recreated properly. I fixed that, and the crash is gone. Unfortunately, the static cache isn't being properly refilled even though I called the appropriate code...

Will have to investigate further, but I committed my current progress, anyway.

 

@duzenko: As discussed, I also put the alignment of static vertex allocs back, but increased the alignment to 240 bytes. Without the alignment, it would trigger an assert, which made debug build being unusable for debugging

[nbohr1more]

Hm, so the crash in vid_restart is caused by the vertex cache buffers not being recreated properly. I fixed that, and the crash is gone. Unfortunately, the static cache isn't being properly refilled even though I called the appropriate code...

Will have to investigate further, but I committed my current progress, anyway.

Disabling r_postprocess (bloom) allows vid_restart to render after it completes but it drops out of FBO.

 

I can do what I did for reloadImages and store settings, disable FBO and Bloom then reactivate

settings once the operation completes.

 

It's a hack but it's pretty benign.

[cabalistic]

Good to know, but I'd rather understand the actual problem and fix that

[Bienie]

Any instructions for how to get it to load in VR? Just add the missing assets to the build you uploaded and start? I would definitely like to give it a try and give some feedback/bug reports.

[cabalistic]

Sorry, this build has no VR support at all. The latest VR build can be found here: https://github.com/fholger/thedarkmodvr/releases

However, it is still based on version 2.05 and won't work with 2.06 assets...

[nbohr1more]

Yes, to be clear, the point of this thread and the corresponding builds is to

gain early insight about how moving to Doom 3 BFG style vertex buffers affects

performance and stability from as many different hardware configs as possible.

 

It just happens that the initial work was in an external repo and now it's been merged into our

main SVN for upcoming TDM versions.

 

This means that testers not only help vet the "VBO project" but also are doing a little 2.07

testing.

 

And finally, since so many users have stumbled on the strange conflicting requirements for AA

and Soft Shadows in 2.06, this build acts as a stopgap to allow players who either won't or

can't follow the workaround instructions and live with the caveats of 2.06.

[duzenko]

@duzenko: As discussed, I also put the alignment of static vertex allocs back, but increased the alignment to 240 bytes. Without the alignment, it would trigger an assert, which made debug build being unusable for debugging

I want to add a cvar that controls this.

Reason: undefined behavior when copying more bytes than the source vertices have.

Alternative: allow non-aligned data in your mem copy code (actually I would prefer it).

[cabalistic]

No, please don't. We have way too many cvars already, and they should not toggle between two dubious hacks. Let's fix it properly, instead.

 

I've already looked into it; the tris are allocated by a special allocator which always returns 16-byte aligned memory blocks. So copying with 16-byte alignment is fine, and that's all we really need. I'll just change the method signature to take the original size and the vertex block alignment as arguments instead of using the macro everywhere. Then the block can be allocated to the full 240-byte alignment, but we only need to copy the 16-byte aligned source bytes.