Runtime Altivec detection

Runtime Altivec detection

[Nathan Ingersoll]

I've recently been working on some Altivec optimizations for a library,
and was looking for a relatively clean way to perform runtime detection.
I did quite a bit of searching and didn't find any good examples of
someone doing this, other than using the sysctl call on Mac OS X.

I decided to whip up a simple test program based on the assumption that
running Altivec code on a non-Altivec enabled CPU would cause a SIGILL.
Basically, I setjmp a position before an altivec instruction is
performed, and catch the SIGILL, then longjmp back into the main program
>from the signal handler.

This seems to work pretty well, at least in my simplistic test case. Is
anyone aware of some long term problems doing this? some possible side
effects? I've seen other projects catch the SIGILL and exit on it, are
they not attempting to fix up after because they know something I don't?

If this is a reasonable approach, I'm hoping to extend it for generic
feature testing on a variety of processors. I've heard that the process
state is undefined by POSIX after a SIGILL has occurred, does anyone know
of a platform where this could be an issue?

I've posted the code I'm testing at http://ningerso.atmos.org/code/alt.c
If no one points out a serious flaw to the approach, and the idea is useful
feel free to use the code under the BSD+advertising clause license.

Any comments or insights?
Thanks,
Nathan

--
------------------------------------------------------------------------
| Nathan Ingersoll           \\ Computer Systems & Network Coordinator |
| ningerso@ruralcenter.org    \\ http://www.ruralcenter.org            |
| http://ningerso.atmos.org/   \\ Minnesota Center for Rural Health    |
------------------------------------------------------------------------

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Runtime Altivec detection

[Dan Malek]

Nathan Ingersoll wrote:

> I've recently been working on some Altivec optimizations for a library,
> and was looking for a relatively clean way to perform runtime detection.

For some time now the Linux kernel has provided support for emulating
the 'mfspr rd, PVR' instruction in user space.  Do this once, get the
PVR and determine the processor type.

You can also just read /proc/cpuinfo and search for the 'cpu :' line.
It will indicate the processor type and if altivec is supported.

There are probably other ways as well....


	-- Dan


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Runtime Altivec detection

[Nathan Ingersoll]

On Fri, Mar 07, 2003 at 12:24:15PM -0500, Dan Malek wrote:
>
> For some time now the Linux kernel has provided support for emulating
> the 'mfspr rd, PVR' instruction in user space.  Do this once, get the
> PVR and determine the processor type.
>
> You can also just read /proc/cpuinfo and search for the 'cpu :' line.
> It will indicate the processor type and if altivec is supported.
>
> There are probably other ways as well....

Thanks for the info Dan, I'll check into doing it this way. I am still
curious about some of my other questions, such as recovering from a
SIGILL caused by an actual illegal instruction. Anyone willing to chime
in on that?

--
------------------------------------------------------------------------
| Nathan Ingersoll           \\ Computer Systems & Network Coordinator |
| ningerso@ruralcenter.org    \\ http://www.ruralcenter.org            |
| http://ningerso.atmos.org/   \\ Minnesota Center for Rural Health    |
------------------------------------------------------------------------

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Runtime Altivec detection

[Anton Blanchard]

> For some time now the Linux kernel has provided support for emulating
> the 'mfspr rd, PVR' instruction in user space.  Do this once, get the
> PVR and determine the processor type.

That will fail on a ppc64 box since we havent implemented that
emulation.

Anton

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Runtime Altivec detection

[Benjamin Herrenschmidt]

On Fri, 2003-03-07 at 18:24, Dan Malek wrote:
> Nathan Ingersoll wrote:
>
> > I've recently been working on some Altivec optimizations for a library,
> > and was looking for a relatively clean way to perform runtime detection.
>
> For some time now the Linux kernel has provided support for emulating
> the 'mfspr rd, PVR' instruction in user space.  Do this once, get the
> PVR and determine the processor type.
>
> You can also just read /proc/cpuinfo and search for the 'cpu :' line.
> It will indicate the processor type and if altivec is supported.
>
> There are probably other ways as well....

There's a much better way. The kernel passes down CPU features
bits down to userland via ELF AUX tables.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Runtime Altivec detection

[Nathan Ingersoll]

On Fri, Mar 07, 2003 at 06:41:05PM +0100, Benjamin Herrenschmidt wrote:
>
> There's a much better way. The kernel passes down CPU features
> bits down to userland via ELF AUX tables.

Do you know of any reference code for accessing that information?

Thanks,
Nathan

