On Sun, Apr 15, 2012 at 8:24 PM, Nick Foster <n...@ettus.com> wrote: > Attached is a patch with one further check -- to make sure the check that > AVX is enabled by the OS, is enabled by the OS. > > No kidding. > > --n
Wonderful, Nick, thanks. Joanna, let us know how this works for you. I'm going to be on the road for the next few days, so I'll be sparsely available. Tom > On Sun, Apr 15, 2012 at 4:09 PM, Nick Foster <n...@ettus.com> wrote: >> >> On Sun, Apr 15, 2012 at 2:26 PM, Joanna Rutkowska >> <joa...@invisiblethingslab.com> wrote: >> <snip> >> >>> Another potential explanations of why this doesn't work I could come up >>> with: >>> >>> 1) Perhaps volk somehow erroneously interprets cpuid info and assumes >>> that AVX is present, while it is no...? Tom, can you point out the >>> specific code in volk that is responsible for deciding whether to use >>> AVX or not? >> >> >> Your CPU has AVX capability, no doubt about it. I agree with Tom that it's >> likely that Xen is disabling AVX support with XSETVB -- I'm not sure why it >> does that. Normal people do not disable extended instruction sets on new >> processors. It's just turning off silicon you paid for, after all. =) >> >> Attached is a patch for Volk which performs the additional step of >> verifying AVX with XGETBV to determine that the OS is not turning off useful >> things. This doesn't fix the fact that Xen is busted, it just won't run AVX >> instructions when the instructions are disabled. >> >> Joanna, please test this patch for me and verify that your Volk machine >> enumerates as sse4_2_64. Thanks! >> >> Tom, the patch is available (based on latest master) at >> github/bistromath:gnuradio.git on the xgetbv branch. >> >> --n > > _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
