• Home
  • History
  • Annotate
  • only in /external/libpng/contrib/arm-neon/
NameDateSize

..12-Mar-20154 KiB

android-ndk.c12-Mar-20151.3 KiB

linux-auxv.c12-Mar-20153.2 KiB

linux.c12-Mar-20154.4 KiB

README12-Mar-20153.4 KiB

README

1OPERATING SYSTEM SPECIFIC ARM NEON DETECTION
2--------------------------------------------
3
4Detection of the ability to exexcute ARM NEON on an ARM processor requires
5operating system support.  (The information is not available in user mode.)
6
7HOW TO USE THIS
8---------------
9
10This directory contains C code fragments that can be included in arm/arm_init.c
11by setting the macro PNG_ARM_NEON_FILE to the file name in "" or <> at build
12time.  This setting is not recorded in pnglibconf.h and can be changed simply by
13rebuilding arm/arm_init.o with the required macro definition.
14
15For any of this code to be used the ARM NEON code must be enabled and run time
16checks must be supported.  I.e.:
17
18#if PNG_ARM_NEON_OPT > 0
19#ifdef PNG_ARM_NEON_CHECK_SUPPORTED
20
21This is done in a 'configure' build by passing configure the argument:
22
23   --enable-arm-neon=check
24
25Apart from the basic Linux implementation in contrib/arm-neon/linux.c this code
26is unsupported.  That means that it is not even compiled on a regular basis and
27may be broken in any given minor release.
28
29FILE FORMAT
30-----------
31
32Each file documents its testing status as of the last time it was tested (which
33may have been a long time ago):
34
35STATUS: one of:
36   SUPPORTED: This indicates that the file is included in the regularly
37         performed test builds and bugs are fixed when discovered.
38   COMPILED: This indicates that the code did compile at least once.  See the
39         more detailed description for the extent to which the result was
40         successful.
41   TESTED: This means the code was fully compiled into the libpng test programs
42         and these were run at least once.
43
44BUG REPORTS: an email address to which to send reports of problems
45
46The file is a fragment of C code. It should not define any 'extern' symbols;
47everything should be static.  It must define the function:
48
49static int png_have_neon(png_structp png_ptr);
50
51That function must return 1 if ARM NEON instructions are supported, 0 if not.
52It must not execute png_error unless it detects a bug.  A png_error will prevent
53the reading of the PNG and in the future, writing too.
54
55BUG REPORTS
56-----------
57
58If you mail a bug report for any file that is not SUPPORTED there may only be
59limited response.  Consider fixing it and sending a patch to fix the problem -
60this is more likely to result in action.
61
62CONTRIBUTIONS
63-------------
64
65You may send contributions of new implementations to
66png-mng-implement@sourceforge.net.  Please write code in strict C90 C where
67possible.  Obviously OS dependencies are to be expected.  If you submit code you
68must have the authors permission and it must have a license that is acceptable
69to the current maintainer; in particular that license must permit modification
70and redistribution.
71
72Please try to make the contribution a single file and give the file a clear and
73unambiguous name that identifies the target OS.  If multiple files really are
74required put them all in a sub-directory.
75
76You must also be prepared to handle bug reports from users of the code, either
77by joining the png-mng-implement mailing list or by providing an email for the
78"BUG REPORTS" entry or both.  Please make sure that the header of the file
79contains the STATUS and BUG REPORTS fields as above.
80
81Please list the OS requirements as precisely as possible.  Ideally you should
82also list the environment in which the code has been tested and certainly list
83any environments where you suspect it might not work.
84