Mesa 21 without Mesa workaround incorrectly renders PointCloud2

[peci1]

Describe your issue here and explain how to reproduce it.

Your environment

• OS Version: Ubuntu 18.04
• ROS Distro: Melodic
• RViz, Qt, OGRE, OpenGl version as printed by rviz:

  [ INFO] [1646652899.525315495] [ros.rviz]: rviz version 1.13.24
  [ INFO] [1646652899.525380866] [ros.rviz]: compiled against Qt version 5.9.5
  [ INFO] [1646652899.525397976] [ros.rviz]: compiled against OGRE version 1.9.0 (Ghadamon)
  [ INFO] [1646652899.533460029] [ros.rviz]: Forcing OpenGl version 0.
  [ INFO] [1646652899.757093342] [ros.rviz]: Stereo is NOT SUPPORTED
  [ INFO] [1646652899.757155850] [ros.rviz]: OpenGL device: AMD RENOIR (DRM 3.44.0, 5.16.10-051610-generic, LLVM 13.0.0)
  [ INFO] [1646652899.757174358] [ros.rviz]: OpenGl version: 4.6 (GLSL 4.6).
  

• If source build, which git commit? 0462dd2
• System locale, i.e. the output of 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

• run rviz in one terminal, configure a PointCloud2 display for topic points2, set fixed frame to map.
• in a second terminal, run this script: https://github.com/ros-visualization/rviz/blob/noetic-devel/src/test/send_point_cloud_2.py
• play around with the pointcloud display style

[peci1]

Is there some kind of OpenGL/Ogre profiling info I can provide?

[peci1]

@simonschmeisser Is this the same issue you described in #1714?

[simonschmeisser]

Yes, I saw the same. We only use "points" so for me the speed gain would be worth it 😉

[rhaschke]

I can confirm the issue on an Intel GPU as well with stock Mesa 21.2.6 on Focal.
#1508 was reporting an issue with the 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 😉

@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...

[simonschmeisser]

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.

[simonschmeisser]

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)

[simonschmeisser]

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

[simonschmeisser]

Is there a way to show shader compilation errors directly in rviz?

[rhaschke]

Is there a way to show shader compilation errors directly in rviz?

No idea. You could try different names in the corresponding shader:

rviz/ogre_media/materials/glsl150/box.geom

Lines 22 to 28 in 697ed3f

	in gl_PerVertex {
	vec4 gl_Position;
	vec4 gl_FrontColor;
	} gl_in[];
	out vec4 gl_TexCoord[];

[rhaschke]

Looks like the GLSL feature used here requires GLSL >= 410: KhronosGroup/glslang#1441 (comment)

[paroj]

rviz/ogre_media/materials/glsl150/box.geom

Lines 22 to 28 in 697ed3f

	in gl_PerVertex {
	vec4 gl_Position;
	vec4 gl_FrontColor;
	} gl_in[];
	out vec4 gl_TexCoord[];

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