Question

我正在尝试多个OpenGL上下文之间的列表共享。这是一个很棒的功能，因为它允许我执行并行渲染线程。

但是因为我正在使用CreateContextAttribs，所以我提供了请求特定OpenGL实现的可能性。因此，可能会发生一些上下文正在实现版本3.2+而另一个正在实现版本2.1。

实际上工作得很好，但我怀疑这种作案手法隐藏了一些副作用。使用具有不同版本的上下文时可能出现的问题列表是什么？

除此之外，我查询每个上下文版本的已实现的扩展，因为我认为不同的版本可以支持不同的扩展，这是对的吗？那么函数指针呢？我必须为每个具有不同版本的上下文重新查询它们（事实上，指针会根据版本而变化）？

Answer 1

这是一个很棒的功能，因为它允许我执行并行渲染线程。

并行从多个线程访问GPU是一个严重的性能杀手。不要这样做。 GPU将在内部并行化任何渲染。你做的其他事情就是将原木扔进车轮。

如果您想加快资产上传速度，请查看缓冲区对象和异步访问。但是不要同时在单独的线程中执行多个OpenGL上下文。

但是因为我正在使用CreateContextAttribs，所以我提供了请求特定OpenGL实现的可能性。因此，可能会发生一些上下文正在实现版本3.2+而另一个正在实现版本2.1。

实际上工作得很好，但我怀疑这种作案手法隐藏了一些副作用。使用具有不同版本的上下文时可能出现的问题列表是什么？

这实际上是一个非常好的问题。 specification清楚地回答：

1) Can different GL context versions share data?

    PROPOSED: Yes, with restrictions as defined by the supported feature
    sets. For example, program and shader objects cannot be shared with
    OpenGL 1.x contexts, which do not support them.

    NOTE: When the new object model is introduced, sharing must be
    established at creation time, since the object handle namespace is
    also shared. wglShareLists would therefore fail if either context
    parameter to it were to be a context supporting the new object
    model.

除此之外，我查询每个上下文版本的已实现的扩展，因为我认为不同的版本可以支持不同的扩展，这是对的吗？

确实，查询每个上下文支持的扩展集是正确的。

那么函数指针呢？我必须为每个具有不同版本的上下文重新查询它们（事实上，指针会根据版本而变化）？

在Windows扩展函数指针上绑定了上下文。这样做的理智方法是有一些

typedef struct OpenGLExtFunctions_S {
    GLvoid (*glFoobarEXT)(GLenum, ...);
    /* OpenGL function pointers */
} OpenGLExtFunctions;

/* currentContextFunction must be thread loacal since
   contexts are active in one thread only */
__declspec(thread) OpenGLExtFunctions *currentContextFunctions;

#define glFoobarEXT (currentContextFunctions->glFoobarEXT);
#define ...

并使用一些辅助函数包装wglMakeCurrent和wglMakeContextCurrent，该函数将currentContextFunctions指针设置为当前上下文之一。像GLEW这样的扩展包装器库为你做了所有这些笨拙的工作，所以你不必费心去做。

在X11 / GLX上，事情要简单得多：glXGetProcAddress返回的函数指针对于所有上下文都必须相同，所以不需要切换它们。

多个上下文与不同的版本

1 个答案: