问题描述
在我的另一个问题中，一个答案表明我应该使用glBindAttribLocation，并且不允许着色器编译器分配自己的索引.我想知道为什么这是推荐的做法，它有什么优点(或者不使用它有什么缺点)?
In another question of mine one of the answers indicate I should use glBindAttribLocation and not allow the shader compiler to assign its own indices. I'm wondering why this is a recommended practice, what advantages does it have (or rather what disadvantages does not using it have)?
我确实知道，如果我有多个共享属性的程序，这是有道理的，因为我可以在程序之间进行切换，而不必重置这些属性.但是，对于不共享的属性，或者对于我的程序不使用这种共享的属性，我认为没有必要显式绑定索引.
I do understand that if I have multiple programs which share attributes this makes sense, since I can switch between programs and not have to reset those attributes. However, for attributes which aren't shared, or if my programs just don't use such sharing, I don't see that it is necessary to bind the index explicitly.
推荐答案
首先，我不建议通过glBindAttribLocation而不是glGetAttribLocation使用显式绑定.话虽如此，这些是我停止使用glGetAttribLocation的主要原因:
First of all I don't think it's a general recommendation to use explicit binding via glBindAttribLocation instead of glGetAttribLocation. That being said, these are the main reasons I stopped using glGetAttribLocation:
首先，这可能会导致不必要的开销.看起来不错，可以使用可读的名称代替数字. 到底什么是属性7"与哦，是的，属性texture_coordinate":我将首先解释可能的开销，然后解释为什么最后一部分甚至没有意义.
First of all, this can cause unnecessary overhead. It all seems nice and well that you can use a readable names instead of numbers. 'What the heck is attribute 7' vs 'oh right, attribute texture_coordinate': I'll explain first what the possible overhead can be and then why that last part doesn't even make sense.
如果经常需要属性位置，则取决于驱动程序，调用glGetAttribLocation的开销可以忽略不计.因此，要处理一般情况，您必须构建一个缓存系统.太好了，这里有一种简单易懂的方法，用名称代替数字，我只需要编写很多非平凡的包装代码.更糟糕的是，您应该非常小心，当程序变得无效时销毁缓存，这很有可能会导致错误并最终导致错误.因此，我们从好看的名字"变成了可怕的越野车混乱".
If you need the attribute location often, the overhead of calling glGetAttribLocation can become non-negligible, depending on the driver. So to handle the general case you have to build a caching-system. Great, there goes my easy and readable method with names instead of numbers, I just had to write quite a lot of non-trivial wrapper code. Worse, you should really take care that you destroy the cache when the program becomes invalid, it's quite likely you'll do this wrong and end up with bugs. So we went from 'nice readable names' to 'horrible buggy mess'.
更何况好读的名字"这个说法有缺陷.对于着色器本身中定义的位置，您可以完美地执行以下操作:
Even more, the 'nice readable names' argument is flawed. You can perfectly do something like the following for locations defined in the shader itself:
const GLint vertex_loc_att = 0;
const GLint texture_coord_att = 1;
...
或者您也可以使用这样的关联容器:
Or you can also use an associative container like this:
attribute_locations["vertex_location"] = 0;
attribute_locations["texture_coordinate"] = 1;
...
您也可以将其与glBindAttribLocation结合使用，只需在链接之前进行此操作即可:
This one you can also combine with glBindAttribLocation, just do this prior to linking:
foreach name, location in attribute_locations
{
glBindAttribLocation(program_id, location, name);
}
仍然非常可读，不需要动态缓存，只是一些甚至可以优化的静态变量.
Still very readable, no dynamic cache necessary, just some static variables that even might get optimized away.
然后，您自己说:在使用多个程序时，它显然具有优势，在此不再赘述，因为Kos .我只会回答您的一个论点:
Then, you say it yourself: it obviously has it advantages when using multiple programs, I won't repeat it here, because Kos explained that one in detail already. I'll just answer one of your arguments:
不需要共享的属性:这意味着还有一些需要共享的属性，使用固定位置具有很大的优势.为什么要在一个应用程序中混合使用两种位置管理方法?避免您因维护而头痛，并坚持使用一个，这里显然是预定义的位置，因为您需要使用它们来共享属性.
Attributes that don't need sharing: This implies there are also attributes that need sharing, for which it is a big advantage that you use fixed locations. Why would you mix two location management approaches in one application? Keep yourself from a maintenance headache and stick with one, here obviously the predefined locations because you need them for the shared attributes.
这篇关于为什么要使用glBindAttribLocation?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！