--
------------------------------------------------------------------------
| Nathan Ingersoll           \\ Computer Systems & Network Coordinator |
| ningerso@ruralcenter.org    \\ http://www.ruralcenter.org            |
| http://ningerso.atmos.org/   \\ Minnesota Center for Rural Health    |
------------------------------------------------------------------------

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Runtime Altivec detection

[Magnus Damm]

> There's a much better way. The kernel passes down CPU features
> bits down to userland via ELF AUX tables.

Any pointers where I can find information about that?

/ magnus

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Runtime Altivec detection

[Benjamin Herrenschmidt]

On Fri, 2003-03-07 at 19:55, Magnus Damm wrote:
> > There's a much better way. The kernel passes down CPU features
> > bits down to userland via ELF AUX tables.
>
> Any pointers where I can find information about that?

Well... I know how the kernel pass them down to glibc, but
I don't know how a userland app can retreive them :)

The actual bitmask is defined in kernel's include/asm/cputable.h,
there are 2 sets of feature bits, one for kernel internal usage
and one passed down to userland.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Runtime Altivec detection

[Hollis Blanchard]

On Friday 07 March 2003 12:55 pm, Magnus Damm wrote:
> > There's a much better way. The kernel passes down CPU features
> > bits down to userland via ELF AUX tables.
>
> Any pointers where I can find information about that?

I played with this once, though I don't remember the outcome (it was a long
time ago). The ELF AUX table is passed as another argument to main(). I think
there may have been another one in between:
	int main(int argc, char *argv[], int something, struct elf_aux_table *table);
Then you can parse table as you like.

This was from information in the SysVR4 ABI PPC addendum, a link to which can
be found at http://penguinppc.org/dev/library/ .

-Hollis
--
IBM Linux Technology Center

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Runtime Altivec detection

[Magnus Damm]

mplayer and ffmpeg does some kind of detection runtime.
I'm playing with it right now actually.

While at it:

I've seen that -maltivec and -mabi=altivec is passed sometimes.
If I want to build a binary that should be able to run on a
G3 without altivec and utilize altivec when present on a G4,
what flags should I use?

/ magnus

On Fri, 7 Mar 2003 10:47:53 -0600
Nathan Ingersoll <ningerso@ruralcenter.org> wrote:

>
> I've recently been working on some Altivec optimizations for a library,
> and was looking for a relatively clean way to perform runtime detection.
> I did quite a bit of searching and didn't find any good examples of
> someone doing this, other than using the sysctl call on Mac OS X.
>
> I decided to whip up a simple test program based on the assumption that
> running Altivec code on a non-Altivec enabled CPU would cause a SIGILL.
> Basically, I setjmp a position before an altivec instruction is
> performed, and catch the SIGILL, then longjmp back into the main program
> >from the signal handler.
>
> This seems to work pretty well, at least in my simplistic test case. Is
> anyone aware of some long term problems doing this? some possible side
> effects? I've seen other projects catch the SIGILL and exit on it, are
> they not attempting to fix up after because they know something I don't?
>
> If this is a reasonable approach, I'm hoping to extend it for generic
> feature testing on a variety of processors. I've heard that the process
> state is undefined by POSIX after a SIGILL has occurred, does anyone know
> of a platform where this could be an issue?
>
> I've posted the code I'm testing at http://ningerso.atmos.org/code/alt.c
> If no one points out a serious flaw to the approach, and the idea is useful
> feel free to use the code under the BSD+advertising clause license.
>
> Any comments or insights?
> Thanks,
> Nathan
>
> --
> ------------------------------------------------------------------------
> | Nathan Ingersoll           \\ Computer Systems & Network Coordinator |
> | ningerso@ruralcenter.org    \\ http://www.ruralcenter.org            |
> | http://ningerso.atmos.org/   \\ Minnesota Center for Rural Health    |
> ------------------------------------------------------------------------
>
>

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Runtime Altivec detection

[Nathan Ingersoll]

On Fri, Mar 07, 2003 at 06:54:58PM +0000, Magnus Damm wrote:
> mplayer and ffmpeg does some kind of detection runtime.
> I'm playing with it right now actually.

Last I heard, it was a compile time detection or flag. So you had to build
separate binaries for your G4 and non-G4 machines.

> While at it:
>
> I've seen that -maltivec and -mabi=altivec is passed sometimes.
> If I want to build a binary that should be able to run on a
> G3 without altivec and utilize altivec when present on a G4,
> what flags should I use?

There is no specific flag for doing so, you need some code to detect the
capability, and then decide whether to use the Altivec routine.

