我怎么知道我是否过于紧密地抽象图形API?


23

制作支持多个图形API的渲染器时,通常需要在与某种图形API(例如OpenGL,Vulkan,D3D11等)绑定的某种低级库中抽象代码。

它们的工作方式彼此非常不同,因此制作一个好的通用API变得至关重要。我已经读到您通常会希望使用一个“后端”来实现要支持的每个API的基本功能,而一个“前端”则是程序员用来在程序上绘制内容的东西。屏幕。

我怎么知道我是否过于严格的抽象?


5
您是否100%确定包装+ Vulkan或D3D11比仅使用OpenGL快?
Mooing Duck

@Mooing Duck,如果使用正确,是的。
加布里埃莱·维尔蒂

4
我会对此表示严重怀疑。Vulkan的大部分收益来自低级的工作以及以非常特殊的方式进行工作。足以在OpenGL或D3D中无缝执行相同操作的通用操作几乎肯定不能做到这一点。重新实现与OpenGL相同的功能(具有讽刺意味的是,就像许多Vulkan教程一样),结果是99.99%的相同性能,而工作量却是原来的20倍。
戴蒙

@Damon是正确的,但是较新的API是经过专门设计的(并非像OpenGL 那样适应),可以在现代GPU上使用;说到Vulkan,您几乎可以在每个受支持的平台上使用相同的API,这与OpenGL相反,在OpenGL中,您需要使用“嵌入式系统”版本。除了较少的cpu开销和精美功能外,我们没有太多其他功能,但是在将来,我们可能会有一些非常令人惊讶的技术,这些技术可能会使用Vk或D3D12而不是OGL或D3D11来运行得更快
Gabriele Vierti 18/12/1 '16

Answers:


44

首先,考虑支持多个图形API是否真正值得。仅使用OpenGL就可以覆盖大多数平台,并且除了图形上最雄心勃勃的项目外,对其他所有项目都“足够好”。除非您为一个大型游戏工作室工作,该工作室可以花数千个人小时来实施和测试多个渲染后端,并且除非您确实要炫耀某些DirectX或Vulcan特定功能,否则通常不值得麻烦。特别是考虑到您可以使用其他人创建的抽象层(第三方库或游戏引擎)来节省大量工作。

但是,让我们假设您已经评估了自己的选择,并得出结论认为,这样做既可行,又值得花时间推出自己的选择。

然后,抽象层的软件体系结构的主要判断者是前端程序员。

  • 他们是否能够实施他们想要实施的游戏系统,而不必担心任何低级细节?
  • 他们是否能够完全忽略存在多个图形API?
  • 从理论上讲,可以在不更改任何前端代码的情况下添加另一个渲染后端吗?

如果是这样,您就成功了。


2
还有一个建议:值得强调的是,目标是以最少的努力来达到项目要点中的目标,即击中目标而不再前进吗?否则,对于典型的开发人员(包括我自己)通常不知道什么时候留下足够好的东西,这些开发人员中的每个人都会陷入困境。:)而且,判断成功的唯一可靠方法是与实际用户迭代开发和测试API ;这是不可能准确猜测的,并且会导致过度设计的麻烦。
鲍勃,

5
我想补充一点,如果你确实支持多个图形库,几乎可以肯定关闭的,现成的一个已经做了你需要的一切,所以即使那么你真的不应该推出自己的。(当然,也有例外,但是如果您没有足够的经验来询问“我应该对抽象进行多严密的处理”,那么您可能没有在进行要求您这样做的项目)
基金莫妮卡的诉讼

我不是图形开发人员,但是从数据库和OS的历史来看兼容性框架,我想补充一点,几乎可以肯定,创建自己的通用框架是不值得的。该框架几乎肯定会牺牲性能来实现兼容性,这可能意味着您无论如何都不能对这些专用功能做太多事情。由于使用范围广泛,几乎可以肯定的是现有框架可以更好地处理这些问题。现在,如果您描述的预算很大,并且想要建立一个专门的框架(例如针对一个游戏或系列),那可能会更可行。
jpmc26

6

首先从API的“包装器”部分中确定您实际需要的内容。它通常非常非常简单:您需要基本资源(缓冲区,着色器,纹理,管线状态),以及通过提交一些绘制调用来使用这些资源来构造框架的方法。

尽量保持任何高级逻辑出的 API的包装部。如果您在API的这一部分中实现了一种巧妙的场景剔除技术,那么现在您将可以在所有后端实现中复制该逻辑。这是很多额外的工作,因此请保持简单。场景管理应该是使用包装器的API高层部分的一部分,而不是包装器本身的一部分

选择您将支持并理解的目标。很难为“所有内容”编写像样的包装,并且您可能不需要(可以说,您也不需要编写单个包装,正如Philipp的回答所述)。如果您不知道要包装的API,则几乎不可能编写一个像样的包装器。

定期评估API的状态。通常,它的表面积应小于底层包装的API。如果您发现自己为每个D3D结构或每个OpenGL函数调用创建一对一的包装器类型,则可能会偏离路线。

看看以前做了什么工作。Sokol和BGFX是提供不可知程度的API,可能对您有用,并且相对容易理解(尤其是前者)。


3

您尚未考虑的另一点是您的绩效目标。如果您的目标是拥有一个可以从廉价的硬件平台上获得良好性能的图形库,而且还可以在功能更强大但使用不同API的各种平台上使用,则可以合理地设计API在性能是问题的平台上本机使用的任何抽象。即使这会在功能更强大的平台上造成50%的速度下降,但如果它允许在性能最重要的平台上将速度提高20%,则可能值得这样做。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.