bond
25th August 2005, 13:01
just saw this on the x264 maillist:
Hi,
attached is a patch based on rev. 287 that implements
* x264_sub8x8_dct8_mmxext
* x264_add8x8_idct8_mmxext
which are 3.3 and 4.0 times faster than their C counterparts
(respectively) on my AthlonXP.
Of course they produce bit identical output compared to the C
implementation and the overall speed gain was 2.23% for my non- sythetic
test inputs. An SSE2 optimized version is also possible ( only a typing
exercise ) but will only result in a minor speep up ( estimated 3.8/4.5
times faster than C ) since only a few parts can be optimized for SSE2.
So far it assembles with nasm. I haven't tested it for other assemblers.
btw. I noticed that the C sub8x8_dct8 isn't exactly the inverse of
add8x8_idct8. I wonder if this is really intended ( to add
compressability with quant/dequant perhaps ) or just a bug.
regards,
Christianhttp://people.via.ecp.fr/~admin/20050825-videolan/x264-dct8-idct8-mmxext.diff
enjoy
Hi,
attached is a patch based on rev. 287 that implements
* x264_sub8x8_dct8_mmxext
* x264_add8x8_idct8_mmxext
which are 3.3 and 4.0 times faster than their C counterparts
(respectively) on my AthlonXP.
Of course they produce bit identical output compared to the C
implementation and the overall speed gain was 2.23% for my non- sythetic
test inputs. An SSE2 optimized version is also possible ( only a typing
exercise ) but will only result in a minor speep up ( estimated 3.8/4.5
times faster than C ) since only a few parts can be optimized for SSE2.
So far it assembles with nasm. I haven't tested it for other assemblers.
btw. I noticed that the C sub8x8_dct8 isn't exactly the inverse of
add8x8_idct8. I wonder if this is really intended ( to add
compressability with quant/dequant perhaps ) or just a bug.
regards,
Christianhttp://people.via.ecp.fr/~admin/20050825-videolan/x264-dct8-idct8-mmxext.diff
enjoy