将DirectX 11功能引入Unity 5.1中的移动设备-CSDN博客

One of the new features in Unity 5.1 is a new unified OpenGL rendering backend.

Unity 5.1中的新功能之一是新的统一OpenGL渲染后端。

…现在统一了吗？ (… A unified what now?)

Until now, we had a separate renderer for OpenGL ES 2.0, one for OpenGL ES 3.0 (that shared a good deal, but not all, code with ES 2.0) and then a completely different one for the desktop OpenGL (that was stuck in the OpenGL 2.1 feature set). This, of course, meant a lot of duplicate work to get new features in, various bugs that may or may not happen on all renderer versions etc.

到目前为止，我们为OpenGL ES 2.0提供了一个单独的渲染器，为OpenGL ES 3.0提供了一个渲染器(与ES 2.0共享了很多但不是全部的代码)，然后为桌面OpenGL提供了一个完全不同的渲染器(卡在了OpenGL 2.1功能集)。当然，这意味着要进行很多重复的工作才能获得新功能，以及所有渲染器版本上可能会或可能不会发生的各种错误。

So, in order to get some sense into this, and in order to make it easier to add features in the future, we created a unified GL renderer. It can operate in various different feature levels, depending on the available hardware:

因此，为了对此有所了解，并在以后使添加功能更容易，我们创建了一个统一的GL渲染器。根据可用的硬件，它可以以各种不同的功能级别运行：

All the differences between these API versions are baked into a capabilities structure based on the detected OpenGL version and the extensions that are available. This has multiple benefits, such as:

这些API版本之间的所有差异都将基于检测到的OpenGL版本和可用扩展放入功能结构中。这具有多种好处，例如：

Provided that the necessary compatibility extensions are present on desktop, we can run GL ES 2.0 and 3.x shaders directly in the editor (again, still experimental in 5.1).
只要桌面上存在必需的兼容性扩展，我们就可以直接在编辑器中运行GL ES 2.0和3.x着色器 (同样，在5.1中仍处于试验阶段)。

计算着色器 (Compute shaders)

Cocuy 2D fluid simulation package from the Unity Asset Store running on OpenGL ES 3.1. No modifications needed.

运行在OpenGL ES 3.1上的Unity Asset Store中的Cocuy 2D流体模拟程序包。无需修改。

One of the first new features we brought to the new OpenGL renderer is compute shaders and image loads/stores (UAVs in DX11 parlance). And again, as we have an unified codebase, it is (more or less) automatically supported on all GL versions that support compute shaders (desktop OpenGL 4.3 onwards and OpenGL ES 3.1 onwards). The compute shaders are written in HLSL just as you’d do on DX11 in previous versions of Unity, and they get translated to GLSL. You’ll use the same Graphics.SetRandomWriteTarget scripting API to bind the UAVs and the same Dispatch API to launch the compute process. The UAVs are also available on other shader stages if supported by the HW (do note that some, usually mobile, GPUS have limitations on that, for example the Mali T-604 in Nexus 10 only supports image loads/stores in compute shaders, not in pixel or vertex shaders).

我们为新的OpenGL渲染器带来的首批新功能之一是计算着色器和图像加载/存储(在DX11中为UAV)。再者，由于我们拥有统一的代码库，因此(支持或不支持)所有支持计算着色器的GL版本(从桌面OpenGL 4.3开始和从OpenGL ES 3.1开始)都自动支持它。就像您在Unity的早期版本中在DX11上所做的一样，计算着色器是用HLSL编写的，并且它们已转换为GLSL。您将使用相同的Graphics.SetRandomWriteTarget脚本API来绑定UAV，并使用相同的Dispatch API来启动计算过程。如果硬件支持，UAV也可以在其他着色器阶段使用(请注意，某些通常是移动的GPU对此有限制，例如Nexus 10中的Mali T-604仅支持计算着色器中的图像加载/存储，不支持在像素或顶点着色器中)。

镶嵌和几何着色器 (Tessellation and Geometry shaders)

GPU Tessellation running on OpenGL ES 3.1

在OpenGL ES 3.1上运行的GPU镶嵌

Both tessellation and geometry shaders from DX11 side should work directly on Android devices supporting Android Extension Pack. The shaders are written as usual, with either #pragma target 50 or #pragma target es31aep (see below for the new shader targets), and it’ll “just work” (if it doesn’t, please file a bug).

DX11侧的镶嵌细分和几何着色器均应直接在支持Android Extension Pack的Android设备上运行。着色器照常编写，使用#pragma target 50或#pragma target es31aep(有关新的着色器目标，请参见下文)，它将“正常工作”(如果无效，请提交错误)。

其他东西 (Other goodies)

Here’s a short list of other things that are working mostly the same as on DX11

