DSP Robotics Support

//// EDIT : Sorry, i was misleading ! There was a problem with the delay i was using !
//// The true answer will be on the next post where i will upload a corrected file !


I do another topic because it go to confusion what works or not. (sorry also have to test more before to post !)

So i get some problem with my last delay optimization trying to use it in poly white.
Depending on the situation, it's confusing seaming to works when it's not...

But using shufps or array with another's poly code with success, it was not clear what was not working..

So here is more about it.. Not already sure of all but here's a delay that use movaps xmm0,mem[eax];
in poly and is working.
(using this is faster than the other way that need to convert the variable in 80bit then reconvert in32)

That's a little experimental for now so maybe some instruction are not really needed..

The true problem is when we do : Movd eax,xmm7; movaps xmm0,mem[eax]; then shufps to mix back the different read. >> Something detect a relation between the different SSE channels ???

So here i use variable where i store all delay address. Then i write the result in a variable :

Code: Select all

mov eax,r1[0];
movaps xmm0,mem[eax];
movd eax,xmm0;
mov read1[0],eax;
mov eax,r1[1];
movaps xmm0,mem[eax];
shufps xmm0,xmm0,85;
movd eax,xmm0;
mov read1[1],eax;
... .... ...

So first i was thinking that movd was the problem.
But i use it to get back the read..
Shufps seams ok but only if it isolate one sse channel after reading all, not when exchanging some of them or mixing different variable...
Maybe the true problem is to shufps 2 operand that are reading the 4 channel of the array ?

What is also confusing is that if you read an external memin (and maybe even an internal)
using the multiple operand shufps mixing, but not writing on the array it works.
But the same do not if we write on the array..

I have no knowledge at all about ASM.
But be careful with SSE. People seem to assume rather than knowing. For example, while all are talking about "4 channels", do you realize that there are no 4 seperated numbers? Numbers are packed into one 128 bit data packet. The packet as a whole is dealt with, not individual numbers. A packed float is not the same as a scalar float.

https://docs.oracle.com/cd/E26502_01/html/E28388/eojde.html

Interesting, i was not thinking in term of 128bit.

In fact i could only see what's working but it's hard in poly to understand what really happening.
Maybe that's the exception, in poly the array would also be in 128 bit, But it have to initialize only a part of the array when a new voice is done.
Writing to 1/4 of the bit.
But when it see that we write and read, then mix/shufps the different reads, it think that we read, write and use this part of the array for another part of the code (32bit).
So it refuse to initialize the new array part, waiting that the first voice stop ?

But if there's no 2 operand mix shufps it doesn't "think" that we already use this part of the array for parallel 32bit and it could initialize and use.

Maybe that's because we could reactivate a voice just after it end, in this case it would maybe not reinitialize the corresponding part of the array but only use what's already there.


Would like to find a way to convert the data in pack of 16bit !)
Some old digital gear was in 16bit and continue to have reputation of warm sound..

Don't know if there some use for this.
A little more experiment..

Normally in white we could not have one variable for all channel that is not susceptible to reset when a new voice is done.

Even if we use an hop with ecx. The ecx could reset.
(i don't understand how envelope deal with this)

But if we do some shufps it's possible.
Here an example, ecx reset (even with shufps) but a mem or more simply a variable will not reset with shufps 0..
It reset only for the new voice that come after 4 voice.

What become strange is if we use another shufps... The shufps 0 is (0,0,0,0).
With 57 it's (1,2,3,0). With this one with a mem it reset when we do a second note.
But with the var it doesn't reset...

SO VERY SORRY I WAS MISLEADING !!!
Testing poly thing with a problematic delay that in fact was mono...


Also now i discover that even a shufp variable could reset, it's more rare but it happen more when we play 4 notes then release some of them... ..


So the true problem when doing a poly delay and write and read faster (with no 4 write, no 80 bit register) is the index.
With a normal index like in blue, they will be a lot of reset.
I try to use a shared var like in the post before. But it make also some reset even if they are more rare..

Finally the only way (without separate 80 bit register acces) seams to have a blue external index with blue to poly.
It will never reset and if the delay is done right it works fine !)

But will it be better optimised ??
Not really, because the blue to poly have more cost than the delay...
So it could maybe only be if we use a lot of delay all feed by the external index.. (unusual in poly/white..)

Or if i find a way to optimize the blue to poly prim..
(not sure it's possible, but with mem address maybe..)