Line rendering on VideoCore 4 GPUs

[jonbe242]

Created from comment on #4494.

We have issues drawing lines on Samsung Galaxy Trend Plus (GT-S7580).

The device draws NO lines at all in the map, no matter how wide they are styled. We are using our own map data and styles.

Tested with MBGL from this spring and from master-branch about two months ago.
How can we help to pinpoint the issue?

Screenshot from Samsung device:

Screenshot from Nexus 5X device:

[jfirebaugh]

Related bugs reporting the same issue on other Broadcom VideoCore IV GPUs: #4037, #6454, #9596, #9599.

We need to order one of these devices if we don't have one in our library:

• Samsung Galaxy Trend Plus (GT-S7580)
• Samsung Galaxy Grand Neo (GT-I9060I)
• Samsung Galaxy Core Plus (SM-G3500)
• Raspberry Pi 3

cc @langsmith @pveugen

[tmpsantos]

I have seen something like this before when running Qt + Mapbox GL on Raspberry Pi 3 (Broadcom BCM2837).

[tmpsantos]

We could try to get a debug build and see if a shader is failing to compile or something like this.

[KK1423]

@tmpsantos Yes, that is exactly the same setup that I'm trying to use right now. I will see if I can figure out those shaders later, but please tell me if there are any specific instructions to cross compile and test that debug build you mentioned.

[tmpsantos]

@KK1423 can you try building QtLocation with this patch? This should enable OpenGL error checking and give us some info if a shader is failing to compile.

Are you using Yocto? If yes, you could apply the patch with this method:
https://wiki.yoctoproject.org/wiki/TipsAndTricks/Patching_the_source_for_a_recipe

diff --git a/src/3rdparty/mapbox-gl-native/include/mbgl/gl/gl.hpp b/src/3rdparty/mapbox-gl-native/include/mbgl/gl/gl.hpp
index 7985097..75c6f58 100644
--- a/src/3rdparty/mapbox-gl-native/include/mbgl/gl/gl.hpp
+++ b/src/3rdparty/mapbox-gl-native/include/mbgl/gl/gl.hpp
@@ -40,11 +40,7 @@ struct Error : std::runtime_error {
 
 void checkError(const char *cmd, const char *file, int line);
 
-#ifndef NDEBUG
 #define MBGL_CHECK_ERROR(cmd) ([&]() { struct __MBGL_C_E { ~__MBGL_C_E() { ::mbgl::gl::checkError(#cmd, __FILE__, __LINE__); } } __MBGL_C_E; return cmd; }())
-#else
-#define MBGL_CHECK_ERROR(cmd) (cmd)
-#endif
 
 } // namespace gl
 } // namespace mbgl

[KK1423]

No, I'm running Raspbian lite. I can just use the patch CLI tool, right?

…

On Wed, Jul 26, 2017, 9:02 AM Thiago Marcos P. Santos < ***@***.***> wrote: @KK1423 <https://github.com/kk1423> can you try building QtLocation with this patch? This should enable OpenGL error checking and give us some info if a shader is failing to compile. Are you using Yocto? If yes, you could apply the patch with this method: https://wiki.yoctoproject.org/wiki/TipsAndTricks/Patching_the_source_for_a_recipe diff --git a/src/3rdparty/mapbox-gl-native/include/mbgl/gl/gl.hpp b/src/3rdparty/mapbox-gl-native/include/mbgl/gl/gl.hpp index 7985097..75c6f58 100644 --- a/src/3rdparty/mapbox-gl-native/include/mbgl/gl/gl.hpp +++ b/src/3rdparty/mapbox-gl-native/include/mbgl/gl/gl.hpp @@ -40,11 +40,7 @@ struct Error : std::runtime_error { void checkError(const char *cmd, const char *file, int line); -#ifndef NDEBUG #define MBGL_CHECK_ERROR(cmd) ([&]() { struct __MBGL_C_E { ~__MBGL_C_E() { ::mbgl::gl::checkError(#cmd, __FILE__, __LINE__); } } __MBGL_C_E; return cmd; }()) -#else -#define MBGL_CHECK_ERROR(cmd) (cmd) -#endif } // namespace gl } // namespace mbgl — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#7583 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AKZIfImlTazbNkUH9z9NcY4VvMH7jlW1ks5sRzjpgaJpZM4LZfpf> .

