Jump to content


Photo

I'm working on a VR version - early alpha


  • Please log in to reply
316 replies to this topic

#301 duzenko

duzenko

    Advanced Member

  • Active Developer
  • PipPipPip
  • 986 posts

Posted 11 December 2017 - 06:41 AM

I guess I'll need to double-check that the vertexcache changes don't break shadow mapping.

Don't worry about shadow maps, I will look into that myself after trunk merge
...

Trunk shows no change in fps with glgeterror skipped on AMD. Will clone your git and give it a try.

...

First impressions: buttons in the main menu flickering when hovering mouse over them?

...

Rightful Property won't load - stuck somewhere in image load.


  • Anderson likes this

#302 cabalistic

cabalistic

    Member

  • Member
  • PipPip
  • 144 posts

Posted 11 December 2017 - 07:17 AM

So, I've got a puzzle for you. I experimented some more with parallelization and made some experimental changes to call AddActiveInteraction in R_AddModelSurfaces in parallel or serially depending on a cvar switch. In each case I timed how long it takes. I can clearly see the times go down with the parallel version, yet the time the frontend takes in total hardly changes at all. Goes down slightly in some maps, actually seems to rise in others. Really don't get it. :(


  • Anderson likes this

#303 cabalistic

cabalistic

    Member

  • Member
  • PipPip
  • 144 posts

Posted 11 December 2017 - 07:42 AM

Actually, never mind. The scenes I was just testing that were strongly frontend-limited yesterday or suddenly backend-limited, so that's why I see no improvements. Something strange is going on with those backend timings, I don't get it.

 

Edit: So it seems Afterburner is another thing that somehow eats time on the backend. Very weird...


Edited by cabalistic, 11 December 2017 - 07:55 AM.

  • Anderson likes this

#304 cabalistic

cabalistic

    Member

  • Member
  • PipPip
  • 144 posts

Posted 11 December 2017 - 09:31 AM

Some more careful timing analysis shows that the frontend time does indeed go down in the multithreading scenario. However, the time between two frames (i.e. after backend and frontend finish and until they start again) suddenly increases and eats up any time savings.

 

I investigated more closely, and what suddenly takes a lot more time is unmapping the vertex caches. If I move that inside the backend, then some other operations still seem to block. My current hypothesis is that even though the backend seemingly finishes early, the GL backend is actually still working. And the next (blocking) GL call thus has to wait. So my seemingly amazing savings after commenting out glGetError might just have been hiding the true backend costs, because that way the backend was waiting for frontend instead of GL...

 

At this point it's still an open question whether I can turn the multithreading savings into something tangible.


  • Anderson likes this

#305 cabalistic

cabalistic

    Member

  • Member
  • PipPip
  • 144 posts

Posted 11 December 2017 - 01:34 PM

Well, here's my attempt at parallelizing R_AddModelSurfaces. It works fine, as far as I can tell. Just doesn't help, because the backend (or GL) will still block.

 

https://github.com/f...bf34785ff5eaf1c


  • nbohr1more and Anderson like this

#306 duzenko

duzenko

    Advanced Member

  • Active Developer
  • PipPipPip
  • 986 posts

Posted 11 December 2017 - 03:33 PM

Intel test (github repo)

Map loads - whew!

Fps is lower than trunk - 36 vs 46.

Second load aborts with error: Not all interactions removed.

This was with the last commit before TBB addition.

Ignore gl errors shows no impact on fps to me.

Console quit hangs in idSessionLocal::WaitForFrontendCompletion


  • Anderson likes this

#307 cabalistic

cabalistic

    Member

  • Member
  • PipPip
  • 144 posts

Posted 11 December 2017 - 04:04 PM

Interesting - and disappointing. Thanks for testing. Was this on Rightful Property? What settings did you use for shadows etc.? There's also a commented line in RenderWorld.cpp:1498 that you might try to enable. It pregenerates some of the static interactions and might take some load of the system, but it causes problems with savegames I haven't yet tracked down.

 

As for the error, I'll have to look into that. Might be some missing cleanups, or just an oversight with the new interactionTable.


  • Anderson likes this

#308 cabalistic

cabalistic

    Member

  • Member
  • PipPip
  • 144 posts

Posted 12 December 2017 - 07:17 AM

So I just tested this with the two devices I have with Intel graphics.One is my work notebook (it's technically an Optimus hybrid of onboard Intel 530 and a GTX960m), the other is my GPD Win (Intel Atom with onboard graphics).

 

First of all, I cannot reproduce any framerate drops in Rightful Property. The GPD Win goes from 19-20 fps to 21-23 fps. The notebook stays just under 50 fps in both cases. Looking at the logs (r_logSmpTimings), I can see a fairly significant reduction in frontend drawing duration on the notebook, which does not increase the frame rate because the backend stays the same and limits it.

 

Unfortunately, the notebook also shows some serious graphical artifacts with the vertexcache version. I tried different versions of the Intel driver to no avail. The GPD Win is fine. The Nvidia card on the notebook is also fine.

 

You did not see any visual artifacts, right? They were fairly noticable, so you'd probably have mentioned them. As for the performance, can you give me more information about the graphical settings you are using? Resolution, AA etc. as well as shadow maps or stencil, ... And what build are you using, release x86 or x64?

 

I'm not sure where to go from here. If the changes cause performance drops or even visual artifacts on some machines, then I'm not sure we want to apply them. But I don't really have a clue how to fix either.


  • Anderson likes this

#309 duzenko

duzenko

    Advanced Member

  • Active Developer
  • PipPipPip
  • 986 posts

Posted 12 December 2017 - 02:56 PM

Maybe leave this for now and return later with a fresh head



#310 cabalistic

cabalistic

    Member

  • Member
  • PipPip
  • 144 posts

Posted 16 December 2017 - 03:04 PM

*
POPULAR

In the meantime, I finally took the time to port my actual VR code from the 2.05 codebase to 2.06. Performance is about the same, as far as I can tell. Not great, because it will cause reprojection at one point or another in most maps, but at least some lighter maps might be very playable.

 

I also experimented with changing the vertexcache buffers to persistent buffers, i.e. buffers you don't have to unmap to draw from, which eliminates driver syncing overhead. It doesn't improve performance per se, but with the syncing overhead of glUnmapBuffer gone, I can now actually reap some benefits from parallelizing the frontend. Nothing spectacular, but for VR, every bit counts.

 

Of course, persistent buffers are an OpenGL 4.4 feature, so this probably won't find its way back into trunk.


  • duzenko, Anderson, Abusimplea and 2 others like this

#311 cabalistic

cabalistic

    Member

  • Member
  • PipPip
  • 144 posts

Posted 25 February 2018 - 11:56 AM

*
POPULAR

Haven't posted here in a while, because I haven't had much time, and progress has been slow as a consequence. But I'm still working on it and still working on getting performance to another level.

 

So far, I have been copying the BFG style approach to stereo rendering by simply doing each eye frame individually, meaning that both back- and frontend basically have to carry double the load. And that causes problem in many places where the CPU load just is too high to do double the load at 90 fps. So instead I'm now aiming to do things smarter. The frontend will only assemble a single view from the head position, which is then rendered twice with slight offsets for each eye. That already saves the double load on the frontend and is already working, aside from a few minor quirks.

 

But to truly profit from that, I also need to lower the CPU load on the backend side. To do that, I have been working on an all new OpenGL4 renderer, which is now in a state where it can render all basic elements of the game. It doesn't do any advanced stuff, yet (no soft shadows or advanced interactions etc.), and it won't until I think I might actually have some room in stereo rendering for it. But what it does, it does with less CPU overhead than the standard renderers, which is good and boosts the VR framerate in tight situations. Also, I can now make use of fancy new OpenGL features to basically render both eye views with a single pass, which will further reduce CPU overhead. So I'm cautiously optimistic that after I've done that, performance will be up at a level where I deem roomscale viable, even if it may not be perfect :)


  • AluminumHaste, duzenko, nbohr1more and 4 others like this

#312 Bienie

Bienie

    Member

  • Member
  • PipPip
  • 147 posts

Posted 25 February 2018 - 03:45 PM

So glad to head that! I would think minimizing the CPU bottleneck would be the key to TDM's performance in VR, since that seems to be where it already is in standard TDM. Best of luck in your endeavours and I can't wait to one day jump into TDM-VR!



#313 BuckleBean

BuckleBean

    Member

  • Member
  • PipPip
  • 51 posts

Posted 27 February 2018 - 11:27 AM

That's great news! I still play missions using your previous implementation. Looking forward to where this goes!



#314 cabalistic

cabalistic

    Member

  • Member
  • PipPip
  • 144 posts

Posted 28 February 2018 - 03:02 PM

Great to hear the initial alpha is finding some use :)

Just to manage expectations, though: due to current time constraints, it's unlikely that any new release will be ready before May, and that will still be a seated version. So please be patient with me :)


  • Bikerdude, Judith, Anderson and 1 other like this

#315 Bikerdude

Bikerdude

    Mod hero

  • Member
  • PipPipPipPipPip
  • 19708 posts

Posted 01 March 2018 - 03:38 AM

Ive been trying to get my best friend to play TDM for years, seeing as he now has an Oculus rift, this might be the push he needs to try it out.



#316 dracflamloc

dracflamloc

    Member

  • Member
  • PipPip
  • 15 posts

Posted 16 March 2018 - 05:32 PM

I am really looking forward to this continuing. Even if progress is slow due to other commitments, thanks for working on this!



#317 Dram

Dram

    Disco Inferno

  • Campaign Dev
  • PipPipPipPipPip
  • 7455 posts

Posted 27 March 2018 - 02:13 PM

Just thought to chime in, thank you for working on this, I have a rift my end too and look forward to giving this a whirl!


  • Anderson likes this




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users