-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Line rendering on VideoCore 4 GPUs #7583
Comments
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:
|
I have seen something like this before when running Qt + Mapbox GL on Raspberry Pi 3 (Broadcom BCM2837). |
We could try to get a debug build and see if a shader is failing to compile or something like this. |
@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. |
@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:
|
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>
.
|
@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. |
Also, deliberately breaking one of the shaders and attempting to run the program does indeed throw an error. |
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. |
That's a useful observation @KK1423! Can you trace why it's becoming zero? It may be that |
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. |
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 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. |
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. |
Passing the normal bits as a separate attribute rather than trying to cram it into the least significant bit of the |
Hi, I tested some branches @mourner provided of 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 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 |
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:
The text was updated successfully, but these errors were encountered: