Repository navigation
Quiver barb size not correct on some arches (ppc64, ppc64le...) #7797
Description
Continuing to work through test suite failures found when building on the Fedora ppc64 arch (big-endian) but not on little-endian arches. Two failures:
matplotlib.tests.test_quiver.test_barbs.test
matplotlib.tests.test_transforms.test_pre_transform_plotting.test
seem to be caused by differences in the lengths of 'barbs' on 'quivers' - the former is a test specific to such barbs, the latter includes a figure with some barbs as part of a larger test. In both cases, the lengths of the barbs come out subtly differently on ppc64:
barbs_test_image GOT: 
barbs_test_image EXPECTED: 
pre_transform_data GOT: 
pre_transform_data EXPECTED: 
the difference is quite subtle, it helps to A/B the images quickly in an image viewer. AFAICS, in all cases where the lengths are visibly different, the barbs actually produced are slightly shorter than expected.
Activity
AdamWill commentedon Jan 11, 2017
@QuLogic @tacaswell
AdamWill commentedon Jan 11, 2017
This may be #4385 ?
[-]Quiver barb size not correct on ppc64 (big-endian)[/-][+]Quiver barb size not correct on some arches (ppc64, ppc64le...)[/+]AdamWill commentedon Jan 11, 2017
This also affects ppc64le, so it's not a big-endian thing. It may also affect aarch64.
dopplershift commentedon Jan 11, 2017
I don't think #4385--that's a different rounding problem, IMO. It looks like some kind of pixel snapping issue to me.
I don't have a clue how to begin to figure out what's going on here without access to a machine...
AdamWill commentedon Jan 11, 2017
@puiterwijk ahoy! would you be willing to let an upstream matplotlib person have access to one of our sandbox ppc64 or aarch64 environments to try and look into this kinda thing?
puiterwijk commentedon Jan 12, 2017
@AdamWill You can add their key to your test instance, and let them use that?
AdamWill commentedon Jan 12, 2017
I thought you'd already torn it down :) If you don't mind leaving it up a while longer, sure. @dopplershift , can you send me your ssh pubkey?
dopplershift commentedon Jan 18, 2017
Sorry, I've been swamped with conference prep. It will probably be no earlier than the 21st/22nd that I might be able to get to this. Not sure if that time frame works for you guys.
AdamWill commentedon Jan 18, 2017
I don't think it should be a problem, we should still be able to put up an instance for you at that time, I think.
puiterwijk commentedon Jan 19, 2017
@AdamWill I'll keep your current instance around. Just let me know when I can clear it after they're done with it.
dopplershift commentedon Jan 31, 2017
@AdamWill Ok, I've got cycles now. Here's the public key:
AdamWill commentedon Aug 23, 2017
sorry, I kinda lost track of these remaining issues; did I ever set you up with the appropriate access, @dopplershift ? If not, should we try another round?
dopplershift commentedon Aug 23, 2017
Not that I'm aware of. I have a few cycles I can use to look at this.
AdamWill commentedon Aug 23, 2017
same pubkey?
7 remaining items
tacaswell commentedon Sep 1, 2017
Did you look at the verts before or after running through all of the path simplification code?
dopplershift commentedon Sep 1, 2017
Before. I may not know enough about the path simplification code, but the differences we're seeing aren't coming from dropping a vertex.
tacaswell commentedon Sep 1, 2017
miss interpretting LE/BE tends to have catastrophic effects, I'm quite puzzled by this. There are some issues with float128 on ppc64 (see https://github.com/h5py/h5py/pull/842/files) I wonder if this is related (I hope not!)?
attn @sandrotosi do you see these with debian too?
AdamWill commentedon Sep 2, 2017
Note this is definitely not an LE / BE thing, per the comment on January 10. It also affects ppc64le.
tacaswell commentedon Sep 2, 2017
Sorry, did not read carefully enough 🐑
QuLogic commentedon Oct 15, 2017
After a few days of trial and error, I think I've found the problem. It seems to originate in the Agg
cross_productfunction. You can see the difference in this gist where I ran a few sample inputs from the broken test. The inputs are bit-for-bit identical between x86 and ppc at the start ofcross_product, but only the first test case outputs the same result. The second and third tests are slightly less and slightly greater than the expected 0.Interestingly, this difference only happens with both
-O2and-fPIC(which are both part of Fedora flags). I wonder if that qualifies as a gcc bug?The slightly negative result is okay, but the slightly positive result triggers the wrong side of this check, meaning the stroking uses an inner join instead of an outer join, resulting in a couple fewer vertices. If this condition is changed to use some epsilon check, then ppc should work (though I'd need to see whether it breaks anything else.)
dopplershift commentedon Oct 17, 2017
Interesting--thanks for running this down @QuLogic !
I've seen this problem in other projects-->0 checks need to be checked against epsilon, just like everything else floating point.
QuLogic commentedon Oct 17, 2017
For now, I'm not sure if we should import the changes here, as it causes a few test failures on x86_64. I've opened this bug report to see if there's anything up with gcc itself as the trigger is a bit odd to me.
QuLogic commentedon Dec 22, 2017
gcc devs say this is an expected optimization (FMA), so I'm going to open a PR with the patch here.
AdamWill commentedon Dec 22, 2017
Thanks a lot for figuring this out, folks!