On Thu, 13 Sep 2012 09:08:59 +0200 Andrea Canciani <ranm...@gmail.com> wrote:
> On Thu, Sep 13, 2012 at 2:08 AM, Siarhei Siamashka > <siarhei.siamas...@gmail.com> wrote: > > On Tue, 11 Sep 2012 23:45:47 +0200 > > Andrea Canciani <ranm...@gmail.com> wrote: > > > >> On Tue, Sep 11, 2012 at 10:44 PM, Siarhei Siamashka > >> <siarhei.siamas...@gmail.com> wrote: > >> > On Tue, 11 Sep 2012 22:25:15 +0200 > >> > Andrea Canciani <ranm...@gmail.com> wrote: > >> > > >> >> On Tue, Sep 11, 2012 at 7:34 PM, Søren Sandmann > >> >> <sandm...@cs.au.dk> wrote: > >> >> > Andrea Canciani <ranm...@gmail.com> writes: > >> >> > > >> >> >> This reminds me that I have some patches to improve building > >> >> >> pixman on win32: > >> >> >> http://cgit.freedesktop.org/~ranma42/pixman/commit/?h=wip/simpleops-to-master > >> >> >> > >> >> >> Soren, is it ok if I push the attached patches? > >> >> > > >> >> > No objections from me if the test suite still passes with > >> >> > PIXMAN_DISABLE=sse2 set. > >> >> > >> >> On MacOS X the testsuite shows no regression with that variable > >> >> in the env. On win32, pixman did not compile without the first > >> >> of those patches. After it, the testsuite fails with: > >> >> > >> >> $ PIXMAN_DISABLE=sse2 ./scaling-test.exe > >> >> Assertion failed: frcd_canary_variable1 == > >> >> frcd_volatile_constant1, file scaling-test.c, line 356 > >> >> pixman: Disabled sse2 implementation > >> >> > >> >> The failing testcase is: > >> >> $ PIXMAN_DISABLE=sse2 ./scaling-test.exe 3348 > >> >> Assertion failed: frcd_canary_variable1 == > >> >> frcd_volatile_constant1, file scaling-test.c, line 356 > >> >> src_fmt=20028888, dst_fmt=20028888 > >> >> op=3, scale_x=27881, scale_y=-65000, repeat=0 > >> >> translate_x=55344, translate_y=56484 > >> >> src_width=11, src_height=8, dst_width=24, dst_height=7 > >> >> src_x=0, src_y=4, dst_x=4, dst_y=3 > >> >> w=20, h=2 > >> >> destination clip box: [16,6-20,6] > >> >> destination clip box: [3,2-18,6] > >> >> pixman: Disabled sse2 implementation > >> >> ... > >> >> > >> >> This seems to be consistent with the compiler warnings: > >> >> pixman-mmx.c > >> >> c:\cygwin\home\ranma42\code\fdo\pixman\pixman\pixman-mmx.c(286) : > >> >> warning C4799: function 'to_uint64' has no EMMS instruction > >> >> c:\cygwin\home\ranma42\code\fdo\pixman\pixman\pixman-mmx.c(469) : > >> >> warning C4799: function 'store8888' has no EMMS instruction > >> >> c:\cygwin\home\ranma42\code\fdo\pixman\pixman\pixman-mmx.c(480) : > >> >> warning C4799: function 'is_equal' has no EMMS instruction > >> >> c:\cygwin\home\ranma42\code\fdo\pixman\pixman\pixman-mmx.c(491) : > >> >> warning C4799: function 'is_opaque' has no EMMS instruction > >> >> c:\cygwin\home\ranma42\code\fdo\pixman\pixman\pixman-mmx.c(497) : > >> >> warning C4799: function 'is_zero' has no EMMS instruction > >> >> c:\cygwin\home\ranma42\code\fdo\pixman\pixman\pixman-mmx.c(565) : > >> >> warning C4799: function 'expand_4xpacked565' has no EMMS > >> >> instruction > >> >> c:\cygwin\home\ranma42\code\fdo\pixman\pixman\pixman-mmx.c(591) : > >> >> warning C4799: function 'expand_4x565' has no EMMS instruction > >> >> c:\cygwin\home\ranma42\code\fdo\pixman\pixman\pixman-mmx.c(3760) : > >> >> warning C4799: function > >> >> 'fast_composite_scaled_bilinear_mmx_8888_8_8888_pad_OVER' has no > >> >> EMMS instruction > >> >> c:\cygwin\home\ranma42\code\fdo\pixman\pixman\pixman-mmx.c(3764) : > >> >> warning C4799: function > >> >> 'fast_composite_scaled_bilinear_mmx_8888_8_8888_none_OVER' has > >> >> no EMMS instruction > >> >> > >> >> I was unable to find out why MSVC thinks that > >> >> fast_composite_scaled_bilinear_mmx_8888_8_8888_{pad,none}_OVER > >> >> are missing an EMMS instruction, but cover/normal are ok. > >> > > >> > Does MSVC respect 'force_inline' and actually inline all of these > >> > functions ('to_uint64', 'store8888', ...)? > >> > >> The compiler does not report inline warnings in pixman-mmx.c, so I > >> would expect that it respects force_inline. > >> I'm attaching the build log, in case it is of any help. > > > > I'm not sure if I can provide much help with MSVC. The _mm_empty() > > intrinsic is also not totally problem free even when using gcc: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47759 > > > > But some kind of workaround is still needed. Can you try to > > confirm which pixman fast paths are triggering this problem? > > It looks like the compiler warning match the issue: > fast_composite_scaled_bilinear_mmx_8888_8_8888_pad_OVER > fast_composite_scaled_bilinear_mmx_8888_8_8888_none_OVER > > > > > If the problem is related to incorrect EMMS instruction reordering, > > then maybe moving EMMS into a non-inlinable function and calling it > > instead of _mm_empty() can help? Just as an experiment for getting > > a bit better understanding about what is going on. > > I confirm that it is likely to be an optimization bug (disabling the > optimizations fixes it). > The attached patch is another possible workaround to the issue. > It causes a lot of warnings about missing EMMS, because the compiler > does not find any EMMS instruction after the MMX instructions), but > the whole testsuite succeeds. > Marking the function as noinline (without disabling the optimizations > on it) does not fix the issue. > > What would be the best way to work around this issue both in gcc and > in msvc? Would it be ok to create a "pixman_mm_empty()" function (to > be used everywhere instead of mm_empty) and disable the optimizations > on it? Looks like this issue has slipped through the cracks. What about just adding something like this to pixman-mmx.c ? #ifdef _MSC_VER #error Sorry, MMX can't be safely used with MSVC. Please consider #error building pixman without MMX support as a workaround. #error More details can be found at #error https://bugs.freedesktop.org/show_bug.cgi?id=NNNNN #endif If it's some specific version of MSVC failing, a precise version check can be used. -- Best regards, Siarhei Siamashka _______________________________________________ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman