So you simply are transferring the graphics calculations from GPU to CPU.
After a little more googleling, yes it forces the program/plugin to use software rendering instead of the driver/GPU.
That leads me to think, that either users that experience problems are using faulty drivers or GPUâs. Or that there is a bug somewhere in Cubase that only triggers some combinations of software, drivers and GPU. Anyway it makes sense to update graphics drivers and disable any sort of virtual desktop or otherwise possible disruptive visual tools.
I checked that out with realstrat and reallpc from musiclab - not working. After checking some possibilities it seems that the problem is the realviewer from musiclab which behaves strange with cubase 8. It concerns the vst2 and vst3 version. So i bridged the vst2 64bit dll with jbridger into a 64bit version and - success. No crashes anymore.
I get your response but it doesnât answer the question. Others already have âsmooth sailingâ without this suggested registry change. Could someone from Steinberg please comment? If your offloading graphic processing from GPU to CPU, somethingâs obviously impactedâŚ
So thatâs what this does?
I ainât got no dedicated graphics board, but instead Intel HD 5000 integrated graphics (on PC). Itâs using using the CPU and chipset together as GPU. Could that explain why I donât experience much improvement from this?
I was skeptical but this actually works for me. Projects close really quick without crashing! Initial load time is still pretty slow but itâs an improvement.
Iâm trying to figure out if this is a solution or a band-aid? Whatâs the impact from shifting processing from GPU to CPU? Does this cause OTHER performance issues being that you are now taxing the CPU more? This might fix one problem but have other unintended consequences.
My personal opionion?
Its a bandaid and a solutionâŚ
No drain of cpu for audio resources on my side⌠Only improvements so farâŚ
(Cubase doesnt really need 3d super visual fx to run smoothly)
But check it out for youself⌠If you dont like it, its easy to reverse by deleting the registry entry againâŚ
The domain/default pair of (com.cubase.common, GraphicsAcceleration) does not exist
The same error message comes up when reading the fabfilter defaults too (I have have fabfilter plugins installed) so I guess this is expected. Iâll apply the setting, reboot, and see if Cubase changes bevior at all.
Thatâs the first question I thought - I guess time will tell.
Iâm not sure this graphics tweak is making any real difference for me. I have noticed that periodically, Cubase and all audio will halt for a split second then resume. Almost like the graphics layer is choking and trying to process something and interrupting the audio stream. Thatâs just my suspicion.
I never had Cubase crashing on me. However, I was fighting ASIO Spikes into the red and occasional crackles for years.
I added the registry entry as suggested onto my Cubase8 Folder, and the ASIO Spikes are - gone! I observe this improvement on my Cubase 8.0.20 Workstation, as well as, on my Cubase 7.5 machine.
Cubase has always done that. Itâs been graphic oversensitive for over a decade. Doesnât have anything to do with this registry hack.
But Iâm not surprised to hear you react with great concern when Cubase freezes up like that. The user freezes up the same way, oneâs mind goes blank. This does actually cause occasional crashes 'cause sometimes cubase doesnât recover from it. So you never really get used to it.