Old 04-02-2019, 01:28 PM   #1
srdmusic
Human being with feelings
 
Join Date: Dec 2016
Posts: 534
Default GPU graphic acceleration

I heard that Reaper does not utilize graphics acceleration to render the user interface. Is this true?

In the sprit of Reaper's preformance, I would assume that even on cheaper video cards, having the GPU process as much of Reaper's GUI and video playback instead of the CPU would equal quite a large preformance boost.

I experience very slow gui redraw rates compared to some of the other DAW I've worked in and it would be so great if I could get the GUI to be a bit snappier on my expensive Nvidia card.

Is there any stability or resource reason why Reaper does not utilize Graphics acceleration.
srdmusic is offline   Reply With Quote
Old 04-17-2019, 08:42 AM   #2
Klangfarben
Human being with feelings
 
Join Date: Jul 2016
Posts: 553
Default

Huge +1 for this.

In a large template, the GUI lag is well, terrible. Save your project? Video stops playing entirely. Scroll down in your template? Sometimes it freezes for several seconds and then finally moves. The list goes on and on. Resizing tracks, refreshing windows, etc.

I know cpu efficiency has been a high priority for the developers. Do yourself a huge favor here and leverage the GPU for hardware acceleration. It is sorely needed and truly necessary for Reaper's growth moving forward.

Yes, CPUs keep getting faster. But the demands placed on the CPU keep getting higher and higher and usually keep pace or even outpace CPU advancement. I don't see any way Reaper is going to maintain a satisfactory GUI response with all that is being asked of the CPU without making use of hardware acceleration.

And for those of you thinking maybe I should update my computer, here are my specs.

Xeon E5-2697A v4 x2 (32 cores at 3.1 GHz)
256GB of DDR4 Memory (running in quad channel at 2800 MHz)
Nvidia P4000 Graphics Card
Samsung 960 Pro 2TB NVMe drive for OS
4x Intel P3500 2TB NVMe drives in RAID0 for Samples

That's nothing to sneeze at. And I'm REALLY struggling with the GUI at high track count and I'm guessing most Reaper users don't have these kind of specs. Yes, there is faster stuff available (at frightening cost) and I'm sure Threadripper 3 will be a beast but really, a machine like the above shouldn't have issues with major GUI lag. That it does really points to the need for hardware acceleration in Reaper.
Klangfarben is offline   Reply With Quote
Old 04-17-2019, 09:06 AM   #3
_Stevie_
Human being with feelings
 
_Stevie_'s Avatar
 
Join Date: Oct 2017
Posts: 2,450
Default

Yep, so +1, Reaper is ultra fast in every aspect, but just not in terms of GUI,
especially with a lot of tracks.
__________________
My Reascripts forum thread | My Reascripts on GitHub | Stephan Römer - film composer
If you wish to donate for my scripts: please consider an organization like: animal shelter, doctors without borders, UNICEF, etc...
_Stevie_ is online now   Reply With Quote
Old 04-17-2019, 11:15 AM   #4
Thonex
Human being with feelings
 
Join Date: May 2018
Location: Los Angeles
Posts: 523
Default

This would explain a lot of things I've been noticing with Reaper on bigger projects.

Big +1 here.
__________________
Cheers,
Andrew K
Reaper 5.95/64 Mac 10.12.+, i7 Quad 2.9GHz, 24GB
Thonex is offline   Reply With Quote
Old 04-17-2019, 11:46 AM   #5
heda
Human being with feelings
 
heda's Avatar
 
Join Date: Jun 2012
Location: Spain
Posts: 5,224
Default

I see many Track Inspector VIP users here
please tell me it is not Track Inspector causing this...
Because it should work the same independently of the number of tracks.
I guess this only affects soundtracks composers that use hundreds and hundreds of tracks. I also see notable performance hit when using many tracks. But I still don't have enough libraries to become a bad situation
__________________
HeDaScripts for REAPER
heda is offline   Reply With Quote
Old 04-20-2019, 01:14 PM   #6
srdmusic
Human being with feelings
 
Join Date: Dec 2016
Posts: 534
Default

Quote:
Originally Posted by Klangfarben View Post
Huge +1 for this.

In a large template, the GUI lag is well, terrible. Save your project? Video stops playing entirely. Scroll down in your template? Sometimes it freezes for several seconds and then finally moves. The list goes on and on. Resizing tracks, refreshing windows, etc.

I know cpu efficiency has been a high priority for the developers. Do yourself a huge favor here and leverage the GPU for hardware acceleration. It is sorely needed and truly necessary for Reaper's growth moving forward.

Yes, CPUs keep getting faster. But the demands placed on the CPU keep getting higher and higher and usually keep pace or even outpace CPU advancement. I don't see any way Reaper is going to maintain a satisfactory GUI response with all that is being asked of the CPU without making use of hardware acceleration.

And for those of you thinking maybe I should update my computer, here are my specs.

Xeon E5-2697A v4 x2 (32 cores at 3.1 GHz)
256GB of DDR4 Memory (running in quad channel at 2800 MHz)
Nvidia P4000 Graphics Card
Samsung 960 Pro 2TB NVMe drive for OS
4x Intel P3500 2TB NVMe drives in RAID0 for Samples

That's nothing to sneeze at. And I'm REALLY struggling with the GUI at high track count and I'm guessing most Reaper users don't have these kind of specs. Yes, there is faster stuff available (at frightening cost) and I'm sure Threadripper 3 will be a beast but really, a machine like the above shouldn't have issues with major GUI lag. That it does really points to the need for hardware acceleration in Reaper.
Totally agree. We would all benefit. From powerful systems to smaller laptops. It doesn't really make sense to not look at utilizing the graphics card more.
srdmusic is offline   Reply With Quote
Old 04-20-2019, 01:16 PM   #7
srdmusic
Human being with feelings
 
Join Date: Dec 2016
Posts: 534
Default

Quote:
Originally Posted by heda View Post
I see many Track Inspector VIP users here
please tell me it is not Track Inspector causing this...
Because it should work the same independently of the number of tracks.
I guess this only affects soundtracks composers that use hundreds and hundreds of tracks. I also see notable performance hit when using many tracks. But I still don't have enough libraries to become a bad situation
Yes, scripts that use visuals would benefit if reaper utalized the GPU for processing the GUI, video etc.
srdmusic is offline   Reply With Quote
Old 04-26-2019, 01:12 PM   #8
srdmusic
Human being with feelings
 
Join Date: Dec 2016
Posts: 534
Default

Hey guys, this seems to be a bigger problem than just video midi editor and track selection lag.

Here's a link to a user that's experiencing massive lag when opening specific Kontakt libraries.

https://forum.cockos.com/showthread.php?t=209303

I too have the same problem opening some Kontakt instruments with lots of GUI bits going on. I also have problems with other plugins and instruments. When I switch tracks it halts the whole Reaper GUI until the plugin interface loads in the FX chain window.

We really need this sort of thing processed on the GPU which on my rig is only running at 1% of it's potential.
srdmusic is offline   Reply With Quote
Old 04-26-2019, 01:44 PM   #9
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 7,258
Default

Quote:
Originally Posted by srdmusic View Post
I heard that Reaper does not utilize graphics acceleration to render the user interface. Is this true?
Of course not.
Any Program's GUI Text is rendered by the GPU. The program would have a hard time to prevent that.

-Michael
mschnell is offline   Reply With Quote
Old 04-26-2019, 02:00 PM   #10
srdmusic
Human being with feelings
 
Join Date: Dec 2016
Posts: 534
Default

Quote:
Originally Posted by mschnell View Post
Of course not.
Any Program's GUI Text is rendered by the GPU. The program would have a hard time to prevent that.

-Michael
Hmmmm. I'm actually not sure this is true of Reaper. I believe they are forcing everything to be processed on the CPU so that Reaper can force the audio threads to be the highest priority. I don't have definitive proof other than there is an extreme amount of lag in Reaper's GUI, video and displaying plugin GUI's when compared to some other DAW's like Cubase. Reaper out preforms on the audio thread side and the CPU saturation is much higher on Reaper but the video suffered.

I believe there should be more controls given back to the user to allow the heavy video and GUI aspects of Reaper to be processed on the graphics card instead of the CPU as our graphics cards are not nearly being utilized.
srdmusic is offline   Reply With Quote
Old 04-26-2019, 02:37 PM   #11
heda
Human being with feelings
 
heda's Avatar
 
Join Date: Jun 2012
Location: Spain
Posts: 5,224
Default

REAPER works fine with plugins that use GPU for the graphics display. The GPU will be used to draw inside the plugin window. Maybe it is a Kontakt issue. I guess the best is to contact Cockos and Native instruments with specific examples and figure it out.
__________________
HeDaScripts for REAPER
heda is offline   Reply With Quote
Old 04-26-2019, 02:42 PM   #12
srdmusic
Human being with feelings
 
