"fbo not supported" on Intel HD 4000 #105
Comments
|
Relevant: https://community.khronos.org/t/problem-using-framebuffer-for-picking/72670/6 It seems quite likely that the problem is with using FBOs with unsigned integers (instead of floats) for picking, which the HD 4000 doesn't seem to support properly. Disabling blending, or reducing the number of bits of the framebuffer (32bits to 16bits) might help. Note that the message "fbo not supported" is actually VPaint code in View::newPicking(): |
|
New development: I just installed Kubuntu 16.04 updates on my on my main Linux laptop, launched VPaint, and I got this error too! Then I realized that this laptop (Asus Zenbook UX31A bought in Feb 2014) is actually using an Intel HD 4000. Since VPaint used to work on this laptop (I made all my Siggraph presentations with it), both on Kubuntu 16.04 and Windows 7, this is not a hardware limitation. And actually, even the same VPaint binary on the same operating system used to work. The version that first showed me this error was the latest commit from VPaint master branch (2c80ed5), compiled locally on Kubuntu 16.04 on Dec 25, 2018 against Qt 5.10.0. So far, I also tried a locally built version of VPaint 1.6 against Qt 5.6.0, and the error doesn't occur. So this can be caused by either OS/driver updates, changes in Qt, or changes in VPaint, or any combinations of those. I'll definitely investigate since I need the latest version of VPaint to run on this laptop! |
|
Alright, this is in fact a regression introduced by 0e80508, where I changed from using the old, deprectated QGLWidget, to the newer, better QOpenGLWidget. More precisely, on an Asus Zenbook UX31A (with Intel HD 4000), up-to-date Kubuntu 16.04, Qt 5.12.5, we have the following:
If I remove the following code in View.cpp: Then the app crashes on the following line: So this really looks like an issue with using GLEW and QOpenGLWidget together in an improper way, and I hope it is fixable (we should use the QtOpenGLFunctions instead of the GLEW direct functions calls). Why it somehow worked before I updated my Kubuntu is still a mystery, though. |
|
Note: I was wondering whether we needed GLEW at all (now that we use QOpenGLWidget), but the answer is yes, because we use GLU for tessellation purposes, and Qt does not provide GLU functions. |
|
After more testing, here are some partial thoughts and results. Using QOpenGLWidget with GLEW really is problematic. If we include GLEW before QOpenGLFunctions, then there is a warning and the latter undefines most (all?) OpenGL 3.0+ functionality defined by GLEW. For example, If we do the opposite and include GLEW after QOpenGLFunctions, then it doesn't compile, as GLEW complains that Therefore, what I tried was to remove GLEW altogether, and manually include GLU in the C++ files that require it for tesselation, which are Doing so, OpenGL 3.0+ functions are not globally accessible anymore. We can access them in relevant C++ files by doing these types of things: Also, doing so, it seems that OpenGL 2.1 functions are still globally accessible, at least they compile. However, there are still a few issues:
The next step is then to try by requesting an OpenGL 3.0 context, even though I believe VPaint requires some OpenGL 3.2 functionality (integer pixel formats? non-rectangle buffers? To be investigated). Note that if we request an OpenGL 3.0 context without calling |
|
For information, when we run the following on the Intel HD 4000 laptop, Kubuntu 16.04, Qt 5.12.5: We get the following output: And running |
dalboris
added a commit
that referenced
this issue
Oct 15, 2019
|
Alright, not including GLEW, and requesting an OpenGL 3.0 context (making sure to set the DeprecatedFunctions option) does work on Kubuntu 16.04 on the laptop with Intel HD 4000. I'll test later on other hardware and operating systems, but already made a commit. Note that despite not including GLEW, I still keep it in the project and link to it. I don't believe this is necessary, but it'll make it easier to add it back if necessary. VPaint should be thrown away eventually, so I go for the minimal working bugfix. |
|
Unfortunately VPaint now crashes on opening on a MacBook Pro (13-inch, 2017, Four Thunderbolt 3 Ports), Intel Iris Plus Graphics 650 1536 MB. This is really annoying, it's because macOS doesn't support at all OpenGL 3.0+ compatibility profiles, so even though I request a 3.0 compatibility profile with: I get in fact a 2.1 context: and the following call returns a nullptr: It seems that it was somewhat working before when using GLEW, but it wasn't really clean anyway. Obviously, the proper fix would be to stop using deprecated OpenGL and request a 3.2 Core Profile, but this would take way too long to implement for prototype software meant to be thrown away soon. Another perhaps sensible solution would be to request a 2.x profile and then use extensions to access 3.x functions. I'm not sure how to do this with Qt 5.12, but I'll investigate. A potential uglier fix is to use back GLEW, doing ugly defines/undefines so that both GLEW and Qt can somehow collaborate. |
|
Note: below is the output from the test program written a few messages above. We can see that macOS really insists on an OpenGL 2.1 context. |
dalboris
added a commit
that referenced
this issue
Nov 9, 2019
|
This should be fixed now. We are now only requesting an OpenGL 2.1 context, and querying explicitely for the |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
A user reported that he managed to compile VPaint, but that he has the following error message at runtime, both on Linux and Windows:
He is using a HP Elitebook 8470p laptop, with an Intel Core i5 3320m, with Intel HD 4000. This is quite an old chipset (released in 2012), but according to Intel it should support OpenGL 4.0, and VPaint only requires OpenGL 3.2.
There are a bunch of similar issues on the Internet, but mostly with Intel HD 3000, not Intel HD 4000. For example:
LWJGL/lwjgl#119
processing/processing#4586
It isn't clear yet whether our specific problem is actually a bug of VPaint (using a FBO with some configuration not officially supported by OpenGL 3.2), or a bug in the OpenGL driver of the HD 4000, claiming that it supports 100% OpenGL 3.2 while actually it doesn't. The above links definitly show that it was a driver problem for the HD 3000. It may or may not be the same for the HD 4000. Either way, it's probably going to be complicated to solve, unfortunately. But I'll see what I can do, especially if this would also affect VGC.
The text was updated successfully, but these errors were encountered: