【问题标题】:Are OpenGL functions actually context-specific?OpenGL 函数实际上是特定于上下文的吗?
【发布时间】:2020-11-16 19:48:35
【问题描述】:

我知道在初始化上下文后我必须将glfwGetProcAddress 函数传递给gladLoadGLLoader 函数。 GLFW 文档说这个函数返回当前上下文的指定函数的地址。根据这些信息,如果我想在另一个上下文中绘制一些东西,我必须输入

glfwMakeContextCurrent(*window*)
gladLoadGLLoader((GLADloadproc)glfwGetProcAddress)

每次我想更改绘图上下文。但是,只需使用 glfwMakeContextCurrent 函数更改上下文就足够了。文档还备注

给定函数的地址不保证相同 上下文之间。

但似乎返回的地址在上下文​​之间实际上是相同的(至少在 Windows 中)。问题是,为了实现稳定和便携的行为,真正做到这一点的方法是什么?

【问题讨论】:

  • 尝试更奇特的配置,例如来自不同 GPU 供应商的显卡驱动单独的显示器 :)
  • @genpfault 现在,让每张卡在 5x2 显示墙上驱动多个显示器,安装人员明智地将 5 倒置并焊接夹具,这样顶部的必须倒置,请注意,其中一家制造商允许您正确旋转顶部图像,而另一家则不能,并且保持卡片同步是徒劳的。
  • Windows API 保证两个上下文的函数指针是相同的,如果它们是为相同的像素格式创建的。在实践中,你得到的还不止这些:如果它们最终位于同一个 ICD 中,它们通常是相同的。但请注意,在 Windows 上,您可以拥有不同的 ICD,即 Microsoft GDI 渲染器、一些专用 GPU 和集成 GPU。如果你真的想要,你可以在同一个应用程序中使用不可共享的函数指针创建不同的上下文。

标签: c++ opengl glfw glad


【解决方案1】:

技术上是的:从 OpenGL 上下文检索的函数指针对于该特定上下文有效。但是,对于大多数实际目的,您可以忽略这一点。如果两个上下文可以共享对象,那么它们几乎肯定会共享函数指针。

如果您想解决函数指针无法跨上下文共享的情况,最好的选择是编写一个专门用于处理这种可能性的加载器。例如,您可以修改 GLAD 以将 OpenGL 函数放入一个结构中,然后将这些函数加载到不同的结构中以用于不同的上下文。

【讨论】:

  • "修改 GLAD 以将 OpenGL 函数放在一个结构中,然后将函数加载到不同的结构中以用于不同的上下文。" GLAD2 分支已经拥有该 FWIW。
猜你喜欢
  • 2023-03-18
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2020-01-14
  • 2011-11-10
  • 1970-01-01
  • 2021-12-17
  • 1970-01-01
相关资源
最近更新 更多