lists.zerezo.com
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MPlayer-dev-eng] [PATCH] Solaris support for SSE(2) autodetection
- Date: Fri, 26 Sep 2008 00:03:17 +0200
- From: Milan Jurik <milan.jurik@xxxxxxxx>
- Subject: Re: [MPlayer-dev-eng] [PATCH] Solaris support for SSE(2) autodetection
Hi Reimar,
Reimar Döffinger napsal(a):
On Thu, Sep 18, 2008 at 10:08:11AM +0200, Milan Jurik wrote:
V st, 17. 09. 2008 v 23:24, Reimar Döffinger píše:
On Wed, Sep 17, 2008 at 10:30:49PM +0200, Milan Jurik wrote:
I don't understand. The code adds possibility for autodetection of
SSE/SSE2 in runtime-cpudetection for Solaris, when it's requested (as
done for other platforms already). I believe it's purpose of runtime CPU
detection to detect CPU capabilities.
There is already working, perfectly portable code to detect CPU
capabilities. The code you are modifying is for detecting if the
operating system supports SSE/SSE2, after we already _know_ that the
CPU supports them.
I am not even sure there are any Solaris versions at all that do not
support SSE/SSE2, in which case the check would be quite pointless.
Ah, this you meant. Officially SSE/SSE2 are supported from Solaris 9 (it
could be workarounded on S8 probably). Not sure if we can count Solaris
8 as relevant on multimedia desktop today. What do you prefer, automatic
enable for Solaris or uname() version test?
If your method works under Solaris 8, too, I think your first patch is
ok - except that it is a bit much code for what it does, casting ignored
return values away is not MPlayer style (though if you ignore the return
value, you should at least initialize the ui variable).
And e.g.
gCpuCaps.hasSSE = !!(ui & AV_386_SSE)
mp_msg(MSGT_CPUDETECT,MSGL_V, gCpuCaps.hasSSE ? "yes" : "no");
saves some code.
But my question was: currently when we have no special code, we assume the OS
does not support SSE. Would it not be better to assume it does?
And a second question is: could we not use the sigaction method for more
than just Linux, I think it might work on Solaris, too.
It took a bit of time (mainly to find working Solaris 8 x86 box) but I
have 2 different options:
a) sigaction.patch is dirty reuse of Linux signal detection, I could
rewrite it in something cleaner
b) uname.patch is based on uname(2) and disables SSE on Solaris < S9
I tested Solaris 8 x86 and it signals sigill for xorps, as documented by
Sun. So I would prefer the uname.patch as simpler.
As alternative you can enable SSE support by default, of course.
Best regards,
Milan
Index: cpudetect.c
===================================================================
--- cpudetect.c (revision 27666)
+++ cpudetect.c (working copy)
@@ -29,6 +29,10 @@
#include <signal.h>
#endif
+#ifdef __sun
+#include <sys/utsname.h>
+#endif
+
#ifdef WIN32
#include <windows.h>
#endif
@@ -187,7 +191,7 @@
#if defined(__linux__) || defined(__FreeBSD__) || defined(__FreeBSD_kernel__) \
|| defined(__NetBSD__) || defined(__OpenBSD__) || defined(__DragonFly__) \
|| defined(__APPLE__) || defined(__CYGWIN__) || defined(__MINGW32__) \
- || defined(__OS2__)
+ || defined(__OS2__) || defined(__sun)
if (caps->hasSSE)
check_os_katmai_support();
if (!caps->hasSSE)
@@ -363,6 +367,20 @@
#ifdef ARCH_X86_64
gCpuCaps.hasSSE=1;
gCpuCaps.hasSSE2=1;
+#elif defined(__sun)
+ struct utsname solname;
+ long major, minor = 0;
+ char *radix;
+
+ if (uname(&solname) > 0) {
+ major = strtol(solname.release, &radix, 10);
+ if (*radix != '\0')
+ minor = strtol(++radix, NULL, 10);
+ if (!(major >= 5 && minor >= 9))
+ gCpuCaps.hasSSE=0;
+ } else {
+ gCpuCaps.hasSSE=0;
+ }
#elif defined(__FreeBSD__) || defined(__FreeBSD_kernel__) || defined(__DragonFly__) || defined(__APPLE__)
int has_sse=0, ret;
size_t len=sizeof(has_sse);
Index: cpudetect.c
===================================================================
--- cpudetect.c (revision 27666)
+++ cpudetect.c (working copy)
@@ -29,6 +29,11 @@
#include <signal.h>
#endif
+#ifdef __sun
+#include <signal.h>
+#include <ucontext.h>
+#endif
+
#ifdef WIN32
#include <windows.h>
#endif
@@ -187,7 +192,7 @@
#if defined(__linux__) || defined(__FreeBSD__) || defined(__FreeBSD_kernel__) \
|| defined(__NetBSD__) || defined(__OpenBSD__) || defined(__DragonFly__) \
|| defined(__APPLE__) || defined(__CYGWIN__) || defined(__MINGW32__) \
- || defined(__OS2__)
+ || defined(__OS2__) || defined(__sun)
if (caps->hasSSE)
check_os_katmai_support();
if (!caps->hasSSE)
@@ -293,8 +298,12 @@
#undef CPUID_STEPPING
-#if defined(__linux__) && defined(_POSIX_SOURCE) && !defined(ARCH_X86_64)
+#if ((defined(__linux__) && defined(_POSIX_SOURCE)) || defined (__sun)) && !defined(ARCH_X86_64)
+#ifdef __sun
+static void sigill_handler_sse( int signal, siginfo_t *sip, ucontext_t * ucp)
+#else
static void sigill_handler_sse( int signal, struct sigcontext sc )
+#endif
{
mp_msg(MSGT_CPUDETECT,MSGL_V, "SIGILL, " );
@@ -308,11 +317,15 @@
* word will be restored at the end of the test, so we don't need
* to worry about doing it here. Besides, we may not be able to...
*/
+#ifdef __sun
+ ucp->uc_mcontext.gregs[EIP] += 3;
+#else
sc.eip += 3;
+#endif
gCpuCaps.hasSSE=0;
}
-#endif /* __linux__ && _POSIX_SOURCE */
+#endif /* (__linux__ && _POSIX_SOURCE) || __sun */
#ifdef WIN32
LONG CALLBACK win32_sig_handler_sse(EXCEPTION_POINTERS* ep)
@@ -413,15 +426,24 @@
DosUnsetExceptionHandler( &RegRec );
mp_msg(MSGT_CPUDETECT,MSGL_V, gCpuCaps.hasSSE ? "yes.\n" : "no!\n" );
}
-#elif defined(__linux__)
-#if defined(_POSIX_SOURCE)
+#elif defined(__linux__) || defined(__sun)
+#if defined(_POSIX_SOURCE) || defined(__sun)
struct sigaction saved_sigill;
+#ifdef __sun
+ struct sigaction sse_sigill;
+
+ sse_sigill.sa_sigaction = (void (*)(int, siginfo_t*, void*))&sigill_handler_sse;
+ sigemptyset (&sse_sigill.sa_mask);
+ sse_sigill.sa_flags = SA_SIGINFO;
+ sigaction( SIGILL, &sse_sigill, &saved_sigill );
+#else
/* Save the original signal handlers.
*/
sigaction( SIGILL, NULL, &saved_sigill );
signal( SIGILL, (void (*)(int))sigill_handler_sse );
+#endif
/* 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
_______________________________________________
MPlayer-dev-eng mailing list
MPlayer-dev-eng@xxxxxxxxxxxx
https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng