4

I know that I must pass glfwGetProcAddress function to gladLoadGLLoader function after context was initialized. GLFW documentation says that this function returns the address of the specified function for the CURRENT context. Based on this information, if I want to draw something on another context, I must type

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

each time I want to change drawing context. However, it is enough to simply change the context with glfwMakeContextCurrent function. Documentation also remarks

The address of a given function is not guaranteed to be the same between contexts.

But it seems like returned addresses are the actually same between contexts (In windows, at least). The question is, what is true way to do this, in order to achieve stable and portable behaviour?

haxen
  • 43
  • 2
  • 2
    Try a more exotic configuration like video cards from different GPU vendors driving separate monitors :) – genpfault Jul 27 '20 at 13:34
  • @genpfault Now take that, have each card drive multiple monitors in a 5x2 display wall where the installer wisely put the 5 on top upside down and welded the jig so that the top ones have to be upside down, and notice that one of the manufacturers lets you rotate the top images correctly while the other does not, and that keeping the cards in sync is an exercise in futility. – 3Dave Jul 27 '20 at 13:48
  • Windows API guarantees that function pointers are the same for two contexts if they were creted for the same pixelformat. In practice, you get more than that: they are usually the same if they end up in the same ICD. But note that on windows, you can have different ICDs, i.e. the Microsoft GDI renderer, some dedicated GPU, and the integrated GPU. And if you really want to, you can create different contexts with non-sharable function pointers in the same application. – derhass Jul 27 '20 at 13:49

1 Answers1

4

Technically yes: function pointers retrieved from an OpenGL context are valid only for that specific context. However, for most practical purposes, you can ignore this. If two contexts can share objects, then they almost certainly share function pointers.

If you want to account for those cases where function pointers can't be shared across contexts, the best option is to write a loader specifically for dealing with that eventuality. You could for example modify GLAD to put OpenGL functions in a struct and then load the functions into different structs for different contexts.

Nicol Bolas
  • 449,505
  • 63
  • 781
  • 982
  • 2
    "modify GLAD to put OpenGL functions in a struct and then load the functions into different structs for different contexts." The [GLAD2](https://github.com/Dav1dde/glad/tree/glad2) branch already has that FWIW. – genpfault Jul 27 '20 at 13:49