sofit
martyghen wrote :
Not putting blame on anyone, just asking the devs to consider that it can actually work perfectly fine on lower spec machines for some people's use cases. The devs can't be expected to test every single configuration, so while it is helpful to make "recommendations" (different to mandatory system requirements), it would also be helpful to continue giving people the functionality to figure out how to get the most from this absolute banger software on their own system.
To simply say "buy bigger hardware" is gatekeeping and I dare say not consistent with VDJ's own philosophy as a software company offering up their platform entirely for free to some users. It's how I started, and I'm forever grateful for it.
Thanks all btw for keeping this bumped. Hoping it will help it get some love from the clever devs at VDJ :)
To simply say "buy bigger hardware" is gatekeeping and I dare say not consistent with VDJ's own philosophy as a software company offering up their platform entirely for free to some users. It's how I started, and I'm forever grateful for it.
Thanks all btw for keeping this bumped. Hoping it will help it get some love from the clever devs at VDJ :)
Please tell me the number of the video driver on which Stems 2.0 works stably on rtx 3050.
geposted Tue 28 Feb 23 @ 2:41 pm
martyghen
sofit wrote :
Please tell me the number of the video driver on which Stems 2.0 works stably on rtx 3050.
It's in the dx readout from og post - 31.0.15.1694
geposted Tue 28 Feb 23 @ 8:26 pm
martyghen
PhantomDeejay wrote :
Before RTX3050Ti come out, we would recommend "any" RTX card as all of them had sufficient VRAM.
When RTX3050Ti come out with only 4GB of VRAM the problem was apparent.
As I said above, stems 2.0 still work. But not with realtime GPU separation.
Also as I said above, the amount of VRAM used by the "engine" (the instructions set loaded byt he GPU to do the calculations) is not up to VirtualDJ. It's up to nVidia.
When RTX3050Ti come out with only 4GB of VRAM the problem was apparent.
As I said above, stems 2.0 still work. But not with realtime GPU separation.
Also as I said above, the amount of VRAM used by the "engine" (the instructions set loaded byt he GPU to do the calculations) is not up to VirtualDJ. It's up to nVidia.
Is there a reason NOT to re-enable the force GPU option then if it works? It's pretty easy to get around the real-time challenge by just loading your track a few seconds before you need to hit the play button, or precomputing the stems, for which use of GPU is still very handy because it's still waaaaaaay better than relying on the CPU.
So my point here is even if the devs see it as imperfect for real-time, it still has a lot of use cases for plenty of people, and defaulting to CPU is pretty bad from the user's perspective.
geposted Tue 28 Feb 23 @ 8:31 pm
PhantomDeejay
What you need to understand is that VirtualDJ switches from GPU to CPU when it detects that CPU decoding would be faster. We don't switch from GPU to CPU just to make users life more difficult.
When the VRAM of your GPU gets consumed, it's decoding speed becomes slower than what your CPU can achieve.
So, in a nutshell:
Your GPU (RTX 3050) may start working "great" but then it becomes slow. And once it becomes slow enough (because it has not enough memory and it got consumed) VirtualDJ switches decoding to CPU because CPU at that point is faster. So, VirtualDJ tries to always use the fastest option.
That being said, we are working against possible work-arounds, but the truth is that this card will never offer great speeds.
When the VRAM of your GPU gets consumed, it's decoding speed becomes slower than what your CPU can achieve.
So, in a nutshell:
Your GPU (RTX 3050) may start working "great" but then it becomes slow. And once it becomes slow enough (because it has not enough memory and it got consumed) VirtualDJ switches decoding to CPU because CPU at that point is faster. So, VirtualDJ tries to always use the fastest option.
That being said, we are working against possible work-arounds, but the truth is that this card will never offer great speeds.
geposted Tue 28 Feb 23 @ 9:33 pm
martyghen
PhantomDeejay wrote :
What you need to understand is that VirtualDJ switches from GPU to CPU when it detects that CPU decoding would be faster. We don't switch from GPU to CPU just to make users life more difficult.
When the VRAM of your GPU gets consumed, it's decoding speed becomes slower than what your CPU can achieve.
So, in a nutshell:
Your GPU (RTX 3050) may start working "great" but then it becomes slow. And once it becomes slow enough (because it has not enough memory and it got consumed) VirtualDJ switches decoding to CPU because CPU at that point is faster. So, VirtualDJ tries to always use the fastest option.
That being said, we are working against possible work-arounds, but the truth is that this card will never offer great speeds.
When the VRAM of your GPU gets consumed, it's decoding speed becomes slower than what your CPU can achieve.
So, in a nutshell:
Your GPU (RTX 3050) may start working "great" but then it becomes slow. And once it becomes slow enough (because it has not enough memory and it got consumed) VirtualDJ switches decoding to CPU because CPU at that point is faster. So, VirtualDJ tries to always use the fastest option.
That being said, we are working against possible work-arounds, but the truth is that this card will never offer great speeds.
Okay well that's good to know that it has those sorts of smarts built in! But my experience is that my RTX3050 works consistently great in v2023 b7388 for STEMS 2.0, and never flips to CPU.
So based on what you're saying about it making its own choice about what's faster, there might actually be a bug here after b7388 because when I use b7388 it uses the GPU without any issues for processing STEMS2.0 and I'm yet to ever see it revert to CPU on that version. Beyond this version, VDJ is switching to CPU when it probably does not need to (all the time), and STEMS goes from the shining beacon of VDJ to unusable. Which makes me very sad, because it's SO cool.
Which takes me back to my original speculation - Could it be erroneously detecting and trying to use the onboard graphics (used only for display output and would most certainly not be capable of doing anything STEMS related) rather than detecting the actual RTX card (used for rendering / should be used for VDJ / was being used until after b7388)? Or perhaps jumping the gun in discarding the GPU in favour of the CPU?
geposted Tue 28 Feb 23 @ 10:01 pm
martyghen
And by "jumping the gun" (sorry, that might be a colloquialism?) I mean, perhaps the method it uses to make the speed assessment is flawed in some way, and the metrics report the GPU would be slower, even though in reality, it is actually still a much better option than the CPU? Or maybe some hard coded rules like never using certain cards (like mine) without even testing it were introduced? All just speculation of course, but I'm just trying to give some ideas for exploring this problem.
geposted Tue 28 Feb 23 @ 10:23 pm
IIDEEJAYII
Try the latest EA 7474 build:
BUILD 7474 (2023-02-28)
-Allow partial GPU acceleration with RTX3000 with 4GB memory
BUILD 7474 (2023-02-28)
-Allow partial GPU acceleration with RTX3000 with 4GB memory
geposted Tue 28 Feb 23 @ 10:40 pm
martyghen
IIDEEJAYII wrote :
Try the latest EA 7474 build:
BUILD 7474 (2023-02-28)
-Allow partial GPU acceleration with RTX3000 with 4GB memory
BUILD 7474 (2023-02-28)
-Allow partial GPU acceleration with RTX3000 with 4GB memory
Sounds promising! I'll give it a go tonight and report back :)
geposted Wed 01 Mar 23 @ 1:04 am
martyghen
IIDEEJAYII wrote :
Try the latest EA 7474 build:
BUILD 7474 (2023-02-28)
-Allow partial GPU acceleration with RTX3000 with 4GB memory
BUILD 7474 (2023-02-28)
-Allow partial GPU acceleration with RTX3000 with 4GB memory
I'm sad to report that this has not resolved the issue. But it did give me a bit more of a chance to test my theory about it using the onboard graphics to compute stems (which in the case of most laptops, is just just as the display output), rather than the main GPU (used for rendering / math / stems, in theory). And it looks as though that is one area where things are definitely going wrong.
You'll see in the below the CPU and onboard graphics ramp up on track load as it begins to compute stems, but the RTX card does not, it just remains stable and appears not to be used. In this case, the stems compute at around 10 seconds of track per minute.
When I disable the onboard graphics and use only the RTX the stems definitely compute faster (obviously because it's not trying to do anything with the onboard graphics) but it's still not using the RTX card. And for some reason this causes the VJD interface to lag terribly, so having this setting permanently isn't an option (I also can't use an external monitor without both cards on; true for a lot of laptops I think). See below with only RTX card enabled:
So there is probably two issues still present here (1) VDJs detection of GPU needs to be careful not to consider onboard graphics (if that turns out to be the problem), and (2) partial use of RTX GPUs doesn't seem to work on some (my) hardware, and there is no way to force it since the force GPU use option was removed. Bringing back the force GPU option with card selection could potentially solve both of these issues, but perhaps you had reasons for getting rid of that option?
Let us know how you go digging into these issues further. And thanks heaps for working on it for us :)
geposted Wed 01 Mar 23 @ 9:15 pm
djdad
Can you try to disable 'Don't Use GPU' in StemsFix setting (if not already) and see if any difference ?
geposted Wed 01 Mar 23 @ 9:35 pm
martyghen
Further to the above post, I went back and timed the compute of stems in b7388 where it DOES use the RTX card perfectly well, and it computes STEMS 2.0 at about 1 minute of track in 5 seconds of real time.
In the above post, after disabling the onboard GPU, resulting in only CPU use, STEMS 2.0 are computed at around 1 minute of track in 15 seconds real time.
And as mentioend above, when it tries to use the onboard graphics to compute STEMS 2.0 it obviously just becomes unusable at 10 seconds of track taking about 1 minute of real time haha. Of course nobody actually wants to do that though :)
In the above post, after disabling the onboard GPU, resulting in only CPU use, STEMS 2.0 are computed at around 1 minute of track in 15 seconds real time.
And as mentioend above, when it tries to use the onboard graphics to compute STEMS 2.0 it obviously just becomes unusable at 10 seconds of track taking about 1 minute of real time haha. Of course nobody actually wants to do that though :)
geposted Wed 01 Mar 23 @ 9:35 pm
martyghen
djdad wrote :
Can you try to disable 'Don't Use GPU' in StemsFix setting and see if any difference ?
It was already disabled (unckeched) for all the above tests.
If I enable it (checked) then the onboard graphics do not get used, only the CPU gets used, and performance is as mentioned above with only CPU.
I reinstalled and tested this in EA 7474.
geposted Wed 01 Mar 23 @ 9:44 pm
djcel
What do you have for the option "skinUseLowPowerGPU" ?
Activate both video cards, remove the nvidia profile if you have one and test this option (VirtualDJ needs to restart when you change it)
Activate both video cards, remove the nvidia profile if you have one and test this option (VirtualDJ needs to restart when you change it)
geposted Wed 01 Mar 23 @ 9:57 pm
martyghen
djcel wrote :
What do you have for the option "skinUseLowPowerGPU" ?
I can't remember the exact name (and I am out of the house now so can't check) but I am fairly sure it's the automatic one.
I can confirm and try other options later today if helpful?
geposted Wed 01 Mar 23 @ 10:06 pm
martyghen
djcel wrote :
What do you have for the option "skinUseLowPowerGPU" ?
Activate both video cards, remove the nvidia profile if you have one and test this option (VirtualDJ needs to restart when you change it)
Activate both video cards, remove the nvidia profile if you have one and test this option (VirtualDJ needs to restart when you change it)
Sure I'll give it a go! Won't be back home until the afternoon now though
geposted Wed 01 Mar 23 @ 10:07 pm
djcel
With this option, you can force the skin to be used by the intel video card so the nvidia is free to be used for other tasks.
geposted Wed 01 Mar 23 @ 10:14 pm
martyghen
djcel wrote :
With this option, you can force the skin to be used by the intel video card so the nvidia is free to be used for other tasks.
Just gave this a test in b7474 and can confirm that the setting chosen here has no impact on the issues described above (i.e., the issues persist regardless of this setting).
geposted Thu 02 Mar 23 @ 7:27 am
martyghen
Okay I have discovered a workaround that works in b7474!
In the NVIDIA control panel in Windows, on dual GPU machines there is an option to force programs to use a specific GPU (either the integrated graphics OR the high power GPU). In this panel if you force the VirtualDJ "app" to use the high powered GPU (in my case, an RTX3050) as shown below, then the problem of VDJ using the integrated graphics to try and compute stems goes away and the software picks up the presence of a high powered GPU and uses it over the CPU. Banger!
I say "workaround" because think it would still be worthwile implementing a solution within VDJ's code that checks for this quirk and avoids trying to use integrated grpahics to compute stems. But at least it seems with the workaround in place (and integrated graphics out of the equation), b7474 now recognises that my RTX 3050 is indeed faster than the CPU and it uses the GPU, which is great.
In the NVIDIA control panel in Windows, on dual GPU machines there is an option to force programs to use a specific GPU (either the integrated graphics OR the high power GPU). In this panel if you force the VirtualDJ "app" to use the high powered GPU (in my case, an RTX3050) as shown below, then the problem of VDJ using the integrated graphics to try and compute stems goes away and the software picks up the presence of a high powered GPU and uses it over the CPU. Banger!
I say "workaround" because think it would still be worthwile implementing a solution within VDJ's code that checks for this quirk and avoids trying to use integrated grpahics to compute stems. But at least it seems with the workaround in place (and integrated graphics out of the equation), b7474 now recognises that my RTX 3050 is indeed faster than the CPU and it uses the GPU, which is great.
geposted Thu 02 Mar 23 @ 7:55 am
martyghen
And just to add to this for clarity, those settings to force use of the high powered GPU were not required in b7388, which used the GPU regardless of the NVIDIA control panel settings.
So something must have changed after b7388 to do with the detection of GPUs (and unintended use of integrated graphics for calculating stems) that needs consideration as suggested above.
But yeah generally speaking, thanks dev team if you're reading this, VDJ's algorithms are honestly kick ass, and even as a data data scientist by day, they still blow my mind. Keep up the good work!
So something must have changed after b7388 to do with the detection of GPUs (and unintended use of integrated graphics for calculating stems) that needs consideration as suggested above.
But yeah generally speaking, thanks dev team if you're reading this, VDJ's algorithms are honestly kick ass, and even as a data data scientist by day, they still blow my mind. Keep up the good work!
geposted Thu 02 Mar 23 @ 7:59 am
Adion
Which cpu do you have? And which amount of memory does it show for the iris in task manager?
geposted Thu 02 Mar 23 @ 9:30 am
