Backend renderer naming/filename mismatch GL versions

malucard commented

2018-06-25 02:08:22 +00:00

(Migrated from github.com)

I think there's some confusion in the OpenGL example renderers. OpenGL 2.0 is where the programmable pipeline was added. The GL 3.2 renderer actually only requires GL 2.0, if you change the shader to version 1.10 (and thus, to use attribute, varying and gl_FragColor), and the GL 2 renderer doesn't use any GL 2 features. The way it is, the 3.2 requirement is completely unnecessary.

I think there's some confusion in the OpenGL example renderers. OpenGL 2.0 is where the programmable pipeline was added. The GL 3.2 renderer actually only requires GL 2.0, if you change the shader to version 1.10 (and thus, to use `attribute`, `varying` and `gl_FragColor`), and the GL 2 renderer doesn't use any GL 2 features. The way it is, the 3.2 requirement is completely unnecessary.

ocornut commented

2018-06-25 07:48:37 +00:00

(Migrated from github.com)

You may be right here.

Changing the current GL 3.2 code shaders to GLSL 1.10 would still requires some extensive testing as real world OpenGL version and driver supports are a mess. We also have a backward compat problem where people called the init version with #150 shader version.
Why do you say "Add a proper OpenGL 2 renderer example": do you actually need one or have use for one? Would there be any use for that? (I personally don't think so).

I'd be tempted to just rename the opengl2.* files to opengl1.*

You may be right here. - Changing the current GL 3.2 code shaders to GLSL 1.10 would still requires some extensive testing as real world OpenGL version and driver supports are a mess. We also have a backward compat problem where people called the init version with `#150` shader version. - Why do you say "Add a proper OpenGL 2 renderer example": do you actually need one or have use for one? Would there be any use for that? (I personally don't think so). I'd be tempted to just rename the opengl2.\* files to opengl1.\*

malucard commented

2018-06-25 17:27:38 +00:00

(Migrated from github.com)

I realized the title doesn't actually reflect what I mean, so I changed it. But yes, there is a use. Not all computers have GL 3.2. I can't just require it in my application if it's not necessary, I'll be leaving a lot of users behind and pissing off a lot of people. I can't just assume everyone has it. A good example is Godot, it started requiring 3.3 and it was a disaster (they're adding 2.0 support back).

But it's true that the GLSL support is a mess. I found that GL 4.5 only requires GLSL 1.40 and later to be supported, although 1.10 is often supported anyway. But it also requires GLSL 1.00, so an option would be to lower the GL 3.2 example to 3.1, and create another version for GL ES 2.0, which isn't going away anytime soon. Optionally, there could be another version for desktop GL 2.0.

I realized the title doesn't actually reflect what I mean, so I changed it. But yes, there is a use. Not all computers have GL 3.2. I can't just require it in my application if it's not necessary, I'll be leaving a lot of users behind and pissing off a lot of people. I can't just assume everyone has it. A good example is Godot, it started requiring 3.3 and it was a disaster (they're adding 2.0 support back). But it's true that the GLSL support is a mess. I found that GL 4.5 only requires GLSL 1.40 and later to be supported, although 1.10 is often supported anyway. But it also requires GLSL 1.00, so an option would be to lower the GL 3.2 example to 3.1, and create another version for GL ES 2.0, which isn't going away anytime soon. Optionally, there could be another version for desktop GL 2.0.

ocornut commented

2018-06-25 18:28:18 +00:00

(Migrated from github.com)

I'll be leaving a lot of users behind and pissing off a lot of people. I can't just assume everyone has it.

But the existing "OpenGL 2" example already full-fill that criteria.
Also, I presume an engine like Godot would have its own renderer, so it'll be easy to rewrite a renderer for their API.

> I'll be leaving a lot of users behind and pissing off a lot of people. I can't just assume everyone has it. But the existing "OpenGL 2" example already full-fill that criteria. Also, I presume an engine like Godot would have its own renderer, so it'll be easy to rewrite a renderer for their API.

malucard commented

2018-06-25 20:25:13 +00:00

(Migrated from github.com)

// **DO NOT USE THIS CODE IF YOUR CODE/ENGINE IS USING MODERN OPENGL (SHADERS, VBO, VAO, etc.)**
// **Prefer using the code in imgui_impl_opengl3.cpp**
// This code is mostly provided as a reference to learn how ImGui integration works, because it is shorter to read.
// If your code is using GL3+ context or any semi modern OpenGL calls, using this is likely to make everything more
// complicated, will require your code to reset every single OpenGL attributes to their initial state, and might
// confuse your GPU driver.
// The GL2 code is unable to reset attributes or even call e.g. "glUseProgram(0)" because they don't exist in that API.

I wouldn't want a renderer with consequences like those.

And Godot's new 2.0 renderer has been in development since the beginning of this year, and it's still not ready, so it's clearly not easy.

```cpp // **DO NOT USE THIS CODE IF YOUR CODE/ENGINE IS USING MODERN OPENGL (SHADERS, VBO, VAO, etc.)** // **Prefer using the code in imgui_impl_opengl3.cpp** // This code is mostly provided as a reference to learn how ImGui integration works, because it is shorter to read. // If your code is using GL3+ context or any semi modern OpenGL calls, using this is likely to make everything more // complicated, will require your code to reset every single OpenGL attributes to their initial state, and might // confuse your GPU driver. // The GL2 code is unable to reset attributes or even call e.g. "glUseProgram(0)" because they don't exist in that API. ``` I wouldn't want a renderer with consequences like those. And Godot's new 2.0 renderer has been in development since the beginning of this year, and it's still not ready, so it's clearly not easy.

