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