具有不同版本的多个上下文

发布于 2024-12-05 22:55:23 字数 328 浏览 0 评论 0原文

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

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

实际上效果很好,但我怀疑这种操作方式隐藏了一些副作用。使用具有不同版本的上下文时可能出现的问题列表是什么?

除此之外,我查询每个上下文版本实现的扩展,因为我认为不同的版本可以支持不同的扩展,这是对的吗?那么函数指针呢?我必须为不同版本的每个上下文重新查询它们(实际上,指针会根据版本而变化)?

I'm experimenting on list sharing among multiple OpenGL contextes. It is a great feature, since it allow me to execute parallel rendering threads.

But since I'm using CreateContextAttribs, I offer the possibility to request a specific OpenGL implementation. So, it can happen the some context is implementing version 3.2+ while the other is implementing version 2.1.

Actually works quite fine, but I suspect that this modus operandi hides some side effect. What would be a list of problems which can occour while using contextes having different versions?

Beyond this, I query the implemented extentions for each context version, since I suppose that different versions can support different extension, is this right? And what about function pointers? I have to requery them for each context with different version (indeed, pointers changes depending on versions)?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

ぺ禁宫浮华殁 2024-12-12 22:55:23

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

从多个线程并行访问 GPU 是严重的性能杀手。不要这样做。 GPU 将在内部并行化任何渲染。你所做的任何其他事情,都是把木头扔进它的轮子里。

如果您想加快资源上传速度,请研究缓冲区对象和异步访问。但请避免同时在单独的线程中执行多个 OpenGL 上下文。


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

实际上效果很好,但我怀疑这种操作方式隐藏了一些副作用。使用不同版本的上下文时可能会出现哪些问题?

这其实是一个非常好的问题。 规范清楚地回答了这个问题:

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 ...

一些辅助函数将 wglMakeCurrentwglMakeContextCurrent 包装起来,将 currentContextFunctions 指针设置为上下文之一正在成为当前。像 GLEW 这样的扩展包装库会为您完成所有这些繁重的工作,因此您不必费心自己做这些工作。

在 X11/GLX 上,事情要简单得多:对于所有上下文,glXGetProcAddress 返回的函数指针必须相同,因此无需切换它们。

It is a great feature, since it allow me to execute parallel rendering threads.

Accessing the GPU from multiple threads in parallel is a serious performance killer. Don't do it. The GPU will parallelize any rendering internally. Anything else you do, is throwing logs into its wheels.

If you want to speed up asset uploads, look into buffer objects and asynchronous access. But stay away from doing multiple OpenGL contexts in separate threads at the same time.


But since I'm using CreateContextAttribs, I offer the possibility to request a specific OpenGL implementation. So, it can happen the some context is implementing version 3.2+ while the other is implementing version 2.1.

Actually works quite fine, but I suspect that this modus operandi hides some side effect. What would be a list of problems which can occour while using contextes having different versions?

This is actually a very good question. And the specification answers it clearly:

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.

Beyond this, I query the implemented extentions for each context version, since I suppose that different versions can support different extension, is this right?

Indeed querying the set of supported extensions for each context is the right thing to do.

And what about function pointers? I have to requery them for each context with different version (indeed, pointers changes depending on versions)?

On Windows extension function pointers are tied to the context. The sane way to do this is having some

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 ...

And wrap wglMakeCurrent and wglMakeContextCurrent with some helper function that sets the currentContextFunctions pointer to the one of the context being made current. Extension wrapper libraries like GLEW do all this grunt work for you, so you don't have to bother doing it yourself.

On X11/GLX things are much simpler: The function pointers returned by glXGetProcAddress must be the same for all contexts, so no need to switch them.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文