--
------------------------------------------------------------------------
| Nathan Ingersoll           \\ Computer Systems & Network Coordinator |
| ningerso@ruralcenter.org    \\ http://www.ruralcenter.org            |
| http://ningerso.atmos.org/   \\ Minnesota Center for Rural Health    |
------------------------------------------------------------------------

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Runtime Altivec detection

[Magnus Damm]

On Fri, 7 Mar 2003 12:08:02 -0600
Nathan Ingersoll <ningerso@ruralcenter.org> wrote:
> > mplayer and ffmpeg does some kind of detection runtime.
> > I'm playing with it right now actually.
>
> Last I heard, it was a compile time detection or flag. So you had to build
> separate binaries for your G4 and non-G4 machines.

The latest released mplayer requires you to pass --enable-altivec to configure.
A runtime check is then performed in:
mplayer/cpudetect.c and ffmpeg/libavcodec/ppc/dsputil_altivec.c

> > I've seen that -maltivec and -mabi=altivec is passed sometimes.
> > If I want to build a binary that should be able to run on a
> > G3 without altivec and utilize altivec when present on a G4,
> > what flags should I use?
>
> There is no specific flag for doing so, you need some code to detect the
> capability, and then decide whether to use the Altivec routine.

Sorry, I think I was a little bit unclear in my question,
Do you have to pass any specific flags to gcc to be able to complile
altivec code, and if these flags are "-maltivec -mabi=altivec", is
it possible to pass them to gcc and still compile for G3 (-mcpu=750)?

It's a nice feature to be able to build one binary that is optimized
for G3 but does runtime checks and enables altivec if present.

/ magnus

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Runtime Altivec detection

[Nathan Ingersoll]

On Fri, Mar 07, 2003 at 07:44:45PM +0000, Magnus Damm wrote:
>
> The latest released mplayer requires you to pass --enable-altivec to
> configure. A runtime check is then performed in: mplayer/cpudetect.c
> and ffmpeg/libavcodec/ppc/dsputil_altivec.c

Ok, that's pretty funny actually. Now that I've looked at that code, it
appears they use the same method I do. Slightly different code, but they
are writing it for an app, not a library. Strange that I wasn't able to
find this at all through google.

> Sorry, I think I was a little bit unclear in my question, Do you have
> to pass any specific flags to gcc to be able to complile altivec code,
> and if these flags are "-maltivec -mabi=altivec", is it possible to
> pass them to gcc and still compile for G3 (-mcpu=750)?
>
> It's a nice feature to be able to build one binary that is optimized
> for G3 but does runtime checks and enables altivec if present.

Those are probably incompatible flags, since you are telling it to
target a specific cpu, but also telling it to use features not present
in that cpu model.

--
------------------------------------------------------------------------
| Nathan Ingersoll           \\ Computer Systems & Network Coordinator |
| ningerso@ruralcenter.org    \\ http://www.ruralcenter.org            |
| http://ningerso.atmos.org/   \\ Minnesota Center for Rural Health    |
------------------------------------------------------------------------

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Runtime Altivec detection

[Bill Fink]

Hi Nathan,

> On Fri, 7 Mar 2003, Nathan Ingersoll wrote:
>
> On Fri, Mar 07, 2003 at 06:54:58PM +0000, Magnus Damm wrote:
> > mplayer and ffmpeg does some kind of detection runtime.
> > I'm playing with it right now actually.
>
> Last I heard, it was a compile time detection or flag. So you had to build
> separate binaries for your G4 and non-G4 machines.
>
> > While at it:
> >
> > I've seen that -maltivec and -mabi=altivec is passed sometimes.
> > If I want to build a binary that should be able to run on a
> > G3 without altivec and utilize altivec when present on a G4,
> > what flags should I use?
>
> There is no specific flag for doing so, you need some code to detect the
> capability, and then decide whether to use the Altivec routine.

Here is the code xine uses to do run time Altivec detection
(from xine-utils/cpu_accel.c):

#if defined (ARCH_PPC) && defined (ENABLE_ALTIVEC)
static sigjmp_buf jmpbuf;
static volatile sig_atomic_t canjump = 0;

static void sigill_handler (int sig)
{
    if (!canjump) {
        signal (sig, SIG_DFL);
        raise (sig);
    }

    canjump = 0;
    siglongjmp (jmpbuf, 1);
}

