Create an account on the HP Community to personalize your profile and ask a question
01-21-2018 04:27 PM
I have a couple virtual machines with passed through NVIDIA GTX 10xx series Pascal based cards. I'm currently using an HP RGS competitor in order to use hardware encoding to present this desktop to my thin clients. I have multiple HP T730 thin clients with NVIDIA Quadro series cards that support NVDEC.
My question is, does HP support NVENC using the GTX series cards and can RGS do NVDEC on the client side? I know I'm supposed to be able to enable the GPU option after enabling AVC compression, however no option to specify hardware encoding/decoding exists within the RGS software (at least as far as I can tell)
My T730 thin clients are currently running Centos 7.4 but if I need to acquire a copy of ThinPro in order to enable this feature, I would be willing to do so.
Solved! Go to Solution.
01-23-2018 08:16 AM
I know that NVENC wasn't working with my GTX card last time I tried the product, because of extremely high CPU usage on the sender (attributed to RGS). At the time I didn't have a card capable of NVDEC on the receiver side but I figured that wouldn't matter to the sender.
01-24-2018 07:56 AM
I did some checking on your question, and have been informed that this should work with Win 10. Thin Client uses Win 10 IoT. It would be interesting to know if 7.4 works on Linux or ThinPro.
I work on the behalf of HP.
01-26-2018 07:18 PM
Finally got around to more testing. I am using Windows 10, latest revision (1709) on the VM.
The logs on the sender side are suggesting that my GTX 1080 is using the microsoft basic render driver . I don't believe this is the case. According to the GeForce Experience application, Windows' Device Manager, and the NVIDIA Control Panel, I am using the latest NVIDIA WHQL Display Driver (390 something or other, released January 8th)
Is the render driver separate from the display driver? Is it tryin to tell me the NVENC feature is unavailable?
On my CentOS receiver box I upgraded to a Pascal card, (Quadro P400) which according to NVIDIA's compatibility matrix fully supports NVENC and NVDEC for the H264 codec. I also decided to do a clean install of CentOS 7.4 on the thin client to make sure everything was in order. It is running the same NVIDIA driver as the sender (390 something or other) and I installed the CUDA Toolkit from NVIDIA's repositories as well to ensure that the NVENC and NVDEC features would be available. According to the logs on the receiver's side, my P400 appears as "unknown" to RGS and so it defaults to software decoding.
Currently I'm installing the CUDA Toolkit on the Windows 10 Sender, in case this is necessary for the RGS program, and plan to reinstall the NVIDIA drivers as well. Are there any techs available this week that might be able to remotely assist me? I'm loving the product, I think it's really cool, I'm just having a tough time getting it to use NVENC and NVDEC which are two major points of importance for my implementation.
01-26-2018 07:30 PM
I forgot to mention, I uninstalled Win10 IOT on the receiver terminals and replaced it with CentOS 7 because the version of IOT that was installed would not install my Quadro card's drivers due to its age.
That and I honestly prefer using CentOS on the client side if that's possible, if not I will look into the reinstallation of Win 10 IOT. Hopefully that can be a last resort, I'm much more experienced administering and locking down Linux terminals and I much prefer them.
01-27-2018 11:52 AM
Hey! I did some more testing yesterday night and today, I know, working on the weekend, something must be wrong with me.
Anyway, I discovered that I had AVC Compression seleted and I think that's why the VM was ignoring my GPU and not using NVENC. So now, as far as I can tell, NVENC is working, just need to figure out how to check up on NVDEC on the client side!
I also need to figure out how to run the receiver in fullscreen mode by default and I need to get USB passthrough working. Once I've got this stuff figured out I think I'm ready to start talking to sales.
Thank you Kelly for your earlier posts. I used the debug tool on the sender to kind of figure out what was going on!
01-30-2018 09:41 AM
Glad things are going better. The RGSbugreport is helpful for troubleshooting. I do have a document that may help you in setting up passthrough with VM if you are still having any issues, however it is more for Windows. Also, we don't support Remote USB with Linux. The sender must be Windows based. Receiver can be Window or ThinPro based.
There are some settings in the rgreceiverconfig file or the ReceiverConfigApp.exe that if enabled, you snap the remote display window when close to the edge of the screen, or try going borderless. If you have match receiver resolution and layout selected in the receiver that should allow you to match your receiver setup.
These are located in the rgsenderconfig file: If trying any of these, make sure to uncomment, change setting, save, and stop and restart the sender for the settings to take effect.
## If ConfigureVmwareDisplaysForBestPerformance is on, then (on Windows Vmware Systems with Nvidia Graphics)the
## Vmware controlled display will be turned off and the Nvidia displays will be turned on at the start of an RGS connection.
## This should allow better compatibility with RGS's Nvidia Comparitron.
## This setting relies on ConfigureVmwareDisplaysForBestPerformance being turned on. If they're both on, then the VMware display
## will be turned back on when RGS disconnects, so that the vSphere console can be accessed properly. Note that this property may
## mean that windows are moved around in between RGS connections as a side effect of Windows activating/deactivating displays.
## This property will allow enhancements in RGS resolution matching for Windows machines with Nvidia graphics.
## Valid settings are on, off, and auto.
We generally set this last property to "on", not auto.