Horizon 7 + Grid K1 vGPU or K5000 vDGA + Blast Extreme = blurry image (works fine with PCoIP)

[JoeUser2212]

I have a really strange issue while testing Horizon 7.0.  When using the BLAST protocol, I'm getting a blurry screen, with blue and red appearing as like a drop shadow effect to the left of items in which they are a component color.  I've tried numerous Nvidia drivers in the 361 and 362 branches, tried it with separate desktop images, and with all vGPU profiles on the K1 as well as vDGA with K5000.  The problem always exists when using the blast protocol and never exists when I switch over to using PCoIP.  Has anyone else seen this issue?

[JoeUser2212]

After even more testing, this appears to be an issue that is linked to the horizon 4 client for windows.  Some testing this evening with a Mac that I was able to borrow showed no issues with the BLAST protocol.  Hopefully this is a known issue that VMWare is working on and will be corrected in the next release of the Horizon client.

[RandyDGroves]

It is also possible that the Mac client is not using H.264 in this scenario. You will have to check the Blast logs to be sure. Note that H.264 inherently creates display artifacts due to its use of a YUV 4:2:0 color space conversion that discards 75% of the chroma information from the pixels. (see:The Importance of Lossless Support). This is why modern remote display protocols use multiple codecs to encode computer displays and use H.264 only where it is appropriate rather than for all content (see: Why You Need Multiple Codecs for Remote Display Protocols).

[JoeUser2212]

This pretty much makes  h.264 encoding and GPU offloading useless for actual business application delivery where the end user experience needs to be workstation equivalent...  Looks like PCOIP won't be going anywhere in the near future, as I need to deliver 4K desktops (single monitor) that can support large video windows at decent framerates, which mjpeg just won't deliver.  PCOIP struggles, even with a higher end thin client like the Wyse P45, so I was really hoping to see h.264 help solve these problems and improve the end user experience.

[RandyDGroves]

In this case, the limit is the PCoIP software encoder not being able to keep up, not the P45. You should try the PCoIP Remote Workstation Card with hardware accelerated PCoIP encoding (See: Remote Workstation)

‌

[JoeUser2212]

I haven't seen one that will support 4K resolutions, including the Apex cards, which is why I was really holding high hopes for h.264 encoding that I could offload to the GPU.  Maybe Teradici will someday figure out how to multithread the software encoder or release hardware that can handle 4K.

[RandyDGroves]

‌We have many customers using 4K displays but with 2560x1440 resolution allowing the monitor to scale up. This works really well with Win7 that doesn't support high DPI displays well anyway. True UHD support from hardware is in the works, though.

[JoeUser2212]

We're running Win 10 in the new environment and a lot of users are now pressing for the curved, ultrawide monitors at 3840x1400 now that a few engineers have them.  The thing that really perplexes me is not fully understanding what is constraining the software pcoip encoder.  It never goes above about 9-10% on a single CPU core.  Here's an example running a 1080p video scaled up to make the pixel change rate on the screen as high as possible, 11FPS but no apparent CPU constraint on the pcoip software encoder.  you can see the offered rate as reported by the thin client.  Bandwidth is set in the registry to 900mbps, max framerate for pcoip and the svga tap are both set to 60.  I'm certinaly open to suggestions on what else could be done to improve this.

[RandyDGroves]

3840x1440 monitors will work with the Remote Workstation card and the P45, but not 3840x2160 (UHD) or anything higher..

The "10%" that is being reported is out of 8 cores, so a single-threaded application like the PCoIP encoder will not exceed 12.5%. Note that CPU1 in your picture is nearly pegged. I'm not sure why it isn't completely pegged, but it is close. Also, the Pipeline Processing Rate Max of 61Mpps is about the max the PCoIP encoder can achieve on a single core. Using a server with fewer, but higher clock rate cores would help.

Also, with a K1, you should not set the max framerate at 60fps. We have found that really slows down the GPU with all the frame buffer requests. I would suggest setting both limits back to 30fps.

One other thing you can try is to set the registry key pcoip.force_lossy_encoding = 1 (REG_DWORD). This can sometimes improve framerate, but does force text and computer graphics to always be encoded lossy. You may want to change the pcoip.maximum_initial_image_quality = 90 (decimal) and pcoip.enable_build_to_lossless = 1 when you do this.

[JoeUser2212]

