Go Back   Cockos Incorporated Forums > REAPER Forums > REAPER Feature Requests

Reply
 
Thread Tools Display Modes
Old 11-16-2019, 05:27 PM   #41
heda
Human being with feelings
 
heda's Avatar
 
Join Date: Jun 2012
Location: Spain
Posts: 7,239
Default

I believe devs recently changed the entire graphics engine of the arrange, to make it also compatible with the new OSX system (which I believe it is hardware accelerated?) and it is much faster with many hundreds of tracks than before. Justin said it would probably break many things, but that didn't stop him to do it.

I really wouldn't complain if we could have GPU accelerated graphics on scripts. Some scripts can become heavy on graphics. And when I scroll the arrange for example, they can stop to be refreshed creating some problems as I described here: https://forum.cockos.com/showthread.php?t=163905
heda is offline   Reply With Quote
Old 11-16-2019, 06:47 PM   #42
pepe44
Human being with feelings
 
pepe44's Avatar
 
Join Date: Jul 2013
Location: Portugal
Posts: 1,827
Default

It is not hardware accelerated. Go check in your system settings. Only certain plugins, like fabfilter use hardware acceleration when used inside reaper. That´s it.
pepe44 is offline   Reply With Quote
Old 11-16-2019, 11:32 PM   #43
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,688
Default

Quote:
Originally Posted by Klangfarben View Post
assigning a dedicated core or cores to the GUI...
I don't suppose this will help in a "CPU busy" situation, as you describe. In a DAW by default CPU threads assigned to audio are higher priority, meaning that the GUI will lag, if all CPU power is needed for audio, but the GUI will automatically get the remaining CPU cycles as soon as it's possible to calculate the audio without dropouts. Audio only is allowed to wait for as long as the buffer setting says. This is not an amount of time the smoothness of the GUI will noticeably benefit from.

Hence in such a "busy" situation, dedicating a core to the GUI will result in degrading audio. This might be what you want in certain situations, but it's bad as a default behavior.

In a "non busy" (audio not demanding or stopped) in fact only one core will do GIU work. Here in fact using multiple cores (i.e. OS threads) might help. But doing so is a lot of work, as communicating with the widget set tools of the OS with multiple threads is non-standard and rather complicated and error-prone. (I in fact did such stuff some years ago.).

Offloading some visual work to the GPU (handling the GUI like a game programmer would, e.g by using a framework like OpenGL) might speed up the GUI without hampering audio. But that needs a complete overhaul of a program initially done by a different GUI tool set (widgets). I in fact once helped doing this for a computer graphics program .

-Michael

Last edited by mschnell; 11-16-2019 at 11:45 PM.
mschnell is offline   Reply With Quote
Old 11-16-2019, 11:40 PM   #44
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,688
Default

Quote:
Originally Posted by heda View Post
(which I believe it is hardware accelerated?)
Any Widget Set of any modern OS is hardware accelerated by using the GPU, and there is close to no hardware that does not feature a GPU. Otherwise rendering just the standard widgets to the screen would be awfully slow. In Linux you can select a Framebuffer driver that does the rendering completely by the CPU. Of course nobody does this any more .
Hence what is discussed here is a kind of "advanced" / manual hardware acceleration of the GUI using the GPU.

-Michael
mschnell is offline   Reply With Quote
Old 11-17-2019, 05:30 AM   #45
BirdBird
Human being with feelings
 
BirdBird's Avatar
 
Join Date: Mar 2019
Posts: 425
Default

Quote:
Originally Posted by mschnell View Post
I don't suppose this will help in a "CPU busy" situation, as you describe. In a DAW by default CPU threads assigned to audio are higher priority, meaning that the GUI will lag, if all CPU power is needed for audio, but the GUI will automatically get the remaining CPU cycles as soon as it's possible to calculate the audio without dropouts. Audio only is allowed to wait for as long as the buffer setting says. This is not an amount of time the smoothness of the GUI will noticeably benefit from.

