Streaming host trying to use quicksync instead of nvidia causes hard crash

[Greg]

For some reason since the latest beta update the steam client on the host attempts to use Quicksync over the Nvidia encoder for steam streaming. This was completely verified by the streaming log. This results in the stream instantly crashing

In order to resolve the situation I had to run display driver uninstaller on the Intel graphics card, didn't bother with a restart. Streaming worked again immediately.

I truly think it would be useful if we had a dropdown list of available encoders that we could select from in the host settings instead of "hardware encoding on or off"

To summarize : There is a huge conflict between quicksync and the nvidia encoder.

[henryg]

Was the Intel GPU actually enabled, or just installed but not connected to a monitor? Do you have any recent files in your Steam\dumps folder that you could upload somewhere?

QuickSync should not have caused a crash like that. We have found that on systems with both QuickSync and AMD hardware encoding, QuickSync performs better and has less framerate impact. NVidia is less clear-cut and so we can switch the priorities around again for that case.

[Greg]

The quicksync GPU was installed and enabled. DDU was supposed to prevent it's reinstallation by windows 10 but it happened anyway. It was NOT connected to a monitor though.

Unfortunately once I fixed the issue I immediately started playing games (it was 3 AM and I was done wasting time with it). I can take a look at my dump folder and see if there is anything dated from last night. The streaming logs are definitely gone though.

I can say for certain it was absolutely attempting to use the DWM Quicksync encoder though over the Nvidia encoder.

Edit: While I understand the "windows" intel graphics drivers may not be completely up to date I have never installed the official quicksync drivers in the past so they were sufficient before.

[Makoto]

Nice to see the priority changed for QSV !

I'm not really experienced with NVENC, but we are closer to the right HW encoder priority chain and it should be something like QSV > NVENC > AMF or NVENC > QSV > AMF, but i've seen that QSV is superior to AMF (that's for sure) and NVENC (there's a thread dedicated to compare them: https://steamcommunity.com/groups/homestream/discussions/0/613935404000578093/ )

On a side note, i believe there's no need to connect a fake monitor on Win 10 to enable QSV (that's why Greg tried to remove the drivers i believe)

[henryg]

For the next build going out today, we've flipped it back to both NV and AMF ahead of QSV, because we think we found a performance improvement on AMF (technical: performance drops if we capture directly from the output buffer, so now we create a temporary GPU staging buffer and copy the whole screen to that before compressing) and want to try it out.

[Greg]

I appreciate you keeping us in the loop on this.

The AMF changes make a lot of sense to me though. It sounds like the final screen rasterization was being blocked by the AMF encode operation lowering the overall framerate?

Could this by why I (incorrectly) assumed that AMD did not have "dedicated" encoding hardware?

Another Edit: I was investigating inside of my device manager and noticed that there IS a "second" monitor "attached" to my system. Nothing is actually physically plugged in though.

The only explanation I can think of for this is the "splashtop desktop streaming" software that I use. Unfortunately this is the most consistent tool i've found for RDP with steam streaming as both teamviewer and windows RDP have a tendency to lock the computer afterwards.

Is there anything I can do to perhaps help resolve this incompatibility?

I took a look at my dumps folder and unfortunately there are none because steam on the host PC would not crash. It was the streaming client that would crash right off the bat. Unfortunately I dug around a bit and I can't find a dump folder on OSX? Any suggestions where this might be?

[Makoto]

Thanks for the infos henryg, i'll test that as soon as the build is available :)

[Greg]

Well I went and reinstalled Quicksync hoping to reproduce the problem and get some crash logs for you guys but the update hit and it works perfectly fine. Thanks for the quick fix.

[Makoto]

Not sure if the performances improvements on AMF you were talking about are on the latest beta build (30 oct), but after some tests there's no change at all, still 3% to 10% frame loss no matter what game, bitrate, encoding method is used, it's even crashing on some games after reaching 50% frame loss.

[Greg]

The optimizations that HenryG was talking about should improve the Frame RATE (FPS).

Frame/Packet LOSS is due to network issues. It shouldn't have much of anything to do with the encoder itself. I'd suggest trying to wire both your link and desktop PC. Something tells me you have both of them on WiFi if you're encountering that much loss.

[Makoto]

