similar to: [PATCH] SSE Assmebly for Win32

Hi Folks, Attached is a patch against the latest svn, plus new source files. This patch allows the specification of c or assembler versions of various functions at run time if _USE_SSE or _USE_ALTIVEC is specified at compile time. The basic concept is to use function pointers and preprocessor trickery to allow for run-time without changing how the other platforms work, esp. the platform function

Hi, Thanks for the patch. I think it's a good idea, although I can't apply it as is. The reason is that in its current form, the SSE version is not tested enough and isn't very clean in some aspects. For example, the order 10 filter is hard-coded and patched to work also for order 8 (less efficiently). Also, I think this should really go into 1.1.x (to become 1.2). I have already

Hi Jean Marc, I think there is just a confusion over terminology going on here- I agree that support for 3dnow base version may not necessarily be relevant; However, even though 3dNow extended is a bastardized version of SSE, it still supports the same instructions, and that is what is important- I don't think we intend to add any AMD specfic code. The real issue is cross CPU SSE support,

Jean-Marc, There is a big difference between SSE and SSEFP. The SSEFP means that the CPU supports the xmm registers. All Intel chips with SSE support do, however no current 32 bit AMD chips support the XMM registers. They will support the SSE instructions but not those registers. You are right about the SSE2 not being used. The AMD Opterons are the first AMD CPU's which support

Can you do another release of the unstable branch that has everything merged in? The run-time flags for SSE / ASM and your new intrinsics. If you have all the sections written, we will happily test them on windows QA machines. Is there anything in particular that you are looking for in testing? Or just that it works? Aron Rosenberg SightSpeed <p>At 01:17 PM 1/18/2004 -0500, you wrote:

Actually, I prefer having the user explicitly specify --enable-sse because you might want to compile for other machines than what you have. Also, any idea what happens if the user already has CFLAGS=-O2 defined (and you add -O3)? Last thing, how do you check whether gcc accepts -msse? Jean-Marc Le ven 02/04/2004 à 00:40, Aron Rosenberg a écrit : > Here is code to add to configure.in

Jean-Marc, Are you sure that you don't need to add just -msse to enable the intrinsics rather than a full fledged -march=pentium3? I did some playing around and I can get intrinsics code to compile with -march=i686 -msse on linux with that. Check out:

Jean-Marc, Good catch on the debug mode. After compiling the same code in release mode it does appear to be using all the registers correctly. Give us a few days to integrate our run-time flags into 1.1.4 and I will let you know how are testing turns out. Aron Rosenberg SightSpeed At 08:54 PM 1/21/2004, you wrote: > > 1. Compile Error with regular mode (FIXED_POINT undefined)

All, Attached is a patch that does two things. First it makes the use of the current SSE code a run time option through the use of speex_decoder_ctl() and speex_encoder_ctl It does this twofold. First there is a modification to the configure.in script which introduces a check based upon platform. It will compile in the sse assembly if you are on an i?86 based platform by making a

Jean-Marc, >I'm still not sure I get it. On an Athlon XP, I can do something like >"mulps xmm0, xmm1", which means that the xmm registers are indeed >supported. Besides, without the xmm registers, you can't use much of >SSE. In the Atholon XP 2400+ that we have in our QA lab (Win2000 ) if you run that code it generates an Illegal Instruction Error. In addition,

Here is code to add to configure.in to do what you want. It preserves CFLAGS and uses that var to hold the sse enable flags. You can subset this under the exisiting AC_ARG for sse or just make it do it all the time. If you notice the i?86, that means any x86 platform target will have it enabled. You can change that i686, but keep in mind that some distros compile/target for i386 on the glibc

So we ran the code on a Windows XP based Atholon XP system and the xmm registers work just fine so it appears that Windows 2000 and below does not support them. We agree on not supporting the non-FP version, however the run time flags need to be settable with a non FP SSE mode so that exceptions are avoided. I thus propose a set of defines like this instead of the ones in our initial patch:

Hi Jean Marc and List, So I have started finally fiddling around with Ultra-wideband mode. It appears to be very similar in operation to Wide mode, except that when peering into the packet structure it looks like (and these are kind of questions as much as statements here): 1. update rate 0 is not used in UWB- only 1-4? 2. The total bits used for each UWB update rate seem to be as follows:

re: At 03:22 PM 10/25/2005, Jean-Marc Valin wrote: >Are you really sure you didn't have some corruption elsewhere? Totally possible- this is the first time this has happened that I know of in many many hours of usage- On the other hand, this null check isn't in my code base and it was in nb_decode_lost, and nb_encode- so I figured it was just an oversight- Tom

Not a big deal, but the "<http://xiph.org/svn.html>Subversion Access" link on http://www.speex.org/download.html page should probably point to: http://www.xiph.org/svn/ rather than: http://xiph.org/svn.html Tom ______________________________________________ Tom Harper Lead Software Engineer SightSpeed - <http://www.sightspeed.com/>http://www.sightspeed.com/ 918 Parker

Jean Marc, I ran across the silence issue that results from the echo canceller producing "bad" floating point data. Unfortunately this hasn't been done in a way i can reproduce, but I found that calling reset didn't fix the silence, unless I also reset: st->PHI[i] st->Eh[i] st->Yh[i] So it may be good to add these to the reset function. I was using these in

That's definitely strange and I've never encountered that. Normally, the only way for _mm_load_ups to generate a segfault is for the input to be invalid memory, in which case the C version should crash too. I suspect the compiler (or something else) may be hiding the real problem. Can you get a debugger and see exactly what assembly statement is causing the crash and what the operands are?

Congrats Jean Marc, Just heard you got a new google assistant for the Ghost project! Tom ______________________________________________ Tom Harper Lead Software Engineer SightSpeed - <http://www.sightspeed.com/>http://www.sightspeed.com/ 918 Parker St, Suite A14 Berkeley, CA 94710 Email: tharper@sightspeed.com Phone: 510-665-2920 Fax: 510-649-9569 My SightSpeed Video Link:

Jean-Marc, So I saw in the latest code that the vad in the preprocessor is gone/going to be re-written. Is there a plan as far as this goes? Just wondering as the current one seems to work pretty well. Thanks! Tom ______________________________________________ Tom Harper Lead Software Engineer SightSpeed - <http://www.sightspeed.com/>http://www.sightspeed.com/ 918 Parker St, Suite A14

Jean Marc, So the C99 array syntax is breaking some lesser compilers- is there a known max size for bark[]? Fiddling with latest svn again... Thanks! Tom ______________________________________________ Tom Harper Lead Software Engineer SightSpeed - <http://www.sightspeed.com/>http://www.sightspeed.com/ 918 Parker St, Suite A14 Berkeley, CA 94710 Email: tharper@sightspeed.com Phone: