On 5/6/2025 6:39 PM, James Almer wrote:
On 5/6/2025 6:26 PM, Michael Niedermayer wrote:x87 float instructions are not used in x86_64, which is both these targets. For float16 it will either use CPU instructions if available, or the fallback we have using a lookup table (through float2half and half2float).On Tue, May 06, 2025 at 06:10:22PM -0300, James Almer wrote:On 5/6/2025 5:44 PM, Michael Niedermayer wrote:On Mon, May 05, 2025 at 04:44:06PM -0300, James Almer wrote:Signed-off-by: James Almer <jamr...@gmail.com> --- tests/fate/image.mak | 3 +++ tests/ref/fate/rgb-scanline-dwab-half-float | 6 ++++++ 2 files changed, 9 insertions(+) create mode 100644 tests/ref/fate/rgb-scanline-dwab-half-floatdiff --git a/tests/fate/image.mak b/tests/fate/image.mak index 042cf6438f..abf204f69f 100644 --- a/tests/fate/image.mak +++ b/tests/fate/image.mak@@ -124,6 +124,9 @@ fate-exr-rgb-scanline-pxr24-float-12x8: CMD = framecrc -i $(TARGET_SAMPLES)/exr/FATE_EXR += fate-exr-rgba-multiscanline-half-b44fate-exr-rgba-multiscanline-half-b44: CMD = framecrc -i $(TARGET_SAMPLES)/exr/rgba_multiscanline_half_b44.exr -vf scale - pix_fmt gbrapf32le+FATE_EXR += fate-rgb-scanline-dwab-half-float+fate-rgb-scanline-dwab-half-float: CMD = framecrc -i $(TARGET_SAMPLES)/exr/rgb_scanline_dwab_half_float.exr -vf scale - pix_fmt gbrpf32le+ FATE_EXR += fate-exr-rgb-scanline-float-b44fate-exr-rgb-scanline-float-b44: CMD = framecrc -i $(TARGET_SAMPLES)/exr/rgb_scanline_float_b44.exr -vf scale -pix_fmt gbrpf32le diff --git a/tests/ref/fate/rgb-scanline-dwab-half-float b/tests/ ref/fate/rgb-scanline-dwab-half-floatnew file mode 100644 index 0000000000..a5a1997785 --- /dev/null +++ b/tests/ref/fate/rgb-scanline-dwab-half-float @@ -0,0 +1,6 @@ +#tb 0: 1/25 +#media_type 0: video +#codec_id 0: rawvideo +#dimensions 0: 512x512 +#sar 0: 1/1 +0, 0, 0, 1, 3145728, 0xbb11b00adiffernt result here: (on linux x86-64)--- ./tests/ref/fate/rgb-scanline-dwab-half-float 2025-05-06 22:40:40.017406113 +0200 +++ tests/data/fate/rgb-scanline-dwab-half-float 2025-05-06 22:40:53.297513198 +0200@@ -3,4 +3,4 @@ #codec_id 0: rawvideo #dimensions 0: 512x512 #sar 0: 1/1 -0, 0, 0, 1, 3145728, 0xbb11b00a +0, 0, 0, 1, 3145728, 0x2a15f7aaTest rgb-scanline-dwab-half-float failed. Look at tests/data/fate/ rgb-scanline-dwab-half-float.err for details.Yeah, I can reproduce it, and even if i add "sws_flags +accurate_rnd+bitexact" i get the same results (0xbb11b00a on Win64,0x2a15f7aa on Linux x86-64). I also get a different hash in both targets ifi don't rescale to gbrpf32, so the problem is not in swscale. Neither Valgrind or gcc-usan complain, so I'm not sure what could be producing this difference.float is not bitexact in C, and float on x86 might use old x87 style while x86-64 might be SSE*/AVX, so if theres any float in the code slight differencescan happen, no idea if half float in this case is affected by this or not
Ok, turns out the Win64 target had the F16C instruction set enabled, which surprisingly results in that difference (Many other tests also use half float samples and the lookup table fallback matches the F16C output).
Might have to look further to find out why.
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
