Closed FabriceSalvaire closed 4 years ago
Can you explain what you mean by a messed desktop?
These error messages look weird:
Invalid alias: The name clear can't be aliased because it is another magic command. Invalid alias: The name more can't be aliased because it is another magic command. Invalid alias: The name less can't be aliased because it is another magic command. Invalid alias: The name man can't be aliased because it is another magic command.
Are you sure, everything was setup correctly?
I don't think we have a lot of developer expertise with Fedora linux (not me anyway), but I would be interested in what happens if you start MH with the --noshaders switch.
For reference here is some discussion of the gt:glx error on Qt forum: https://forum.qt.io/topic/90639/comparing-qt-widgets-app-under-gnome-wayland-using-platform-wayland-egl-to-xcb/20 They seem to be indirectly tying it to Wayland.
I also note in passing that you are working with newer versions of many dependencies than we have used as a rule. I don't know if this is critical, but we had some compatibility issues in numpy when ubuntu 18.04 came out.
Your logs show: NUMPY.VERSION: 1.16.2 QT.VERSION: 5.12.2
For the record, I'm still at: NUMPY.VERSION: 1.13.3 QT.VERSION: 5.10.1
I've tested with the latest release of (k)ubuntu and I can confirm the problem. I assume a problem with Intels's Mesa Driver. The viewport isn't really messed up, but the human does not appear i.e. the screen is black and other windows overlaying the viewport do not get cleared. There are no errors in the logging. Using my AMD-GPU some (very) quick tests showed that there it is working. So I'm not convinced it is a Wayland/Qt-issue...
I can confirm the issue on intel, after i have upgraded whole system. There are no errors in the log, but the viewport is black. Rendering on the render tab works.
My config from logs:
SYS.VERSION: 3.7.2 (default, Dec 30 2018, 16:18:15) [GCC]
SYS.PLATFORM: linux
PLATFORM.PROCESSOR: x86_64
PLATFORM.UNAME.RELEASE: 5.0.11-1-vanilla
PLATFORM.LINUX_DISTRIBUTION:
NUMPY.VERSION: 1.16.2
QT.VERSION: 5.12.3
QT.JPG_SUPPORT: not supported
QT.SVG_SUPPORT: not supported
QT.PLUGIN_PATH: /usr/lib64/qt5/plugins:/usr/bin
QT.PLUGIN_PATH_ENV:
QT.CONF: NOT PRESENT
qt.glx: qglx_findConfig: Failed to finding matching FBConfig (8 8 8 1)
qt.glx: qglx_findConfig: Failed to finding matching FBConfig (1 8 8 1)
qt.glx: qglx_findConfig: Failed to finding matching FBConfig (1 1 8 1)
qt.glx: qglx_findConfig: Failed to finding matching FBConfig (1 1 1 1)
qt.glx: qglx_findConfig: Failed to finding matching FBConfig (1 1 1 1)
qt.glx: qglx_findConfig: Failed to finding matching FBConfig (1 1 1 1)
qt.glx: qglx_findConfig: Failed to finding matching FBConfig (8 8 8 1)
qt.glx: qglx_findConfig: Failed to finding matching FBConfig (1 8 8 1)
qt.glx: qglx_findConfig: Failed to finding matching FBConfig (1 1 8 1)
qt.glx: qglx_findConfig: Failed to finding matching FBConfig (1 1 1 1)
qt.glx: qglx_findConfig: Failed to finding matching FBConfig (1 1 1 1)
qt.glx: qglx_findConfig: Failed to finding matching FBConfig (1 1 1 1)
PYOPENGL.VERSION: 3.1.3b1
GL.VENDOR: Intel Open Source Technology Center
GL.RENDERER: Mesa DRI Intel(R) Ivybridge Mobile
GL.VERSION: 3.0 Mesa 19.0.3
GLSL.VERSION: 1.30
GL.EXTENSION: GL_ARB_multisample enabled (0x samples)
Creating new texture for image data/textures/texture_notfound.png.
GL.EXTENSION: GL_ARB_texture_non_power_of_two enabled
"messy" means that viewport shows some static frame with background apps and splash screen, as if captured on the makehuman startup
I had the same problem with Ubuntu 18, but MH worked flawlessly for the first time. I closed the application and re-opened the program and this issue happened. Is there a workaround?
Workaround that works on my system:
In file lib/qtui.py, line 185, class Canvas
, method __init__()
comment out the following two lines by prepending them with a #, i.e.
# format.setSampleBuffers(True)
# format.setSamples(4)
Thank you Christoph for helping out. It fixes the bug on my system and I couldn't see negative side effects with my second graphics card or on older Linux systems. Pushed the fix with commit 8552716. I'll leave the task open for some days, in case anyone reports further problems.
Thanks cfeck, that's exceptionally good news. I was never able to reproduce the problem on any of my computers, so it was a bit hard to track down.
So far I haven't been able to see any downside on my ubuntu/nvidia system either.
Upon closer examination, the fix does something with transparency. This is obviously better than crashing, but we should take this into account before releasing.
The first image is before the fix, the second is after the fix:
We probably should be careful to document hardware, versions and conditions here.
Did the transparency problem occur with your Nvidia card or an Intel card? Ubuntu 18.04 I presume? The latest Mesa drivers ( https://www.mesa3d.org/ ) are 19.1.1 and 19.0.8. Were these involved?
The images were from an nvidia card with nvidia-384 binary drivers repackaged by ubuntu.
mesa version on the machine is 18.0.5
Oops, I must confess I've missed that one, though the explanation for that is quite simple, since transparency didn't work for a longer time on my system. Which, by the way, is not true when doing a render, regardless of the GPU or version of the OS. Could you recheck this on your systems? In the end, that forces the assumption the problem is in the rest code rather than in the bug fix. Perhaps our user cfeck is affordable for another round of bug fixing ...?
Just to make that discussion a little more complete, here is a short quote of Brecht^:
The original plan for Blender 2.80 was to work on all GPUs that have OpenGL 3.3 drivers and were released in the last 10 years. However, we have found that there are many graphic cards that support OpenGL 3.3 in hardware, but have critical bugs in the OpenGL drivers.
We have found workarounds for dozens of those bugs, which has been very time-consuming. Blender now works on the large majority GPUs that our users have. Unfortunately, there are still some GPUs where Blender does not run reliably, and we won’t be able to officially support them for the 2.80 release. All these are cases where the OpenGL driver was last updated 3 years ago or more.
Reading these lines, I start yearning for an extra dose of Prozac....
Just to follow up on the transparency comments, I think we may be introducing fixes that are causing us to lose ground. We may want to reverse commits. Compare the ponytail hairline with the alpha3 windows build and current master 1.2.0 Alpha4 (master:41b65779).
I've introduced a change that makes the above fix depend on the --noshaders argument, with the reasoning that on a crippled graphics card --noshaders might make sense anyway. This way users with a working card won't be affected.
I'm not sure if that's the solution. As I stated above the transparency issue is on my AMD Graphics card, too. But when rendering the model, transparency is shown correctly. This makes me think of crippled OpenGL code rather than of a crippled graphics card. Not everyone is in the fortunate situation having multiple high end NVIDIA GPUS in the working machine. Still wondering about the minimum specs to run MakeHuman... Funnily enough Blender 2.8 (sic!) is working without problems on my crippled Intel GPU (though rendering speed could be slightly better...).
The current situation is that the fix with commenting out two lines makes things better for intel cards and worse for an unknown set of other cards.
Until we figure out a proper fix which works for all cards, I don't think we should have these two lines commented out per default. But for intel cards, users need to be able to disable the two offending lines.
An alternative solution for now might be to make the two lines with the fix for intel cards optional using some other mechanism, either through configuration or through command line arguments. I agree that using --noshaders might be a somewhat overkill solution.
Hey there. I’m still experiencing this same issue with my integrated gpu on my X1 Carbon ThinkPad. I know this bug says a fix exists, but what do we do if we still see this issue?
Checking this task again, one thing is interesting: The eyes still seem to show the correct transparency.
I'm also still struggling with this. When I try running makehuman after commenting out those two lines I get this indentation error and it won't open at all.
Traceback (most recent call last): File "./makehuman.py", line 613, in
main() File "./makehuman.py", line 603, in main from mhmain import MHApplication File "./core/mhmain.py", line 45, in import mh File "./lib/mh.py", line 50, in from qtui import Keys, Buttons, Modifiers, Application File "./lib/qtui.py", line 188 super(Canvas, self).init(format, parent) ^ IndentationError: expected an indented block
Nevermind, just removed
if not G.args.get('noshaders', False):
and now everything seems to be working perfectly
Just had the original issue show up on a non-intel gpu:
Nvidia Quadro fx 880m ( yeah, old) Archlinux, Nouveau driver.
Xfce4 w/ compositing disabled. I'll edit in version numbers when I get a chance to check.
I had exact the same issue on Debian 10. Intel® UHD Graphics 630 (Coffeelake 3x8 GT2) / GeForce GTX 1060 Mobile
As suggested by @cfeck removing / commenting the lines in lib/qtui.py solves the issue:
if not G.args.get('noshaders', False):
format.setSampleBuffers(True)
format.setSamples(4)
Thank you! Riccardo
I have now implemented two settings that can be tried if the viewport misbehaves. Their behavior is described in http://www.makehumancommunity.org/wiki/FAQ:The_interface_looks_broken
The current nightly build contains these changes. It'd be nice if someone who had problems with the viewport checked if this is of any help.
I have now implemented two settings that can be tried if the viewport misbehaves. Their behavior is described in http://www.makehumancommunity.org/wiki/FAQ:The_interface_looks_broken
The current nightly build contains these changes. It'd be nice if someone who had problems with the viewport checked if this is of any help.
After checking those two options and restarting a warning appears, stating that only simple shading will be available. I press ok and... voilà, everything is correct :smiley: !
Thank you @joepal1976 !
Good to hear. I'm going to assume that this available workaround is enough to solve the problem for most people, and thus close the issue.
logs are