Hence in such a "busy" situation, dedicating a core to the GUI will result in degrading audio. This might be what you want in certain situations, but it's bad as a default behavior.

In a "non busy" (audio not demanding or stopped) in fact only one core will do GIU work. Here in fact using multiple cores (i.e. OS threads) might help. But doing so is a lot of work, as communicating with the widget set tools of the OS with multiple threads is non-standard and rather complicated and error-prone. (I in fact did such stuff some years ago.).


-Michael
Thanks for the explanation I am still trying to wrap my head around it.
So in a situation like this:

Core 1: Audio ---------- Core 2: Audio ---------- Core 3: Audio ---------- Core 4: GUI

Would the GUI thread here still starve if there is heavy audio workload? I was under the assumption that since different cores do their operations in parallel the workload on the other 3 cores would not affect the performance on the 4th core.
BirdBird is offline   Reply With Quote
Old 11-17-2019, 08:25 AM   #46
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,688
Default

As all cores can run at the same time and Reaper sets the audio threads to highest priority, and Reaper requests an OS thread for each track, and the OS assigns cores to OS threads according th the priority, all available cores are assigned to audio as long as there are more tracks with work to do. only then a core will be assigned to the GUI thread.
Hence yer: it would sometimes (unnecessarily) starve audio, if the behavior would be changed.

-Michael
mschnell is offline   Reply With Quote
Old 11-17-2019, 09:01 AM   #47
BirdBird
Human being with feelings
 
BirdBird's Avatar
 
Join Date: Mar 2019
Posts: 425
Default

Quote:
Originally Posted by mschnell View Post
As all cores can run at the same time and Reaper sets the audio threads to highest priority, and Reaper requests an OS thread for each track, and the OS assigns cores to OS threads according th the priority, all available cores are assigned to audio as long as there are more tracks with work to do. only then a core will be assigned to the GUI thread.
Hence yer: it would sometimes (unnecessarily) starve audio, if the behavior would be changed.

-Michael
So you just described how it currently works, is that correct? What i am trying to understand is, if the behaviour was changed and we could assign a dedicated core that does GUI only, would that mean that the GUI thread could do its work without getting interrupted by audio?

The other end of it is that i wouldn't really mind losing some processing power for FX processing if it means i get a stable GUI out of it, the tweak suggested is less about audio performance and more about user experience, superb audio performance doesn't matter much if i can't do anything during playback
BirdBird is offline   Reply With Quote
Old 11-17-2019, 09:06 AM   #48
Xenakios
Human being with feelings
 
Xenakios's Avatar
 
Join Date: Feb 2007
Location: Oulu, Finland
Posts: 8,062
Default

Quote:
Originally Posted by mschnell View Post
Any Widget Set of any modern OS is hardware accelerated by using the GPU
Are you sure that is the case for example with the Windows win32 common controls? (Which is what Reaper uses for some parts of its GUI.) But even if that was so, most of the screen estate in Reaper has custom graphics that are currently rendered on the CPU. (Level meters, audio waveforms, the MIDI editor...) I literally see 0% GPU use in Windows with Reaper when not using any 3rd party plugins that use the GPU for their graphics. Maybe parts of the Reaper GUI are rendered on the GPU by the OS, but it uses so few GPU cycles it doesn't even register in Process Explorer's GPU usage graph.
__________________
I am no longer part of the REAPER community. Please don't contact me with any REAPER-related issues.
Xenakios is offline   Reply With Quote
Old 11-17-2019, 09:12 AM   #49
Klangfarben
Human being with feelings
 
Join Date: Jul 2016
Location: Los Angeles, CA
Posts: 1,701
Default