static uint32_t arch_accel (void)
{
    signal (SIGILL, sigill_handler);
    if (sigsetjmp (jmpbuf, 1)) {
        signal (SIGILL, SIG_DFL);
        return 0;
    }

    canjump = 1;

    __asm__ volatile ("mtspr 256, %0\n\t"
                  "vand %%v0, %%v0, %%v0"
                  :
                  : "r" (-1));

    signal (SIGILL, SIG_DFL);
    return MM_ACCEL_PPC_ALTIVEC;
}
#endif /* ARCH_PPC */

And here's the gcc command used to compile cpu_accel.c:

gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../.. -I../../include -I../../include -I../../src -I../../src/xine-engine -I../../src/xine-engine -I../../src/xine-utils -I/usr/X11R6/include -std=gnu89 -Wall -D_REENTRANT -D_FILE_OFFSET_BITS=64 -DXINE_COMPILE -O3 -pipe -fomit-frame-pointer -fexpensive-optimizations -fschedule-insns2 -fno-strict-aliasing -ffast-math -funroll-loops -funroll-all-loops -finline-functions -Wa,-m7400 -I/usr/include/kde/artsc -c cpu_accel.c -Wp,-MD,.deps/cpu_accel.TPlo  -fPIC -DPIC -o cpu_accel.lo

						-Bill

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Runtime Altivec detection

[Hollis Blanchard]

On Friday 07 March 2003 08:02 pm, Bill Fink wrote:
>
> Here is the code xine uses to do run time Altivec detection
> (from xine-utils/cpu_accel.c):
>
> #if defined (ARCH_PPC) && defined (ENABLE_ALTIVEC)
> static sigjmp_buf jmpbuf;
> static volatile sig_atomic_t canjump = 0;
>
> static void sigill_handler (int sig)
[snip]

