I'm working on a VR version - early alpha

[cabalistic]

The mod only supports SteamVR right now, so that is to be expected and a good sign, actually. Means it's working.

[Eldrad]

AH! Thanks for your patience.

 

You Dark Mod people have brought such joy and happiness into the world!

[nbohr1more]

Here's how this scene looks to me on a GT 640.

Can you attach your .cfg?

@Nbohre1more, how does it look for you?

 

I'm seeing the same thing Cabalistic sees.

 

With the "Enhanced Ambient" there is flickering and blown-out highlights. With the "Simple Ambient" everything looks just about identical to the ARB path.

[duzenko]

 

I'm seeing the same thing Cabalistic sees.

 

With the "Enhanced Ambient" there is flickering and blown-out highlights. With the "Simple Ambient" everything looks just about identical to the ARB path.

I brought the enhanced ambient glsl to the same color vertex method. Please test.

I will try to look later today at the difference between arb & glsl ambients.

[cabalistic]

Ok, that seems to have gotten rid of the flickering

[cabalistic]

Meanwhile, I've experimented a bit with glMapBufferRange. Changing the frame temp allocs in the VertexCache to that method is straight-forward enough, but it doesn't seem to have any noticable effect. The problem, though, is that the engine also does a lot of "static" vertexcache allocations which are regularly freed again. The BFG engine doesn't even support freeing static vertexcache allocations, allowing it to do all static allocations on a single big vbo, which I'm sure would speed up the engine quite a bit. Unfortunately, the changes to support that are quite significant, and I don't think they are straight-forward to port. But I'll probably try, anyway.

[duzenko]

 

I'm seeing the same thing Cabalistic sees.

 

With the "Enhanced Ambient" there is flickering and blown-out highlights. With the "Simple Ambient" everything looks just about identical to the ARB path.

GLSL ambient shader: ported from ARB minus fresnel

[duzenko]

Meanwhile, I've experimented a bit with glMapBufferRange. Changing the frame temp allocs in the VertexCache to that method is straight-forward enough, but it doesn't seem to have any noticable effect.

Make sure that you're rendering a scene that is driver limited: GPU usage < 90%, r_showSmp is printing mostly dots.

[cabalistic]

Don't think my GPU is ever even close to 50% in the Dark Mod. In any case, my primary interest in getting glMapBufferRange and the changes to static handling is that this will open up further parallelising the frontend.

[nbohr1more]

Enhanced Ambient no longer flickers!

 

Pretty close:

 

Simple:

 

 

GLSL:

 

 

ARB:

 

[AluminumHaste]

Nice.

[duzenko]

Meanwhile, I've experimented a bit with glMapBufferRange. Changing the frame temp allocs in the VertexCache to that method is straight-forward enough, but it doesn't seem to have any noticable effect.

Try the wine cellar in Caduceus of St Alban. I'm playing this mission right now and the shadow calculation of the bottle stand and 2 nearby lights, plus the wobblesky texgens, is putting my Intel on its knees.

[nbohr1more]

This is my go-to stress test scene from Rightful Property:

 

 

 

...but it hits both the CPU and GPU, thus the threading patch is pretty beneficial here.

 

I'm struggling to think of a purely GPU bound scene since shadows are the biggest impact and they provoke skinning operations

on the CPU. Maybe the Cabin with all the fog particles in the 2nd part of Down by the Riverside?

[duzenko]

Lightgem here needs some attention.

I get random but numerous driver crashes when it's enabled.

I can't get my head around how its drawing is synchronized with the main render?

[cabalistic]

It isn't. It happens before the main render on the main thread, while the frontend thread is idling. So basically, it's running exclusively.

 

Hm, unless it's accessing buffers that the frontend wrote to and are still syncing? That's the only thing I could think of...

Do the crashes go away if you disable com_smp?

Edited August 27, 2017 by cabalistic

[duzenko]

