New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

master fails on RH6/CentOS6 #1481

Open
doutriaux1 opened this Issue Aug 5, 2015 · 9 comments

Comments

Projects
None yet
3 participants

@doutriaux1 doutriaux1 added this to the 2.3 milestone Aug 5, 2015

@doutriaux1

This comment has been minimized.

Member

doutriaux1 commented Aug 5, 2015

@sankhesh @jbeezley I'm going to try to get the buildbot server going here. Can you try in the meantime to get your CentOS VM talk to your buildbot server? Thx.

@doutriaux1

This comment has been minimized.

Member

doutriaux1 commented Aug 5, 2015

@dlonie can you remind us what the various part of the picture supposed to be on CDASH?
I usually use left vs right, but in the test it seems that bottom/top is completely different. For example:
https://open.cdash.org/testDetails.php?test=360286757&build=3940803

@allisonvacanti

This comment has been minimized.

Contributor

allisonvacanti commented Aug 5, 2015

Heh, yeah....CDash doesn't handle multiple images very well.

As I understand it, Top Left is the first test image, Top Right is the first reference image, and Bottom Left/Right are the same for the second image. Any others aren't shown in the fancy slider widget.

I usually just look at the image diffs that follow the slider when more than two images are present.

@allisonvacanti

This comment has been minimized.

Contributor

allisonvacanti commented Aug 5, 2015

FWIW, the labeled isoline tests are failing due to the lack of a stencil buffer in the GLX visual. @durack1 and @jbeezley had some additional insights in the discussion on #1456.

@doutriaux1

This comment has been minimized.

Member

doutriaux1 commented Aug 5, 2015

@jbeezley to follow up on your idea at #1456 here the xwininfo output:

xwininfo -root

xwininfo: Window id: 0x2e8 (the root window) (has no name)

  Absolute upper-left X:  0
  Absolute upper-left Y:  0
  Relative upper-left X:  0
  Relative upper-left Y:  0
  Width: 5040
  Height: 1920
  Depth: 24
  Visual: 0x56
  Visual Class: TrueColor
  Border width: 0
  Class: InputOutput
  Colormap: 0x55 (installed)
  Bit Gravity State: NorthWestGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsViewable
  Override Redirect State: no
  Corners:  +0+0  -0+0  -0-0  +0-0
  -geometry 5040x1920+0+0
@allisonvacanti

This comment has been minimized.

Contributor

allisonvacanti commented Sep 4, 2015

I setup a CentOS 6.7 VM using mesa-libGL 10.4.3 and can reproduce this. I focused on the stenciling issues with the labeled isolines.

What I've noticed:

  • Only background mode has the issue. Plotting in a window stencils the lines out properly.
  • At the time the stencil is created, OpenGL reports that GL_STENCIL_BITS is 8, meaning that the stencil buffer exists and has 8 bits (as it should).
  • Dumping the stencil buffer with glReadPixels and writing this data out to a file shows that the stencil buffer is populated with the correct data (there is a quad stenciled out at each label's location).

From this, my next guess is that it's a mesa bug. For some reason, this GL implementation is ignoring the stencil buffer, or incorrectly performing the stencil test when using an FBO rather than a driver-provided visual (FBOs are used with offscreen rendering). I'll need to confirm this with a minimal example and if I can, I'll report the bug upstream to mesa / CentOS.

This will likely be a couple of weeks before I can get to it, as I've burned through my allocation for UVCDAT to track this down and other projects need my attention, but wanted to share that there is some progress being made on this issue.

@doutriaux1

This comment has been minimized.

Member

doutriaux1 commented Sep 14, 2015

we commented these out for 2.4 but would be nice to be back in 3.0

@aashish24

This comment has been minimized.

Contributor

aashish24 commented Aug 29, 2016

@doutriaux1 should we close this bug?

@doutriaux1

This comment has been minimized.

Member

doutriaux1 commented Aug 29, 2016

hum... They are probably still commented out though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment