> nmake [...] [100%] Built target glean [100%] Generating constant_array_size_tests.list Traceback (most recent call last): File "piglit/generated_tests/gen_constant_array_size_tests.py", line 37, in <module> from builtin_function import * File "piglit\generated_tests\builtin_function.py", line 836, in <module> _make_componentwise_test_vectors(test_suite) File "piglit\generated_tests\builtin_function.py", line 804, in _make_compo nentwise_test_vectors f('abs', 1, '1.30', np.abs, None, [ints]) File "piglit\generated_tests\builtin_function.py", line 767, in f make_arguments(test_inputs), python_equivalent, tolerance_function) File "piglit\generated_tests\builtin_function.py", line 581, in _simulate_f unction if glsl_type_of(expected_output).base_type != glsl_float: File "piglit\generated_tests\builtin_function.py", line 220, in glsl_type_o f assert isinstance(value, np.ndarray) AssertionError NMAKE : fatal error U1077: 'python' : return code '0x1' Stop. NMAKE : fatal error U1077: '"c:\Program Files\Microsoft Visual Studio 10.0\VC\BI N\nmake.exe"' : return code '0x2' Stop. NMAKE : fatal error U1077: '"c:\Program Files\Microsoft Visual Studio 10.0\VC\BI N\nmake.exe"' : return code '0x2' Stop.
At first blush, this looks like a bug in the Windows implementation of numpy that we're going to have to work around. Vinson, would you mind running this test on Windows and letting me know if your output matches mine? I don't have access to my Windows VM at the moment. ~ $ python Python 2.7.1 (r271:86832, Apr 12 2011, 16:15:16) [GCC 4.6.0 20110331 (Red Hat 4.6.0-2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import numpy >>> print numpy.version.version 1.5.1 >>> values = [numpy.int32(x) for x in [-5, -2, -1, 0, 1, 2, 5]] >>> print [type(v) for v in values] [<type 'numpy.int32'>, <type 'numpy.int32'>, <type 'numpy.int32'>, <type 'numpy.int32'>, <type 'numpy.int32'>, <type 'numpy.int32'>, <type 'numpy.int32'>] >>> print [type(numpy.abs(v)) for v in values] [<type 'numpy.int32'>, <type 'numpy.int32'>, <type 'numpy.int32'>, <type 'numpy.int32'>, <type 'numpy.int32'>, <type 'numpy.int32'>, <type 'numpy.int32'>] >>> exit()
Looks like it matches the output in comment #1. Python 2.6.5 (r265:79096, Mar 19 2010, 21:48:26) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import numpy >>> numpy.version.version '1.6.1' >>> values = [numpy.int32(x) for x in [-5, -2, -1, 0, 1, 2, 5]] >>> print [type(v) for v in values] [<type 'numpy.int32'>, <type 'numpy.int32'>, <type 'numpy.int32'>, <type 'numpy. int32'>, <type 'numpy.int32'>, <type 'numpy.int32'>, <type 'numpy.int32'>] >>> print [type(numpy.abs(v)) for v in values] [<type 'numpy.int32'>, <type 'numpy.int32'>, <type 'numpy.int32'>, <type 'numpy. int32'>, <type 'numpy.int32'>, <type 'numpy.int32'>, <type 'numpy.int32'>]
I don't know if it's related but I see NumPy warnings when compiling on Mac OS X 10.7.1 (Lion) and Ubuntu 11.10 i386. Mac OS X 10.7.1 (Lion) Warning: overflow encountered in uint_scalars Ubuntu 11.10 i386 Warning: overflow encountered in ulong_scalars
Ok, I've reproduced this bug on my Windows VM. There is definitely some kind of problem in the Windows implementation of numpy we're going to have to work around. On Linux: ~ $ python Python 2.7.1 (r271:86832, Apr 12 2011, 16:15:16) [GCC 4.6.0 20110331 (Red Hat 4.6.0-2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import numpy >>> x = numpy.int32(5) >>> y = numpy.abs(x) >>> print type(x) <type 'numpy.int32'> >>> print type(y) <type 'numpy.int32'> >>> print type(x) == type(y) True >>> exit() On Windows: Python 2.7.2 (default, Jun 12 2011, 15:08:59) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import numpy >>> x = numpy.int32(5) >>> y = numpy.abs(x) >>> print type(x) <type 'numpy.int32'> >>> print type(y) <type 'numpy.int32'> >>> print type(x) == type(y) False >>> exit() It seems that on the Windows implementation of numpy, there are at least two numpy.int32 types, and they are not instances of one another. Certain operations (e.g. numpy.abs()) "convert" from one to the other. This messes up glsl_type_of(), which assumes that it can detect a numpy.int32 using isinstance(x, numpy.int32). But that doesn't work, because it only detects one of the numpy.int32 types. It seems pretty clear to me that this is a numpy/Windows bug. I have some ideas about how to work around it, though. I'll submit a workaround as soon as I can.
(In reply to comment #3) > I don't know if it's related but I see NumPy warnings when compiling on Mac OS > X 10.7.1 (Lion) and Ubuntu 11.10 i386. > > Mac OS X 10.7.1 (Lion) > Warning: overflow encountered in uint_scalars > > Ubuntu 11.10 i386 > Warning: overflow encountered in ulong_scalars As far as I know these warnings are unrelated. They occur because we are testing some overflow cases which are nonetheless well-defined by the GLSL 1.30 spec (e.g. 1u - 2u == 4294967295u). Numpy "helpfully" gives us a warning when overflow occurs while computing these test vectors.
Ok, patch sent to Piglit mailing list and awaiting code review.
Python 2.6.5 (r265:79096, Mar 19 2010, 21:48:26) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import numpy >>> numpy.version.version '1.6.1' >>> x = numpy.int32(5) >>> y = numpy.abs(x) >>> print type(x) <type 'numpy.int32'> >>> print type(y) <type 'numpy.int32'> >>> print type(x) == type(y) False >>> print x.dtype int32 >>> print y.dtype int32 >>> print x.dtype == y.dtype True
(In reply to comment #7) > Python 2.6.5 (r265:79096, Mar 19 2010, 21:48:26) [MSC v.1500 32 bit (Intel)] on > win32 > Type "help", "copyright", "credits" or "license" for more information. > >>> import numpy > >>> numpy.version.version > '1.6.1' > >>> x = numpy.int32(5) > >>> y = numpy.abs(x) > >>> print type(x) > <type 'numpy.int32'> > >>> print type(y) > <type 'numpy.int32'> > >>> print type(x) == type(y) > False > >>> print x.dtype > int32 > >>> print y.dtype > int32 > >>> print x.dtype == y.dtype > True Interesting. I think a workaround could be constructed using this idea too. Vinson, have you had a chance to try the patch I sent to the Piglit list at 4:53pm yesterday? If that works for you, I think I'll just stick with it, on the reasoning that it's probably not worth spending too much time looking for the perfect workaround.
Fixed in commit 363d7ce647ec148e070552863f69a05a41a97aec
piglit: cc4474e51494f9d934d7cc3f99f1f3de9b766abe (master) Verified fixed.
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.