Join Date: Dec 2016
Posts: 534
Default

Quote:
Originally Posted by heda View Post
REAPER works fine with plugins that use GPU for the graphics display. The GPU will be used to draw inside the plugin window. Maybe it is a Kontakt issue. I guess the best is to contact Cockos and Native instruments with specific examples and figure it out.
I believe you are correct with plugins that use 'Open GL'. However, there are several plugins that have problems within the DAW when Open GL is turned on. For example many user complain about Fab Filter plugins causing crashes with Open GL turned on. So much so that Fab Filter released a doc to help users disable Open GL in there plugins.

Reaper, should also allow, video, scripts, the Main GUI and the MIDI editor etc to have the option of running on the GPU instead of the CPU.

There used to be a check box in Reaper prefs to allow for faster GUI redraws. This has since been removed. Not sure what happened with that but I've experienced a lot of lag with Reaper across many aspects of the program.
srdmusic is offline   Reply With Quote
Old 04-26-2019, 02:54 PM   #13
heda
Human being with feelings
 
heda's Avatar
 
Join Date: Jun 2012
Location: Spain
Posts: 5,224
Default

Maybe there is a way to disable GPU for Kontakt? I have no idea.

of course it would be nice to have GPU... I would totally use GPU acceleration in the scripts if possible.

Maybe the problem is that it would make the entire system less stable. I hope we can experiment with it at least some day.

I think it would help if you can record a small video of the lag you are experiencing and contact Cockos for support. Big lag is not normal and should be fixed.
__________________
HeDaScripts for REAPER
heda is offline   Reply With Quote
Old 04-26-2019, 03:13 PM   #14
EvilDragon
Human being with feelings
 
EvilDragon's Avatar
 
Join Date: Jun 2009
Location: Croatia
Posts: 23,043
Default

Quote:
Originally Posted by heda View Post
Maybe there is a way to disable GPU for Kontakt? I have no idea.
Nope. Also Kontakt AFAIK doesn't use OpenGL, just regular software 2D rendering, not accelerated.
EvilDragon is online now   Reply With Quote
Old 04-26-2019, 03:27 PM   #15
heda
Human being with feelings
 
heda's Avatar
 
Join Date: Jun 2012
Location: Spain
Posts: 5,224
Default

Quote:
Originally Posted by EvilDragon View Post
Nope. Also Kontakt AFAIK doesn't use OpenGL, just regular software 2D rendering, not accelerated.
If it doesn't use GPU, then the lag must be caused by something else. I would try to change the Run as... option for Kontakt in the FX browser and set it to separate process and see if it makes a difference in lag, and also change/limit the number of CPU threads Kontakt uses to leave some threads for REAPER graphics updates.
__________________
HeDaScripts for REAPER
heda is offline   Reply With Quote
Old 04-26-2019, 11:55 PM   #16
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 7,258
Default

Quote:
Originally Posted by srdmusic View Post
Hmmmm. I'm actually not sure this is true of Reaper.
AFAIK, Reaper uses the open source WDL Library for this. So you would be able to check it out.
-Michael
mschnell is offline   Reply With Quote
Old 04-27-2019, 12:01 AM   #17
EvilDragon
Human being with feelings
 
EvilDragon's Avatar
 
Join Date: Jun 2009
Location: Croatia
Posts: 23,043
Default

WDL itself doesn't seem to do OpenGL or any sort of graphics accelleration.
EvilDragon is online now   Reply With Quote
Old 04-27-2019, 06:22 AM   #18
Xenakios
Human being with feelings
 
Xenakios's Avatar
 
Join Date: Feb 2007
Location: Oulu, Finland
Posts: 7,713
Default

Quote:
Originally Posted by EvilDragon View Post
WDL itself doesn't seem to do OpenGL or any sort of graphics accelleration.
There's actually a folder named "gpu" in WDL but that has last been modified in 2015 and the files don't contain anything that would really be used by Reaper. It would seem implementing GPU acceleration for graphics is not a priority for Cockos. The minimal code they have in those files is also using OpenGL, which is a legacy technology which isn't really worth using anymore. Windows has a lacking implementation of it and on macOs it is being phased out entirely.