Quote:
Originally Posted by mschnell View Post
Hence in such a "busy" situation, dedicating a core to the GUI will result in degrading audio. This might be what you want in certain situations, but it's bad as a default behavior.
It could only negatively affect the audio if the CPU usage exceeded the number of remaining (non-dedicated) cores/threads. So, in the case of having enough available cores/threads, the audio would not be affected in any way. I agree, this should not be default behavior, but if the user has enough cores, there is nothing negative about doing this. Other DAWS have reserved cores for certain functions without degrading audio. There is no reason to think Reaper would be different in this regard.

Also, keep in mind the high CPU usage of GUI-related functions can and will degrade the audio. Yes, audio threads are always processed with highest priority, but if the CPU spikes or the GUI-related function is eating up too much of the available CPU/threads, the audio most certainly is negatively affected. Reaper is pretty good about this, but when the CPU is maxed/strained, you still get clicks and pops and other degradation.

So, what we are talking about here is that currently, because of non-optimized or hardware-accelerated GUI, we are getting laggy behavior that destroys workflow. Slow or non-existent redraw, no video playback, etc, etc. Also, because GUI is only using CPU rather than GPU/hardware acceleration, it can also negatively affect audio playback, even when audio has the highest priority. Now, the second issue can only be solved by offloading to the GPU or optimizing the GUI usage. But the first could be solved with a dedicated core as long as CPU usage didn't exceed what is available on the remaining cores. I think it should be an option.
Klangfarben is offline   Reply With Quote
Old 11-17-2019, 09:28 AM   #50
Xenakios
Human being with feelings
 
Xenakios's Avatar
 
Join Date: Feb 2007
Location: Oulu, Finland
Posts: 8,062
Default

I think an extension plugin could be made to test the "assign a dedicated CPU core for the GUI thread" thing. (On Windows, enumerate through the Reaper process threads and use SetThreadAffinityMask and SetThreadPriority as appropriate for them.) I don't have any heavy real life projects to test the behavior with, though, I could only do synthetic tests. My expectation is that it wouldn't really help anything, even if there were CPU cores/time to spare. Some of the GUI operations in Reaper just are inherently slow and assigning more CPU priority or even a dedicated core to them isn't likely to help that much. It would still be interesting to test, I guess.
__________________
I am no longer part of the REAPER community. Please don't contact me with any REAPER-related issues.

Last edited by Xenakios; 11-17-2019 at 09:36 AM.
Xenakios is offline   Reply With Quote
Old 11-17-2019, 09:30 AM   #51
pepe44
Human being with feelings
 
pepe44's Avatar
 
Join Date: Jul 2013
Location: Portugal
Posts: 1,827
Default

sure klang, and has i said, cockos has different priorities for now.
Rebuilding a full GUI engine is not one of them.
pepe44 is offline   Reply With Quote
Old 11-17-2019, 09:34 AM   #52
BirdBird
Human being with feelings
 
BirdBird's Avatar
 
Join Date: Mar 2019
Posts: 425
Default

Quote:
Originally Posted by pepe44 View Post
sure klang, and has i said, cockos has different priorities for now.
Rebuilding a full GUI engine is not one of them.
Do you work at Cockos? Are you one of the developers? Why are you talking on their behalf?
BirdBird is offline   Reply With Quote
Old 11-17-2019, 09:36 AM   #53
Klangfarben
Human being with feelings
 
Join Date: Jul 2016
Location: Los Angeles, CA
Posts: 1,701
Default

Quote:
Originally Posted by Xenakios View Post
I think an extension plugin could be made to test the "assign a dedicated CPU core for the GUI thread" thing. (Enumerate through the Reaper process threads and use SetThreadAffinityMask and SetThreadPriority as appropriate for them.) I don't have any heavy real life projects to test the behavior with, though, I could only do synthetic tests. My expectation is that it wouldn't really help anything, even if there were CPU cores/time to spare. Some of the GUI operations in Reaper just are inherently slow and assigning more CPU priority or even a dedicated core to them isn't likely to help that much. It would still be interesting to test, I guess.
Wow, that's actually a really clever idea. You might be right though, in which case a dedicated core wouldn't be much good.
Klangfarben is offline   Reply With Quote
Old 11-17-2019, 09:39 AM   #54
Klangfarben
Human being with feelings
 
Join Date: Jul 2016
Location: Los Angeles, CA
Posts: 1,701
Default

Quote:
Originally Posted by pepe44 View Post
sure klang, and has i said, cockos has different priorities for now.
Rebuilding a full GUI engine is not one of them.
Well I can't say what their priorities are obviously. But it is a workflow killer so I think the OPs request is pretty valid and will make the argument and let the chips fall where they may.
Klangfarben is offline   Reply With Quote
Old 11-17-2019, 09:43 AM   #55
pepe44
Human being with feelings
 
pepe44's Avatar
 
Join Date: Jul 2013
Location: Portugal
Posts: 1,827
Default

Quote:
Originally Posted by BirdBird View Post
Do you work at Cockos? Are you one of the developers? Why are you talking on their behalf?
Hi BirdBird, no i´m not a developer. But there are at least 10 forum posts about this subject, just look at the dates and see for how long this has been asked.

Did you even listen to the latest Justin talk on Dawbench podcast? Maybe its a good start to get in into the real deal of Cockos and reaper.
pepe44 is offline   Reply With Quote
Old 11-17-2019, 09:45 AM   #56
pepe44
Human being with feelings
 
pepe44's Avatar
 
Join Date: Jul 2013
Location: Portugal
Posts: 1,827
Default

Quote:
Originally Posted by Klangfarben View Post
Well I can't say what their priorities are obviously. But it is a workflow killer so I think the OPs request is pretty valid and will make the argument and let the chips fall where they may.
Sure it is, im not against the OP request! we all would benefit from that.
But do you understand that is not on the Top priorities ? and why they are not ?
pepe44 is offline   Reply With Quote
Old 11-17-2019, 09:54 AM   #57
_Stevie_
Human being with feelings
 
_Stevie_'s Avatar
 
Join Date: Oct 2017
Location: Black Forest
Posts: 5,054
Default

I wouldn’t be too sure about this. No one really expected the devs to make Reaper work smoother with a huge track count, Then, from one day to another, we had this feature showing up in a pre. Expect the unexpected.
__________________
My Reascripts forum thread | My Reascripts on GitHub
If you like or use my scripts, please support the Ukraine: Ukraine Crisis Relief Fund | DirectRelief | Save The Children | Razom
_Stevie_ is online now   Reply With Quote
Old 11-17-2019, 09:55 AM   #58
Klangfarben
Human being with feelings
 
Join Date: Jul 2016
Location: Los Angeles, CA
Posts: 1,701
Default

Quote:
Originally Posted by pepe44 View Post
But do you understand that is not on the Top priorities ? and why they are not ?
I don't actually. I can't speak for the developers nor what their road map/priority list might be. They've certainly introduced new features out of the blue I never expected or thought I would ever see (like re-writing CC with interpolation) so this wouldn't be any different. I think discussing the developers mindset and what they may or may not do is pretty moot. As users all we can do is make the argument and show the need. Anything else is outside our purview.
Klangfarben is offline   Reply With Quote
Old 11-17-2019, 10:00 AM   #59
pepe44
Human being with feelings
 
pepe44's Avatar
 
Join Date: Jul 2013
Location: Portugal
Posts: 1,827
Default

http://dawbench.libsyn.com/episode-0...present-future
pepe44 is offline   Reply With Quote
Old 11-17-2019, 10:04 AM   #60
_Stevie_
Human being with feelings
 
_Stevie_'s Avatar
 
Join Date: Oct 2017
Location: Black Forest
Posts: 5,054
Default

