The Receiver 4.4 - 客户端硬件解码 - 大幅度提升3D显示效能

简介:

在做3D/vGPU 这类桌面虚拟化项目的时候,除了对于服务器端的CPU有硬性要求之外,还对前端设备,如:PC、瘦客户机的主频有较高的要求,导致对终端设备的规格要求变得非常的高。

这是因为在3D/vGPU场景中,由于涉及到GPU物理解码以及各种专用软件的匹配,通信的时候需要通过H.264压缩技术来传输相关的图像信息。

而当服务器端将桌面中图像信息传输到前端设备进行重组并在屏幕上显示的时候,就需要使用到前端设备上的资源来完成相关工作,也就是我们平时说的解码。而对于解码通常有两种方法:

  1. CPU解码

  2. GPU解码


由于涉及到图形、图像的解码,GPU的效能一定会高于CPU。不过过去的Citrix客户端Receiver由于只支持对于H.264的CPU解码,所以导致对于前端设备的性能,尤其是CPU性能有相当程度的要求。


不过随着Windows Receiver 4.4的发布(Linux Receiver 13.x早已经支持),这种情况将发生根本性的改善,即Windows Receiver 4.4支持客户端硬件解码,简单的说就是在3D场景中,可以使用客户端的GPU资源来进行H.264的解码即图形、图像的重组。

这样必然带来客户端CPU需求的降低,同时提升图形、图像的显示质量。


对此我们来做一个简单的对比:

wKioL1aoN_mxy9QEAAC23m6Ny4Y946.jpg

wKioL1aoN_iDJE3cAABTKriASwI876.jpg

通过简单的对比我们可以看到:

  1. 在使用新版Receiver之后,帧率提升了近一倍,从7到了15(请注意这里的分辨率已经达到了4K级别,15的帧率已经非常可观,由于人眼的识别在每秒不低于24帧的情况下就会看到是一个连贯的画面,所以这种程度提高在很多场景中是会带来显示的质的飞越。)

  2. 终端设备CPU使用率降低了近一半,从30降低到了13。


所以从这两个3D项目中的两个重要指标来看,一方面通过提升最终显示的帧率而获得更好的显示效果,另一方面通过降低终端CPU的需求,使得更低端的设备(需带有GPU)也能作为终端进行使用。从整体上带来极好3D的用户体验。


如何确认终端设备是否支持客户端硬解码,这里需要使用到一个三方的小工具来做检测,DXVA Checker。将这个小程序在终端设备上运行,检测该设备是否支持H264。

这里如图所示:该设备支持 SD/HD/FHD/4K等几种解码规格


wKiom1aoOzjTxBMgAAEsi1dzR8s498.png

由于有些设备无法支持4K,所以只会显示有SD/HD/FHD。但对于绝大多数3D/vGPU项目来说,这个是够用了,毕竟支持4K不仅设备要支持,对于显示器也是非常高的要求。

当然如果使用不支持4K的设备而硬推4K的显示的话,Receiver将会自动使用传统的CPU解码方式来完成图像的显示。


最后,要提醒一点由于Windows Receiver 4.4是第一个支持客户端硬解码的版本,所以秉承Citrix一贯谨慎的做法,这个功能默认是OFF状态,j_0004.gif


你需要通过如下方式来启用:

  1. 拷贝“C:\Programe File(x86)\Citrix\ICA Client\Configuration\receiver.adml” 到 “C:\Windows\PolicyDefinitions\”

    “C:\Windows\PolicyDefinitions\zh-cn

    “C:\Windows\PolicyDefinitions\en-us”

    三个目录下。

  2. 拷贝“C:\Programe File(x86)\Citrix\ICA Client\Configuration\receiver.admx” 到 “C:\Windows\PolicyDefinitions\”

    “C:\Windows\PolicyDefinitions\zh-cn”

    “C:\Windows\PolicyDefinitions\en-us”

    三个目录下。

  3. 访问 本地策略编辑器 “Local Group policy editor”, gpedit.msc

  4. 在 Computer Configuration-> Administrative Templates -> Citrix Receiver -> User Experience, 打开“Hardware Acceleration for graphics”

  5. 勾选“Enabled” ,点击 “Ok”

这样完成之后,当你通过Receiver访问一个3D session的时候,检查如***册表信息:

Registry Path: HKCU\Software\Citrix\ICA Client\CEIP\Data\GfxRender\<session ID>

Graphics_GfxRender_Decoder 和 Graphics_GfxRender_Renderer 的数值应该为2,代表GPU解码,如果是 1 代表仍然为CPU解码。


限制:

1. 不推荐为XA/XD 7.6 on Windows Server 2008 R2的用户启用硬件解码,强行启用可能带来更差的使用体验。


参考文档:







      本文转自sesame.qian  51CTO博客,原文链接:http://blog.51cto.com/kaiqian/1739138,如需转载请自行联系原作者


相关实践学习
基于阿里云DeepGPU实例,用AI画唯美国风少女
本实验基于阿里云DeepGPU实例,使用aiacctorch加速stable-diffusion-webui,用AI画唯美国风少女,可提升性能至高至原性能的2.6倍。
相关文章
|
6月前
|
前端开发 芯片
【芯片前端】保持代码手感——握手协议ready打拍时序优化
【芯片前端】保持代码手感——握手协议ready打拍时序优化
|
24天前
|
网络协议 程序员 网络安全
掌握 SOME/IP :事件通知 构建高效通信系统的关键技术
掌握 SOME/IP :事件通知 构建高效通信系统的关键技术
72 0
|
2月前
|
编解码 网络协议 Unix
相较于ffmpeg我更倾向于使用socket实现推流工作
相较于ffmpeg我更倾向于使用socket实现推流工作
29 0
|
5月前
|
缓存 NoSQL 应用服务中间件
零拷贝并非万能解决方案:重新定义数据传输的效率极限
本文讨论了零拷贝在优化数据传输效率方面的局限性。尽管零拷贝技术在减少数据传输过程中的内存拷贝次数方面有很大的优势,但它并非适用于所有情况。文章介绍了一些其他的优化方法,如异步I/O和直接I/O的组合、根据文件大小选择不同的优化方式。至此,我们的计算机基础专栏就结束了,不知道大家有没有发现,操作系统底层提供了丰富的解决方案来支持应用程序的复杂性和可扩展性。对于任何工作中遇到的问题,我们都可以从操作系统的角度寻找解决方法。
零拷贝并非万能解决方案:重新定义数据传输的效率极限
|
6月前
|
前端开发 芯片
【芯片前端】保持代码手感——握手型同步fifo的进一步拓展
【芯片前端】保持代码手感——握手型同步fifo的进一步拓展
|
6月前
|
前端开发 芯片
【芯片前端】保持代码手感——握手型同步FIFO设计
【芯片前端】保持代码手感——握手型同步FIFO设计
|
7月前
|
算法 安全 Linux
高性能网络 SIG 月度动态:推动 virtio 支持动态中断调节及更灵活的分流机制
高性能网络 SIG 月度动态送达,一键了解 8 月各项目进展。
|
8月前
|
编解码 监控 安全
Android平台GB28181设备接入侧如何同时对外输出RTSP流?
Android平台GB28181设备接入侧如何同时对外输出RTSP流?
105 0
|
9月前
|
对象存储 UED CDN
传输加速是一项很重要的功能
传输加速是一项很重要的功能
69 2