您的位置:首页 > 运维架构

OpenGL驱动质量的事实现状(精简翻译版)

2015-12-09 09:40 423 查看
http://blog.csdn.net/nightmare/article/details/25835699

原文:http://richg42.blogspot.com/2014/05/the-truth-on-opengl-driver-quality.html

一、厂商A:
为大多数开发者所使用,功能最全,测试得最好,几乎是事实上的标准驱动。其驱动性能很高,而且其设计偏向于实际中管用,而不是GL标准的纯粹性。大多数你所能听到的GL的好话,比如可以和D3D12/Mantle抗衡,源自使用这家驱动的开发者。但不幸的是,我们不能只支持这一家的驱动,否则会损失大量市场。

其驱动支持不计其数的扩展,而且基本都可用。但是当你开始使用其中一些扩展时,可能会超出驱动的安全执行路线而导致驱动崩溃。

但是,这家厂商的工具一直很悲催,或者只在一段时期内能用,或者你能祈求到其工具团队的帮助。

该厂商有着一个精明的策略,他们派开发人员进驻到游戏开发公司的队伍里,以便推进事情的进展。但这是一把双刃剑,因为这些开发者会拒绝调试在其他驱动上遇到的问题。他们会努力取得在他们自家驱动上的最好性能,而完全不管对其他驱动的影响。

该厂商也有被开玩笑地称作“图形黑帮”。如果你的队伍里有他们的人,要留心。他们可是玩真的。

二、厂商B:
完全杂乱不定的性能特征,混乱的回归测试,不能正常工作的驱动多线程,这些都完全失控。不幸的是,其GPU也基本上是业界标准,并且性能不俗,所以我们也不能将其忽略。其驱动试图紧密遵循GL规范,但结果并不好,因为多数开发者用厂商A的驱动做开发,而当在B的驱动上出问题时,他们批评B,而不是GL规范。

该厂商的关键扩展赤裸裸的不管用。基本都是实验性或者是纸面上的扩展,可以用来充实简历,或者向老版展现成绩。主流GL开发者从来不用这些扩展,因为不管用。

其驱动无法让Query或Sync这些功能可靠地运作。所以依赖它们的任何扩展都不能可靠地运作。每当他们更新驱动改正一个bug,都会引入两个新的bug。如果你单步进其驱动源码,你会发现一层套一层的长年来堆积起来的代码,已经没有人能够安全地修改。

有趣的是,他们有一个很小的工具团队,做出了一些非常有用的调试工具。若不是他们的工具,Source引擎到Linux的移植会花很长很长时间。

好的一面,相信与否,他们精通GL规范。如果你能取得他们的帮助,他们的建议对GL相关的问题非常有价值,但扩展除外。

三、厂商C:
你很难对它生气,因为他们根本不想做图形,这只是对其主体业务的偏离。但如今的趋势是把所有的东西集成到一个芯片上,而且他们有很多富余的片上空间。他们精通硬件,但对软件完全没兴趣。它是开源图形驱动的领军者,并且其硬件规范几乎完全公开。这伙人非常有钱,以致可以养得起两个独立完整的驱动团队。
驱动#1:
无论如何,该厂商的人力资源队伍很聪明:直接雇佣参与开源开发的人来推动驱动开发。这个驱动落后其他厂商很多,但其基本可用。如果遇到不管用的情况,你可以深入其源码,改正bug,然后提交一个补丁。如果你经常修补这个驱动,那么你可能会得到这家厂商的offer。

不幸的是,这个驱动通常落后于GL规范一两年。但你无法忽略它,因为它有很高的市场占有率,而且还在不断上升。

驱动#2:
一个彻底的灾难。这个团队的驱动几乎没人用,太多的执行路径不能正确工作。他们会每次给你一个独一无二的、错误百出的驱动版本,用来做性能分析或测试。他们会很诚实地问你,性能和正确性,哪一个更重要。

我曾见过一个知名引擎团队花了一年时间,试图让其GL 4.x后端能在这个驱动上正常工作。但是,它就是不行。所以,象其他游戏一样,直接实现一个GL 3.x的后端凑活用吧。

好的一面,厂商C为这个驱动团队提供了大量硬件技术细节。所以此驱动会比驱动#1快几个百分点。当然,前提是它得能正常工作。
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: