[FIXED] mplayer not using SSE?

kokoko3k · 2013-05-31 09:28:07

Thats what i have when i play anything:

Cannot test OS support for SSE, disabling to be safe.

Can i do something about?

Last edited by kokoko3k (2013-06-13 15:19:50)

kokoko3k · 2013-06-05 14:07:40

I found a very old post about this issue here:
http://web.archiveorange.com/archive/v/ … dwoyjDC9en

Could somebody explain me what is going on?

skottish · 2013-06-05 17:55:25

You've provided almost no information about what you know or what you've done, so help is going to be hard to come by. I recommend that you check the output of:

cat /proc/cpuinfo

and see what it says.

kokoko3k · 2013-06-06 06:07:22

Is not that mplayer finds that my cpu has not sse, but that it doesn't even had a clue about it

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 6
model           : 28
model name      : Intel(R) Atom(TM) CPU N280   @ 1.66GHz
stepping        : 2
microcode       : 0x212
cpu MHz         : 1000.000
cache size      : 512 KB
physical id     : 0
siblings        : 1
core id         : 0
cpu cores       : 0
apicid          : 1
initial apicid  : 1
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl est tm2 ssse3 xtpr pdcm movbe lahf_lm dtherm
bogomips        : 3334.89
clflush size    : 64
cache_alignment : 64
address sizes   : 32 bits physical, 32 bits virtual
power management:

previous mplayer version didn't complain about that thing.

skottish · 2013-06-06 16:28:35

Have you tried mplayer2, or better yet, mpv-git from the AUR?

skanky · 2013-06-06 16:45:19

If you have ffmpeg installed, ffplay may be of use: http://ffmpeg.org/ffplay.html

kokoko3k · 2013-06-07 05:56:37

I'd prefer to stay with mplayer, but for testing purpose it may be helpfull to compile the forks too and see if i've the same problem.
i'll try asap.

skanky · 2013-06-07 09:03:29

kokoko3k wrote:

I'd prefer to stay with mplayer, but for testing purpose it may be helpfull to compile the forks too and see if i've the same problem.
i'll try asap.

ffplay has cpu flags (inc. sse ones) that might help with testing. Might be worth finding some docs on it though.

kokoko3k · 2013-06-07 10:55:12

mplayer2 works as expected:

Detected cache-line size is 64 bytes
Testing OS support for SSE... yes.

...that's weird