以下是与DX11大致相同的其他功能的简短列表

与DX11的不同 (Differences from DX11)

There are some differences to the feature set available in DX11, apart from things discussed above:

除上述内容外，DX11中可用的功能集还存在一些差异：

着色器管 (Shader pipe)

The shader compilation process for ES 2.0 and the old desktop GL renderer (and, until now, for ES3.0 as well) is as follows:

ES 2.0和旧的桌面GL渲染器(以及直到现在还包括ES3.0)的着色器编译过程如下：

The HLSL shader is translated to GLSL / GLSL ES using hlsl2glsl (https://github.com/aras-p/hlsl2glslfork)
使用hlsl2glsl( https://github.com/aras-p/hlsl2glslfork )将HLSL着色器翻译为GLSL / GLSL ES
The resulting GLSL shader is fed to GLSL optimizer (https://github.com/aras-p/glsl-optimizer)
生成的GLSL着色器被馈送到GLSL优化器( https://github.com/aras-p/glsl-optimizer )

The problem with this is that neither of the modules above support anything later than Shader Model 3.0 shaders, effectively limiting the shaders to DX9 feature set. In order to compile HLSL shaders that use DX11 / Shader Model 5.0 features, we are using the following shader compilation pipeline for GL ES 3.0 and above, and for all desktop GL versions running on unified GL backend:

问题在于，以上两个模块都不支持Shader Model 3.0着色器之后的任何内容，从而有效地将着色器限制为DX9功能集。为了编译使用DX11 / Shader Model 5.0功能的HLSL着色器，我们将以下着色器编译管道用于GL ES 3.0及更高版本，以及在统一GL后端上运行的所有桌面GL版本：

The bytecode is translated to GLSL / GLSL ES using our heavily reworked fork of HLSLCrossCompiler (https://github.com/James-Jones/HLSLCrossCompiler)
使用我们经过大量修改的HLSLCrossCompiler分支( https://github.com/James-Jones/HLSLCrossCompiler )，将字节码转换为GLSL / GLSL ES。

The new shader pipeline seems to be working fairly well for us, and allows us to use the shader model 5.0 features. It also can benefit from the optimizations the D3D compiler performs (but also all the drawbacks of having a bytecode that treats everything as vec4’s, always). As a downside, we’ll have a dependency to the D3D compiler and the language syntax it provides, so we’ll have to go through some hoops to get our Unity-specific language features through (such as sampler2D_float for sampling depth textures).

新的着色器管道似乎对我们来说运作良好，并允许我们使用着色器模型5.0功能。它也可以从D3D编译器执行的优化中受益(但也有使用字节码将所有内容始终视为vec4的所有缺点)。不利的一面是，我们将依赖于D3D编译器及其提供的语言语法，因此我们必须经过一些努力才能获得我们特定于Unity的语言功能(例如，sampler2D_float用于采样深度纹理)。

Existing OpenGL ES 3.0 (and of course, OpenGL ES 2.0) shaders should continue to work as they did previously. If they do not, please file a bug.

现有的OpenGL ES 3.0(当然还有OpenGL ES 2.0)着色器应继续像以前一样工作。如果没有，请提交错误。

那么，我该如何使用呢？ (So, how can I use it?)

For Unity 5.1 release, we are not yet deprecating the legacy OpenGL renderer, so it will still be used on OS X and on Windows when using the -force-opengl flag. The desktop GL renderer is still considered very experimental at this point, but it will be possible to activate it with the following command line arguments for both the editor and standalone player (currently Windows only, OSX and Linux are on our TODO list):

对于Unity 5.1版本，我们尚未弃用旧版OpenGL渲染器，因此当使用-force-opengl标志时，仍将在OS X和Windows上使用它。到目前为止，桌面GL渲染器仍被认为是非常试验性的，但是可以通过以下命令行参数将其激活，以用于编辑器和独立播放器(当前仅Windows，OSX和Linux在我们的TODO列表中)：

Remember to include the corresponding shaders in the Standalone Player Settings dialog (uncheck the “Automatic Graphics API” checkbox and you’ll be able to manually select the shader languages that will be included).

请记住，在“独立播放器设置”对话框中包括相应的着色器(取消选中“自动图形API”复选框，您将能够手动选择将包含的着色器语言)。

Note that these flags (including the ES flags) can also be used when launching the editor, so the user will see the rendering results of the actual ES shaders that will be used on the target. Also note that these features are to be considered experimental on desktop at this stage, so experiment with these at your own risk. In 5.1, you can also use the standalone player to emulate GL ES targets: In Player settings just make sure you include GL ES2/3 shaders in the graphics API selection and start the executable with one of the -force-glesXX flags above. We’re also working on getting this to function on Linux as well.

请注意，在启动编辑器时也可以使用这些标志(包括ES标志)，因此用户将看到将在目标上使用的实际ES着色器的渲染结果。另请注意，在此阶段，这些功能应考虑在台式机上进行试验，因此，自行承担试验风险。在5.1中，您还可以使用独立播放器来模拟GL ES目标：在播放器设置中，只需确保在图形API选择中包括GL ES2 / 3着色器，并使用上面的-force-glesXX标志之一启动可执行文件。我们也在努力使它也能在Linux上运行。

There are some known issues with running ES shaders on the desktop: Desktop and mobiles use different encoding for normal maps and lightmaps, so the ES shaders expect the data to be in different encoding than what’s being packaged alongside the standalone player build. The OpenGL Core shader target should work as expected.

在台式机上运行ES着色器存在一些已知问题：台式机和移动设备对法线贴图和光照贴图使用不同的编码，因此ES着色器期望数据采用的编码方式与独立播放器版本打包在一起的编码方式不同。 OpenGL Core着色器目标应该可以正常工作。

On iOS, the only change is that the ES 3.0 shaders will be compiled using the new shader pipeline. Please report any breakage. ES 2.0 and Metal rendering should work exactly as before. Again, please report any breakage.

在iOS上，唯一的变化是ES 3.0着色器将使用新的着色器管道进行编译。请报告任何破损。 ES 2.0和金属渲染应完全像以前一样工作。再次，请报告任何破损。

On Android, if the “Automatic Graphics API” checkbox is cleared, you can select which shaders to include in your build, and also set manifest requirements for OpenGL ES 3.1 and OpenGL ES 3.1 + Android Extension Pack (remember to set your required API level to Android 5.0 or later as well). The default setting is that the highest available graphics level will always be used.

在Android上，如果取消选中“自动图形API”复选框，则可以选择要在构建中包含的着色器，还可以设置OpenGL ES 3.1和OpenGL ES 3.1 + Android Extension Pack的清单要求(请记住，设置所需的API级别以及Android 5.0或更高版本)。默认设置是将始终使用最高的可用图形级别。

AN IMPORTANT NOTE:

重要说明：

Apart from some fairly rare circumstances, there should never be any need to change the target graphics level from Automatic. ES 3.1 and ES 3.0 should work just as reliably as ES 2.0, and if this isn’t the case, please file a bug. (Of course it is possible to write a shader using #pragma only_renderers etc that will break on ES3 vs ES2 but you’ll get the idea.) Same applies to the desktop GL levels once we get them ready. The Standard shader is currently configured to use a simpler version of the BRDF on ES 2.0 (and also cuts some other corners here and there for performance reasons), so you can expect the OpenGL ES 3.0 builds to both have more accurate rendering results and have slightly lower performance figures compared to ES 2.0. Similarily, directional realtime lightmaps require more texture units than is guaranteed to be available in ES 2.0, so they are disabled there.

除了一些非常罕见的情况外，永远都不需要从“自动”更改目标图形级别。 ES 3.1和ES 3.0应该和ES 2.0一样可靠，如果不是这种情况，请提交错误。 (当然，可以使用#pragma only_renderers等编写着色器，该着色器在ES3和ES2上会中断，但您会明白的。)一旦我们准备好它们，它们同样适用于桌面GL级别。目前，标准着色器已配置为在ES 2.0上使用BRDF的简单版本(并且出于性能方面的考虑，在此处也存在一些其他缺陷)，因此您可以期望OpenGL ES 3.0构建既具有更准确的渲染结果，又具有与ES 2.0相比，性能略低。同样，定向实时光照贴图所需要的纹理单位要比ES 2.0中保证的要多，因此在此处将其禁用。

When writing ShaderLab shaders, the following new #pragma target enums are recognized:

编写ShaderLab着色器时，将识别以下新的#pragma目标枚举：

When using the existing #pragma targets, they map to following GL levels:

使用现有的#pragma目标时，它们会映射到以下GL级别：

For including and excluding shader platforms from using a specific shaders, the following #pragma only_renderers / exclude_renderers targets can be used:

为了在使用特定着色器时包含和排除着色器平台，可以使用以下#pragma only_renderers / exclude_renderers目标：

未来发展 (Future development)

As described above, a common GL codebase allows us to finally bring more features to the OpenGL / ES renderer. Here are some things we’ll be working on next (no promises, schedule- or otherwise, your mileage may vary, please talk with your physician before use, and all the other usual disclaimers apply):

如上所述，通用的GL代码库使我们最终可以为OpenGL / ES渲染器带来更多功能。以下是我们接下来要处理的一些事情(无承诺，时间表-否则，您的里程可能会有所不同，请在使用前与您的医生谈谈，并使用所有其他通常的免责声明)：