Jump to content
The Dark Mod Forums
Sign in to follow this  
cabalistic

Testers and reviewers wanted: BFG-style vertex cache

Recommended Posts

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++

  • Like 2

Amnesty for Bikerdude!

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.


Amnesty for Bikerdude!

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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.


Amnesty for Bikerdude!

Share this post


Link to post
Share on other sites

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

  • Like 1

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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.

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

Share this post


Link to post
Share on other sites
  • 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.

Share this post


Link to post
Share on other sites

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.

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

Share this post


Link to post
Share on other sites

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

  • Like 1

Share this post


Link to post
Share on other sites

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.


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

Share this post


Link to post
Share on other sites

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.


My Fan Missions:

   Series:                                                                           Standalone:

Chronicles of Skulduggery 1: Pearls and Swine                     The Night of Reluctant Benefaction

Chronicles of Skulduggery 2: A Precarious Position              Langhorne Lodge

Chronicles of Skulduggery 3: Sacricide [WIP]

 

 

 

Share this post


Link to post
Share on other sites

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.


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

Share this post


Link to post
Share on other sites

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


Amnesty for Bikerdude!

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Sign in to follow this  

×
×
  • Create New...