为什么要使用 glBindAttribLocation? [英] Why should I use glBindAttribLocation?

问题描述

可能的重复:
OpenGL 着色器的显式与自动属性位置绑定

在我的另一个问题中，其中一个答案表明我应该使用 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 到底是什么"与哦对了，属性纹理坐标":我将首先解释可能的开销是什么，然后为什么最后一部分甚至没有意义.

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?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！