The custom graphics elements in Reaper are drawn with their Lice library which is entirely CPU based. Some elements are drawn by operating system API calls. (Which may or may not be GPU accelerated but even if they are, the benefit is probably negligible because of all the CPU based rendering Reaper is doing anyway.)
__________________
For info on SWS Reaper extension plugin (including Xenakios' previous extension/actions) :
http://www.sws-extension.org/
https://github.com/Jeff0S/sws
--
Xenakios blog (about HourGlass, Paul(X)Stretch and λ) :
http://xenakios.wordpress.com/

Last edited by Xenakios; 04-27-2019 at 06:27 AM.
Xenakios is offline   Reply With Quote
Old 04-27-2019, 08:06 AM   #19
srdmusic
Human being with feelings
 
Join Date: Dec 2016
Posts: 534
Default

Thanks for the info guys. I think I understand why Reaper's dev team wants full control of CPU priority. I think it maybe one of the only ways Reaper can guarantee that the audio threads are always highest priority.

However, CPUs and GPUs have seen some huge inprovements since the start of Reaper, and it's my belief that the GPU is an untapped resource that should be available for users and scripters to access if they want. Almost every other aspect of Reaper is customizable for the knowledgeable user so the GPU should be no different.

If I'm wrong, I hope the devs can shed some light on why giving access to the GPU would be a bad idea.
srdmusic is offline   Reply With Quote
Old 04-27-2019, 08:33 AM   #20
tack
Human being with feelings
 
tack's Avatar
 
Join Date: Jan 2014
Location: Ontario, Canada
Posts: 662
Default

Apart from video playback and processing, I don't really see much benefit to using the GPU here. The actual graphics rendering work done by Reaper's UI can be done with a tiny fraction of CPU time on modern processors. I strongly suspect the lag we experience in large projects is related to internal processing (iterating over tracks, crunching through object states, etc.) and not the actual task of graphics rendering.
tack is online now   Reply With Quote
Old 04-27-2019, 08:34 AM   #21
Xenakios
Human being with feelings
 
Xenakios's Avatar
 
Join Date: Feb 2007
Location: Oulu, Finland
Posts: 7,713
Default

Quote:
Originally Posted by srdmusic View Post

If I'm wrong, I hope the devs can shed some light on why giving access to the GPU would be a bad idea.
The problem is that they would need to rewrite all their graphics code to use the GPU. It isn't simply a switch to enable.
__________________
For info on SWS Reaper extension plugin (including Xenakios' previous extension/actions) :
http://www.sws-extension.org/
https://github.com/Jeff0S/sws
--
Xenakios blog (about HourGlass, Paul(X)Stretch and λ) :
http://xenakios.wordpress.com/
Xenakios is offline   Reply With Quote
Old 04-27-2019, 08:42 AM   #22
Xenakios
Human being with feelings
 
Xenakios's Avatar
 
Join Date: Feb 2007
Location: Oulu, Finland
Posts: 7,713
Default

Quote:
Originally Posted by tack View Post
The actual graphics rendering work done by Reaper's UI can be done with a tiny fraction of CPU time on modern processors.
It's also worth remembering that Reaper shares the GUI thread with 3rd party plugins. If there is even one plugin active that has difficulties updating its GUI fast enough, it will affect Reaper and other plugins too. (Plugins may also be doing other time consuming things in the GUI thread besides drawing graphics. They really shouldn't do that, but sometimes developers opt to do things that way because it is easier than using separate threads.)
__________________
For info on SWS Reaper extension plugin (including Xenakios' previous extension/actions) :
http://www.sws-extension.org/
https://github.com/Jeff0S/sws
--
Xenakios blog (about HourGlass, Paul(X)Stretch and λ) :
http://xenakios.wordpress.com/
Xenakios is offline   Reply With Quote
Old 04-27-2019, 08:55 AM   #23
tack
Human being with feelings
 
tack's Avatar
 
Join Date: Jan 2014
Location: Ontario, Canada
Posts: 662
Default

Quote:
Originally Posted by Xenakios View Post
It's also worth remembering that Reaper shares the GUI thread with 3rd party plugins. If there is even one plugin active that has difficulties updating its GUI fast enough, it will affect Reaper and other plugins too.
Would bridging such plugins would avoid that situation? By definition they can't share the same thread -- although if Reaper blocks its UI thread waiting for bridged plugins to respond then it would have the same effect (although that'd be kinda lame and probably not too difficult to fix).
tack is online now   Reply With Quote
Old 04-27-2019, 10:55 AM   #24
srdmusic
Human being with feelings
 
Join Date: Dec 2016
Posts: 534
Default

Quote:
Originally Posted by tack View Post
Would bridging such plugins would avoid that situation? By definition they can't share the same thread -- although if Reaper blocks its UI thread waiting for bridged plugins to respond then it would have the same effect (although that'd be kinda lame and probably not too difficult to fix).
The load time on bridged plugins make is pretty unusable for anything other than a few problematic plugs that crash reaper otherwise.
srdmusic is offline   Reply With Quote
Old 04-27-2019, 10:57 AM   #25
srdmusic
Human being with feelings
 
