[Pixman] [cairo] help building cairo on windows

Andrea Canciani ranma42 at gmail.com
Thu Sep 13 00:08:59 PDT 2012


On Thu, Sep 13, 2012 at 2:08 AM, Siarhei Siamashka
<siarhei.siamashka at gmail.com> wrote:
> On Tue, 11 Sep 2012 23:45:47 +0200
> Andrea Canciani <ranma42 at gmail.com> wrote:
>
>> On Tue, Sep 11, 2012 at 10:44 PM, Siarhei Siamashka
>> <siarhei.siamashka at gmail.com> wrote:
>> > On Tue, 11 Sep 2012 22:25:15 +0200
>> > Andrea Canciani <ranma42 at gmail.com> wrote:
>> >
>> >> On Tue, Sep 11, 2012 at 7:34 PM, Søren Sandmann <sandmann at cs.au.dk>
>> >> wrote:
>> >> > Andrea Canciani <ranma42 at 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?

Andrea
-------------- next part --------------
A non-text attachment was scrubbed...
Name: workaround.patch
Type: application/octet-stream
Size: 430 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/pixman/attachments/20120913/4262148a/attachment.obj>


More information about the Pixman mailing list