High End PC unable to render Domain without hanging and flashing screen


#1

Hi, I am a long-time SL user 8+ years and have a high-end PC that is not working with High Fidelity.
My experience is nothing like the sample photos of the domains. My HF hangs, the screen flashes white, loading and rezzing is horrible. I cannot find any instructions how to configure or debug what’s going on.

My Setup:
Quad-core i5-4690K @ 3.5GHz
32 GB Ram
64 bit Win 7 Pro w/ SP1
No audio in
No HMD
dual NVidia GTX-980TI in SLI mode (each with 6GB VRAM)
Comcast 100Mb/s down
Dell 34" Curved Monitor

Suggestions?


#2

I don’t think Hifi supports SLI. But I do not know if thats what is slowing you down.

One 980ti is more than enough though.


#3

I guess I could unconfigure the SLI or pull one of the GTX 980TI’s and retry it


#4

Gameworks VR user here.
Check your driver first. Seems like a no brainer, but best to get that out of the way first.


#5

@Ron.Khondji is right, we do not yet support SLI. But it’s on the roadmap!


#6

Okay Thanks, I want to participate so I will unconfigure the SLI… I only set that up since I bought 2 NVidia cards by mistake and thought “What the heck”. I don’t do anything that makes use of SLI.
Thank you!


#7

Doesn’t Gameworks engage by default when using an HMD?


#8

Okay I turned off SLI and set the GTX980 to balanced between performance and quality and that made a huge difference… probably along with having most things cached already. I suspect if I set it to performance it would even be better. I actually saw everything in the sandbox and even saw another avatar for the first time. Couldn’t communicate, didn’t hear anything… so becoming productive in HF is going to take some more time and a vertical learning curve. To bad there isn’t a beginners (“Dummy’s”) guide. I have been reading the docs and also agree that some form of text interaction is crucial to getting people to adopt this VR.


#9

Only if your program (or render engine) supports it.
We would need to add custom support for it to work, and it would only work on Nvidia GPUs.
I doubt we’ll ever support GameWorks but instead we’ll build our own version of it that we can more easily port to different plateforms.


#10

Awesome, glad it works!

Regarding audio, you might want to go enable “Settings > Advanced” and make sure that “Audio > Devices” is configured correctly.
You also have a mic icon in the top right you can click on to enable/disable your mic.

Re GameWorks: I just talked with @sam, our lead graphics engineer that told me we could eventually support some part of GameWorks, as apparently it is cross GPU now. I think PhysX would be an interesting one to support.


#11

That was definitely me I talk to you and everything glad you’re getting sorted out


#12

It seems Vulkan support is much better than just SLI support because Vulkan can use multiple GPU of different vendors simultaneously and transparently by design.


#13

Vulcan is definitely something we’ve been looking at, and has had @sam excited about since its announcement.
Currently we have one unified OpenGL backend for all platforms.
But our render engine was specifically designed to be able to have different backends to support different rendering technologies, so it’s something we’ve had in mind for a while.
In the future one could imagine us having an Vulcan backend for new GPU/drivers, an OpenGL backend for older ones, a Metal backend for mac, etc.
But that’s probably not something that’ll happen in the next few months.


#14

If High Fildelity engine will be nvidia-only instead of support of standards it will be fail. I recommend to make Vulkan rendering engine (all videocards from minimal system requirements of High Fidelity support it right now) and Bullet for physics. It will work good everywhere. Nvidia Gameworks support is not a good idea because of significant performance issues and a lack of standardization (see The Witcher 3). Of course Vulkan is more complicated to programming graphics engine than OpenGL since its some sort of version of OpenCL. But advantages (outstangind multiplatform performance, standard API, native multigpu support even with videocards of different vendors at single PC, etc.) are much more significant than nvidia-only support.

I am interested to see arguments of @sam why closed and non-standard solution is better than open and widely supported one, especially in open source project.


#15

Actually there are some Gameworks features that we could definitely take advantage of, like the multi-resolution viewports. Unfortunately in the current Gameworks VR release they’re only exposed to Direct3D, so we can’t use them.


#16

We already use Bullet for physics, and as I said in my previous post, we are planning on building a Vulcan backend eventually.

If High Fildelity engine will be nvidia-only instead of support of standards it will be fail.

I never it would be Nvidia only, we support every type of GPU right now, and will continue to do so.

I am interested to see arguments of @sam why closed and non-standard solution is better than open and widely supported one, especially in open source project.

Again I never said that, I actually said we would build our own GameWorks like library, but that since it appears to be cross-platform and is mostly (fully?) open source now, we could take advantage of some parts of it on the hardware that supports it.


#17

Requiring nVidia gameworks features would be bad. But I disagree that simply supporting them would also be bad. Bear in mind that most modern GPU functionality that you see in APIs like OpenGL 4.5 and Vulkan 1.0 actually started out as some vendor’s extension. Lots of extensions were mad and then never really got anywhere, but some extensions were created and used so widely that it made sense to integrate them into the code API.

In particular, since VR is so new, it would actually be very surprising not to see lots of extensions related to it, and again it would not be surprising to see them (eventually) integrated into Vulkan, OpenGL and Direct3D as core functionality. But eventually can be a pretty long time, so writing some custom code that interacts with a vendor extension is perfectly reasonable as long as you

  • Get some significant benefit out of it
  • Have a fallback path for when the extension isn’t available
  • Thoroughly test both paths

#18

Then you are very lucky because you can already use such library (100% open source and cross platform): http://gpuopen.com/
You dont need to develop a new one. This library was developed by AMD but it will also work with nvidia hardware because it based on open standards and technologies. I recommend to consider this option. The only issue is a lack of OpenGL support. But this library has Vulkan support which is nearest future of graphics.


#19

Some additional words about GPUOpen:

You can find among these libraries also DX11-only things like TressFX (direct compute). Of course its not good to use these things, and they are presenten in the library only because AMD just opened them. I expect similar things for OpenCL in future as a part of GPUOpen because DirectX 11 is obsolete technology and DirectX 12 have failed as widely used API.


#20

FWIW crossfire on ATI cards seems to work well – i have dual r9 390s at home. some SLI 1080s when i outgrow those, i hope!