Join Date: Dec 2016
Posts: 534
Default

Quote:
Originally Posted by Xenakios View Post
It's also worth remembering that Reaper shares the GUI thread with 3rd party plugins. If there is even one plugin active that has difficulties updating its GUI fast enough, it will affect Reaper and other plugins too. (Plugins may also be doing other time consuming things in the GUI thread besides drawing graphics. They really shouldn't do that, but sometimes developers opt to do things that way because it is easier than using separate threads.)
This is exactly the problem I'm running into more and more, especially with Kontakt instruments that require a lot of visual overhead.
srdmusic is offline   Reply With Quote
Old 04-27-2019, 11:03 AM   #26
Xenakios
Human being with feelings
 
Xenakios's Avatar
 
Join Date: Feb 2007
Location: Oulu, Finland
Posts: 7,713
Default

Quote:
Originally Posted by srdmusic View Post
This is exactly the problem I'm running into more and more, especially with Kontakt instruments that require a lot of visual overhead.
Right, but there isn't really anything that can be done about it that would work reliably or would be easy to implement.(*) Or are you saying things work somehow differently in other hosts with Kontakt? If that is the case, then it could be a genuine bug with how Reaper handles 3rd party plugin GUIs. But if the GUI lags happen because of Kontakt itself, it should affect other hosts too and there is no obvious fix except to beg Native Instruments to fix it.

(*) Things like handling the host GUI in another thread or using GPU for the graphics rendering are not at all trivial to implement.
__________________
For info on SWS Reaper extension plugin (including Xenakios' previous extension/actions) :
http://www.sws-extension.org/
https://github.com/Jeff0S/sws
--
Xenakios blog (about HourGlass, Paul(X)Stretch and λ) :
http://xenakios.wordpress.com/
Xenakios is offline   Reply With Quote
Old 04-27-2019, 11:56 AM   #27
srdmusic
Human being with feelings
 
Join Date: Dec 2016
Posts: 534
Default

Quote:
Originally Posted by tack View Post
Would bridging such plugins would avoid that situation? By definition they can't share the same thread -- although if Reaper blocks its UI thread waiting for bridged plugins to respond then it would have the same effect (although that'd be kinda lame and probably not too difficult to fix).
The load time on bridged plugins make is pretty unusable for anything other than a few problematic plugs that crash reaper otherwise.
srdmusic is offline   Reply With Quote
Old 04-27-2019, 12:45 PM   #28
EvilDragon
Human being with feelings
 
EvilDragon's Avatar
 
Join Date: Jun 2009
Location: Croatia
Posts: 23,043
Default

Must say I never noticed any difference in loading times between bridged and non-bridged plugins.
EvilDragon is online now   Reply With Quote
Old 04-27-2019, 04:28 PM   #29
srdmusic
Human being with feelings
 
Join Date: Dec 2016
Posts: 534
Default

Quote:
Originally Posted by EvilDragon View Post
Must say I never noticed any difference in loading times between bridged and non-bridged plugins.
It's much more noticable in larger templates as there is a lag for each plugin load. Some plugins also take longer than others. If a user is only working with self made Kontakt instruments then I can see them not noticing a huge difference.
srdmusic is offline   Reply With Quote
Old 04-27-2019, 10:34 PM   #30
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 7,258
Default

Quote:
Originally Posted by srdmusic View Post
there is a lag for each plugin load
... when they are in a row ? (When they are in parallel this does not seem likely.)

Is that latency denoted in the PDC (and hence compensated if possible) ?

Regarding multiple bridged Plugins in a row, it might be possible to bridge them as a block, which would at least save CPU resources. (No idea if that does happen.)

("Block bridging" might show up a way for future kind of such "bridging" task discussed elsewhere, such as creating an oversampling environment for a bunch of plugins or a "Wine" bridge for Windows plugins in a Linux installation of Reaper.)

-Michael

Last edited by mschnell; 04-27-2019 at 10:47 PM.
mschnell is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 02:56 PM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.