Re: [Pixman] pixman on iOS
Ben Avison wrote: Unless someone has forked Pixman somewhere else, then no, there is no special support for AArch64. The existing ARMv6 and ARMv7 optimisations are all hand-coded assembly, so can only be built for the AArch32 instruction set. If you run an ARMv8 in AArch32 state, then I would expect the ARMv6 and ARMv7 optimisations to still work - in AArch32 state, ARMv8 is only incrementally different from ARMv7 - but I have a feeling that Apple only run their ARMv8 chips in AArch64 state (BICBW). You are correct, Apple specifically runs these chips in 64 bit mode. Pixman rendering without optimization is pretty slow even on those processors. There is still code in Pixman, first added at 0.24, to determine which ARM features are available when building for iOS - it's just in pixman-arm.c now rather than pixman-cpu.c. However it makes no attempt to factor in the AArch32/AArch64 state before enabling the ARMv6 and ARMv7 optimisations. You'd also need some magic in the build system so that it doesn't even attempt to assemble any of the AArch32 assembly source files in an AArch64 build. 0.24 is the version I am using, and it never built natively (i.e. using configure script) for iOS. There was, as I recall, an issue with iOS assembly being incompatible with gnu/Linux toolchain for which pixman assembly code was written. Someone instead posted manually created (I think through assembly/disassembly on a Linux box) file that was manually added to the pixman build. At least that's what I still have in 0.24. I tried current version and encountered the same issue - essentially optimization assembly is not compatible with current Apple compiler. If you're having trouble even building the ARM optimisations for AArch32, you might want to try building intermediate versions of Pixman until you can narrow down where it stopped working. It sounds as though, unless something changed dramatically, iOS tools are still not compatible with assembler used in pixman so they are unlikely to work. If anyone wants to take a look at it, I am glad to help build anything - but my own knowledge of assembly code is pretty rudimentary. ___ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman
Re: [Pixman] pixman on iOS
On Wed, 28 Nov 2012 12:00:39 -0800 Jeremy Huddleston Sequoia jerem...@apple.com wrote: On Nov 28, 2012, at 11:52 AM, Siarhei Siamashka siarhei.siamas...@gmail.com wrote: Now it appears that this bug also affects mingw-w64, not just clang: https://bugs.freedesktop.org/show_bug.cgi?id=57591 I have sent a patch to change the order of checks, but another option to evaluate is to revert a069da6c66da407cc52e1e92321d69c68fd6beb5. Jeremy, it might look like I'm picking on you, but it would really help to get a confirmation that a069da6c66da407cc52e1e92321d69c68fd6beb5 actually fixed some real problem on iOS. The commit message was a bit vague. Shit happens, I guess nobody here could have predicted that __declspec generally has such a weird behavior in modern compilers and everyone had time to review your patch before it got pushed. So it is not like you are the one to blame. Oh, and yes a069da6c66da407cc52e1e92321d69c68fd6beb5 did fix a real problem caught by tinderbox. pixman was failing to compile on my OS X clang tinderbox. I'm not sure why you asked specifically about iOS, but yes, it would fix the same failure building for iOS as it fixed building for OS X. It was just to make sure that __declspec is really the only way to get TLS on iOS. And not, for example, the case when both __thread and __declspec(thread) are supported, with the latter being just officially preferred or something like this. You commit message for a similar patch in xserver mentioned silencing warnings. And this got me confused. If there are no objections and nobody suggests a better patch within a few days, I guess we can just apply: http://lists.freedesktop.org/archives/pixman/2012-November/002379.html -- Best regards, Siarhei Siamashka ___ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman
Re: [Pixman] pixman on iOS
On Fri, 02 Nov 2012 01:40:01 +0100 sandm...@cs.au.dk (Søren Sandmann) wrote: Siarhei Siamashka siarhei.siamas...@gmail.com writes: I would suggest to just change the order of checks for __declspec(thread) and __thread in configure.ac We should maybe try using -Werror=ignored-attributes in the test, or just prefer the first one. Using -Werror=ignored-attributes will not help because clang-3.1 (and maybe older versions too) just silently ignores __declspec(thread). This non-working TLS problem could have been detected by the pixman test suite if clang had OpenMP support. In any case, I was just lucky to notice the fresh warning when doing preemptive testing for the current clang svn (just to be sure that pixman would not need any ugly compiler bug workarounds for the upcoming clang-3.2). Regarding your original patch, how does iOS behave when somebody tries to use __thread keyword? Does it fail compilation? If nobody knows the answer to this, let's just change the order of the checks as you suggested. We can't support iOS unless someone is willing to maintain it. Now it appears that this bug also affects mingw-w64, not just clang: https://bugs.freedesktop.org/show_bug.cgi?id=57591 I have sent a patch to change the order of checks, but another option to evaluate is to revert a069da6c66da407cc52e1e92321d69c68fd6beb5. Jeremy, it might look like I'm picking on you, but it would really help to get a confirmation that a069da6c66da407cc52e1e92321d69c68fd6beb5 actually fixed some real problem on iOS. The commit message was a bit vague. Shit happens, I guess nobody here could have predicted that __declspec generally has such a weird behavior in modern compilers and everyone had time to review your patch before it got pushed. So it is not like you are the one to blame. -- Best regards, Siarhei Siamashka ___ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman
Re: [Pixman] pixman on iOS
On Nov 28, 2012, at 11:52 AM, Siarhei Siamashka siarhei.siamas...@gmail.com wrote: Now it appears that this bug also affects mingw-w64, not just clang: https://bugs.freedesktop.org/show_bug.cgi?id=57591 I have sent a patch to change the order of checks, but another option to evaluate is to revert a069da6c66da407cc52e1e92321d69c68fd6beb5. Jeremy, it might look like I'm picking on you, but it would really help to get a confirmation that a069da6c66da407cc52e1e92321d69c68fd6beb5 actually fixed some real problem on iOS. The commit message was a bit vague. Shit happens, I guess nobody here could have predicted that __declspec generally has such a weird behavior in modern compilers and everyone had time to review your patch before it got pushed. So it is not like you are the one to blame. Oh, and yes a069da6c66da407cc52e1e92321d69c68fd6beb5 did fix a real problem caught by tinderbox. pixman was failing to compile on my OS X + clang tinderbox. I'm not sure why you asked specifically about iOS, but yes, it would fix the same failure building for iOS as it fixed building for OS X. --Jeremy ___ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman
Re: [Pixman] pixman on iOS
On Mon, 13 Feb 2012 16:16:30 -0800
Jeremy Huddleston jerem...@apple.com wrote:
From: Jeremy Huddleston jerem...@apple.com
Date: Sat, 11 Feb 2012 00:44:38 -0800
Subject: [PATCH 2/2] Expand TLS support beyond __thread to
__declspec(thread)
Also prefer initial-exec if available. This code was pretty much
coppied from a similar commit that I made to xorg-server in April.
cf: xorg/xserver: bb4d145bd25e2aee988b100ecf1105ea3b6a40b8
Signed-off-by: Jeremy Huddleston jerem...@apple.com
This commit seems to cause troubles for clang in linux.
Running pixman configure with clang-3.1 prefers the use
of __declspec(thread) for TLS:
checking for gettimeofday... yes
checking sys/time.h usability... yes
checking sys/time.h presence... yes
checking for sys/time.h... yes
checking for thread local storage (TLS) support... __declspec(thread)
And config.log contains:
configure:13722: checking for thread local storage (TLS) support
configure:13750: clang -c -g -O2 -Wall -fno-strict-aliasing -fvisibility=hidden
conftest.c 5
configure:13750: $? = 0
configure:13750: clang -c -g -O2 -Wall -fno-strict-aliasing -fvisibility=hidden
conftest.c 5
configure:13750: $? = 0
configure:13758: result: __declspec(thread)
So clang seems to accept both __thread and __declspec(thread) but
selects the latter because it is the last in the list.
For the current clang svn (soon to be clang-3.2) we get a bit different
result in config.log:
configure:13722: checking for thread local storage (TLS) support
configure:13750: clang -c -g -O2 -Wall -fno-strict-aliasing -fvisibility=hidden
conftest.c 5
configure:13750: $? = 0
configure:13750: clang -c -g -O2 -Wall -fno-strict-aliasing -fvisibility=hidden
conftest.c 5
conftest.c:45:16: warning: __declspec attribute 'thread' is not supported
[-Wignored-attributes]
int __declspec(thread) test;
^
1 warning generated.
configure:13750: $? = 0
configure:13758: result: __declspec(thread)
Here clang-3.2 produces a warning about __declspec(thread), but does not
fail compilation. Which results in __declspec(thread) also being
selected for TLS.
A simple test demonstrates that __declspec(thread) does not work
correctly in clang:
//
#include pthread.h
#include unistd.h
#include assert.h
int __declspec(thread) a = 0;
void *thread_func(void * arg)
{
a++;
sleep(1);
assert(a == 1);
return NULL;
}
int main(void)
{
pthread_t thread1, thread2;
pthread_create(thread1, NULL, thread_func, NULL);
pthread_create(thread2, NULL, thread_func, NULL);
pthread_join(thread1, NULL);
pthread_join(thread2, NULL);
return 0;
}
//
On a positive side, looks like clang-3.2 is going to be able to pass
pixman test suite successfully.
I would suggest to just change the order of checks for
__declspec(thread) and __thread in configure.ac
--
Best regards,
Siarhei Siamashka
___
Pixman mailing list
Pixman@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pixman
Re: [Pixman] pixman on iOS
We should maybe try using -Werror=ignored-attributes in the test, or just
prefer the first one.
On Oct 25, 2012, at 14:44, Siarhei Siamashka siarhei.siamas...@gmail.com
wrote:
On Mon, 13 Feb 2012 16:16:30 -0800
Jeremy Huddleston jerem...@apple.com wrote:
From: Jeremy Huddleston jerem...@apple.com
Date: Sat, 11 Feb 2012 00:44:38 -0800
Subject: [PATCH 2/2] Expand TLS support beyond __thread to
__declspec(thread)
Also prefer initial-exec if available. This code was pretty much
coppied from a similar commit that I made to xorg-server in April.
cf: xorg/xserver: bb4d145bd25e2aee988b100ecf1105ea3b6a40b8
Signed-off-by: Jeremy Huddleston jerem...@apple.com
This commit seems to cause troubles for clang in linux.
Running pixman configure with clang-3.1 prefers the use
of __declspec(thread) for TLS:
checking for gettimeofday... yes
checking sys/time.h usability... yes
checking sys/time.h presence... yes
checking for sys/time.h... yes
checking for thread local storage (TLS) support... __declspec(thread)
And config.log contains:
configure:13722: checking for thread local storage (TLS) support
configure:13750: clang -c -g -O2 -Wall -fno-strict-aliasing
-fvisibility=hidden conftest.c 5
configure:13750: $? = 0
configure:13750: clang -c -g -O2 -Wall -fno-strict-aliasing
-fvisibility=hidden conftest.c 5
configure:13750: $? = 0
configure:13758: result: __declspec(thread)
So clang seems to accept both __thread and __declspec(thread) but
selects the latter because it is the last in the list.
For the current clang svn (soon to be clang-3.2) we get a bit different
result in config.log:
configure:13722: checking for thread local storage (TLS) support
configure:13750: clang -c -g -O2 -Wall -fno-strict-aliasing
-fvisibility=hidden conftest.c 5
configure:13750: $? = 0
configure:13750: clang -c -g -O2 -Wall -fno-strict-aliasing
-fvisibility=hidden conftest.c 5
conftest.c:45:16: warning: __declspec attribute 'thread' is not supported
[-Wignored-attributes]
int __declspec(thread) test;
^
1 warning generated.
configure:13750: $? = 0
configure:13758: result: __declspec(thread)
Here clang-3.2 produces a warning about __declspec(thread), but does not
fail compilation. Which results in __declspec(thread) also being
selected for TLS.
A simple test demonstrates that __declspec(thread) does not work
correctly in clang:
//
#include pthread.h
#include unistd.h
#include assert.h
int __declspec(thread) a = 0;
void *thread_func(void * arg)
{
a++;
sleep(1);
assert(a == 1);
return NULL;
}
int main(void)
{
pthread_t thread1, thread2;
pthread_create(thread1, NULL, thread_func, NULL);
pthread_create(thread2, NULL, thread_func, NULL);
pthread_join(thread1, NULL);
pthread_join(thread2, NULL);
return 0;
}
//
On a positive side, looks like clang-3.2 is going to be able to pass
pixman test suite successfully.
I would suggest to just change the order of checks for
__declspec(thread) and __thread in configure.ac
--
Best regards,
Siarhei Siamashka
___
Pixman mailing list
Pixman@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pixman
Re: [Pixman] pixman on iOS
On Thu, 25 Oct 2012 14:57:29 -0700
Jeremy Huddleston Sequoia jerem...@apple.com wrote:
On Oct 25, 2012, at 14:44, Siarhei Siamashka
siarhei.siamas...@gmail.com wrote:
On Mon, 13 Feb 2012 16:16:30 -0800
Jeremy Huddleston jerem...@apple.com wrote:
From: Jeremy Huddleston jerem...@apple.com
Date: Sat, 11 Feb 2012 00:44:38 -0800
Subject: [PATCH 2/2] Expand TLS support beyond __thread to
__declspec(thread)
Also prefer initial-exec if available. This code was pretty much
coppied from a similar commit that I made to xorg-server in April.
cf: xorg/xserver: bb4d145bd25e2aee988b100ecf1105ea3b6a40b8
Signed-off-by: Jeremy Huddleston jerem...@apple.com
This commit seems to cause troubles for clang in linux.
Running pixman configure with clang-3.1 prefers the use
of __declspec(thread) for TLS:
checking for gettimeofday... yes
checking sys/time.h usability... yes
checking sys/time.h presence... yes
checking for sys/time.h... yes
checking for thread local storage (TLS) support...
__declspec(thread)
And config.log contains:
configure:13722: checking for thread local storage (TLS) support
configure:13750: clang -c -g -O2 -Wall -fno-strict-aliasing
-fvisibility=hidden conftest.c 5 configure:13750: $? = 0
configure:13750: clang -c -g -O2 -Wall -fno-strict-aliasing
-fvisibility=hidden conftest.c 5 configure:13750: $? = 0
configure:13758: result: __declspec(thread)
So clang seems to accept both __thread and __declspec(thread) but
selects the latter because it is the last in the list.
For the current clang svn (soon to be clang-3.2) we get a bit
different result in config.log:
configure:13722: checking for thread local storage (TLS) support
configure:13750: clang -c -g -O2 -Wall -fno-strict-aliasing
-fvisibility=hidden conftest.c 5 configure:13750: $? = 0
configure:13750: clang -c -g -O2 -Wall -fno-strict-aliasing
-fvisibility=hidden conftest.c 5 conftest.c:45:16: warning:
__declspec attribute 'thread' is not supported
[-Wignored-attributes] int __declspec(thread) test; ^
1 warning generated.
configure:13750: $? = 0
configure:13758: result: __declspec(thread)
Here clang-3.2 produces a warning about __declspec(thread), but
does not fail compilation. Which results in __declspec(thread) also
being selected for TLS.
A simple test demonstrates that __declspec(thread) does not work
correctly in clang:
//
#include pthread.h
#include unistd.h
#include assert.h
int __declspec(thread) a = 0;
void *thread_func(void * arg)
{
a++;
sleep(1);
assert(a == 1);
return NULL;
}
int main(void)
{
pthread_t thread1, thread2;
pthread_create(thread1, NULL, thread_func, NULL);
pthread_create(thread2, NULL, thread_func, NULL);
pthread_join(thread1, NULL);
pthread_join(thread2, NULL);
return 0;
}
//
On a positive side, looks like clang-3.2 is going to be able to pass
pixman test suite successfully.
I would suggest to just change the order of checks for
__declspec(thread) and __thread in configure.ac
We should maybe try using -Werror=ignored-attributes in the test, or
just prefer the first one.
Using -Werror=ignored-attributes will not help because clang-3.1 (and
maybe older versions too) just silently ignores __declspec(thread).
This non-working TLS problem could have been detected by the pixman test
suite if clang had OpenMP support. In any case, I was just lucky to
notice the fresh warning when doing preemptive testing for the current
clang svn (just to be sure that pixman would not need any ugly compiler
bug workarounds for the upcoming clang-3.2).
Regarding your original patch, how does iOS behave when somebody
tries to use __thread keyword? Does it fail compilation?
Also, as mentioned in your commit message, xorg-server is likely to
have the same TLS problem if somebody ever tries to compile it with
clang in linux:
http://cgit.freedesktop.org/xorg/xserver/commit/?id=bb4d145bd25e2aee
As I don't have iOS and have no idea how TLS works there, I would
prefer to step down and let you take care of the issue.
--
Best regards,
Siarhei Siamashka
___
Pixman mailing list
Pixman@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pixman
Re: [Pixman] pixman on iOS
On Sun, Feb 19, 2012 at 6:37 AM, cu cairou...@yahoo.com wrote:
Siarhei Siamashka wrote:
It should be not necessary to compile on linux. Having no OS X, I have
never tried it, but chances should be good for successful compilation
of crossbinutils on OS X targeting arm linux. Which could a part of a
fully automated pixman iOS build script like I tried to suggest here:
http://lists.freedesktop.org/archives/pixman/2011-August/001362.html
I know we've discussed this previously, but just in case - until such
time as iOS gets an appropriate assembler, perhaps it might be possible
to include the pre-compiled (i.e. compiled-decompiled into basic
assembly without macros) version of NEON code with pixman distribution?
This could be made a part of release process, especially if appropriate
binutils are available on the release system somwhere.
Yes, just this release process should not require any extra manual
labour and be fully scriptable. If there is manual labour involved,
then:
a) somebody has to do this for each release
b) there is a much higher chance to screw up something
BTW, could somebody try to run the following steps on OS X and check
if pixman-arm-neon-asm.txt disassembly listing can be successfully
generated?
#!/bin/sh
# build crossbinutils
export BINUTILSVERSION=2.22
export CROSSDIRECTORY=`pwd`
export TARGET=arm-none-linux-gnueabi
mkdir ${CROSSDIRECTORY}/binutils
wget http://ftp.gnu.org/gnu/binutils/binutils-${BINUTILSVERSION}.tar.bz2
tar -xjf binutils-${BINUTILSVERSION}.tar.bz2
cd binutils-${BINUTILSVERSION}
./configure --prefix=${CROSSDIRECTORY}/binutils --target=$TARGET
make -j8
make install
cd ..
# clone pixman sources and get disassembly listing from pixman-arm-neon-asm.S
git clone git://anongit.freedesktop.org/pixman
# gcc can be also used here if clang is not available
clang -E pixman/pixman/pixman-arm-neon-asm.S tmp.s
binutils/bin/arm-none-linux-gnueabi-as -o tmp.o tmp.s
binutils/bin/arm-none-linux-gnueabi-objdump -d tmp.o pixman-arm-neon-asm.txt
--
Best regards,
Siarhei Siamashka
___
Pixman mailing list
Pixman@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pixman
Re: [Pixman] pixman on iOS
On Sun, Feb 19, 2012 at 12:02 PM, Andrea Canciani ranm...@gmail.com wrote: On Sun, Feb 19, 2012 at 10:21 AM, Siarhei Siamashka siarhei.siamas...@gmail.com wrote: On Sun, Feb 19, 2012 at 6:37 AM, cu cairou...@yahoo.com wrote: Siarhei Siamashka wrote: It should be not necessary to compile on linux. Having no OS X, I have never tried it, but chances should be good for successful compilation of crossbinutils on OS X targeting arm linux. Which could a part of a fully automated pixman iOS build script like I tried to suggest here: http://lists.freedesktop.org/archives/pixman/2011-August/001362.html I know we've discussed this previously, but just in case - until such time as iOS gets an appropriate assembler, perhaps it might be possible to include the pre-compiled (i.e. compiled-decompiled into basic assembly without macros) version of NEON code with pixman distribution? This could be made a part of release process, especially if appropriate binutils are available on the release system somwhere. Yes, just this release process should not require any extra manual labour and be fully scriptable. If there is manual labour involved, then: a) somebody has to do this for each release b) there is a much higher chance to screw up something BTW, could somebody try to run the following steps on OS X and check if pixman-arm-neon-asm.txt disassembly listing can be successfully generated? Yes, it works (except for wget not being available, which can easily be solved by using curl). Here is the script I ran and the assembly file it generates: http://people.freedesktop.org/~ranma42/ios-neon-asm/ I'm running XCode 4.2.1, which ships with: $ clang --version Apple clang version 3.0 (tags/Apple/clang-211.12) (based on LLVM 3.0svn) Target: x86_64-apple-darwin11.3.0 Thread model: posix I just noticed that there is also a newer XCode version (4.3). I'll upgrade and check if anything breaks. Thanks for testing. It proves that there is indeed no real need to have linux computer for running the GNU assembler assemble-disassemble tricks. And if OS X / iOS linker could support ELF object file format, everything would be even better. I any case, iOS people may consider my old quickly hacked objdump2s.rb script [1] as public domain and use it in any way they wish. Just be warned that it is a primitive proof of concept and it can't even handle literal pools (as used in pixman-arm-simd-asm.S). Moreover, doing objdump to assembly source conversion is probably better to be implemented in perl. Because perl is unversally available everywhere, and pixman already uses perl. 1. http://lists.freedesktop.org/archives/pixman/2011-March/00.html -- Best regards, Siarhei Siamashka ___ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman
Re: [Pixman] pixman on iOS
I know we've discussed this previously, but just in case - until such time as iOS gets an appropriate assembler, perhaps it might be possible to include the pre-compiled (i.e. compiled-decompiled into basic assembly without macros) version of NEON code with pixman distribution? This could be made a part of release process, especially if appropriate binutils are available on the release system somwhere. Siarhei Siamashka wrote: It should be not necessary to compile on linux. Having no OS X, I have never tried it, but chances should be good for successful compilation of crossbinutils on OS X targeting arm linux. Which could a part of a fully automated pixman iOS build script like I tried to suggest here: http://lists.freedesktop.org/archives/pixman/2011-August/001362.html ___ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman
Re: [Pixman] pixman on iOS
On Thu, Feb 16, 2012 at 10:19 PM, Søren Sandmann sandm...@cs.au.dk wrote: Jeremy Huddleston jerem...@apple.com writes: Can you give me a bit more specifics? Do you have a reduced test case that you can show me of the problems you are having? Have you opened a bug report on llvm's bugzilla? Have you filed a radar with Apple's bug tracker? Yes, one possible resolution is to get Clang/LLVM more compatible with gcc/binutils. Or more specifically its integrated assembler. Right now clang integrated assembler it is quite far from accepting any GAS code, especially the .altmacro syntax used by pixman NEON assembly. To give an example of some bug report, this one is needed for better gcc/binutils compatibility: http://llvm.org/bugs/show_bug.cgi?id=11855 As I understand it: The reduced test case is to just run the configure script on iOS. It will produce something like this: Checker whether to use ARM NEON assembler ... ARM NEON intrinsics not detected Which is a problem because pixman has an extensive set of high-quality NEON fast paths that signifcantly improves performance when NEON is available. It's not easy to solve this problem because the issue is that the toolchain used for iOS simply can't cope with the assembler directives used in pixman-arm-neon-asm.S. Hence people have resorted to compiling it on Linux and then using a disassembler to get preprocessed assembly back that the iOS toolchain *can* cope with. It should be not necessary to compile on linux. Having no OS X, I have never tried it, but chances should be good for successful compilation of crossbinutils on OS X targeting arm linux. Which could a part of a fully automated pixman iOS build script like I tried to suggest here: http://lists.freedesktop.org/archives/pixman/2011-August/001362.html -- Best regards, Siarhei Siamashka ___ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman
Re: [Pixman] pixman on iOS
Jeremy Huddleston jerem...@apple.com writes: Can you give me a bit more specifics? Do you have a reduced test case that you can show me of the problems you are having? Have you opened a bug report on llvm's bugzilla? Have you filed a radar with Apple's bug tracker? As I understand it: The reduced test case is to just run the configure script on iOS. It will produce something like this: Checker whether to use ARM NEON assembler ... ARM NEON intrinsics not detected Which is a problem because pixman has an extensive set of high-quality NEON fast paths that signifcantly improves performance when NEON is available. It's not easy to solve this problem because the issue is that the toolchain used for iOS simply can't cope with the assembler directives used in pixman-arm-neon-asm.S. Hence people have resorted to compiling it on Linux and then using a disassembler to get preprocessed assembly back that the iOS toolchain *can* cope with. I geuss the remark I made in the release announcement was a bit misleading: it's not too difficult to build pixman itself; it's building the NEON optimizations that is difficult. Søren ___ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman
Re: [Pixman] pixman on iOS
Jeremy Huddleston jerem...@apple.com writes: I noticed this message in the release notes for 0.24.4: This release also contains some basic support for using the NEON acceleration on iOS, although actually building pixman on that platform remains difficult. I was curious about what was so difficult about building pixman for iOS and decided to lend a hand. Attached are 2 patches for review and build instructions for how I got it to build. The script will build pixman master for iOS (after the 2 patches are applied). The patches fix TLS detection and add support for --disable-libpng (because I didn't feel like building libpng, too, and pkg-config picked up my host libpng). Everything built just fine. I haven't tested it, but this should make it easier for people to use in iOS if they want. You'll need to adjust the path to the SDK and the minimum version of iOS that you want to support as appropriate. I have pushed the libpng patch. Regarding the TLS patch, Subject: [PATCH 2/2] Expand TLS support beyond __thread to __declspec(thread) Also prefer initial-exec if available. This code was pretty much coppied from a similar commit that I made to xorg-server in April. I don't think initial-exec is appropriate for pixman, which is often dynamically opened. See these bugs: https://bugs.freedesktop.org/show_bug.cgi?id=34335 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=613221 https://bugs.freedesktop.org/show_bug.cgi?id=35268 Also, this part of the patch: -AC_MSG_CHECKING(for __thread) -AC_LINK_IFELSE([AC_LANG_SOURCE([[ -#if defined(__MINGW32__) !(__GNUC__ 4 || (__GNUC__ == 4 __GNUC_MINOR__ = 5)) -#error This MinGW version has broken __thread support -#endif -#ifdef __OpenBSD__ -#error OpenBSD has broken __thread support -#endif looks like it is losing the workarounds for broken __thread support on OpenBSD and certain versions of MinGW. Søren ___ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman
Re: [Pixman] pixman on iOS
I haven't tested anything or even looked at your assembly. I just fixed it
such that it would build out of the box. That's not to say that it builds
*correct* out of the box, but now it at least builds trivially, and you can
look into any other issues.
What errors are you getting trying to compile the pixman arm assembly code for
iOS?
On Feb 15, 2012, at 6:34 AM, cu cairou...@yahoo.com wrote:
I think the difficulty refers to the fact that pixman arm assembly code
can't be directly compiled for iOS.
Does this patch still require the precompiled-disassembled version of
pixman_arm_neon.S?
Jeremy Huddleston wrote:
I noticed this message in the release notes for 0.24.4:
This release also contains some basic support for using the NEON
acceleration on iOS, although actually building pixman on that platform
remains difficult.
I was curious about what was so difficult about building pixman for iOS and
decided to lend a hand. Attached are 2 patches for review and build
instructions for how I got it to build.
The script will build pixman master for iOS (after the 2 patches are
applied). The patches fix TLS detection and add support for
--disable-libpng (because I didn't feel like building libpng, too, and
pkg-config picked up my host libpng).
Everything built just fine. I haven't tested it, but this should make it
easier for people to use in iOS if they want. You'll need to adjust the
path to the SDK and the minimum version of iOS that you want to support as
appropriate.
SDK=/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.0.sdk
export CC=$(xcrun -sdk iphoneos -find clang)
export AS=$(xcrun -sdk iphoneos -find as)
export CPPFLAGS=-isysroot ${SDK}
export CFLAGS=-g3 -gdwarf-2 -Os -pipe -miphoneos-version-min=5.0 -arch
armv6 -arch armv7
export LDFLAGS=-isysroot ${SDK} -miphoneos-version-min=5.0 -arch armv6
-arch armv7
./configure --host=arm-apple-darwin
make
--Jeremy
___
Pixman mailing list
Pixman@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pixman
___
Pixman mailing list
Pixman@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pixman
Re: [Pixman] Pixman on iOS
On Mon, Jul 25, 2011 at 5:02 AM, cu cairou...@yahoo.com wrote: It's been a while - but I am finally at a point where this is going to become project of the day. Are there any recent changes to be aware of, in particular: - A known good version of binutils objdump? - Anything new wrt. erroneous decoding of instructions or any other caveats that make using most recent pixman impossible? This is something to be investigated by those who want to get pixman ARM NEON optimizations working on iOS. I can answer some questions about the code and provide some minor assistance, but the iOS porting task needs to be driven by somebody else. Sorry. My plan is to go through the pre-processing, get a working .S assembly file and, provided it actually works for iOS, return it to the public (i.e it could be checked into the source with appropriate disclaimers, as you have suggested) Adding such automatically generated file to pixman repository is not maintainable because any changes to the ARM NEON assembly files would make it immediately outdated. Assuming that pixman ARM assembly sources keep using gnu assembler and no updates to iOS toolchain are coming to fix gnu assembler compatibility issue, there are two solutions possible: a) use some gas compatible macro preprocessor which supports all the features needed by pixman, https://github.com/yuvi/gas-preprocessor may be possibly improved to become one (it got libjpeg-turbo support recently, but this is not enough for pixman) b) use the original preprocessor from gnu assembler itself and extract its results via some hacks The second option is technically easier for pixman, but it is also more messy. For it to work, we need: 1. A reasonably bug free version of binutils which can do a successful as - objdump - simple script - as roundtrip. All the binutils bugs should be reported to binutils bug tracker: http://www.gnu.org/s/binutils/ 2. Some script for pixman which can automatically download a suitable version of binutils, compile it and do all the steps needed to get the resulting iOS assembler compatible source, eliminating any possible human error in this process. The as - objdump step is not quite nice, so it might be a good idea to try investigating whether it is possible to get the intermediate output of the preprocessor from gnu assembler instead of the object file. If such feature exists, then we should use it. If not, then a feature request (preferably with a patch) is better to be submitted to binutils maintainers. -- Best regards, Siarhei Siamashka ___ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman
Re: [Pixman] Pixman on iOS
Yes, all options were set exactly the same. The only difference during font test was the method used to create fonts, - either by using cairo_ft_font_face_create_for_ft_face() or cairo_quartz_font_face_create_for_cgfont() respectively. As an aside, even if I use exactly the same fonts (selected by name in Quartz vs. loaded as file in Freetype), they render differently in both image and quartz surface, with Freetype fonts quite a bit crisper. I didn't see this difference on Windows. Did you set the anti-aliasing and hinting options to the same values for both surfaces? ___ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman
Re: [Pixman] Pixman on iOS
2011/7/11 cu cairou...@yahoo.com: Yes, all options were set exactly the same. The only difference during font test was the method used to create fonts, - either by using cairo_ft_font_face_create_for_ft_face() or cairo_quartz_font_face_create_for_cgfont() respectively. I don't know anything about the quartz backend, but it could very well be that it disregards some of the options. Is there any combination of hinting/aa that gives the same results for both font engines? As an aside, even if I use exactly the same fonts (selected by name in Quartz vs. loaded as file in Freetype), they render differently in both image and quartz surface, with Freetype fonts quite a bit crisper. I didn't see this difference on Windows. Did you set the anti-aliasing and hinting options to the same values for both surfaces? Maarten ___ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman
Re: [Pixman] Pixman on iOS
I am lifting an old thread here, since there is a bit of data that may be related. I have been testing Quartz surface vs. image surface performance - on an Intel Mac. The results are somewhat surprising to me. A certain image that's a pretty good mix of polygons, lines, icons (copied from another surface) and text gets the following drawing times (seconds): Pixman with SSE - 0.122 Pixman, no SSE or MMX: 0.140 Quartz (using fonts through Freetype backend): 0.145 Quartz (using fonts through Quartz font backend): 0.165 A few conclusions: - Pixman is quite a bit faster than Quartz when used by cairo. Assuming this extrapolates to iOS/arm - having a proper optimized Pixman build on iOS is quite crucial. - Even unoptimized, it is still somewhat preferable to use pixman over Quartz - Quartz is slower with its own fonts - this one I just don't get As an aside, even if I use exactly the same fonts (selected by name in Quartz vs. loaded as file in Freetype), they render differently in both image and quartz surface, with Freetype fonts quite a bit crisper. All of the above based on cairo 1.9.8. --cu Andrea Canciani wrote: Cairo should already provide the needed support for iOS in the Quartz backend. If that is the main backend used by the application, Pixman should already be quite usable without NEON optimization, as it will only be used for fallbacks. Of course it would be nice to get NEON fast paths, if they can actually be used on that architecture. ___ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman
Re: [Pixman] Pixman on iOS
On Sun, Mar 6, 2011 at 2:55 PM, Luca Barbato lu_z...@gentoo.org wrote: On 03/06/2011 11:27 AM, Siarhei Siamashka wrote: On Sun, Mar 6, 2011 at 5:28 AM, cu cairou...@yahoo.com wrote: I am starting to look (very carefully) into building pixman and, one day may be, cairo on iphone/ipad/iOS. So far I've got to the point where I can configure and build pixman for a single arm architecture. So far so good. However, I seem to be unable to enable NEON optimizations. Presumably, iPhone/iPad armv7 does have those. I wonder if the issue is specific set of compiler directives used to access NEON operations? Any help or insight would be appreciated. In order to compile NEON assembly optimizations, ideally one would need GAS compatible assembler (fully supporting 'modern' features like macros) which can produce Mach-O object files. I'm not aware of the latest news on this front and my information may be a bit outdated. But from what I read, apparently Apple forked an ancient version of binutils ages ago and has a very primitive assembler. And on the other hand, upstream GNU binutils do not support Mach-O yet. The popular solution seems to be to use intermediate preprocessors written in scripting languages on assembly source files to produce something that can be digested by the assembler from iPhone SDK. That one helps a lot: https://github.com/yuvi/gas-preprocessor Thanks for the link, it's clearly interesting. Unfortunately this script seems to be choking on 'pixman-arm-neon-asm.S', so it might need to be improved a bit. I also experimented with solving a similar problem in a bit different way some time ago after Mozilla folks expressed some concerns on IRC regarding whether the new pixman NEON optimizations would be also usable on Windows Mobile. This Windows Mobile topic died eventually, but my old script is still available here: http://cgit.freedesktop.org/~siamashka/pixman/commit/?h=objdump2sid=7eab8ae70780974bddff4b623549647f536011ca The usage is simple. First one needs to do a normal build of pixman for ARM linux, so that the library with object files in ELF format is generated for NEON optimizations in 'pixman/.libs/libpixman-arm-neon.a'. Then run: $ arm-none-gnueabi-objdump -d pixman/.libs/libpixman-arm-neon.a objdump.log $ ruby objdump2s.rb objdump.log pixman/pixman-arm-neon-asm.S As a result, 'pixman/pixman-arm-neon-asm.S' should now contain the NEON assembly source file with all macros expanded. I have just tested it, and everything seems to work fine (compiling it for ARM linux again) except for two problems: 1. objdump from binutils 2.21 seems to have proken alignment specifiers (2.20.1 is fine) 2. all versions of objdump that I have seem to disassemble 'vshll.u16' instruction incorrectly and this instruction is used by the new bilinear fast path, a temporary solution is to try pixman-2.21.6 which does not have bilinear optimizations yet And the final note. If anyone would want to redistribute this preprocessed file for whatever purpose, preserving the original copyright header and also adding a notice that it is not the original source but an autogenerated file would be really appreciated. As well as also having a reference to the original source or including it verbatim. After NEON assembly can be compiled, pixman runtime CPU detection needs to be tweaked to detect NEON and enable it on iPhone. And finally, somebody needs to check whether iPhone ABI is compatible with what is used by Linux and Android (ARM EABI) because this can be potentially a source of really bad runtime bugs. Just running tests from pixman test suite to see whether they pass or fail may be a good start. For starter I'd just force-enable/disable depending on the target build. Yes, that makes sense. At least for the initial test build. That said, I neither have any Apple hardware required to do iPhone development, nor do I feel that it would be the right thing for me to work on this issue considering many factors. Surely it would have been better for everyone if Apple tried to be more compatible with Linux. But as it does not seem to be the case, somebody has to do some work to make sure that pixman NEON optimizations work there. I have the needed hardware so if enough people find that part interesting I could give a try. I'm actually more worried that if this build for iPhone ends up being a one shot experiment without any maintainer to keep it alive, then it is going to bitrot soon. IMHO adding support for more marginal platforms (in cairo/pixman context) is not something that is clearly beneficial. More like it will attract the users who can't solve their problems themselves but complaining about bugs and breakages. -- Best regards, Siarhei Siamashka ___ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman
Re: [Pixman] Pixman on iOS
On 03/07/2011 03:19 PM, Siarhei Siamashka wrote: https://github.com/yuvi/gas-preprocessor Thanks for the link, it's clearly interesting. Unfortunately this script seems to be choking on 'pixman-arm-neon-asm.S', so it might need to be improved a bit. I see =| I'm actually more worried that if this build for iPhone ends up being a one shot experiment without any maintainer to keep it alive, then it is going to bitrot soon. IMHO adding support for more marginal platforms (in cairo/pixman context) is not something that is clearly beneficial. More like it will attract the users who can't solve their problems themselves but complaining about bugs and breakages. Given how ColorSync seems quite harder to grasp than pixman and given swscale isn't yet arm-optimized (working on cleaning it up so adding arm support could be done right now), probably more and more people could help supporting it even if it is a fringe/annoying platform. lu -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero ___ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman
Re: [Pixman] Pixman on iOS
I'm actually more worried that if this build for iPhone ends up being a one shot experiment without any maintainer to keep it alive, then it is going to bitrot soon. IMHO adding support for more marginal platforms (in cairo/pixman context) is not something that is clearly beneficial. More like it will attract the users who can't solve their problems themselves but complaining about bugs and breakages. That might be me :) That said, I think iOS is not a marginal platform - perhaps differently abled :) That it is not a major target for cairo is a matter of time and a bit of chicken egg issue. It would be if there was support for it. As for users that can't solve their own problems - that describes majority of users of any library, pixman not being any different. I'll give your pre-compiled optimized code a try. I wonder if there is a way to make some sort of a step-by-step writeup of what's needed to make code like that, so that someone with access to both Linux and iOS/MacOS could repeat these steps. --M ___ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman
Re: [Pixman] Pixman on iOS
On Mon, Mar 7, 2011 at 8:09 PM, cu cairou...@yahoo.com wrote: I'm actually more worried that if this build for iPhone ends up being a one shot experiment without any maintainer to keep it alive, then it is going to bitrot soon. IMHO adding support for more marginal platforms (in cairo/pixman context) is not something that is clearly beneficial. More like it will attract the users who can't solve their problems themselves but complaining about bugs and breakages. That might be me :) That said, I think iOS is not a marginal platform - perhaps differently abled :) That it is not a major target for cairo is a matter of time and a bit of chicken egg issue. It would be if there was support for it. Cairo should already provide the needed support for iOS in the Quartz backend. If that is the main backend used by the application, Pixman should already be quite usable without NEON optimization, as it will only be used for fallbacks. Of course it would be nice to get NEON fast paths, if they can actually be used on that architecture. As for users that can't solve their own problems - that describes majority of users of any library, pixman not being any different. I'll give your pre-compiled optimized code a try. I wonder if there is a way to make some sort of a step-by-step writeup of what's needed to make code like that, so that someone with access to both Linux and iOS/MacOS could repeat these steps. An example/model of such a guide could be: http://www.cairographics.org/end_to_end_build_for_mac_os_x/ It gives you the whole sequence of commands needed to compile the library (in the boxes) and explains what's happening and why. Andrea ___ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman
Re: [Pixman] Pixman on iOS
On Sun, Mar 6, 2011 at 5:28 AM, cu cairou...@yahoo.com wrote: I am starting to look (very carefully) into building pixman and, one day may be, cairo on iphone/ipad/iOS. So far I've got to the point where I can configure and build pixman for a single arm architecture. So far so good. However, I seem to be unable to enable NEON optimizations. Presumably, iPhone/iPad armv7 does have those. I wonder if the issue is specific set of compiler directives used to access NEON operations? Any help or insight would be appreciated. In order to compile NEON assembly optimizations, ideally one would need GAS compatible assembler (fully supporting 'modern' features like macros) which can produce Mach-O object files. I'm not aware of the latest news on this front and my information may be a bit outdated. But from what I read, apparently Apple forked an ancient version of binutils ages ago and has a very primitive assembler. And on the other hand, upstream GNU binutils do not support Mach-O yet. The popular solution seems to be to use intermediate preprocessors written in scripting languages on assembly source files to produce something that can be digested by the assembler from iPhone SDK. After NEON assembly can be compiled, pixman runtime CPU detection needs to be tweaked to detect NEON and enable it on iPhone. And finally, somebody needs to check whether iPhone ABI is compatible with what is used by Linux and Android (ARM EABI) because this can be potentially a source of really bad runtime bugs. Just running tests from pixman test suite to see whether they pass or fail may be a good start. That said, I neither have any Apple hardware required to do iPhone development, nor do I feel that it would be the right thing for me to work on this issue considering many factors. Surely it would have been better for everyone if Apple tried to be more compatible with Linux. But as it does not seem to be the case, somebody has to do some work to make sure that pixman NEON optimizations work there. -- Best regards, Siarhei Siamashka ___ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman
Re: [Pixman] Pixman on iOS
Luca Barbato wrote: For starter I'd just force-enable/disable depending on the target build. Indeed. armv7 arch on iPhone/iPad supposedly always means NEON. Runtime detection can always come later. That said, I neither have any Apple hardware required to do iPhone development, nor do I feel that it would be the right thing for me to work on this issue considering many factors. Surely it would have been better for everyone if Apple tried to be more compatible with Linux. But as it does not seem to be the case, somebody has to do some work to make sure that pixman NEON optimizations work there. I have the needed hardware so if enough people find that part interesting I could give a try. I have the hardware and reasonable set-up to try things. Admittedly, I am a C developer and when it comes to assembly, using definitions from Kung-fu Panda - there is now a level zero. But, I can definitely try things and provide feedback, as well as help with the build in any way I can. Cairo and pixman do quite a bit to be compatible with various systems. I think considering the amount of iHardware out there it would be beneficial for many to get it working properly. --M ___ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman
