62204 2011-06-07 05:15:49 -0700 Master bug for rounding issues which cause 1px difference on 32/64 bit architectures 2024-01-02 09:17:43 -0800 1 1 1 Unclassified WebKit WebCore Misc. 528+ (Nightly build) Unspecified Unspecified RESOLVED CONFIGURATION CHANGED P2 Normal --- 42624 47467 52810 54474 56465 62003 65831 72254 82601 89597 1 zherczeg webkit-unassigned abecsi ahmad.saleem792 ap loki ossy tonikitoo vanuan zimmermann oldest_to_newest 416441 0 zherczeg 2011-06-07 05:15:49 -0700 Such bugs are mostly caused by rounding. But what does exactly happen there? And how? The answer is here, let's divide 400000 by 600 If the input arguments are float: 400000/600 = 666.666687 If the input arguments are double: 400000/600 = 666.666667 This is nice, but shouldn't the same rounding error should happen on ALL machines? The understand this better, we need to see what exactly happen on lower (machine code) levels. The systems use registers to temporary keep the values of arithmetic. On x86, these registers have fixed size (10 byte for x87 fpu, and 8 byte for SSE2), and all arithmetic operations are executed using the highest precision. However, results are rounded to the storage size if we move the data to the memory. Let's we have a super simple x86 machine with 2 double precision registers, d1 and d2, and we want to evaluate: (A*B)+(C*D). The following pesudo code show this: LOAD A to d1 MULTIPLY B to d1 LOAD C to d2 MULTIPLY D to d2 ADD d1 and d2 However, what does happen, if let's say, d2 is reserved for some reasons: LOAD A to d1 MULTIPLY B to d1 STORE d1 to [4 byte mem area] // CONVERSION HERE!!! LOAD C to d2 MULTIPLY D to d2 ADD d1 and [4 byte mem area] There are several versions of such code, but the issue is the same: moving data to a storage with different precision cause rounding. However, if the data is not need to be moved (because it is in the right register at the moment), the rounding is ALSO optimized out by the compiler, and you may get a different result on different platforms. Solution? I can't see a good solution. Storing everything on the highest precision would increase the memory consumption too much. Furthermore, these differences are hardly visible to the user. However, it is a nightmare for platform maintainers, you need to maintain too many expected files. I think we should live with it now, and try to reduce these bugs. 416444 1 zherczeg 2011-06-07 05:28:47 -0700 > LOAD A to d1 > MULTIPLY B to d1 > STORE d1 to [4 byte mem area] // CONVERSION HERE!!! > LOAD C to d2 > MULTIPLY D to d2 > ADD d1 and [4 byte mem area] My bad, the second example was wrong. It should look like: LOAD A to d1 MULTIPLY B to d1 STORE d1 to [4 byte mem area] // CONVERSION HERE!!! LOAD C to d1 MULTIPLY D to d1 ADD d1 and [4 byte mem area] 416529 2 fischman 2011-06-07 08:52:04 -0700 FTR, chromium/linux/ia32 builds with -mfpmath=sse -msse2 to avoid this sort of problem: http://codesearch.google.com/codesearch/p?hl=en#OAMlx_jo-ck/src/build/common.gypi&q=file:build/common.gypi&exact_package=chromium&l=1211 501506 3 vanuan 2011-11-13 04:45:36 -0800 Please add this bug https://bugs.webkit.org/show_bug.cgi?id=54474 as a dependency 501769 4 zimmermann 2011-11-14 03:24:22 -0800 Add more dependencies. 1923710 5 ahmad.saleem792 2023-01-06 18:05:40 -0800 All dependent bugs are fixed now, do we need to track anything else here? Thanks! 2002520 6 ahmad.saleem792 2024-01-02 09:17:43 -0800 All dependent bugs are fixed. So marking this as 'RESOLVED CONFIGURATION CHANGED'. Please reopen renew bug as needed.