Open peci1 opened 2 years ago
Is there some kind of OpenGL/Ogre profiling info I can provide?
@simonschmeisser Is this the same issue you described in #1714?
Yes, I saw the same. We only use "points" so for me the speed gain would be worth it :wink:
I can confirm the issue on an Intel GPU as well with stock Mesa 21.2.6 on Focal.
Points
display using weird point sizes for specific window heights.Here, the points
display works fine (was fixed in Mesa 21.0.3), but all other geoms ignore color and size settings.
With nvidia everything works as expected :wink:
@simonschmeisser, you argue with speed gain. What exactly do you compare and how?
I guess, points are faster than any other geom. Are the GLSL 1.5 shaders faster than GLSL 1.2 as well? If so, we might drop the Mesa workaround despite the bug reported here, because points
are the way to go anyway. We should make points
the default then...
My "measurements" have not been very scientific so far. With the hack enabled and a very detailed octomap rendering drops < 1fps. (octomap rendering is basically type "boxes") (That "data point" was on bionic)
Trying to make it a bit more reproducible I changed the send_point_cloud_2.py to 1000x1000 points. Without the hack the white dots are displayed at 30fps, with rviz --opengl 310
the frame rate drops to 10-15 fps.
This bug unfortunately also applies to the display of octomaps
I tried using renderdoc but it complains about old OpenGl versions/ contexts being used ... oh my.
I think the big difference in performance is in https://github.com/ros-visualization/rviz/blob/noetic-devel/src/rviz/ogre_helpers/point_cloud.cpp using geometry shaders and only transferring the one point we currently see or doing that "by hand" on the cpu and then transferring a lot more data (and doing a lot more transformations potentially)
apitrace gives shader compiler errors:
229192 @0 glCompileShaderARB(shaderObj = 1057)
229192: warning: compilation failed
229192: warning: 0:25(3): error: redeclaration of gl_PerVertex must be a subset of the built-in members of gl_PerVertex
0:28(1): error: identifier `gl_TexCoord' uses reserved `gl_' prefix
0:55(2): error: `gl_FrontColor' undeclared
0:55(2): error: value of type vec4 cannot be assigned to variable of type error
229442: message: major shader compiler error 2112: 0:25(3): error: redeclaration of gl_PerVertex must be a subset of the built-in members of gl_PerVertex
229442: message: major shader compiler error 2113: 0:28(1): error: identifier `gl_TexCoord' uses reserved `gl_' prefix
229442: message: major shader compiler error 2114: 0:55(2): error: `gl_FrontColor' undeclared
229442: message: major shader compiler error 2115: 0:55(2): error: value of type vec4 cannot be assigned to variable of type error
Is there a way to show shader compilation errors directly in rviz?
Is there a way to show shader compilation errors directly in rviz?
No idea. You could try different names in the corresponding shader: https://github.com/ros-visualization/rviz/blob/697ed3ff0496b79b1bb4270aabf457ee2f2ae736/ogre_media/materials/glsl150/box.geom#L22-L28
Looks like the GLSL feature used here requires GLSL >= 410: https://github.com/KhronosGroup/glslang/issues/1441#issuecomment-404594895
dont call that block gl_PerVertex
Looks like the GLSL feature used here requires GLSL >= 410:
no. SSO are not supported by GL1. For GL3+ Ogre takes care of that for you: https://ogrecave.github.io/ogre/api/latest/group___render_system.html#gga3d2965b7f378ebdcfe8a4a6cf74c3de7ab41320a27ddb636a52235e144b8289fb
I tried using renderdoc but it complains about old OpenGl versions/ contexts being used
renderdoc only works with GL3+
Are the GLSL 1.5 shaders faster than GLSL 1.2 as well?
no. just different syntax.
I think the big difference in performance is using geometry shaders and only transferring the one point
yes. this frees up CPU and Ogre is CPU bound.
geometry shaders can be used with GLSL120 too, though https://github.com/OGRECave/ogre/blob/master/Samples/Media/materials/programs/GLSL120/SwizzleGP.glsl
Describe your issue here and explain how to reproduce it.
Your environment
echo "$LANG $LC_NUMERIC"
:C C
On this system, I'm using a more recent Mesa from kisak-mesa PPA (mesa 21.3.7).
Currently, there is the mesa version workaround that forces using GLSL 1.4 on systems with Mesa >= 20. In order to resolve #1701, I tried disabling the Mesa workaround, since the original issue (large points) should have been fixed since Mesa 21.0.3. The big points issue is fixed, but there is another problem: every style of PointCloud2 display except "Points" is displayed just as a white dot regardless of the settings:
How to test
rviz
in one terminal, configure aPointCloud2
display for topicpoints2
, set fixed frame tomap
.