Bug 71363 - line rendering with --with-osmesa-bits=32
Summary: line rendering with --with-osmesa-bits=32
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/OSMesa (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: mesa-dev
QA Contact:
Depends on:
Reported: 2013-11-07 23:27 UTC by burlen
Modified: 2019-09-18 20:12 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

rendered with osmesa --with-depth-bits=32 (6.77 KB, text/plain)
2013-11-07 23:27 UTC, burlen
correct baseline image (7.75 KB, image/png)
2013-11-07 23:28 UTC, burlen
rendered with osmesa (bug) (6.77 KB, image/png)
2013-11-07 23:30 UTC, burlen
diff (2.99 KB, image/png)
2013-11-07 23:31 UTC, burlen
osmesa patch to test (1.70 KB, patch)
2013-11-08 02:02 UTC, Brian Paul
Details | Splinter Review
apitrace from the failing bar chart test (96.92 KB, application/octet-stream)
2013-11-08 17:21 UTC, burlen

Description burlen 2013-11-07 23:27:48 UTC
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.
Comment 1 burlen 2013-11-07 23:28:29 UTC
Created attachment 88860 [details]
correct baseline image
Comment 2 burlen 2013-11-07 23:30:53 UTC
Created attachment 88861 [details]
rendered with osmesa (bug)
Comment 3 burlen 2013-11-07 23:31:31 UTC
Created attachment 88862 [details]
Comment 4 Brian Paul 2013-11-08 00:52:34 UTC
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?
Comment 5 Brian Paul 2013-11-08 02:02:33 UTC
Created attachment 88866 [details] [review]
osmesa patch to test

Can you try this patch?
Comment 6 burlen 2013-11-08 17:16:00 UTC
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.
Comment 7 burlen 2013-11-08 17:21:59 UTC
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.
Comment 8 burlen 2013-11-08 17:37:54 UTC
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

# VTK config


cmake \
  -DOPENGL_gl_LIBRARY=$MESA/lib/libOSMesa$BITS\.so \
  -DOPENGL_xmesa_INCLUDE_DIR=$MESA/include \
  -DVTK_DATA_STORE=/work/VTK/VTKExternalData \
Comment 9 GitLab Migration User 2019-09-18 20:12:34 UTC
-- 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.