| Summary: | line rendering with --with-osmesa-bits=32 | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | burlen <burlen.loring> |
| Component: | Drivers/OSMesa | Assignee: | mesa-dev |
| Status: | RESOLVED MOVED | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | git | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
rendered with osmesa --with-depth-bits=32
correct baseline image rendered with osmesa (bug) diff osmesa patch to test apitrace from the failing bar chart test |
||
Created attachment 88860 [details]
correct baseline image
Created attachment 88861 [details]
rendered with osmesa (bug)
Created attachment 88862 [details]
diff
I'm guessing it's a fragment Z interpolation issue. Can you provide some info about: * does the test use GL_DEPTH_TEST? * Any calls to glDepthRange()? * What are the vertex Z values (zeros?) * Using glPolygonOffset? Created attachment 88866 [details] [review] osmesa patch to test Can you try this patch? Comment on attachment 88866 [details] [review] osmesa patch to test Review of attachment 88866 [details] [review]: ----------------------------------------------------------------- The patch made no difference. I only tested the affected classes and not all of VTK. Created attachment 88901 [details]
apitrace from the failing bar chart test
The apitrace developers shared a patch that allows the tool to work with OSMesa.
The bug can be reproduced using VTK built against OSMesa. The following shows how I configured Mesa and VTK. # Mesa config ./configure CXXFLAGS="-O2 -g" CFLAGS="-O2 -g" --disable-xvmc --disable-glx --disable-dri --with-dri-drivers= --with-gallium-drivers= --enable-texture-float --disable-shared-glapi --disable-egl --with-egl-platforms= --enable-osmesa --with-osmesa-bits=32 --enable-gallium-llvm=no --prefix=/work/apps/mesa/devel/classic #!/bin/bash # VTK config MESA=$1 shift BITS=$1 shift cmake \ -DCMAKE_BUILD_TYPE=Debug \ -DVTK_DEBUG_LEAKS=ON \ -DBUILD_SHARED_LIBS=ON \ -DBUILD_TESTING=ON \ -DVTK_USE_X=OFF \ -DVTK_OPENGL_HAS_OSMESA=ON \ -DOPENGL_INCLUDE_DIR=$MESA/include \ -DOPENGL_gl_LIBRARY=$MESA/lib/libOSMesa$BITS\.so \ -DOPENGL_xmesa_INCLUDE_DIR=$MESA/include \ -DOSMESA_INCLUDE_DIR=$MESA/include \ -DOSMESA_LIBRARY=$MESA/lib/libOSMesa$BITS\.so \ -DVTK_DATA_STORE=/work/VTK/VTKExternalData \ $* -- 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/877. |
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.
Created attachment 88859 [details] rendered with osmesa --with-depth-bits=32 when runnning VTK regression suite on an OSMesa classic build with --with-osmesa-bits=32 (and only 32 - 8,16 and none work) 80 regressions show bad line rendering. I'm attaching some images that are illustrative. There's a thread on the mesa-dev mailist about this issue.