NVIDIA GPUs older than the 50XX series never supported 4:2:2 decoding so it's expected that VEGAS switches to the iGPU for these. Here I'm getting decent performance with my iGPU but it depends on the source footage.

One thing that did change in VP 23 is ACES- is view transform off (ACES disabled) in the project properties in both 22 and 23?

You are correct that older NVIDIA cards (like RTX 30xx or RTX 40xx) do not support 4:2:2 decoding, so the switch to the iGPU is expected. However, I want to clarify my main point:

Automatic Switching: I am aware that prior to VP22, we had to manually select the Intel iGPU for dedicated hardware decoding. The automatic switching between NVIDIA and Intel GPUs that was introduced in VP22 is actually a fantastic feature. It allows us to get proper 4:2:2 decoding while efficiently managing memory, avoiding the extra-large amount of shared iGPU memory or excessive VRAM usage, and it's not the source of the problem.

For example, when using a modern discrete card (like an RTX 30XX or 40XX, or current AMD cards) in combination with an 11th Gen or newer Intel CPU (like my i9-14900K), VEGAS Pro performs intelligent decoding.

Specifically, when the timeline contains both H.265 10-bit 4:2:0 and H.265 10-bit 4:2:2 media, VEGAS Pro intelligently manages the workload. It utilizes the Intel iGPU exclusively for the H.265 10-bit 4:2:2 decoding. Critically, it does this without the excessive VRAM usage by the RTX 3060 that would normally be dedicated to the H.265 10-bit 4:2:0 files, or the large amount of shared iGPU memory used if the iGPU were manually set as the sole decoder in the File I/O preferences.

In my opinion, this intelligent Automatic Switching leaves significantly more RAM and VRAM free to be utilized by other demanding elements in VEGAS Pro.

The Actual Issue: The true regression is that this automatic iGPU decoding (which works fine in VP22) fails specifically in VP23 when the Pixel Format is set to 32-bit floating point (full range). It functioned perfectly in 32-bit float in both VP21 and VP22.

This is simply a bug I wanted to highlight for the developers. Thank you for asking about ACES

I've uploaded the project settings screenshot for reference.

@Abdali: Please try to switch to ACES 1.3 and see if it improves the performance. This version supports DirectX and connects better to the new engine components.

View transform is off so it doesn't seem any ACES is in use.

On my laptop (Intel Xe + RTX 4060) I tested a few 10-bit 422 media. Only one ever worked with decoding and that was when I manually set the Xe in file io. So the switchover isn't working properly here. 32-bit is slower than 8-bit though that's as expected.

I can't test on my desktop as 422 media isn't decoding at all with 50XX GPUs.

@Abdali: Please try to switch to ACES 1.3 and see if it improves the performance. This version supports DirectX and connects better to the new engine components.

I have already tried switching the project to ACES 1.3, but unfortunately, this did not improve the performance or resolve the stuttering issue either.

On my laptop (Intel Xe + RTX 4060) I tested a few 10-bit 422 media. Only one ever worked with decoding and that was when I manually set the Xe in file io. So the switchover isn't working properly here. 32-bit is slower than 8-bit though that's as expected.

I can't test on my desktop as 422 media isn't decoding at all with 50XX GPUs.

It's strange that the switchover isn't working for you, because I've successfully tested the automatic switching feature on both of my systems, and it works great at correctly delegating the decoding task of H265 10Bit 422 file to the iGPU.

To be clear about my core issue: I'm not just saying the performance is slower in 32-bit float—which is expected—I'm saying the playback is severely stuttering (or jerky). This stuttering is a noticeable bug that did not exist in the previous versions (VP21/22), and that's the real problem I'm highlighting.

@Abdali For the stuttering issue I'd suggest contacting support so they can work with you directly.

A 5080 user had this diagnosis but I have no way of knowing if that's relevant to a 30XX GPU. My own GPUs are of a different generation and aren't exhibiting the issue you noted.

Vegas Pro Build 356 Performance & Color Issues

While testing Build 356 i have seen significant regression in VEGAS Pro 23 Build 356 regarding H.265 10-bit 4:2:2 media. Same project 32-bit floating point (full range), and the behavior has become even worse then Build 302.

1. Issue still remains Timeline Playback Playback of H.265 10-bit 4:2:2 media is extremely jerky and stuttery. Even on a clean timeline with zero effects, smooth previewing is impossible in 32-bit floating point (full range)

2. Severe Render Degradation (Build 356 vs 302) In Build 302 i could at least render normally to ProRes.it was still slower compared to Vegas Pro 22 but now In Vegas Pro Build 356 Renders now take roughly 5x longer in 32-bit floating point (full range) &

3. Broken Color/Gamma The colors are completely messed up in the final render in ProRes. The video is far too bright it looks like a major Color Range or Gamma mismatch is occurring.

This affects both Log and non-Log footage. It happens whether the footage is color-graded or left raw.

It was expected as other also had similar problems with this build 356, but still i wanted to share what i experienced hope we get a fix in the next update. :)