Quote:
Originally Posted by Klangfarben View Post
As users all we can do is make the argument and show the need. Anything else is outside our purview.
That’s exactly right. There’s no room for speculations.
__________________
My Reascripts forum thread | My Reascripts on GitHub
If you like or use my scripts, please support the Ukraine: Ukraine Crisis Relief Fund | DirectRelief | Save The Children | Razom
_Stevie_ is online now   Reply With Quote
Old 11-17-2019, 10:09 AM   #61
Klangfarben
Human being with feelings
 
Join Date: Jul 2016
Location: Los Angeles, CA
Posts: 1,701
Default

Quote:
Originally Posted by pepe44 View Post
I listened to that as well. And apparently we should all be concerned because we are all going to have to switch to Linux.

Come on man. Stop convoluting the thread with speculation. If you support the feature then chime in with a plus 1. If you don't, then make the argument against. Btw, saying the developers don't have time for it isn't an argument against. Unless you had coffee with Justin this morning there's a pretty fair chance you don't know what's coming in the next pre.
Klangfarben is offline   Reply With Quote
Old 11-17-2019, 10:12 AM   #62
_Stevie_
Human being with feelings
 
_Stevie_'s Avatar
 
Join Date: Oct 2017
Location: Black Forest
Posts: 5,054
Default

Well, +1
__________________
My Reascripts forum thread | My Reascripts on GitHub
If you like or use my scripts, please support the Ukraine: Ukraine Crisis Relief Fund | DirectRelief | Save The Children | Razom
_Stevie_ is online now   Reply With Quote
Old 11-17-2019, 10:16 AM   #63
pepe44
Human being with feelings
 
pepe44's Avatar
 
Join Date: Jul 2013
Location: Portugal
Posts: 1,827
Default

Quote:
Originally Posted by Klangfarben View Post
I listened to that as well. And apparently we should all be concerned because we are all going to have to switch to Linux.

Come on man. Stop convoluting the thread with speculation. If you support the feature then chime in with a plus 1. If you don't, then make the argument against. Btw, saying the developers don't have time for it isn't an argument against. Unless you had coffee with Justin this morning there's a pretty fair chance you don't know what's coming in the next pre.
+1 , peace.
Not here to talk on developers behalf or make wrong suppositions.

Regarding the Linux, maybe its the future anyway..since 1980...
pepe44 is offline   Reply With Quote
Old 11-17-2019, 10:19 AM   #64
White Tie
Pixel Pusher
 
White Tie's Avatar
 
Join Date: Mar 2007
Location: Blighty
Posts: 4,950
Default

Quote:
Originally Posted by Klangfarben View Post
Why does everyone always make the argument that x feature request will completely break the Reaper code? Justin and Schwa aren't idiots.
Its not a matter of being idiots. Its a matter of replacing something known, tested and trusted with something untested and uncertain. The bigger the change, the bigger the degree of uncertainty and the greater the risk.

Its also not an absolute thing. Justin or Schwa might make a change seemingly flawlessly, and the hard-working folks in the pre forum might test it hard, and then months later something odd might happen for 3 users who like to run 48 instances of a bolivian noseflute plugin from 1992, and there would be no indication that it stems back to that change that was made. The potential time spent chasing that bugger down needs to be factored into the time the change would make.

Source : I have been responsible for causing this sort of thing!

GPU acceleration is only going to become more important, as future computers' screen resolutions rise and their CPU power is throttled to save power and thermals. This is the way things are going. This will need to be addressed. But the driving motivation will, I expect, come from users reporting poor performance, to which GPU utilization might be the cure, than from requests for GPU acceleration for its own sake.
__________________
The House of White Tie
White Tie is offline   Reply With Quote
Old 11-17-2019, 10:27 AM   #65
Klangfarben
Human being with feelings
 
Join Date: Jul 2016
Location: Los Angeles, CA
Posts: 1,701
Default

Thanks White Tie. All good points.

I do want to point out that it is in fact the poor performance that is driving the feature request, not just for its own sake. For those of us running large screens or multiple screens or with large templates, it's a big problem.