This particular workstation is using the Quadro K5000 as vDGA, rather than the K1.  Its one reason only a handful of engineers have the widescreen setups (each of us are assigned to a VM pool with manual workstations that have  K5000s using vDGA).  Even with the K180Q profile, the K1 won't support a single 3840x1440 display at native resolution.  As for the workstation card, the specs only make mention of 2560x1440 as the max resolution and I'm a bit confused as to how workstation cards would play in an ESXi server environment.  I'm guessing PCI passthrough?  More importantly, does the Apex 2800 support resolutions higher than advertised as well?  Seems like you know quite a bit about the PCoIP hardware solutions, so I'll ask one more all-important question.  Is 4K support something that will be added with a firmware update to existing adapters (by means of reducing the total number of displays supported) or will it be new hardware (if you have any insight).  Apex would make a lot more sense because I can feed multiple vDGA/vGPU clients while only eating up a single physical slot.

I'm not opposed to going the Apex route if the card has a future, I've just avoided it because it really looked like it might be sunsetting due to increases in monitor resolution.

[RandyDGroves]

I confirmed that the current firmware for the Remote Workstation Card explicitly rejects any EDIDs wider than 2560 or higher than 1600 today. This will be extended to 3840x2160 later this year, but you would have to use 2560x960 to connect to your 3840x1440 monitors today and let the monitor scale up (1.5x). We have numerous customers using PCIe passthrough with these cards (though more of them are on KVM than on ESXi to be honest).

There are absolutely no plans to sunset the Hardware Accelerator Card (aka APEX), however formal support for >2560x1600 is not currently planned for development. Feel free to put in a feature request on the Teradici Community forum to help build the business case for our Product Management.

[JoeUser2212]

We've learned some expensive lessons about "betting on the come" in the past and have old hardware laying around that never made it to production because we purchased based upon a combination of existing features and those that were supposed to be coming soon, only they never did.  Its one reason why we haven't looked at the new Nvidia GPUs even though the K1s we have are getting a bit dated.  We planned to move some Linux desktop solutions into VDI as well, but Nvidia thanked us for our early adoption by abandoning Kepler from Linux vGPU functionality.  AMD pulled the same stunt on us by dragging their feet on putting out an ESXi vSGA VIB for the S7000s we use for lighter duty workloads and we ended up scrappig a pile of them when we needed to move to 6.0 (its when we ended up getting the first bunch of K1s).

I might get more bang for my buck in the interim by doing as you mentioned earlier and just upgrading the CPUs in these hosts to E5690s.  20% increase in clock speed might be enough of a crutch to get me by until there is more certainty around that updated firmware you're talking about and it wouldn't be a loss even if the workstation cards never see that firmware update.

[JoeUser2212]

After a quick verification, the workstation card wouldn't work in the interim anyway.  I jumped on one of the thin clients and manually tried to set the resolution to 2560x1600 and the LG ultrawide monitors we're using won't support that resolution.  Looks like I'm up a creek for the moment and the only real option I have is CPU upgrades or to do away with the widescreens.

One last question.  With the upcoming firmware, would a 2240 only support a single monitor at that resolution or will it replace the existing 2560x1600 limitation and allow for multiple displays?  One persona has already been asking about adding three monitor setup with smaller, portrait orientation monitors on each side of the large widescreen in the center.

[RandyDGroves]

SInce the ultrawide monitors are an 8:3 aspect ratio, the resolution you need to select also needs to be 8:3. The largest that would be supported with the host card today is 2560x960 (not 1600). The next good resolution would be 1920x720. The Zero Client resolution override will not give you these options since they are technically not "VESA standard" resolutions, but they should work just fine. You will have to set these resolutions on the host side using the NVIDIA control panel.

The current Remote Workstation card can support a single 2560x1600 and two 1920x1080 displays if that was your question.

[JoeUser2212]

I was actually referring to a workstation card based on the 2240, which states two 2560x1600 or four 1920x1080 displays are supported.  I was mostly curious if the resolution enhancement would reduce that to a single display or if it might end up being possible to have one primary high resolution display along with a much lower resolution secondary/tertiaty display.

[RandyDGroves]

The upgrade in development will allow a Tera2240 to encode two UHD displays (or two 3840x1440 displays) so the second display can be lower resolution. Unfortunately, the Tera2140 zero client will be limited to a maximum resolution of 3840x1440 (i.e. no UHD at native resolution, so 2560x1440 would have to be used).

[Bleeder]

Horizon 7.4 added a new "H.264 High Color Accuracy" policy that supports the YUV 4:4:4 colorspace, which may help.

What's New in VMware Horizon 7.4 and Horizon Client 4.7 | VMware End-User Computing Blog