-edit
i toke a look to the coudetect.c file (the message and tests about sse are there) of both mplayer and mplayer2, and compiled both with the same file (discarding the changes done by mplayer2, but the result is the same.
Also, it seems that for some reason all lies here:

if defined(_POSIX_SOURCE)
    struct sigaction saved_sigill;

//kokoko3k:
 mp_msg(MSGT_CPUDETECT,MSGL_V, "IF YOU READ ME, POSIX SOURCE IS DEFINED " );
//


    /* Save the original signal handlers.
     */
    sigaction( SIGILL, NULL, &saved_sigill );

    signal( SIGILL, (void (*)(int))sigill_handler_sse );

    /* Emulate test for OSFXSR in CR4.  The OS will set this bit if it
     * supports the extended FPU save and restore required for SSE.  If
     * we execute an SSE instruction on a PIII and get a SIGILL, the OS
     * doesn't support Streaming SIMD Exceptions, even if the processor
     * does.
     */
    if ( gCpuCaps.hasSSE ) {
        mp_msg(MSGT_CPUDETECT,MSGL_V, "Testing OS support for SSE... " );

//      __asm__ volatile ("xorps %%xmm0, %%xmm0");
        __asm__ volatile ("xorps %xmm0, %xmm0");

        mp_msg(MSGT_CPUDETECT,MSGL_V, gCpuCaps.hasSSE ? "yes.\n" : "no!\n" );
    }

    /* Restore the original signal handlers.
     */
    sigaction( SIGILL, &saved_sigill, NULL );

    /* If we've gotten to here and the XMM CPUID bit is still set, we're
     * safe to go ahead and hook out the SSE code throughout Mesa.
     */
    mp_msg(MSGT_CPUDETECT,MSGL_V, "Tests of OS support for SSE %s\n", gCpuCaps.hasSSE ? "passed." : "failed!" );
#else
    /* We can't use POSIX signal handling to test the availability of
     * SSE, so we disable it by default.
     */
    mp_msg(MSGT_CPUDETECT,MSGL_WARN, "Cannot test OS support for SSE, disabling to be safe.\n" );
    gCpuCaps.hasSSE=0;
#endif /* _POSIX_SOURCE */

mplayer say that _POSIX_SOURCE is not defined; mplayer2 seems to get it.

-EDIT-
I went deeper into this and found that _POSIX_SOURCE is defined in /usr/include/features.h

-EDIT-
Seems not to be a packaging issue but a mainstream one; i used the previous PKGBUILD ewith the current mplayer snapshot and the bug is still there.

I guess that as soon as mplayer2 will get the current changes it will be affected too.

Last edited by kokoko3k (2013-06-07 12:38:17)

skottish · 2013-06-07 16:28:09

I haven't followed Mplayer development for a while and I'm not sure how they're doing things these days, but I know that mplayer2 and mpv are relying on FFmpeg/libav for just about everything. What I'm suggesting is that mplayer2 and mpv may not ever see this problem. If you truly want to stay with Mplayer, I'd file a report upstream. Or at least ask on IRC.

Awebb · 2013-06-07 16:41:05

Now we are sure, that mplayer is old, can we please discuss a little the question, whether ffmpeg or libav is better?

kokoko3k · 2013-06-08 10:50:23

skottish:
as far as i know, mplayer, mplayer2 and mpv all relies on ffmpeg, but provides other implementations you are free to give priority to.
For the record, i prefer mplayer over mplayer2 because mplayer2 broke -af export filter that cannot be used for visualization plugins anymore if you want smooth animations, and mplayer over mpv because mpv changed syntax and output messages so that it is incompatible with my favourite gui/frontends.

awebb:
I really don't know

Last edited by kokoko3k (2013-06-08 10:51:56)

Awebb · 2013-06-08 12:12:24

Sorry, please disregard my previous comment. I was being unnecessarily sarcastic.

skottish · 2013-06-08 18:00:19

I meant to say that mplayer2 and mpv rely on external versions of FFmpeg/libav, but I'm thinking that it probably not really a factor.

Anyway, I'm at a loss. I checked both configure and making the mplayer package on this machine, and everything works properly.

Last edited by skottish (2013-06-08 18:01:44)

kokoko3k · 2013-06-08 21:04:00

Awebb:
i suspected your reply wan't serious, but i answered by following the safe path

skottish:
Thank you for trying by yourself. I forgot to say that the coulprit code i found isn't executed if you are running a 64bit system.
That makes sense because sse is supported in any amd64 system.

Are you on 64bit kernel/userspace?

skottish · 2013-06-08 21:32:30

kokoko3k wrote:

Are you on 64bit kernel/userspace?

Yes.

I do have an Atom based netbook here, but it hasn't been updated (read: turned on) since before the /lib symlink glibc/filesystem move. Hmmm, two updates with big changes to the filesystem package. That sounds like an interesting process. I may just give it a shot. If I don't blow up that computer, which I have very little hope for, I'll let you know what happens with Mplayer...

WonderWoofy · 2013-06-08 21:56:56

I think you will have to use the ARM to get past each recent news item, as I really don't think updating straight to the current state is going to work at all. Somewhere around here that was some kind of a workaround in which libs were called directly from their full path, which in theory would allow you to update straight the the current packages. But I cannot quite find that ATM.

Edit: Of course, right after I posted that I found it! https://bbs.archlinux.org/viewtopic.php … 8#p1282528

Last edited by WonderWoofy (2013-06-08 21:58:15)

skottish · 2013-06-09 01:42:47

Thanks WW. When you posted I had already pulled glibc and filesystem from ARM, and was already installing many packages. The link came in handy in that initramfs was broken. But aside from a few bumps, it wasn't too painful. I'm actually shocked as the glibc/filesystem update hosed my workstation the first time around...

@kokoko3k,

It's no surprise that the version from the repos gives the message that you are seeing before. Interestingly, configure actually finds all of the SSE components. So, I decided to build without --enable-cpu-runtime-detection. This changes nothing. My conclusion? Mplayer's broken.

*** The crowd first gasps, then goes silent ***

There it is.

By the way, it took longer for me to build Mplayer on this system than it did for me to bring the netbook all the way to current state. Yikes!

Last edited by skottish (2013-06-09 01:43:12)

WonderWoofy · 2013-06-09 02:18:27

skottish wrote:

My conclusion? Mplayer's broken.
*** The crowd first gasps, then goes silent ***
There it is.
By the way, it took longer for me to build Mplayer on this system than it did for me to bring the netbook all the way to current state. Yikes!

This is pure comedy in truth right here...

This is why people are trying to recommend to you that you switch to a better maintained modern fork of mplayer. Mplayer is cool, but it is certainly not without its issues and cruft. This is why mplayer2 came about in the first place.

kokoko3k · 2013-06-10 14:18:33

Well, if anybody wants to track:
http://bugzilla.mplayerhq.hu/show_bug.cgi?id=2142

kokoko3k · 2013-06-13 15:19:31

fixed upstream:
http://bugzilla.mplayerhq.hu/show_bug.cgi?id=2142

kokoko3k · 2013-10-30 12:27:15

If somebody cares, i filed a bugreport to arch here:
https://bugs.archlinux.org/task/37553

Arch Linux

#1 2013-05-31 09:28:07

[FIXED] mplayer not using SSE?

#2 2013-06-05 14:07:40

Re: [FIXED] mplayer not using SSE?

#3 2013-06-05 17:55:25

Re: [FIXED] mplayer not using SSE?

#4 2013-06-06 06:07:22

Re: [FIXED] mplayer not using SSE?

#5 2013-06-06 16:28:35

Re: [FIXED] mplayer not using SSE?

#6 2013-06-06 16:45:19

Re: [FIXED] mplayer not using SSE?

#7 2013-06-07 05:56:37

Re: [FIXED] mplayer not using SSE?

#8 2013-06-07 09:03:29

Re: [FIXED] mplayer not using SSE?

#9 2013-06-07 10:55:12

Re: [FIXED] mplayer not using SSE?

#10 2013-06-07 16:28:09

Re: [FIXED] mplayer not using SSE?

#11 2013-06-07 16:41:05

Re: [FIXED] mplayer not using SSE?

#12 2013-06-08 10:50:23

Re: [FIXED] mplayer not using SSE?

#13 2013-06-08 12:12:24

Re: [FIXED] mplayer not using SSE?

#14 2013-06-08 18:00:19

Re: [FIXED] mplayer not using SSE?

#15 2013-06-08 21:04:00

Re: [FIXED] mplayer not using SSE?

#16 2013-06-08 21:32:30

Re: [FIXED] mplayer not using SSE?

#17 2013-06-08 21:56:56

Re: [FIXED] mplayer not using SSE?

#18 2013-06-09 01:42:47

Re: [FIXED] mplayer not using SSE?

#19 2013-06-09 02:18:27

Re: [FIXED] mplayer not using SSE?

#20 2013-06-10 14:18:33

Re: [FIXED] mplayer not using SSE?

#21 2013-06-13 15:19:31

Re: [FIXED] mplayer not using SSE?

#22 2013-10-30 12:27:15

Re: [FIXED] mplayer not using SSE?

Board footer