[KK1423]

@tmpsantos I ran the mapviewer example again with the debugging patch applied, and I'm getting nothing on the terminal except the usual "Threaded rendering is not optimal in the Mapbox GL plugin." Messing around with fprintf statements shows that the checkError method is definitely being run, but never finds an error.

[KK1423]

Also, deliberately breaking one of the shaders and attempting to run the program does indeed throw an error.

[KK1423]

Okay, messing around with the line shader shows that the alpha value always ends up being zero by the end of the fragment shader. setting it to one makes the lines visible. I'd like to get anti aliasing working too though.

[jfirebaugh]

That's a useful observation @KK1423! Can you trace why it's becoming zero? It may be that alpha and/or some of the related variables (dist, v_width2, blur2, v_gamma_scale, etc.) need to be highp precision for this GPU.

[KK1423]

I've never really worked with glsl before, so I'm struggling to understand what the expected values for the variables you listed are. I'll try changing the precision on some of those variables and seeing what happens.

[jfirebaugh]

I've received a test device, have reproduced the issue, and can confirm your findings @KK1423.

The root of the problem seems to be that we're expecting mod(a_pos, 2.0) to return 0 or 1 (or at least, results in the range (0.0, 1.0)), but for this GPU it's returning results in the range (1.0, 2.0).

Forcing an integer modulus operation allows lines to show up:

diff --git a/src/mbgl/shaders/line.cpp b/src/mbgl/shaders/line.cpp
index 1eb92c4b7..fa61c7ed3 100644
--- a/src/mbgl/shaders/line.cpp
+++ b/src/mbgl/shaders/line.cpp
@@ -123,7 +123,8 @@ void main() {
     // transform y so that 0 => -1 and 1 => 1
     // In the texture normal, x is 0 if the normal points straight up/down and 1 if it's a round cap
     // y is 1 if the normal points up, and -1 if it points down
-    mediump vec2 normal = mod(a_pos, 2.0);
+    ivec2 i_pos = ivec2(a_pos);
+    mediump vec2 normal = vec2(i_pos - 2 * (i_pos / 2));
     normal.y = sign(normal.y - 0.5);
     v_normal = normal;
 

However this still produces line rendering artifacts near tile boundaries.

[KK1423]

Nice! I was about to give up and use the regular mapbox qt plugin instead, or at least patch it to ignore the alpha value.

One of the steps I took to try and debug the shader was to try and output v_normal in the fragment shader, assuming expected values, where x is 0 or 1 and y is -1 or 1. I remember that this produced (1,1) everywhere except tile boundaries. This might be related to those artifacts you mentioned.

Also, how is the performance for you? I'm getting some severe stuttering, another reason that I might switch over to the regular mapbox qt plugin and just use the map with north pointing up.

[jfirebaugh]

Passing the normal bits as a separate attribute rather than trying to cram it into the least significant bit of the a_pos attribute seems to fix both issues. We're not up against the 8 attribute limit in these shaders yet, so this seems like a viable fix. cc @ansis.

[ahk]

Hi, I tested some branches @mourner provided of mapbox-gl-js related to this issue. Device used was a Raspberry Pi 3B+, running Raspbian GNU/Linux 9.8 (stretch), using system Chromium. On this platform it seems that this PR both fixes the rendering bug seen here and improves performance. This assumes that gl-js in Chromium through an OpenGL shim on this device actually instruments the bug. Before/after testing seemed to confirm this, with the v0.39.1 version failing to fully paint before blitting incorrectly then crashing the rendering subsystem.

Notes on device setup: I did NOT update any peripheral firmware or apt packages. I enabled the "GL (Full KMS) Desktop Drivers" (afaik this includes an OpenGL2.1 shim). I also enabled compositing in Chromium (disabled by default in system config). WebGL report listed my renderer as Gallium 0.4 on VC4 V3D 2.1.

Apologies if this device/environment combo isn't very meaningful, happy to take suggestions here. Without building Android for the RPi3 this was the best test I could think of. We'll be testing gl-native itself through Qt5 on this device soon.