gcc-3.0.1: update for configure + problems with mmx & ffdivx
Hi! gcc-3.0.1 isn't officially released but current snapshots return 3.0.1 as version number, which lead to a misleading error ("found 3.0.1 please upgrade/downgrade...") [patch below]. Btw, it compiles with 3.0.x _but_ I think there is a gcc-3.0.x bug (?) with the ffdivx driver when mmx support is enabled => the image is completely garbled... I've narrowed the problem to the compilation of libavcodec/mpegvideo.c (and especially libavcodec/i386/mpegvideo.c): by changing the level of optimization from -O4 to -O0 it works... So if anyone litterate in asm can check that, I can provide -S outputs... else maybe it should be added to the BUGS files. Best regards. --- configure 20 Jul 2001 00:01:08 -0000 1.112 +++ configure 23 Jul 2001 11:57:27 -0000 @@ -341,7 +341,7 @@ cc_version=`$_cc -v 2>&1 | sed -n 's/^.*version \([aegcygnustp-]*[0-9.]*\).*$/\1/p'` case $cc_version in '') cc_version="v. ?.??, bad"; cc_verc_fail=yes;; + 2.95.[2-9]|2.95.[2-9].[0-9]|3.[0-9]|3.[0-9].[0-9]) - 2.95.[2-9]|2.95.[2-9].[0-9]|3.[0-9]) cc_version="$cc_version, ok";; *) cc_version="$cc_version, bad"; cc_verc_fail=yes;; esac _______________________________________________ Mplayer-dev-eng mailing list Mplayer-dev-eng@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/mplayer-dev-eng
Hi, On Mon, Jul 23, 2001 at 02:16:27PM +0200, pl wrote: [...]
Btw, it compiles with 3.0.x _but_ I think there is a gcc-3.0.x bug (?) with the ffdivx driver when mmx support is enabled => the image is completely garbled... [...]
Well... Since I don't have a C bible available I can't say who's wrong/right but here is what I found. gcc-3.0 does not produce the code expected at optimization level -Ox (x>=1) for main/libavcodec/i386/mpegvideo.c with MMX enabled. The problem comes from the use of the const attribute for the two data arrays (mm_wabs[], mm_wone[]). As far as I can tell, expected code (first part of Nick's inline asm) is: [...] movd %edi, %mm6 punpckldq %mm6, %mm6 movq mm_wabs, %mm4 * movq %mm6, %mm7 movq mm_wone, %mm5 * packssdw %mm6, %mm7 pxor %mm6, %mm6 [...] which effectively corresponds to what is expected load register %mm? with the 8 bytes of mm_w???[]. gcc-3.0 at -O4 generate the following "evil" code: [...] .LC113: .value 1 .align 2 .LC114: .value 65535 .text .align 16 [...] movd %edi, %mm6 punpckldq %mm6, %mm6 movq .LC114, %mm4 * movq %mm6, %mm7 movq .LC113, %mm5 * packssdw %mm6, %mm7 pxor %mm6, %mm6 [...] And there it does not load completely what it should... Therefore, it sucks. The image is completely garbled, women yell, children cry, ... So... as I don't know how the C standard defines the behavior of constant arrays VS inlined asm, here are possible fixes: Fixes: ------ - wait for gcc team to fix it - explicitely not use gcc-3.0.x for this file - use -O0 for this file - remove the const attribute for: static const unsigned short mm_wabs[4] __attribute__ ... static const unsigned short mm_wone[4] __attribute__ ... - change unsigned short[4] to unsigned long long (see patch enclosed) (preferred and maybe cleaner) Best regards. -- pl
Hi, pl! On 2001-07-24 18:58:52 you wrote:
Well... Since I don't have a C bible available I can't say who's wrong/right but here is what I found.
gcc-3.0 does not produce the code expected at optimization level -Ox (x>=1) for main/libavcodec/i386/mpegvideo.c with MMX enabled.
The problem comes from the use of the const attribute for the two data arrays (mm_wabs[], mm_wone[]).
As far as I can tell, expected code (first part of Nick's inline asm) is:
[...] movd %edi, %mm6 punpckldq %mm6, %mm6 movq mm_wabs, %mm4 * movq %mm6, %mm7 movq mm_wone, %mm5 * packssdw %mm6, %mm7 pxor %mm6, %mm6 [...] which effectively corresponds to what is expected load register %mm? with the 8 bytes of mm_w???[].
gcc-3.0 at -O4 generate the following "evil" code: [...] .LC113: .value 1 .align 2 .LC114: .value 65535 .text .align 16 [...] movd %edi, %mm6 punpckldq %mm6, %mm6 movq .LC114, %mm4 * movq %mm6, %mm7 movq .LC113, %mm5 * packssdw %mm6, %mm7 pxor %mm6, %mm6 [...]
And there it does not load completely what it should... Therefore, it sucks. The image is completely garbled, women yell, children cry, ...
So... as I don't know how the C standard defines the behavior of constant arrays VS inlined asm, here are possible fixes:
Fixes: ------ - wait for gcc team to fix it
- explicitely not use gcc-3.0.x for this file
- use -O0 for this file
- remove the const attribute for: static const unsigned short mm_wabs[4] __attribute__ ... static const unsigned short mm_wone[4] __attribute__ ...
- change unsigned short[4] to unsigned long long (see patch enclosed) (preferred and maybe cleaner)
Your gcc is sucks!!! The constructions which you use in patch are common for this file. If you look at several lines below of the block which you've patched you'll find there the same code which don't caused any problem on your gcc. Therefore it's problem of gcc. could you tell me please - what type of "C" you will use for 16-bit SSE? So it's not solution (maybe partial for your situation but in general it doesn't remove a problem - only hides it). Do you report about this problem to gcc team? They planned to release 3.0.1 soon. I didn't understand what version of gcc you use - official 3.0 or 3.0.1-pre but imho it's gcc's bug and it would be better to fix it in compiler. Best regards! Nick (2001-07-24 22:15:58) _______________________________________________ Mplayer-dev-eng mailing list Mplayer-dev-eng@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/mplayer-dev-eng
Hi! On Tue, Jul 24, 2001 at 10:24:33PM +0000, Nick Kurshev wrote: [...]
gcc-3.0 does not produce the code expected at optimization level -Ox (x>=1) for main/libavcodec/i386/mpegvideo.c with MMX enabled. [...] Your gcc is sucks!!! The constructions which you use in patch are common for this file. If you look at several lines below of the block which you've patched you'll find there the same code which don't caused any problem on your gcc. Therefore it's problem of gcc. could you tell me please - what type of "C" you will use for 16-bit SSE? So it's not solution (maybe partial for your situation but in general it doesn't remove a problem - only hides it).
I've already figured by myself gcc-3 has problems... Maybe it's kinda masochism :)
Do you report about this problem to gcc team? They planned to release 3.0.1 soon. I'm going to report it - just wanted to be sure it was not a special feature of const in C :)
I didn't understand what version of gcc you use - official 3.0 or 3.0.1-pre but imho it's gcc's bug and it would be better to fix it in compiler. I used debian pre snapshot of gcc-3.0.1 but it broke the same way for gcc-3.0.
Best regards. _______________________________________________ Mplayer-dev-eng mailing list Mplayer-dev-eng@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/mplayer-dev-eng
Hi, pl! On 2001-07-24 21:19:58 you wrote:
Hi!
On Tue, Jul 24, 2001 at 10:24:33PM +0000, Nick Kurshev wrote: [...]
gcc-3.0 does not produce the code expected at optimization level -Ox (x>=1) for main/libavcodec/i386/mpegvideo.c with MMX enabled. [...] Your gcc is sucks!!! The constructions which you use in patch are common for this file. If you look at several lines below of the block which you've patched you'll find there the same code which don't caused any problem on your gcc. Therefore it's problem of gcc. could you tell me please - what type of "C" you will use for 16-bit SSE? So it's not solution (maybe partial for your situation but in general it doesn't remove a problem - only hides it).
I've already figured by myself gcc-3 has problems... Maybe it's kinda masochism :)
Do you report about this problem to gcc team? They planned to release 3.0.1 soon. I'm going to report it - just wanted to be sure it was not a special feature of const in C :)
I didn't understand what version of gcc you use - official 3.0 or 3.0.1-pre but imho it's gcc's bug and it would be better to fix it in compiler. I used debian pre snapshot of gcc-3.0.1 but it broke the same way for gcc-3.0. But what tell other gcc-3.0 users? (Felix - for example or Arpi) Does this problem exist for thrm?
Best regards! Nick (2001-07-24 23:25:59) _______________________________________________ Mplayer-dev-eng mailing list Mplayer-dev-eng@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/mplayer-dev-eng
Hello! Since many video chips are able to decode mpeg1, mpeg2 streams end even perform inverse direct cosine transformation (ATI only) may be it would be better to add something to libvo2 to have possibility to add support of these features in the future? I mean add to list of video surfaces something like IMGFMT_MPEG2 IMGFMT_MPEG1 IMGFMT_IDCT to already existed list of IMGFMT_YUV2 IMGFMT_YV12 and so on Best regards! Nick _______________________________________________ Mplayer-dev-eng mailing list Mplayer-dev-eng@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/mplayer-dev-eng
Hello!
Since many video chips are able to decode mpeg1, mpeg2 streams end even perform inverse direct cosine transformation (ATI only) may be it would be better to add something to libvo2 to have possibility to add support of these features in the future? I mean add to list of video surfaces something like IMGFMT_MPEG2 IMGFMT_MPEG1 IMGFMT_IDCT to already existed list of IMGFMT_YUV2 IMGFMT_YV12 and so on and there are also chips, that support Motion Compensation in Hardware, like
On Saturday, 28. July 2001 14:28, you wrote: the GeForce, would also be nice to add possibility to support that.
Best regards! Nick
-- Best Regards, Felix _______________________________________________ Mplayer-dev-eng mailing list Mplayer-dev-eng@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/mplayer-dev-eng
Hi,
Since many video chips are able to decode mpeg1, mpeg2 streams end even perform inverse direct cosine transformation (ATI only) may be it would be better to add something to libvo2 to have possibility to add support of these features in the future? Do you know any card with linux support for these?
I mean add to list of video surfaces something like IMGFMT_MPEG2 IMGFMT_MPEG1 IMGFMT_IDCT to already existed list of IMGFMT_YUV2 IMGFMT_YV12 and so on it isn't so simple. at least the IDCT stuff. there was a long thread about XvMC at libmpeg2 list. Those cards are very limited, can do _partial_ dct and mc, but they have limits, and can't handle every case. and for mc, they must know the reference frames, so we have to pass those environmental infos to teh libvo driver.
A'rpi / Astral & ESP-team -- mailto:arpi@thot.banki.hu http://esp-team.scene.hu _______________________________________________ Mplayer-dev-eng mailing list Mplayer-dev-eng@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/mplayer-dev-eng
Hi,
Since many video chips are able to decode mpeg1, mpeg2 streams end even perform inverse direct cosine transformation (ATI only) may be it would be better to add something to libvo2 to have possibility to add support of these features in the future? Do you know any card with linux support for these? No. Simply I guess that in the future I could add simplest mplayer's driver (for ATI in root mode) maybe with using some ATI's RFC or other information
Hi, Arpi! On 2001-07-28 15:32:45 you wrote: sources. AFAIK - adding such features in X11 still not planed, but other OS's simply have drivers which support such features and applications which use these drivers. It's non standard way but acceptable for Linux.
I mean add to list of video surfaces something like IMGFMT_MPEG2 IMGFMT_MPEG1 IMGFMT_IDCT to already existed list of IMGFMT_YUV2 IMGFMT_YV12 and so on it isn't so simple. at least the IDCT stuff. there was a long thread about XvMC at libmpeg2 list. Those cards are very limited, can do _partial_ dct and mc, but they have limits, and can't handle every case. and for mc, they must know the reference frames, so we have to pass those environmental infos to teh libvo driver.
May be - I still didn't dig out this problem in depth. Best regards! Nick (2001-07-29 21:29:03) _______________________________________________ Mplayer-dev-eng mailing list Mplayer-dev-eng@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/mplayer-dev-eng
Hello Nick, Sunday, July 29, 2001, 11:36:15 PM, you wrote:
Hi, Arpi!
On 2001-07-28 15:32:45 you wrote:
Hi,
[snip]
I mean add to list of video surfaces something like IMGFMT_MPEG2 IMGFMT_MPEG1 IMGFMT_IDCT to already existed list of IMGFMT_YUV2 IMGFMT_YV12 and so on it isn't so simple. at least the IDCT stuff. there was a long thread about XvMC at libmpeg2 list. Those cards are very limited, can do _partial_ dct and mc, but they have limits, and can't handle every case. and for mc, they must know the reference frames, so we have to pass those environmental infos to teh libvo driver.
May be - I still didn't dig out this problem in depth. For information on Motion Compensation check out: http://lal.cs.byu.edu/ketav/issue_2.5/vod/node7.html
Best regards! Nick (2001-07-29 21:29:03)
-- Best regards, Felix mailto:atmosfear@users.sourceforge.net _______________________________________________ Mplayer-dev-eng mailing list Mplayer-dev-eng@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/mplayer-dev-eng
On Monday, 23. July 2001 14:16, you wrote:
Hi!
gcc-3.0.1 isn't officially released but current snapshots return 3.0.1 as version number, which lead to a misleading error ("found 3.0.1 please upgrade/downgrade...") [patch below].
applied to cvs
Btw, it compiles with 3.0.x _but_ I think there is a gcc-3.0.x bug (?) with the ffdivx driver when mmx support is enabled => the image is completely garbled...
I've narrowed the problem to the compilation of libavcodec/mpegvideo.c (and especially libavcodec/i386/mpegvideo.c): by changing the level of optimization from -O4 to -O0 it works... So if anyone litterate in asm can check that, I can provide -S outputs... else maybe it should be added to the BUGS files.
Best regards.
-- Best Regards, Felix _______________________________________________ Mplayer-dev-eng mailing list Mplayer-dev-eng@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/mplayer-dev-eng
participants (4)
-
Arpi -
Felix Buenemann -
Nick Kurshev -
pl