Also, I'd like to point out that I'm very partial to nose flute. And Linux
Klangfarben is offline   Reply With Quote
Old 11-17-2019, 01:19 PM   #66
pepe44
Human being with feelings
 
pepe44's Avatar
 
Join Date: Jul 2013
Location: Portugal
Posts: 1,827
Default

I have a Dual monitor setup and regularly i mix medium/large sessions (40 to 100 tracks). Some medium / heavy CPU load with routing, FX and outboard. I do "spread" outboard in a few submixes to offload the high PDC on one only Submix track. Do you guys do that ? If not maybe worth a test.
This new windows update 1909 made some things a bit smoother regarding the GUI spikes
I normally print tracks too.
pepe44 is offline   Reply With Quote
Old 11-17-2019, 04:17 PM   #67
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,688
Default

Quote:
Originally Posted by BirdBird View Post
i wouldn't really mind losing some processing power for FX processing
If CPU power is available without producing dropouts and cracks, it's given to the GUI thread, anyway.

-Michael
mschnell is offline   Reply With Quote
Old 11-17-2019, 04:19 PM   #68
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,688
Default

Quote:
Originally Posted by Xenakios View Post
Are you sure that is the case for example with the Windows win32 common controls.
Any text rendering is done by the GPU. anything else would result in a horrible performance.

-Michael
mschnell is offline   Reply With Quote
Old 11-17-2019, 04:22 PM   #69
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,688
Default

Quote:
Originally Posted by Klangfarben View Post
It could only negatively affect the audio if the CPU usage exceeded the number of remaining (non-dedicated) cores/threads. .
The count of tracks (plus master track) very often will be greater than the number of cores.

-Michael
mschnell is offline   Reply With Quote
Old 11-17-2019, 06:25 PM   #70
Xenakios
Human being with feelings
 
Xenakios's Avatar
 
Join Date: Feb 2007
Location: Oulu, Finland
Posts: 8,062
Default

Quote:
Originally Posted by mschnell View Post
Any text rendering is done by the GPU. anything else would result in a horrible performance.
Nah, I don't think so. Doing text rendering fully on the GPU is extremely complicated, doing it on the CPU would probably make much more sense, especially considering situations when the text needs to be incorporated with other graphics. (At least Cockos's Lice and Juce do it on the CPU. The Qt framework also used to. And I bet win32 common controls also do it on the CPU.)
__________________
I am no longer part of the REAPER community. Please don't contact me with any REAPER-related issues.
Xenakios is offline   Reply With Quote
Old 11-17-2019, 06:31 PM   #71
Xenakios
Human being with feelings
 
Xenakios's Avatar
 
Join Date: Feb 2007
Location: Oulu, Finland
Posts: 8,062
Default

Quote:
Originally Posted by heda View Post
I really wouldn't complain if we could have GPU accelerated graphics on scripts.
It wouldn't make any sense to implement it only for scripts, the needed effort would be pretty much the same as implementing it for Reaper's other graphics.
__________________
I am no longer part of the REAPER community. Please don't contact me with any REAPER-related issues.
Xenakios is offline   Reply With Quote
Old 11-18-2019, 12:21 AM   #72
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,688
Default

Quote:
Originally Posted by Xenakios View Post
Nah, I don't think so.
So I am in error here with m guessing ? I in fact did not do a research on that, as it seemed perfectly obvious to me: offloading True Type character rendering as the most computational intensive standard task from the CPU.

At my work, we once used a flash player embedded in the GUI of a program to avoid the need for handling such stuff in our own software, which was not intended to use the GPU.

-Michael

Last edited by mschnell; 11-18-2019 at 12:29 AM.
mschnell is offline   Reply With Quote
Old 02-12-2020, 06:04 PM   #73
PitchSlap
Human being with feelings
 
PitchSlap's Avatar
 
