Summary: | Mesa software rendering draws incompletely on Raspberry Pi | ||
---|---|---|---|
Product: | Mesa | Reporter: | Lloyd Wood <lloyd.wood> |
Component: | Drivers/Gallium/llvmpipe | Assignee: | mesa-dev |
Status: | RESOLVED MOVED | QA Contact: | mesa-dev |
Severity: | normal | ||
Priority: | medium | CC: | lloyd.wood |
Version: | unspecified | ||
Hardware: | Other | ||
OS: | All | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: | Raspberry PI Model B PIXEL 1.2 distro glxinfo output |
Description
Lloyd Wood
2017-06-08 01:05:20 UTC
Can you attach the output of glxinfo? Created attachment 131819 [details]
Raspberry PI Model B PIXEL 1.2 distro glxinfo output
Attaching glxinfo from the PIXEL 1.2 Model B.
I don't have a Raspberry Pi to test with. I installed geomview/savi on my Intel deskside system and tested with both NVIDIA's driver and llvmpipe. With both I see a shaded blue sphere with an orbit ring and red/green/blue axes. No blue and yellow texture mapping. No missing triangles. My guess is an LLVM code generation issue. I don't think llvmpipe has been tested much with ARM CPUs. Maybe someone else knows more about that. I guess one alternative would be the 'softpipe' driver (export GALLIUM_DRIVER=softpipe) but it's very slow and probably won't be practical. Sorry I can't be of more help. The original Raspberry Pi IIRC doesn't even support NEON. Theoretically, llvm should still support all the vector instructions by decomposing them into scalar ones, but if that really works correctly? I know it didn't work some time ago (at all) on x86, so I wouldn't be surprised if things get miscompiled on arm neither. (And Brian is right, llvmpipe isn't all that well tested on anything but x86. In theory it should work alright at least on all little endian archs, though you really want to have a cpu with vector instructions, otherwise it not only will be slow but there's a whole another set of potential issues with llvm code generation. Possibly a newer llvm version could help, albeit 3.9 isn't all that old.) Brian, Thanks for checking this out. Which versions of Geomview and SaVi did you install? Seeing a solid blue sphere on your Intel system suggests either that texturemapping is not used by default in SaVi (in SaVi versions earlier than 1.5.0 - play with the Rendering/map menu options, where you can select a blue/yellow sphere or a more faithful realistic rendition) or that Geomview was built without OpenGL support, and is only drawing using X. OpenGL is both a build option and a command-line switch to turn it off in Geomview; configure --with-opengl=DIR if building Geomview yourself. To really show if OpenGL support is there and give it a workout, please open Views/Global Coverage... in SaVi, select a map size from the popup dialog, then turn on texturemapping from the end of the coverage window's Rendering window and select the Views/>> Forwards... menu option to send the redrawn map bitmap through to Geomview to wrap on the sphere during the animation. You'll see the kind of thing shown in the top screenshots at http://savi.sourceforge.net/papers/ The Raspberry Pi Model B problem affects all versions of SaVi I've tried on it, and all recent versions of Geomview I've seen there are built with OpenGL, which is why I didn't feel the need to be more detailed in my initial report, sorry. I've never seen a similar rendering problem on the Intel systems I've used this on, in over fifteen years (on Redhat, Cygwin, Ubuntu.) A photo of SaVi/Geomview running on PIXEL 1.2 on the Pi Model B, showing the rendering problem clearly, is at: http://personal.ee.surrey.ac.uk/Personal/L.Wood/software/SaVi/images/raspberry-pi-model-b-software-mesa.jpeg -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/244. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.