Multi-Rendering API 引擎着色器文件管理

Question

我正在开发一个 3D 引擎，旨在支持任何给定图形的实现 API。我希望得到您对我计划如何管理着色器文件的反馈：

我考虑创建一个包含 3 个字符串变量、目录和文件名（顶点和片段）的结构，如下所示：

class ShaderFile : public SerializableAsset
{
    std::string nameID; //Identifier
    std::string directory;
    std::string vertexName;
    std::string fragmentName;
};

用户可以在编辑器中设置这些变量。然后，我的引擎会像这样加载着色器文件：

void createShader(RenderAPI api)
{
    ShaderFile shaderFile //Get it from some place
    std::string vertexPath = shaderFile.directory + shader.vertexName + api.name + api.extension;
    std::string fragmentPath = shaderFile.directory + shader.fragmentName + api.name + api.extension;
    //Create shader...
}

这会创建如下内容：Project/Assets/Shaders/standardVulkan.spv.

我的思考方向是否正确，或者这是一种完全愚蠢的方法？任何反馈

Answer 1

这是一个有趣的想法，我们实际上已经做到了这一点，但我们在此过程中发现了一些不容易处理的事情：

如果您更深入地了解着色器 API，虽然它们在纸面上几乎提供相同的功能，但它们通常不以相同的方式支持功能，因此必须以不同的方式进行管理。通过扩展，着色器也是如此。驱动程序实现是这里的关键，有时在管理内部状态（同步和缓冲区处理）方面会有很大差异。

灵活性

您会发现 OpenGL 在处理属性和制服方面非常灵活，而 DirectX 更侧重于通过根据您的 renderpass 配置将它们绑定到块中来最大程度地减少对硬件的上传，通常在 per-object/per-frame/per-pass 基础等。虽然您也可以通过创建小块来做到这一点，但这显然会带来不同的性能。

显然，有多种方法可以进行绑定，甚至缓冲对象或着色器，即使在单个 API 中也是如此。此外，获取着色器变量名称和绑定点在 DirectX 中查询并不灵活，一些参数需要从代码中设置。在 Vulkan 中，绑定着色器属性和制服更加通用：您可以完全根据需要配置绑定点。

版本控制

另一个主题是与 GLSL/HLSL 着色版本控制有关的所有内容：您可能需要为支持较低着色器模型的不同硬件功能编写不同的着色器。如果您打算编写独特的着色器并且不打算使用超级着色器方法（并且如果您使用这种方法也会在很大程度上扩展），如果它与您的设计联系得太紧密，并且考虑到数量排列可能不切实际。

扩展

OpenGL 和 Vulkan 扩展可以在着色器中 'queried'，而其他 API（例如 DirectX）则需要从代码端进行设置。尽管如此，在同一个 compute_capability 中，您可以拥有仅适用于 NVidia 的扩展，或者获得 ARB 批准但未获得 CORE 等。这确实非常混乱，并且 在大多数情况下特定于应用程序 .

弃用

API 的相当一部分一直在被弃用。如果您的引擎希望这些功能保持不变，这可能会有问题，特别是如果您想要处理支持该功能的多个 API。

编译和缓存

现在大多数 API 都支持某种形式的离线编译，可以稍后加载。编译需要相当多的时间，所以缓存是有意义的。由于硬件着色器代码是为您拥有的硬件专门编译的，因此您需要为代码应该运行在每个平台上执行此练习，无论是在应用程序第一次需要着色器时，还是在其他一些聪明的地方在您的生产管道中的方式。在这种情况下，您的文件名将被哈希替换，以便可以从缓存中检索着色器。但这意味着缓存需要一个时间戳，以便它可以检测源着色器的新版本，因为如果着色器源发生变化，则需要重建缓存条目。等..:)

长话短说

如果您的目标是在任何 API 中获得最大的灵活性，您最终会在引擎中添加一个无用的层，在最好的情况下，它只会复制底层调用。如果您的目标是通用 API，您很快就会陷入版本故事中，在扩展、弃用和驱动程序实现支持方面，不同 API 之间完全不同步。

Multi-Rendering API 引擎着色器文件管理

Multi-Rendering API Engine shader file management

c++

rendering

design-patterns

game-engine