Join Date: Jan 2008
Location: Vancouver, BC
Posts: 3,793
Default

This could be very helpful, as it feels like a bit of a waste having high end GPU mostly unutilized.

I find high track and plugin counts the GUI seems to feel sluggish and a bit loose.

I don't think CPU is the limited factor.
__________________
FRs: v5 Media Explorer Requests, Global Quantization, Session View
Win10 Pro 64-bit, Reaper 6(x64), AMD 3950x, Aorus X570 Master, 64GB DDR4 3600, PowerColor Red Devil 5700XT, EVO 970 2TB, 10TB HD, Define R6
PitchSlap is offline   Reply With Quote
Old 02-13-2020, 05:36 AM   #74
Xenakios
Human being with feelings
 
Xenakios's Avatar
 
Join Date: Feb 2007
Location: Oulu, Finland
Posts: 8,062
Default

Quote:
Originally Posted by PitchSlap View Post
This could be very helpful, as it feels like a bit of a waste having high end GPU mostly unutilized.

I find high track and plugin counts the GUI seems to feel sluggish and a bit loose.

I don't think CPU is the limited factor.
It's been suggested some of the sluggishness in Reaper could be because of other things happening in the CPU GUI thread and not because of the graphics rendering itself. (Algorithmic inefficiencies, hard drive I/O...) That may be the case or not. If that is the case, then it would make sense for the Reaper developers to tackle those issues first, before starting a massive overhaul of how the graphics themselves are rendered, which might not in the end even help much. 3rd party plugins that use the CPU for their GUI of course wouldn't be helped at all by Reaper itself using the GPU.
__________________
I am no longer part of the REAPER community. Please don't contact me with any REAPER-related issues.
Xenakios is offline   Reply With Quote
Old 02-13-2020, 09:08 AM   #75
Klangfarben
Human being with feelings
 
Join Date: Jul 2016
Location: Los Angeles, CA
Posts: 1,701
Default

Quote:
Originally Posted by Xenakios View Post
It's been suggested some of the sluggishness in Reaper could be because of other things happening in the CPU GUI thread and not because of the graphics rendering itself. (Algorithmic inefficiencies, hard drive I/O...) That may be the case or not. If that is the case, then it would make sense for the Reaper developers to tackle those issues first, before starting a massive overhaul of how the graphics themselves are rendered, which might not in the end even help much. 3rd party plugins that use the CPU for their GUI of course wouldn't be helped at all by Reaper itself using the GPU.
The slow/sluggish GUI seems to be related more to high track count than anything else. It really has nothing to do with i/o or disk speed or even available CPU as many of us with high core count/clock speed have reported.
The GUI also tends to grind to a halt if you are trying to do something while the transport is playing. Many users have pointed out that this is wanted behavior so the audio thread is never interrupted but this is not common in other DAWs where you generally get good GUI response and refresh while playing (without affecting the audio). So it points more to the fact that Reaper's graphics implementation needs a major overhaul.

While GPU may or may not have a significant effect on that, there are many other things that would be greatly helped. For example, I'm on a 32 core machine and when I render a project in realtime, there is no video playback. If Reaper supported GPU hardware decoding, this wouldn't be an issue with video not refreshing while realtime rendering and I could make use of my high end Nvidia card. It would also save a lot of CPU especially with most of the commonly used video formats in post-production. So it's not just a matter of plugin GUI. There are other areas that could be improved as well with GPU support such as scripting where we are currently limited to 30fps and no hardware support. While it might be a large undertaking I think it is something that would benefit most users and make day-to-day use much more efficient. It is also something that is most likely going to get worse over time until it is sorted so dealing with it sooner than later might be the better option.
Klangfarben is offline   Reply With Quote
Old 12-02-2020, 06:45 AM   #76
b0se
Human being with feelings
 
b0se's Avatar
 
Join Date: Jan 2019
Location: UK
Posts: 938
Default

+1000