It isn't. It happens before the main render on the main thread, while the frontend thread is idling. So basically, it's running exclusively.

 

Hm, unless it's accessing buffers that the frontend wrote to and are still syncing? That's the only thing I could think of...

Do the crashes go away if you disable com_smp?

Not sure when I can test that, maybe not for a few weeks.

But think about this: at the time of lightgem's CaptureRenderToBuffer where is the lightgem draw command - in the frame that the backend has just completed rendering or in the frame that the frontend has prepared for the next backend run?

[nbohr1more]

Possibly related:

 

http://forums.thedarkmod.com/topic/18892-weird-ctd-error-with-svn-capturerendertobuffer/

[cabalistic]

Not sure when I can test that, maybe not for a few weeks.

But think about this: at the time of lightgem's CaptureRenderToBuffer where is the lightgem draw command - in the frame that the backend has just completed rendering or in the frame that the frontend has prepared for the next backend run?

In the one the backend was just using before, but already reset. So what I said before is actually very unlikely. I'm out of ideas for the moment. Need to know if this is related to SMP at all or not.

[Eldrad]

JUST want to say OMG! It is awesome!

 

I can't see the light gem or my equipment but not that much of an issue.

 

Have a bit of flickering with head movements and shadows are in one side of the lens if that helps.

 

Overall it's so awesome to see TDM in VR that I am besides myself with happiness and joy!!

 

THANKS!

[nbohr1more]

Cabalistic, we are seeing a few new bugs with Collision:

 

http://bugs.thedarkmod.com/view.php?id=4613

 

Do your changes allow Collision code to update "trace model cache" (Clip.cpp) in parallel?

 

Maybe we need to "atomic_thread_fence" in there?

[cabalistic]

Update in parallel - no. Update in one thread, read in another - maybe? I don't think it's likely, since I'd expect this should be limited to gametics and frontend drawing, but I'd have to check to be sure.

Though I see that you reproduced the bug with threading disabled...

[nbohr1more]

Looks like you're off the hook unless you know anything helpful about FPU and SSE assembly\intrinsics. We have the culprit.

[cabalistic]

I know nothing about assembly, but have dabbled with SSE before. Wouldn't consider me an expert by any means, though

[cabalistic]

So, this weekend I went ahead and ported the BFG-style VertexCache in full. This means that, instead of two frame temporary buffers and lots of individual vbos, there are now two larger frame temporary buffers and a single static buffer. The static buffer is filled during level load with static interactions and static model data. Everything else is now allocated on the temporary buffers and thus only valid for a single frame.

 

This means that the frontend no longer needs to make GL calls, which also means that it no longer needs the shared context and does not have to sync its GL calls. On the other hand, it also means that it currently probably recreates some vertex caches a lot more often than previously, since they are only valid for a single frame.

 

In practice, the performance appears to be largely unchanged in a Release build. There might be an ever-so-tiny advantage in certain areas, but it's really hard to tell. In debug, performance is significantly worse in some places, probably due to the increased memcpy operations.

 

The whole thing is highly experimental, so I pushed it to a separate git repository for now. You can find it here: https://github.com/fholger/thedarkmod (you need to checkout the branch vertexcache). I think I broke the lightgem rendering, and it may also have somewhat broken loading of savegames. Still, I expected a lot more problems, so that's not too bad

 

Given that the change does not really bring any worthwhile performance improvements, I'd rather not integrate it into the SVN repository in its current form. However, the potential promise of the change is that it should make porting additional BFG features a little easier, and also it should allow to further multithread the frontend renderer. I don't know how much the latter would help, though, because in the bottleneck scenes I'm currently investigating, the backend takes about as much time as the frontend. So at the moment I'll try to find ways to improve the backend performance, first.

[nbohr1more]

Fantastic!

 

I'm not seeing map_buffer_range in use here? Are the temp buffers using a hold and modify pattern? If not, they may still require buffer swapping.

(Not that I'm good enough to evaluate at this level..)