opengl - 为什么要使用 glBindAttribLocation？

Question

这个问题在这里已经有了答案:




9年前关闭。

Possible Duplicate:
Explicit vs Automatic attribute location binding for OpenGL shaders

在我的另一个问题中，其中一个答案表明我应该使用 glBindAttribLocation并且不允许着色器编译器分配自己的索引。我想知道为什么这是推荐的做法，它有什么优点(或者说不使用它有什么缺点)？

我确实明白，如果我有多个共享属性的程序，这是有道理的，因为我可以在程序之间切换而不必重置这些属性。但是，对于未共享的属性，或者如果我的程序不使用此类共享，我认为没有必要显式绑定(bind)索引。

Answer 1

首先，我不认为通过 glBindAttribLocation​ 使用显式绑定(bind)是一般建议。而不是 glGetAttribLocation .话虽如此，这些是我停止使用 glGetAttribLocation 的主要原因。 :

首先，这可能会导致不必要的开销。您可以使用可读的名称而不是数字，这一切看起来都很好。 “属性 7 到底是什么”与“哦，对了，属性 texture_coordinate”:我将首先解释可能的开销是什么，然后解释为什么最后一部分甚至没有意义。

如果您经常需要属性位置，调用 glGetAttribLocation 的开销可能会变得不可忽略，具体取决于驱动程序。因此，要处理一般情况，您必须构建一个缓存系统。太好了，我的方法简单易读，用名称代替数字，我只需要编写很多重要的包装代码。更糟糕的是，当程序变得无效时，您真的应该注意销毁缓存，您很可能会做错并最终导致错误。所以我们从“好读的名字”变成了“可怕的马车困惑”。

更重要的是，“好读的名字”的论点是有缺陷的。对于着色器本身中定义的位置，您可以完美地执行以下操作:

const GLint vertex_loc_att = 0;
const GLint texture_coord_att = 1;
...

或者您也可以使用这样的关联容器:

attribute_locations["vertex_location"] = 0;
attribute_locations["texture_coordinate"] = 1;
...

这个你也可以和 glBindAttribLocation 结合使用，只需在链接之前执行此操作:

foreach name, location in attribute_locations
{
    glBindAttribLocation(program_id, location, name);
}

仍然非常可读，不需要动态缓存，只是一些静态变量，甚至可能会被优化掉。

那你自己说吧:多程序使用时明显有优势，这里不再赘述，因为科斯 explained that one in detail already .我只回答你的一个论点:

不需要共享的属性:这意味着也有需要共享的属性，使用固定位置是一个很大的优势。为什么要在一个应用程序中混合两种位置管理方法？让自己免于维护头痛并坚持使用，这里显然是预定义的位置，因为您需要它们来共享属性。