Exciting news, RE's can now be as heavily optimised as vst and use streaming simd instructions
-
- Posts: 1284
- Joined: 16 Jan 2015
Kvr link:
viewtopic.php
i honestly just about wet myself reading this. So the 2.1 SDK is a huge improvement and I guess in beta means it will be out soon.
disco dsp couldn't port their stuff thus far due to optimisation issues (George has said this himself, I am not just making it up or anything), so hopefully this means we will see discovery pro/corona at some stage now.
Finally!!!.. this will be a complete game changer if the info is correct..
Just add some pdc in there too props, and I might just be in heaven. Oh, and a working authoriser.
viewtopic.php
i honestly just about wet myself reading this. So the 2.1 SDK is a huge improvement and I guess in beta means it will be out soon.
disco dsp couldn't port their stuff thus far due to optimisation issues (George has said this himself, I am not just making it up or anything), so hopefully this means we will see discovery pro/corona at some stage now.
Finally!!!.. this will be a complete game changer if the info is correct..
Just add some pdc in there too props, and I might just be in heaven. Oh, and a working authoriser.
Mac Studio M2 Ultra/64Gb/Apollo T-Bolt 3/OS 14.6.1/PT 2024.6/R13.02/Logic 11.01
MSI GT77/13980HX/RTX 4090m/64GB/Arturia Minifuse 2/PT 2024.6/R13.02/Low DPC latency tuned
MSI GT77/13980HX/RTX 4090m/64GB/Arturia Minifuse 2/PT 2024.6/R13.02/Low DPC latency tuned
-
- Posts: 328
- Joined: 18 Jan 2015
I hope that devs update their existing RE with the new optimizations, though I doubt many will actually do it.
IMHO, RE tech is still worse than "old crappy tech" (Ernest trashing AAX, AU, RTAS & VST)
IMHO, RE tech is still worse than "old crappy tech" (Ernest trashing AAX, AU, RTAS & VST)
-
- Posts: 3431
- Joined: 16 Jan 2015
SIMD instructions only work with 32bit values and most audio developers use 64bit internally so this will only help for a handful of algorithms (e.g. U-He's offerings). For normal code, the compiler already uses SIMD instructions if the code can be translated to these. I am happy though that the Props found a platform-independent way to add vectoring support so that this bit of RE criticism can be laid to rest.
-
- Posts: 1284
- Joined: 16 Jan 2015
Ok thanks for further clarification.. Interesting and just as I suspected that it was probably improved in tandem with U-HEnormen wrote:SIMD instructions only work with 32bit values and most audio developers use 64bit internally so this will only help for a handful of algorithms (e.g. U-He's offerings). For normal code, the compiler already uses SIMD instructions if the code can be translated to these. I am happy though that the Props found a platform-independent way to add vectoring support so that this bit of RE criticism can be laid to rest.
By the way, do SIMD only work for 32 bit instructions in RE, or do you mean even in vst?
Mac Studio M2 Ultra/64Gb/Apollo T-Bolt 3/OS 14.6.1/PT 2024.6/R13.02/Logic 11.01
MSI GT77/13980HX/RTX 4090m/64GB/Arturia Minifuse 2/PT 2024.6/R13.02/Low DPC latency tuned
MSI GT77/13980HX/RTX 4090m/64GB/Arturia Minifuse 2/PT 2024.6/R13.02/Low DPC latency tuned
-
- Posts: 3431
- Joined: 16 Jan 2015
SSE etc. basically just allow you to do computations with tuples containing 4 values at once, so you can use quaternions and vectors and do computations with these directly in one CPU cycle instead of computing the single values in the tuples in 4 (or more) cycles. These tuples have a width of 128bit in the hardware, meaning 32bit for each single value. So yes, this is a general limitation of SSE, MMX, Altivec etc. Back when the G4/G5 came out the eMagic developers have been asked why the new CPUs don't boost their DSP code performance to the levels expected from the marketing hype. Their answer was exactly this, they do computations in 64bit and they don't translate well to these instruction sets.Theo.M wrote:Ok thanks for further clarification.. Interesting and just as I suspected that it was probably improved in tandem with U-HE
By the way, do SIMD only work for 32 bit instructions in RE, or do you mean even in vst?
So this means that a) you need to have your algorithms based on vectors / quaternions or in general tuples and b) you can only process 32bit values for the single numbers in the tuples when you want to use SIMD instructions directly. Anyway, if a modern compiler sees a chance to process your (even non-vectorized) 32bit computations with a SIMD instruction it will take your (normal, non-optimized) code and convert it to SIMD machine code, this is already true for current REs which are compiled by llvm.
Urs from U-He called the 64bit processing "64bit bullshittery" and said he was "proud to say that their offerings process at 32bit" because they use "modern algorithms that don't cause issues at 32bit precision". He's certainly a way better programmer and mathematician than I am so I tend to believe him. Still theres few others that I heard this from and most audio developers still underline the fact that their algorithms work at 64bit precision.
-
- Posts: 1456
- Joined: 15 Jan 2015
Great news! Hopefully this will mean some activity from U-he and friends again.
Sarah Mancuso
My music: Future Human
My music: Future Human
-
- Competition Winner
- Posts: 4076
- Joined: 16 Jan 2015
Well he had many requests, including access to static data. Adding access to static data has a problem in that it puts limitations on the Rack Extension system as a whole.esselfortium wrote:Great news! Hopefully this will mean some activity from U-he and friends again.
So you never know, there may be a bit of a stalemate.
-
- Posts: 1284
- Joined: 16 Jan 2015
esselfortium wrote:Great news! Hopefully this will mean some activity from U-he and friends again.
Let's think nice and positive. And whilst we are thinking positive, let's think that awesome scripted IDT stuff is on it's way tooavasopht wrote:
Well he had many requests, including access to static data. Adding access to static data has a problem in that it puts limitations on the Rack Extension system as a whole.
So you never know, there may be a bit of a stalemate.
Mac Studio M2 Ultra/64Gb/Apollo T-Bolt 3/OS 14.6.1/PT 2024.6/R13.02/Logic 11.01
MSI GT77/13980HX/RTX 4090m/64GB/Arturia Minifuse 2/PT 2024.6/R13.02/Low DPC latency tuned
MSI GT77/13980HX/RTX 4090m/64GB/Arturia Minifuse 2/PT 2024.6/R13.02/Low DPC latency tuned
-
- Moderator
- Posts: 11323
- Joined: 15 Jan 2015
-
- Competition Winner
- Posts: 4076
- Joined: 16 Jan 2015
Hey you know me. I'm all positive with a hint of cautionTheo.M wrote:
Let's think nice and positive. And whilst we are thinking positive, let's think that awesome scripted IDT stuff is on it's way too
There are a deluge of open sourced vectorised algorithms that can benefit from this.
-
- Moderator
- Posts: 1402
- Joined: 15 Jan 2015
Do that many developers really write their DSP routines to use 64-bit math? That's incredibly wasteful, even without Uhe's saying so, all the audio handling code I write has used 32-bit floats, instead of needlessly promoting it to 64-bit.
Also SSE2 and later can do vector processing on double precision (64-bit) values. The 128-bit registers can hold four 32-bit values, or two 64-bit. So it can only crunch two values per iteration, instead of four, but the fetching of the values from RAM still uses the SSE pathways, so there are still quite a few gains to be had.
For those of you following along. SIMD (Single Instruction, Multiple Data) instructions in modern CPUs allow one instruction to process more than one value. Before this if you wanted to process four 32-bit values, you'd write a loop and run through it four times. So not only was the CPU doing four floating point calculations, but it was also keeping track of where it was in the loop, and fetching the values to be worked on, with each time through the loop. SIMD allows multiple values to be pre-loaded before the calculation starts, reducing the number of times the CPU has to stop to wait for data to load, and does its calculation on them all at the same time. Also because of requirements places on the programmer, when using SIMD instructions the values have to be aligned on special bounders in RAM. Because of this requirement, the CPU can make additional optimizations when doing the fetching that saves a lot of time too. (Non-SIMD instructions can perform better with aligned data, but checks have to be done to make sure it is aligned, because there's no requirement for it to be.)
Also SSE2 and later can do vector processing on double precision (64-bit) values. The 128-bit registers can hold four 32-bit values, or two 64-bit. So it can only crunch two values per iteration, instead of four, but the fetching of the values from RAM still uses the SSE pathways, so there are still quite a few gains to be had.
For those of you following along. SIMD (Single Instruction, Multiple Data) instructions in modern CPUs allow one instruction to process more than one value. Before this if you wanted to process four 32-bit values, you'd write a loop and run through it four times. So not only was the CPU doing four floating point calculations, but it was also keeping track of where it was in the loop, and fetching the values to be worked on, with each time through the loop. SIMD allows multiple values to be pre-loaded before the calculation starts, reducing the number of times the CPU has to stop to wait for data to load, and does its calculation on them all at the same time. Also because of requirements places on the programmer, when using SIMD instructions the values have to be aligned on special bounders in RAM. Because of this requirement, the CPU can make additional optimizations when doing the fetching that saves a lot of time too. (Non-SIMD instructions can perform better with aligned data, but checks have to be done to make sure it is aligned, because there's no requirement for it to be.)
-
- Posts: 1553
- Joined: 16 Jan 2015
Whatever those quaternions, leptons and bosons do, I'll have some of 'm.
-
- Competition Winner
- Posts: 4076
- Joined: 16 Jan 2015
Some filter designs are unstable with 32-bit precision.ScuzzyEye wrote:Do that many developers really write their DSP routines to use 64-bit math? That's incredibly wasteful, even without Uhe's saying so, all the audio handling code I write has used 32-bit floats, instead of needlessly promoting it to 64-bit.
Also SSE2 and later can do vector processing on double precision (64-bit) values. The 128-bit registers can hold four 32-bit values, or two 64-bit. So it can only crunch two values per iteration, instead of four, but the fetching of the values from RAM still uses the SSE pathways, so there are still quite a few gains to be had.
For those of you following along. SIMD (Single Instruction, Multiple Data) instructions in modern CPUs allow one instruction to process more than one value. Before this if you wanted to process four 32-bit values, you'd write a loop and run through it four times. So not only was the CPU doing four floating point calculations, but it was also keeping track of where it was in the loop, and fetching the values to be worked on, with each time through the loop. SIMD allows multiple values to be pre-loaded before the calculation starts, reducing the number of times the CPU has to stop to wait for data to load, and does its calculation on them all at the same time. Also because of requirements places on the programmer, when using SIMD instructions the values have to be aligned on special bounders in RAM. Because of this requirement, the CPU can make additional optimizations when doing the fetching that saves a lot of time too. (Non-SIMD instructions can perform better with aligned data, but checks have to be done to make sure it is aligned, because there's no requirement for it to be.)
-
- Posts: 65
- Joined: 16 Jan 2015
Anytime UHE Satin is brought up, I can help but to think of this video. Mostly because the first time I saw Satin I misread it Satan.
https://www.youtube.com/watch?v=liSseCH6_p8
https://www.youtube.com/watch?v=liSseCH6_p8
"As I stare into the digital abyss, I will remember when the world was real."
-
- Moderator
- Posts: 1402
- Joined: 15 Jan 2015
True, if you take code that's using doubles, and just change them to floats, you can break the filter. But it is also possible to make a few other small changes to keep the errors due to the loss of precision from piling up.avasopht wrote:Some filter designs are unstable with 32-bit precision.
-
- Posts: 3431
- Joined: 16 Jan 2015
avasopht wrote:Some filter designs are unstable with 32-bit precision.
The thing is mainly transients during processing, yeah. While 32bit is way enough in terms of headroom and noise floor, when you do processing (especially physical/analog modeling) the values you get in between might get very small / big and thus start to scratch the resolution boundaries of 32bit.ScuzzyEye wrote: True, if you take code that's using doubles, and just change them to floats, you can break the filter. But it is also possible to make a few other small changes to keep the errors due to the loss of precision from piling up.
-
- RE Developer
- Posts: 59
- Joined: 22 Jan 2015
For stereo processing SSE2 is very useful, and whenever high numerical precision is required.ScuzzyEye wrote:Do that many developers really write their DSP routines to use 64-bit math? That's incredibly wasteful, even without Uhe's saying so, all the audio handling code I write has used 32-bit floats, instead of needlessly promoting it to 64-bit.
Also SSE2 and later can do vector processing on double precision (64-bit) values. The 128-bit registers can hold four 32-bit values, or two 64-bit. So it can only crunch two values per iteration, instead of four, but the fetching of the values from RAM still uses the SSE pathways, so there are still quite a few gains to be had.
Richard
-
- Posts: 393
- Joined: 15 Jan 2015
I don't understand any of it really, but I do know it means that SDK is making some progress.
I'm with you theo, bring on the big: drums, brass and strings IDT stuff! Thought for sure we'd have some of those by now. :/
I'm with you theo, bring on the big: drums, brass and strings IDT stuff! Thought for sure we'd have some of those by now. :/
"Reason is not measured by size or height, but by principle.” -Epictetus
-
- RE Developer
- Posts: 1176
- Joined: 15 Jan 2015
Please do not discuss the SDK on this forum. Developers are well aware they are under NDA and thus shouldn't be commenting in public.
I won't lock this thread as it was started by a user based on a post from an other public source, but Devs - you should know better. Use the official RE Developers Forum. I will lock this thread if NDA level comments continue.
I won't lock this thread as it was started by a user based on a post from an other public source, but Devs - you should know better. Use the official RE Developers Forum. I will lock this thread if NDA level comments continue.
-
- Posts: 1284
- Joined: 16 Jan 2015
My apologies i had NO idea, now I feel really bad.JiggeryPokery wrote:Please do not discuss the SDK on this forum. Developers are well aware they are under NDA and thus shouldn't be commenting in public.
I won't lock this thread as it was started by a user based on a post from an other public source, but Devs - you should know better. Use the official RE Developers Forum. I will lock this thread if NDA level comments continue.
Obviously if i was an RE dev and had known there was a beta and it was breaking NDA to leak this feature, i would never do it myself. My apologies.
Mac Studio M2 Ultra/64Gb/Apollo T-Bolt 3/OS 14.6.1/PT 2024.6/R13.02/Logic 11.01
MSI GT77/13980HX/RTX 4090m/64GB/Arturia Minifuse 2/PT 2024.6/R13.02/Low DPC latency tuned
MSI GT77/13980HX/RTX 4090m/64GB/Arturia Minifuse 2/PT 2024.6/R13.02/Low DPC latency tuned
-
- RE Developer
- Posts: 1176
- Joined: 15 Jan 2015
JiggeryPokery wrote:Please do not discuss the SDK on this forum. Developers are well aware they are under NDA and thus shouldn't be commenting in public.
I won't lock this thread as it was started by a user based on a post from an other public source, but Devs - you should know better. Use the official RE Developers Forum. I will lock this thread if NDA level comments continue.
Theo.M wrote:
My apologies i had NO idea, now I feel really bad.
Obviously if i was an RE dev and had known there was a beta and it was breaking NDA to leak this feature, i would never do it myself. My apologies.
Comments in this thread have been fairly general, about SSE use and limitations, rather than the RE SDK specifically, unlike another thread I did close today. So I don't feel there has been an NDA violation caused by this thread, as you were just reposting something you had publicly heard from elsewhere.
Really I was just warning other Devs of their obligations not to discuss the SDK in this thread before they did, accidentally or not
If people want to continue to discuss the ins and outs of SIMD instructions on a general level, knock yourselves out. But SDK specifics are most definitely banned and I will wield the hammer 'o bans. RE Devs know where they can discuss SDK stuff freely.
-
- Posts: 328
- Joined: 18 Jan 2015
Come on, this is not PUF.JiggeryPokery wrote:Please do not discuss the SDK on this forum. Developers are well aware they are under NDA and thus shouldn't be commenting in public.
I won't lock this thread as it was started by a user based on a post from an other public source, but Devs - you should know better. Use the official RE Developers Forum. I will lock this thread if NDA level comments continue.
They aren't discussing anything illegal, political, religion or hate speech. If A developer wants to tell everything he wants to tell about RE SDK he shouldn't be censored by Admins, it's PH business to enforce their NDA.
I presume that you admins who signed the NDA are responsible for yourself, not what other dev disclose.
IMHO, this kind of censorship will give bad vibes of the forum, with posts and topics being so slow. You guys should encourage discussions about Reason and all related, not oppose it.
Otherwise, you could drive this forum into a "Discover" forum, and leave the real Reason discussions to other forums like KVR, gearslutz etc.
-
- Posts: 3551
- Joined: 16 Jan 2015
- Location: Contest Weiner
Why do I feel oddly comforted by this after PUF?JiggeryPokery wrote: I will wield the hammer 'o bans.
Who’s using the royal plural now baby? 🧂
-
- RE Developer
- Posts: 1176
- Joined: 15 Jan 2015
If it's being censored how come you've posted a reply!?Kategra wrote: Come on, this is not PUF.
They aren't discussing anything illegal, political, religion or hate speech. If A developer wants to tell everything he wants to tell about RE SDK he shouldn't be censored by Admins, it's PH business to enforce their NDA.
I presume that you admins who signed the NDA are responsible for yourself, not what other dev disclose.
IMHO, this kind of censorship will give bad vibes of the forum, with posts and topics being so slow. You guys should encourage discussions about Reason and all related, not oppose it.
Otherwise, you could drive this forum into a "Discover" forum, and leave the real Reason discussions to other forums like KVR, gearslutz etc.
I clearly stated in my follow-up response I don't consider this thread to be NDA breaking, it's fair to say my first post you've quoted didn't make that clear, hence the follow-up reply to Theo, who was unnecessarily concerned. I was merely reminding Devs that specific SDK discussion stuff is off-limits per their agreement with PH, as someone else happened to post such a request on a different thread.
So please reread my other response:
"If people want to continue to discuss the ins and outs of SIMD instructions on a general level, knock yourselves out. But SDK specifics are most definitely banned and I will wield the hammer 'o bans. RE Devs know where they can discuss SDK stuff freely."
So I'm not sure which bits of that are unclear, so I'll repeat: this thread was not locked because it is a general coding discussion and so everyone here free to carry on in the same manner, and afaiac the same goes for any other general coding thread, or job requests. But discussion of how to use the SDK is not allowed: we signed an NDA, we need a working relationship with Propellerhead, so I won't allow that, and I'm sure Richard, avasopht and Scuzzy above appreciate that view. There is an official PH forum for developers, that, more importantly, PH staff can offer valuable assistance, that won't be the case here. We're being practical and pragmatic.
No, this is not PUF, but we have to try our best to use a bit more common sense.
-
- Competition Winner
- Posts: 4076
- Joined: 16 Jan 2015
JiggeryPokery wrote:Please do not discuss the SDK on this forum. Developers are well aware they are under NDA and thus shouldn't be commenting in public.
I won't lock this thread as it was started by a user based on a post from an other public source, but Devs - you should know better. Use the official RE Developers Forum. I will lock this thread if NDA level comments continue.
Nothing unreasonable about that rule. Plenty of forums have that.Kategra wrote:
Come on, this is not PUF.
They aren't discussing anything illegal, political, religion or hate speech. If A developer wants to tell everything he wants to tell about RE SDK he shouldn't be censored by Admins, it's PH business to enforce their NDA.
I presume that you admins who signed the NDA are responsible for yourself, not what other dev disclose.
IMHO, this kind of censorship will give bad vibes of the forum, with posts and topics being so slow. You guys should encourage discussions about Reason and all related, not oppose it.
Otherwise, you could drive this forum into a "Discover" forum, and leave the real Reason discussions to other forums like KVR, gearslutz etc.
Some do it so they don't receive a cease and desist, for example, forum.gbadev.org had many licensed developers as active users while at the same time never came into legal issues.
It's a simple policy that any mature developer would have no problem with.
-
- Information
-
Who is online
Users browsing this forum: Chi-Individual and 2 guests