ocornut commented

2018-06-26 09:41:34 +00:00

(Migrated from github.com)

Regardless, if you implemented dear imgui in Godot you would want to use Godot's renderer API and not really a raw OpenGL api?

malucard commented

2018-06-26 17:21:36 +00:00

(Migrated from github.com)

I'm not using Godot. And this is about the GL versions of the examples, nothing to do with Godot.

ocornut commented

2018-06-26 17:30:17 +00:00

(Migrated from github.com)

Maintaining those examples is already a crazy amount of work. I can’t be creating new ones for hypothetical situations.

It’s easier for anyone to create the render loop they need in their own project than for me or anyone to create one function that save and restore every possible GL state for a given GL version.

Maintaining those examples is already a crazy amount of work. I can’t be creating new ones for hypothetical situations. It’s easier for anyone to create the render loop they need in their own project than for me or anyone to create one function that save and restore every possible GL state for a given GL version.

malucard commented

2018-06-26 17:56:06 +00:00

(Migrated from github.com)

I don't follow. I was saying the GL 3 example only actually required GL 2 features, so there could be an identical one with a a #version 110 shader named GL 2, and the current GL 2 example could be renamed to GL 1. No need to fix the current legacy GL example.

ocornut commented

2018-06-26 18:39:22 +00:00

(Migrated from github.com)

I may rename the GL2 to GL1.

The mere changing of the GLSL version to #version 110 + shader is something we haven't tested properly it is bound to break something. See #1466, #1513, #1667 and dozens of other issues to get an impression how tricky/messy the whole multi-platform driver situation is. While I'm not against it, there's no point is risking to break something if there's no actual user for it.

I may rename the GL2 to GL1. The mere changing of the GLSL version to `#version 110` + shader is something we haven't tested properly it is bound to break something. See #1466, #1513, #1667 and dozens of other issues to get an impression how tricky/messy the whole multi-platform driver situation is. While I'm not against it, there's no point is risking to break something if there's no actual user for it.

ocornut commented

2018-07-10 16:37:00 +00:00

(Migrated from github.com)

@jv110 I have now pushed some changes to the GL3 code Examples+Bindings to support more version of GLSL. Unfortunately it is tricky to test widely because each drivers appears to have different support for backward compatibility, and before GL 3.0 we can't reliably request a Forward Compatible context.

I think it should work now with GLSL #version 110 (see commit above) but it's not impossible that my driver is being kinder than required. Perhaps it'll work with GL ES now.

Interested in your feedback if you have any way to test some of this.
Do you think as it stand the code would run on a pure GL 2.0 era machine?

(I am still considering doing some renaming renaming after we sorted this out carefully)

@jv110 I have now pushed some changes to the GL3 code Examples+Bindings to support more version of GLSL. Unfortunately it is tricky to test widely because each drivers appears to have different support for backward compatibility, and before GL 3.0 we can't reliably request a Forward Compatible context. I _think_ it should work now with GLSL `#version 110` (see commit above) but it's not impossible that my driver is being kinder than required. Perhaps it'll work with GL ES now. Interested in your feedback if you have any way to test some of this. Do you think as it stand the code would run on a pure GL 2.0 era machine? (I am still considering doing some renaming renaming after we sorted this out carefully)

ocornut commented

2019-03-13 10:59:39 +00:00

(Migrated from github.com)

Hello @jv110,

Would you be able to help testing and/or patch the code in imgui_impl_opengl3.cpp to correctly support GL 2.0/2.1 and GLSL 1.10 ?

Right now we default to GLSL 1.30 what do you think of that in term of compatibility?

imgui_impl_opengl3.cpp has been recently improved for WebGL 1/2. I will rename imgui_impl_opengl3.cpp to imgui_impl_opengl.cpp, and imgui_impl_opengl2.cpp to imgui_impl_opengl_legacy.cpp eventually, maybe the 1.70 milestone is a good target for that.

Thank you.

Hello @jv110, Would you be able to help testing and/or patch the code in imgui_impl_opengl3.cpp to correctly support GL 2.0/2.1 and GLSL 1.10 ? Right now we default to GLSL 1.30 what do you think of that in term of compatibility? imgui_impl_opengl3.cpp has been recently improved for WebGL 1/2. I will rename `imgui_impl_opengl3.cpp` to `imgui_impl_opengl.cpp`, and `imgui_impl_opengl2.cpp` to `imgui_impl_opengl_legacy.cpp` eventually, maybe the 1.70 milestone is a good target for that. Thank you.

malucard commented

2019-03-14 04:17:22 +00:00

(Migrated from github.com)

I'm sorry, it had been so long, I had forgotten about all this. But sure, I can try to help. I'll try this out tomorrow.

1.30 is pretty good, and I think a lot of applications do require that, although the choice is important. My computer only supports GL 3.1 (GLSL 1.40), if that's relevant.

I'm sorry, it had been so long, I had forgotten about all this. But sure, I can try to help. I'll try this out tomorrow. 1.30 is pretty good, and I think a lot of applications do require that, although the choice is important. My computer only supports GL 3.1 (GLSL 1.40), if that's relevant.

👍 1

Rows
Columns

Backend renderer naming/filename mismatch GL versions #1900