No, actually that's related to the encoding, there's no packet loss (i'm using wired gigabit network).
The frame loss can either be because of encoder performance, network or decoder, in that case i'm sure it's related to the encoder, QSV and Software are displaying a solid 0% frame loss.

[Greg]

Originally posted by Makoto:

No, actually that's related to the encoding, there's no packet loss (i'm using wired gigabit network).
The frame loss can either be because of encoder performance, network or decoder, in that case i'm sure it's related to the encoder, QSV and Software are displaying a solid 0% frame loss.

Is your "estimated bandwidth" meter moving above 30 mbit/s with AMD hardware encoding enabled? It's completely broken with Nvidias. If you have sub-optimial network conditions the stream will be unable to compensate if thats the case.

What GPU do you have exactly? And how much System RAM?

I suppose it could be possible that in creating a new render target(this is what HenryG explained above) for streaming you are blowing the cap on your memory. Games generally allocate as much as they can. If all of a sudden you need an extra 15MB (I know this sounds small but if you're maximizing your memory usage potential it's really not) of graphics ram that was unaccounted for I could possibly see that becoming an issue.

If the FBO (Render target) creation exceeds either system RAM or graphics RAM there is a very good chance it will be paged out. If this were the case then the copy operation into the framebuffer as well as out to the network could be affected drastically.

This is really the only thing I can think of that would cause the entire pipeline to stall so hard that it would drop a percentage of your frames. Either this or the copy operation from the framebuffer is taking far longer than expected. This is all with the assumption that it's not something introduced by steam itself.

-- Keep in mind I know nothing about valve's internal implementation though.

[Makoto]

I understand what you meant, but i hope that's not the case, my system specs are quite good and i don't see why it should cause such bottleneck or else it will not run on many systems.

I also ran some test to see if the bitrate of the video is the issue, but it's not, even on 5MB/s the encoder struggles to deliver 60fps.
I also noticed that sometimes the bitrate went haywire (reaching 50 or 60MB/s even if i cap it at 30MB/s), it may be because the framerate is taken into the calculation, not sure about that.
For example it you have a 30fps capped game, your bitrate will be set at 15MBs if you set it at 30MBs in steam settings.
But for me it's a minor and random bug and i didn't notice it in the latest steam beta.

I've seen that the people behind OBS recently included VCE support and saying that VCE 1.0 and 2.0 (GCN 1.0 and 1.1 cards) are extremely limited and they could not achieve 1080p@60fps with decent encoding quality, they are somewhat limited to 45fps max.
This could be the cause so this problem may never be fixed entierely i'm afraid.

Here's the source for OBS: https://obsproject.com/forum/threads/obs-branch-with-amd-vce-support.13996/


For info here's my system specs:

R9 290 w 3GB
16GB system ram
Core i5 4670k @4ghz
Win 7 64bits
System runs on SSD
Gigabit network

[Greg]

Shouldn't be paging on that. Is the issue universal with all games?

I used an AMD R9 290 to stream almost all of my games from July 2014 - January 2015 and during that time I definitely noticed a nice drop in frame rate and quite a bit of stuttering. It was bad to the point where I wouldn't stream anything except "slow" games.

I hate to say it, and I had to come off as a Fanboy but both my R9 290's were crap. Even when I wasn't streaming those cards would choke and stall and want to kill themselves. I screwed around with them for 6 months straight and I honestly wish I just bought the right card to begin with.

That actually reminds me though, have you checks the thermals on your card? The R9's are notorious for running right at the 94C mark. At 95C they throttle themselves HARD. It's possible your frame loss is occurring during a period of throttling. This is mostly what was causing my R9 to stutter. I had to manually crank the fan up to 80% and keep it there. The card would run at about 75C then.

Truthfully if you want a smooth streaming experience I'd switch to Nvidia. I remember looking at my perf monitor after installing my nvidia card and it was completely night and day. Instead of the entire graph on the right being a bunch of jagged crap it's one nice smooth line all the way across at all times.

If you need some convincing check out the perf overlay in this screenshot. I'm sure if your AMD card looked anything like mine it looks disgusting compared to this. This is also rendered in 4x DSR so the GPU is cranking pretty damn hard.

http://i.imgur.com/HEFUywt.jpg

[Makoto]

Maybe i'll switch to nvidia one day, but not on this card gen, their price here (france) is totally crazy compared to AMD ones, the next generation maybe.

QSV is the way to go in my opinion, too bad it's poorly implemented in IHS and Win 7/intel drivers, one of my option is switching to Windows 10 because i've heard it handles QSV better, but again Windows 10 has its own problems.

The thermals are in check, i've mounted an Accelero xtreme III on it, it never reaches 70°C at full load.

[Greg]

I hate to say it but the next generation of Nvidia cards are going to be fun, to say the least. I'm not sure where they're going with this NVLink stuff but I fully expect to have to buy a new motherboard. With all the crazy architectural changes they're making I'm going to fully assume it'l be quite buggy for the first year or two.

I'm looking forward to it personally, the pascal architecture should bring some dire-needed technology which would essentially close the gap between PC and console graphics hardware. Consoles have a slight advantage here because GPU memory can also be mapped into system RAM. In fact for steam streaming itself this should be a HUGE bump in latency.

As an end user, I wouldn't expect it to work 100% for a quite a bit of time though.