Made another post about this, after speaking to a plugin developer who mentioned that Reaper has a weird refresh rate issue.

Test yourself:

1. Empty project in Reaper

2. Load Pro Q3, Crave, Equilibrium or any cross DAW graphical parametric EQ

3. Add an EQ point and drag it around. It's a laggy/choppy movement.

Do the same with any other daw (or even Plugin Doctor) and it's as smooth as silk. As mentioned elsewhere, it's like gaming on a 50Hz monitor vs a 120Hz one.

Ironically, it makes the most efficient DAW out there feel laggy.

Side note: "and then months later something odd might happen for 3 users who like to run 48 instances of a bolivian noseflute plugin from 1992"

LOL!
__________________
Smooth V6 1080P/HiDPI Theme
b0se is offline   Reply With Quote
Old 12-02-2020, 10:19 AM   #77
pepe44
Human being with feelings
 
pepe44's Avatar
 
Join Date: Jul 2013
Location: Portugal
Posts: 1,827
Default

Quote:
Originally Posted by b0se View Post
+1000

Made another post about this, after speaking to a plugin developer who mentioned that Reaper has a weird refresh rate issue.

Test yourself:

1. Empty project in Reaper

2. Load Pro Q3, Crave, Equilibrium or any cross DAW graphical parametric EQ

3. Add an EQ point and drag it around. It's a laggy/choppy movement.

Do the same with any other daw (or even Plugin Doctor) and it's as smooth as silk. As mentioned elsewhere, it's like gaming on a 50Hz monitor vs a 120Hz one.

Ironically, it makes the most efficient DAW out there feel laggy.

Side note: "and then months later something odd might happen for 3 users who like to run 48 instances of a bolivian noseflute plugin from 1992"

LOL!
I admit i haven´t had much issues with the plugins that take advantage of GPU. I prefer to keep Reaper smooth and fast than having it supporting much graphics power and be slow. Maybe i´m wrong, correct me please. I like to learn
pepe44 is offline   Reply With Quote
Old 12-02-2020, 10:49 AM   #78
Jae.Thomas
Human being with feelings
 
Join Date: Jun 2006
Posts: 22,567
Default

When I use the NVIDIA utility, it doesn't show that reaper is running on the GPU... but look at what is:



why all these apps and not reaper
Jae.Thomas is offline   Reply With Quote
Old 12-02-2020, 04:50 PM   #79
operator
Human being with feelings
 
operator's Avatar
 
Join Date: Nov 2019
Location: Austria, near Lake Constance
Posts: 453
Default

Now is the time...
operator is offline   Reply With Quote
Old 12-03-2020, 12:08 AM   #80
xpander
Human being with feelings
 
xpander's Avatar
 
Join Date: Jun 2007
Location: Terra incognita
Posts: 7,670
Default

Quote:
Originally Posted by b0se View Post
1. Empty project in Reaper
2. Load Pro Q3, Crave, Equilibrium or any cross DAW graphical parametric EQ
3. Add an EQ point and drag it around. It's a laggy/choppy movement.
I'm afraid that test isn't detailed enough, unless you want proof that Reaper isn't necessarily laggy, depending...

Six year old i7 4770k with integrated CPU graphics, fast and responsive here. No, I'm never as nervous as below with real life adjustments, but I tried for this one.




Quote:
Originally Posted by b0se View Post
Ironically, it makes the most efficient DAW out there feel laggy.
I'm not doubting that there wouldn't be problems, depending on a case. But I find no irony in Reaper efficiency. It has easily been the most efficient DAW I've tried in recent years. YMMV, of course.

No reason for me being against these requests, even while they would apparently bring no benefit for me currently. But maybe as a reminder of a user base who is not all in with the latest and greatest, are having working setups regardless and don't want to lose that.

Last edited by xpander; 12-03-2020 at 10:41 AM.
xpander is online now   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 04:57 PM.


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