Compared to testing the CPU feature bits supplied by the kernel (for a long
time now; Ben could tell you exactly how long) this method seems *extremely*
messy. Please see my other posts (and Ben's) in this thread for details.

-Hollis
--
IBM Linux Technology Center

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Runtime Altivec detection

[Bill Fink]

Hi Hollis,

On Fri, 7 Mar 2003, Hollis Blanchard wrote:

> On Friday 07 March 2003 08:02 pm, Bill Fink wrote:
> >
> > Here is the code xine uses to do run time Altivec detection
> > (from xine-utils/cpu_accel.c):
> >
> > #if defined (ARCH_PPC) && defined (ENABLE_ALTIVEC)
> > static sigjmp_buf jmpbuf;
> > static volatile sig_atomic_t canjump = 0;
> >
> > static void sigill_handler (int sig)
> [snip]
>
> Compared to testing the CPU feature bits supplied by the kernel (for a long
> time now; Ben could tell you exactly how long) this method seems *extremely*
> messy. Please see my other posts (and Ben's) in this thread for details.

OK, here's a sample program that uses the auxiliary vector table to
get the user visible CPU features.

--------------------------------------------------------------------------------
#include <stdio.h>
#include <linux/elf.h>

typedef struct {
	int	a_type;
	union {
		long	a_val;
		void	*a_ptr;
		void	(*a_fcn)();
	} a_un;
} auxv_t;

main(int argc, char *argv[], char *env[], auxv_t aux_table[])
{
	int has_altivec = 0;

	while (aux_table[0].a_type != AT_NULL) {
		fprintf(stdout, "a_type = %2d", aux_table[0].a_type);
		fprintf(stdout, " a_val = 0x%X\n", aux_table[0].a_un.a_val);
		if ((aux_table[0].a_type == AT_HWCAP) &&
		    (aux_table[0].a_un.a_val & PPC_FEATURE_HAS_ALTIVEC))
			has_altivec++;
		aux_table++;
	}

	fprintf(stdout, "CPU %s have Altivec\n",
			has_altivec ? "does" : "doesn't");
	exit(0);
}
--------------------------------------------------------------------------------

And it seems to work.  Here's a run on my home dual 500 MHz G4:

a_type = 22 a_val = 0x16
a_type = 22 a_val = 0x16
a_type = 19 a_val = 0x20
a_type = 20 a_val = 0x20
a_type = 21 a_val = 0x0
a_type = 16 a_val = 0x9C000000
a_type =  6 a_val = 0x1000
a_type = 17 a_val = 0x64
a_type =  3 a_val = 0x10000034
a_type =  4 a_val = 0x20
a_type =  5 a_val = 0x6
a_type =  7 a_val = 0x30000000
a_type =  8 a_val = 0x0
a_type =  9 a_val = 0x10000350
a_type = 11 a_val = 0x130
a_type = 12 a_val = 0x130
a_type = 13 a_val = 0xA
a_type = 14 a_val = 0xA
CPU does have Altivec

a_type = 16 (AT_HWCAP) holds the "arch dependent hints at CPU capabilities".
Here are the CPU features as defined by asm/cputable.h:

#define PPC_FEATURE_32                  0x80000000
#define PPC_FEATURE_64                  0x40000000
#define PPC_FEATURE_601_INSTR           0x20000000
#define PPC_FEATURE_HAS_ALTIVEC         0x10000000
#define PPC_FEATURE_HAS_FPU             0x08000000
#define PPC_FEATURE_HAS_MMU             0x04000000
#define PPC_FEATURE_HAS_4xxMAC          0x02000000
#define PPC_FEATURE_UNIFIED_CACHE       0x01000000

So for my home dual 500 MHz G4, 0x9C000000 translates to the following
features:

	32, HAS_ALTIVEC, HAS_FPU, HAS_MMU

That seems to be a good sanity check on the code.

I then did a run on a 300 MHz G3:

a_type = 22 a_val = 0x16
a_type = 22 a_val = 0x16
a_type = 19 a_val = 0x20
a_type = 20 a_val = 0x20
a_type = 21 a_val = 0x0
a_type = 16 a_val = 0x8C000000
a_type =  6 a_val = 0x1000
a_type = 17 a_val = 0x64
a_type =  3 a_val = 0x10000034
a_type =  4 a_val = 0x20
a_type =  5 a_val = 0x6
a_type =  7 a_val = 0x30000000
a_type =  8 a_val = 0x0
a_type =  9 a_val = 0x1000039C
a_type = 11 a_val = 0x130
a_type = 12 a_val = 0x130
a_type = 13 a_val = 0xA
a_type = 14 a_val = 0xA
CPU doesn't have Altivec

One thing I'm not sure about is if the auxv_t typedef needs to be
different for PPC64.

There's also a practical consideration.  For example, in the xine case,
the test for Altivec support is done in the xine library package, whereas
the main() program is in a separate package, namely the xine UI, of which
there are actually several available UIs.  Now if there was a getaux
function similar to the getenv function, this would make matters a lot
simpler.

So while the current xine code may be somewhat ugly, it does work and
is pretty easy to implement within a library.

						-Bill

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Runtime Altivec detection

[Nathan Ingersoll]

On Sat, Mar 08, 2003 at 03:04:40AM -0500, Bill Fink wrote:
>
> There's also a practical consideration.  For example, in the xine case,
> the test for Altivec support is done in the xine library package, whereas
> the main() program is in a separate package, namely the xine UI, of which
> there are actually several available UIs.  Now if there was a getaux
> function similar to the getenv function, this would make matters a lot
> simpler.
>
> So while the current xine code may be somewhat ugly, it does work and
> is pretty easy to implement within a library.

One issue I saw with the xine code, is if it's in a library, you may want
to use sigaction to save the previous handler, since the app may set it's
own signal handler.

While somewhat ugly, it should be relatively OS independant, and it
could also be used in a callback type fashion for testing instruction
availability on a variety of platforms. The code I linked to in my
original post is an example of this. It could be called with
cpu_detect(mmx_test); on x86, cpu_detect(altivec_test); on ppc, or
cpu_detect(vis_test) on sparc, etc.

Thanks for all the ideas folks, looks like I'll have to consider the
different approaches, or use a combination.

--
------------------------------------------------------------------------
| Nathan Ingersoll           \\ Computer Systems & Network Coordinator |
| ningerso@ruralcenter.org    \\ http://www.ruralcenter.org            |
| http://ningerso.atmos.org/   \\ Minnesota Center for Rural Health    |
------------------------------------------------------------------------

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Runtime Altivec detection

[Albert Cahalan]

For those of you needing to get at ELF note info
to determine CPU features and other things, here
is the code procps-3.1.x has been using. You'll
need the appropriate ID code; here I use AT_CLKTCK
to determine USER_HZ. Pass the ID code into this
function, and you get back the ELF note value.

//////////////////////////////////////////////////////////////////////////
#ifndef AT_CLKTCK
#define AT_CLKTCK       17    // frequency of times()
#endif

#define ERROR_CODE 42  // choose something better!

extern char** environ;

// for ELF executables, notes are pushed before environment and args
static unsigned long find_elf_note(unsigned long findme){
  unsigned long *ep = (unsigned long *)environ;
  while(*ep++);
  while(*ep){
    if(ep[0]==findme) return ep[1];
    ep+=2;
  }
  return ERROR_CODE;
}

// Usage:
// Hertz = find_elf_note(AT_CLKTCK);

////////////////////////////////////////////////////////////////////////


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/