When OpenGL ogre2 rendering is happening via mesa's llvmpipe 21 or 22 with Ignition Fortress a black area is displayed instead of the 3D rendering #1116
Comments
|
Did the name and/or location of Looking through the logs plugin loads usually take the form However, this is not the case for the ogre2 rendering plugin. Instead, there are several entries that claim to load the plugin, but they all just seem to fizzle, i.e., they claim to load and then fail silently (without a log entry) causing ignition to re-attempt the load several times to no avail. Edit: Wouldn't failing/waiting for the load also explain the problems with closing the application? Ignition would be waiting for a system call to dynamically return/load the requested library (perhaps several times) and hence will wait for the load to complete to then unload afterwards and exit cleanly. |
I should have made this more clear in the original post, but what I noticed is that the program is not closing correctly if one tries to closes it via the X button in the GUI, but it closes normally if one tries to closes it via Ctrl+C in the terminal. Furthermore, I did not included it in the original post, but now I added the |
|
The ogre.log is generated by the underlying render system, in the case of Fortress this is ogre-next v2-2. It looks like there are GLSL compile errors, which most likely means that the version of OpenGL being used is not supported on the platform you are running. Ogre v2.2 uses a number of OpenGL features that require version >= 4.2. If these are only partially supported on WLS2 that would explain the compile error and it may be that this leaves the application in an undefined state, so the slow close etc. Btw there are similar issues using Ogre 2.2 on macOS with OpenGL which is why we’ve been exploring using Metal for that platform. I’m not familiar with the OpenGL implementation used by WLS2 but I ran into what might be a related issue running an Ubuntu 20.04 VMware client on a macOS host with Ignition Edifice. In this case the driver is Mesa and initially it would not render, however there’s are environment variables to override the OpenGL profile and extensions being used, and disabling OpenGL extensions that were not fully supported or correctly implemented resolved the issue. The issue for VMware is discussed here: https://answers.gazebosim.org//question/27244/ignition-flashing-image-cant-quit/ |
traversaro
changed the title
|
Thanks @srmainwaring! Your comment explained a lot, and now I am indeed investigating what is going on at deeper level. The OpenGL rendering in this case is happening via mesa's llvm as one can see via the For completeness, the compiler errors mentined by @srmainwaring are: So the shaders involved are:
Note that in general |
traversaro
changed the title
|
I was able to replicate the problem on GitPod, a virtualized solution that we use a lot (for things such as https://github.com/robotology/icub-gazebo-grasping-sandbox):
Also the ogre2.log errors are exactly the same. This confirms that the problem is in the latest |
To be honest, I noticed now that |
For reference, the actual error is: and the error is raised from https://github.com/OGRECave/ogre-next/blob/ec3f70cb53a8a7e5d196855d0274ac03f90a2f4c/RenderSystems/GL3Plus/src/OgreGL3PlusRenderSystem.cpp#L3364 . The glxinfo OpenGL line for mesa 21.0 are: while the same lines for mesa 22.0 are: the main difference is the "Max compat profile version" line, that is 3.1 for mesa 21 while 4.5 for mesa 22. |
traversaro
changed the title
|
Indeed, even with mesa 21 I was able to start |
|
@traversaro I have a Windows VM which I could try to replicate this on - I'll probably start trying to get the ignition-rendering examples working because there's a lot less going on than with ignition-gazebo and they will generally display similar behaviour re. OpenGL etc. Is there a set of instructions to set up your environment that I can follow to ensure I match (mainly the WSL setup). |
|
I installed WSL2 Ubuntu 20.04 from Windows Store. After that, I installed two additional apt repos:
After that, I run: and then: After that, you should be able to reproduce the "blank screen" problem by executing: Note that based on my experience with gitpod probably the problem is not WSL-specific, so I would expect that you are able to reproduce this problem even on any Ubuntu 20.04 system, by running: if you have mesa 22 installed, or: if you only have mesa 21 installed. In both cases the use of LIBGL_ALWAYS_SOFTWARE variable should ensure that |
|
And thanks a lot for the interest @srmainwaring ! |
traversaro
changed the title
|
Regarding the shader compile errors:
They've been fixed (gazebosim/gz-rendering#433 and gazebosim/gz-rendering#456) and one is being forward ported. They are related to mouse picking and lidar visualization. I think those PRs won't help here though as it looks like the issue is something else. |
Thanks a lot for chiming in! Indeed I tried also with a build from source in which that PR have been merged, and the issue is still there but the compiler errors are not there:
See in the following for the |
|
@traversaro I've taken a look at this and am almost certain that the main issue is because the default multi-sampling anti-aliasing (MSAA) settings are not valid for the llvmpipe OpenGL profile. The system I used for the analysis is Ubuntu 20.04 running as a VMware Fusion 12.1.2 guest. The host is a Mac Pro running macOS Big Sur 11.6. The Ubuntu machine has the 1. Software rendering (llvmpipe): OpenGL 3.3 not supportedTo avoid the Reason: Setting Compare not setting $ LIBGL_ALWAYS_SOFTWARE=true LANG=C glxinfo -B | grep -i '\(direct rendering\|opengl\|profile\)'
direct rendering: Yes
Preferred profile: core (0x1)
Max core profile version: 4.5
Max compat profile version: 3.1
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.2
OpenGL vendor string: Mesa/X.org
OpenGL renderer string: llvmpipe (LLVM 12.0.0, 256 bits)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 21.0.3
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL version string: 3.1 Mesa 21.0.3
OpenGL shading language version string: 1.40
OpenGL context flags: (none)
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 21.0.3
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20To setting $ LIBGL_ALWAYS_SOFTWARE=true MESA_GL_VERSION_OVERRIDE=4.5 LANG=C glxinfo -B | grep -i '\(direct rendering\|opengl\|profile\)'
direct rendering: Yes
Preferred profile: core (0x1)
Max core profile version: 4.5
Max compat profile version: 4.5
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.2
OpenGL vendor string: Mesa/X.org
OpenGL renderer string: llvmpipe (LLVM 12.0.0, 256 bits)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 21.0.3
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL version string: 4.5 (Compatibility Profile) Mesa 21.0.3
OpenGL shading language version string: 4.50
OpenGL context flags: (none)
OpenGL profile mask: compatibility profile
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 21.0.3
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20I suspect what is going on is that Qt looks to the compatibility profile when setting the OpenGL context and scene graph surface format. Without the override this falls back to 3.1 and then Ogre warns that the OpenGL version is insufficient. 2. Software rendering (llvmpipe): Main scene is not renderedThe ignition rendering, gui, sensor and gazebo libraries set default values for the MSAA in a number of places. If the default values are not compatible with the Mesa driver the final step of the scene compositor, which attaches the resolved scene to the FBO used by the Qt scene graph, fails (the FBO colour attachment is not valid, and you get a host of OpenGL errors). A work-around is to disable the anti-aliasing by setting it to 0 everywhere it is defaulted. With this change we have for example: $ ign gazebo -v4 -r camera_sensor.sdf
These are the places where the anti-aliasing is set:
# ign-rendering/ogre/src/OgreRenderEngine.cc
@@ -542,7 +542,7 @@ void OgreRenderEngine::CreateRenderSystem()
// check if target fsaa is supported
unsigned int fsaa = 0;
- unsigned int targetFSAA = 4;
+ unsigned int targetFSAA = 0;
auto const it = std::find(this->dataPtr->fsaaLevels.begin(),
this->dataPtr->fsaaLevels.end(), targetFSAA);
if (it != this->dataPtr->fsaaLevels.end())
# ign-rendering/ogre2/include/ignition/rendering/ogre2/Ogre2RenderTarget.hh
@@ -222,7 +222,7 @@ namespace ignition
protected: bool backgroundMaterialDirty = false;
/// \brief Anti-aliasing level
- protected: unsigned int antiAliasing = 4;
+ protected: unsigned int antiAliasing = 0;
/// \brief visibility mask associated with this render target
protected: uint32_t visibilityMask = IGN_VISIBILITY_ALL;
# ign-rendering/ogre2/src/Ogre2RenderEngine.cc
@@ -612,7 +612,7 @@ void Ogre2RenderEngine::CreateRenderSystem()
// check if target fsaa is supported
unsigned int fsaa = 0;
- unsigned int targetFSAA = 4;
+ unsigned int targetFSAA = 0;
auto const it = std::find(this->dataPtr->fsaaLevels.begin(),
this->dataPtr->fsaaLevels.end(), targetFSAA);
if (it != this->dataPtr->fsaaLevels.end())
# ign-gui/src/plugins/minimal_scene/MinimalScene.cc
@@ -544,7 +544,7 @@ void IgnRenderer::Initialize()
this->dataPtr->camera->SetLocalPose(this->cameraPose);
this->dataPtr->camera->SetImageWidth(this->textureSize.width());
this->dataPtr->camera->SetImageHeight(this->textureSize.height());
- this->dataPtr->camera->SetAntiAliasing(8);
+ this->dataPtr->camera->SetAntiAliasing(0);
this->dataPtr->camera->SetHFOV(M_PI * 0.5);
// setting the size and calling PreRender should cause the render texture to
// be rebuilt
# ign-gui/src/plugins/scene3d/Scene3D.cc
@@ -1146,7 +1146,7 @@ void IgnRenderer::Initialize()
this->dataPtr->camera->SetLocalPose(this->cameraPose);
this->dataPtr->camera->SetImageWidth(this->textureSize.width());
this->dataPtr->camera->SetImageHeight(this->textureSize.height());
- this->dataPtr->camera->SetAntiAliasing(8);
+ this->dataPtr->camera->SetAntiAliasing(0);
this->dataPtr->camera->SetHFOV(M_PI * 0.5);
// setting the size and calling PreRender should cause the render texture to
// be rebuilt
# ign-sensors/src/CameraSensor.cc
@@ -169,7 +169,7 @@ bool CameraSensor::CreateCamera()
}
// \todo(nkoeng) these parameters via sdf
- this->dataPtr->camera->SetAntiAliasing(2);
+ this->dataPtr->camera->SetAntiAliasing(0);
math::Angle angle = cameraSdf->HorizontalFov();
if (angle < 0.01 || angle > IGN_PI*2)
# ign-sensors/src/DepthCameraSensor.cc
@@ -386,7 +386,7 @@ bool DepthCameraSensor::CreateCamera()
this->dataPtr->near = near;
// \todo(nkoeng) these parameters via sdf
- this->dataPtr->depthCamera->SetAntiAliasing(2);
+ this->dataPtr->depthCamera->SetAntiAliasing(0);
math::Angle angle = cameraSdf->HorizontalFov();
if (angle < 0.01 || angle > IGN_PI*2)
# ign-sensors/src/RgbdCameraSensor.cc
@@ -344,7 +344,7 @@ bool RgbdCameraSensor::CreateCameras()
}
// \todo(nkoeng) these parameters via sdf
- this->dataPtr->depthCamera->SetAntiAliasing(2);
+ this->dataPtr->depthCamera->SetAntiAliasing(0);
math::Angle angle = cameraSdf->HorizontalFov();
// todo(anyone) verify that rgb pixels align with d for angles >90 degrees.
# ign-gazebo/src/gui/plugins/scene3d/Scene3D.cc
@@ -2124,7 +2124,7 @@ void IgnRenderer::Initialize()
this->dataPtr->camera->SetLocalPose(this->cameraPose);
this->dataPtr->camera->SetImageWidth(this->textureSize.width());
this->dataPtr->camera->SetImageHeight(this->textureSize.height());
- this->dataPtr->camera->SetAntiAliasing(8);
+ this->dataPtr->camera->SetAntiAliasing(0);
this->dataPtr->camera->SetHFOV(M_PI * 0.5);
this->dataPtr->camera->SetVisibilityMask(this->visibilityMask);
// setting the size and calling PreRender should cause the render texture to(The gazebo change is not really required, because |
|
Thanks a lot @srmainwaring ! |
|
sounds like a similar problem that we ran into with Metal? So our check for anti-aliasing support is probably just not reliable. for this particular case, we could add a check, something like: if (renderSys->getCapabilities()->getDeviceName().find("llvmpipe") != std::string::npos)When testing with software rendering, the device name string for me is |
|
That's right - same issue as with Metal. It may be that the config containing the available FSAA levels obtained from Ogre is not correct, and the ignition check is doing what it's meant to but based on incorrect data. Btw. with Ignition Edifice I was able to get hardware accelerated rendering running on an Ubuntu 20.04 VM - this was really great as I could check both macOS and Ubuntu setups. Unfortunately the vmware Mesa svga driver only supports up to OpenGL 4.1 and that is not currently working for ogre-next2.2 / ignition fortress. I've made some inroads on getting ogre2.2 to work with OpenGL 4.1 but set that aside to get the Metal support for ignition in place. My question: is there sufficient interest in the community to fallback support for OpenGL 4.1, if not then I might leave that and focus on getting Metal working well and merged for ignition garden. |
Is vmware using a custom Mesa driver provided by the virtual machine softare, or just the llvmpipe driver provided by the virtualized operating system? In the latter case, recent versions of llvmpipe are OpenGL 4.5 compatible (see https://www.phoronix.com/scan.php?page=news_item&px=LLVMpipe-OpenGL-4.5-Conformant and https://www.khronos.org/conformance/adopters/conformant-products/opengl#submission_272) so if OpenGL 4.5 is enough, we can just recommend Ubuntu 20.04 users to install a recent mesa version via oibaf or similar PPA, while Ubuntu 22.04 should have a recent enough mesa for OpenGL 4.5 compatibility. |
I am definitely not an expert here, but it is possible that the one reporting incorrectly the available FSAA levels is llvmpipe itself? I tried to read a few issues in the mesa issue tracker, and there seems to be a few reference to issue that mention that it is not trivial to report correctly the available FSAA levels, but I was not able to understand them completly. Anyhow, I guess that @iche033 suggestion to just disable FSAA on llvmpipe may be a simple but effective idea, I guess that anyhow any user that uses llvmpipe is not actually interested in accurate/nice rendering (that would be quite slow for complex scenes), but just to check that basic worlds are working fine. |
The driver is VMware SVGA3D and is available for Linux. It provides Linux VM access to the hosts GPU.
I am using the standard mesa packages on Ubuntu 20.04 - so no need for custom drivers from a PPA in this case as well.
Seems like a good option given the intended use case, and does not require any upstream changes. |
I see, so it is not something directly related to |
|
To understand more I tried to navigate the code to understand it, these are the references (thay may be wrong) if anyone wants to do the same:
From the last one, it seems that ogre-next returned FSAA levels are just a guess, and the only thing that is retrieved are the maximum level, that is returned via the // We don't know which sample counts are supported (and some colour
// formats may have further restrictions)
//
// However it's usually a safe guess that all powers of 2 between 1 and maxSamples
// ought to be supported
PFNGLGETINTEGERVPROC myGlGetIntegerv =
(PFNGLGETINTEGERVPROC)eglGetProcAddress( "glGetIntegerv" );
GLint maxSamples;
myGlGetIntegerv( GL_MAX_COLOR_TEXTURE_SAMPLES, &maxSamples );
for( GLint sample = 2u; sample <= maxSamples; sample <<= 1 )
{
mDeviceData.back().fsaa.push_back(
SampleDescription( static_cast<uint8>( sample ) ) );
}
destroyDevice( size_t( i ) ); |
|
Well I am not using WSL, but I face the same error in docker, as you can see in https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/runtime/docker.html?highlight=opengl your run command should include |
…hen using OpenGL 4.5. See gazebosim/gz-sim#1116 (comment)
…hen using OpenGL 4.5. See gazebosim/gz-sim#1116 (comment)
…hen using OpenGL 4.5. See gazebosim#1116 (comment)
…hen using OpenGL 4.5. See gazebosim/gz-sim#1116 (comment)
|
I was having the same problem (Black Screen on Docker on AWS Cloud when running Ignition Fortress) Following @srmainwaring's instructions worked for me. In the end, what I did was:
Then the Black Screen went away for me. |
|
I think there is no need to recompile gz-gui, gz-sim, gz-sensors to fix the problem. I think it is sufficient to fix a bug in ign-rendering, see gazebosim/gz-rendering#661 for the proposed fix. |
|
@iche033 probably it could make sense to keep this open until a release of gz-rendering containing this fix is released, as otherwise most users (that do not install gz-rendering from source) would be still affected by this. |
|
Sounds good. I think it auto-closed after merging the PR. Re-opening. |
|
The fix was released in ign-rendering 6.5.1 and gz-rendering 7.0.0, so I think we can close the issue. |
|
I'm not really sure this has been solved. I'm still having a black screen on AWS with ign-rendering 6.5.1, as we can see in the output of sudo dpkg -l | grep tion-rendering |
|
Can you open a new issue with all the information indicated by the issue template? This would make it easier to debug your issue, thanks! |
…hen using OpenGL 4.5. See gazebosim/gz-sim#1116
…hen using OpenGL 4.5. See gazebosim/gz-sim#1116
…hen using OpenGL 4.5. See gazebosim/gz-sim#1116
|
I had the error, as I mentioned yesterday. Today, after upgrading mesa libraries as indicated on ros2/rviz#948 (comment), it worked perfectly.
|
On WSL2 with an X server, Ignition Gazebo works correctly for version 3, 4 and (partially) 5, while it stops working in versions 6. See the detailed log in the following.
Note that this is issue may be related to #920, but it is different as it only affects Ignition Fortress and it refers to WSL2 on Windows 10 using an X server, not using WSLg, that is the official solution for GUI application from Windows that only works on Windows 11 and uses Wayland.
Environment
dxdiagand report the GPU-related information.system_profiler SPDisplaysDataType. Copy the output here.~/.ignition/renderingDescription
Steps to reproduce
See the Output section for detailed information.
Output
I am on a Ubuntu 20.04 on top of a WSL2 on top of a Windows Version 20H2 (19042.1237). The Ubuntu system is pretty standard, beside the fact that the Ignition Gazebo apt repo is installed, and the Oibaf ppa ( https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers ) with the latest mesa and related graphics library is installed as at some point I had a "OpenGL 3.3 is not supported. Please update your graphics card drivers" error (similar to #1066 and #1049) when trying to launch Ogre 2-related software that I solved by updating to the latest mesa and graphics driver.
For the X server, I used Xming 6.9.0.31, configured as described in https://github.com/robotology/robotology-superbuild/tree/b441b7f025d84fe39910c01c185dd06641854fb9#wsl2 .
Output of requested command on Linux:
Output of
DxDiagon Windows:For reproducibility, exact versions of apt packages installed (see robotology/community#450):
Environment (
apt list --installed):Thanks to the amazing side-by-side installation support in the apt packaging of ignition libraries, it is quite easy to test the different versions of Ignition Gazebo without having to remove or install apt packages.
Citadel
Logs:
Output:
Effect: Ignition Gazebo starts fine, the shapes are visualized, and it exits correctly.
Dome
Logs:
Output:
Effect: Ignition Gazebo starts fine, the shapes are visualized, and it exists correctly. Exactly like Citadel.
Edifice
ogre2.log:https://gist.github.com/traversaro/9e9a17acc69dfc2762870a06c53ad414
Output:
Effect: Ignition Gazebo starts fine, the shapes are visualized (even the additional ones that are not there in Citadel/Dome). Then, when closed via the x button in the window, it does not exits cleanly. W.r.t. to Citadel and Dome, there are some additional errors in the terminal.
Fortress
Output:
ogre2.log:Effect: Ignition Gazebo starts, but a black area is visualized instead of the OpenGL rendering area. It does not close correctly, and it is necessary to force its closing via multiple Ctrl+C .
The text was updated successfully, but these errors were encountered: