u/iamgarffi

Yes, its nothing new today. Both Intel and AMD provide a fixed number of PCIE lanes supported by the CPU, with remaining ones driven by chipsets.

What is hard to understand is why today we're still seeing such a low ceiling for lane availability?

Flagship boards offer up to 7 nvme slots (1-2 true gen 5.0 x4) with remaining ones as pcie 4.0.

For instance ROG X870E Glacial (Extreme variant). Marketing is very proud of 7 nvme drive support, but that comes with big limitations and lane budgeting:

I have 4 nvmes (1x gen 5.0 x4) and 3x gen 4.0 x4.

I can place my boot drive in M2_1 (shared with cpu, without stealing lanes from primary pcie x16 gpu slot). Fine

M2_2 is out of the question as populating that slot will drop gpu to X8 (technically doable as even RTX 5090 works fine in X8 mode with 1-3% drop) - but what about 1-2 years from now when new card drop with higher bandwidth?

M2_3 is chipset driven so nvme inserted there will run as gen 4.0 x4. So far so good.

Remaining 2 drives. Decision comes to either pcie x16 hypercard or dimm2.

The sad part about dimm.2 is that one side is pcie 4.0 x4 and other is pcie 4.0 x2 only.

TLDR
So in the end no matter how you slide or dice it, if you want all 7 nvmes, you'll neuter your GPU bandwidth and some of the drives. (dropping to x2 will reduce throughput by half).

Or... even if you decide to go the route with Hypercard, forget about bottom mounted fans or feeding GPU fresh cool air - so again, storage at the expense of GPU performance.

I wish AMD/Intel and board makers work together for once and consider raising the ceiling.

Yes, I am talking to you Lisa and whatever puppet that runs Intel today. Get your acts together.

Thoughts? How's your experience with multi nvme drives?

https://preview.redd.it/56djhpqxeb1h1.jpg?width=4032&format=pjpg&auto=webp&s=cdec3429745029e791fbcae484fa99135e1a09e0

https://preview.redd.it/2z3f9qqxeb1h1.jpg?width=4032&format=pjpg&auto=webp&s=b588db9b6e509a1b443ac8bc6c7a68f6e2fc1759

https://preview.redd.it/7ygsrpqxeb1h1.jpg?width=4032&format=pjpg&auto=webp&s=5f4ec9d03ab95df0e76e7e14585e447d709207f2

Offering pristine XIO (full retail experience) with condition of 10/10.

Included:
- everything that you would find in retail packaging. Ear-tips unused (picture includes Eletech Baroque Stage tips).

Interested in trading for Noble Audio Onyx (full retail experience) ideally in great to pristine condition as well.

You might remember me from few past posts, excited for both Thor III PSU and Equalizer cable.

While the latter didnt arrive on the market yet (and received a healthy dose of scrutiny from Roman on YT) I have decided to share quick updates on the PSU alone.

I used to have the ROG Loki in 1000 and 1200W to pair with RTX 5090 (Astral LC) and no matter the workload (gaming or creative work with rendering or LLMs) sooner or later I would see the card scream with it's blinking red light, indicating either severe current imbalance or above the threshold reading on 12v-2x6 connector.

I had a chance to introduce Thor III 1200W (did not go with 1600W variant for obvious reasons - price) to may day to day use cases and I have not seen a single indication of imbalance.

Regardless of 4K gaming with Path tracing, 8K video renders or training my home LLM.

And this is with stock cable that came in the box. Either I have been extremely lucky with my kit or "stock" cable is good enough and I might skip the Equalizer hype altogether.

Attaching quick HWiNFO for reference. While there is a difference between pins, not even once I've seen it climb to 9amps. That's something...

Thor III with stock cable

I’m trying to understand whether this is expected behavior, a config issue, or an RTX 50-series optimization problem in Topaz Video 1.5.0.

System

• GPU: NVIDIA GeForce RTX 5090, 32 GB VRAM
• Driver: 596.36
• CUDA reported by NVIDIA-SMI: 13.2
• OS: Windows 11 25H2
• Source: 1080p MKV
• Output: 3840×2160
• Tested models: Proteus / prob-4, Artemis / amq-13
• Tested output encoders: H.264 NVENC, HEVC Main10 NVENC, AV1 NVENC

Issue

During 1080p → 4K enhancement/upscale, the RTX 5090 appears heavily underutilized.

Preview mode in this build only shows percentage complete, not FPS, so I used NVIDIA-SMI as the main diagnostic signal. During a 30-second preview, GPU SM utilization mostly sits around 25–40% during the active processing phase, with occasional short spikes higher. NVENC and NVDEC usage remain very low.

Example from nvidia-smi dmon -s u during a 30-second preview:

# gpu     sm    mem    enc    dec    jpg    ofa
# Idx      %      %      %      %      %      %
    0     85     14      0     11      0      0
    0     33      6      0     10      0      0
    0     41      7      0      0      0      0
    0     39      7      4      0      0      0
    0     24      4      0      0      0      0
    0     32      5      4      2      0      0
    0     29     10      5      0      0      0
    0     27     10      6     11      0      0
    0     30     11      6      0      0      0
    0     28     10      7      0      0      0
    0     29     10      6      0      0      0
    0     28     10      6      0      0      0
    0     34     12      6     14      0      0

The early 85% SM spike shows the card can be loaded by the workload, but steady-state active processing settles much lower, usually around 25–40%. Encoder utilization is typically only around 0–7%, so NVENC does not appear to be the main bottleneck.

FFmpeg / Topaz command example

Topaz launches its bundled FFmpeg with the custom tvai_up filter. Example from a HEVC Main10 NVENC preview:

"C:\Program Files\Topaz Labs LLC\Topaz Video\ffmpeg" -hide_banner -nostdin -y -nostats
-t 3.019683251259194
-ss 1948.806
-i "C:/Users/adamm/Downloads/test_t00.mkv"
-flush_packets 1
-sws_flags spline+accurate_rnd+full_chroma_int
-filter_complex tvai_up=model=prob-4:scale=0:w=3840:h=2160:preblur=0:noise=0:details=0:halo=0:blur=0:compression=0:estimate=8:blend=0.2:device=0:vram=0.9:instances=0,scale=w=3840:h=2160:flags=lanczos:threads=0
-fflags +flush_packets
-c:v hevc_nvenc
-profile:v main10
-pix_fmt p010le
-b_ref_mode disabled
-tag:v hvc1
-g 30
-preset p5
-tune hq
-rc constqp
-qp 17
-rc-lookahead 20
-spatial_aq 1
-aq-strength 15
-b:v 0
-an
-fps_mode:v passthrough

This confirms that:

tvai_up is targeting GPU device 0
vram=0.9 is being passed
instances=0 is being passed
HEVC output is using hevc_nvenc

What I already tested

Topaz originally used NVENC -preset p7. I modified video-encoders.json so the NVIDIA NVENC profiles use -preset p5 instead.

Topaz honored the change. The FFmpeg command now shows:

-preset p5

instead of:

-preset p7

However, this did not materially fix GPU underutilization. NVENC usage remains low, so the output encoder does not appear to be the limiting factor.

I also tested with grain disabled to reduce encoder and post-processing load. The GPU still did not reach sustained high utilization.

Bundled FFmpeg NVIDIA capability check

Topaz’s bundled FFmpeg exposes the expected NVIDIA encoders:

av1_nvenc
h264_nvenc
hevc_nvenc

It also exposes NVIDIA/CUDA decode and hardware acceleration paths:

av1_cuvid
h264_cuvid
hevc_cuvid
cuda
dxva2
d3d11va
d3d12va

So this does not look like a missing FFmpeg/NVIDIA codec support issue.

Suspicious part

The command uses NVENC for output and sends tvai_up to GPU device 0, but the input side does not appear to explicitly request hardware decode. The command starts with a normal input:

-i "source.mkv"

I do not see pre-input decode flags like:

-hwaccel cuda
-hwaccel d3d11va
-hwaccel_output_format cuda
-c:v h264_cuvid
-c:v hevc_cuvid

That may or may not matter for this workload, but it is worth asking because decode usage is inconsistent and generally low.

The bigger suspicion is the tvai_up scheduling / inference pipeline:

device=0:vram=0.9:instances=0

I assume instances=0 means automatic model instance selection. If so, auto may be choosing too conservatively for a 5090, leaving the card underfed.

Performing similar type of work (upscaling + tone mapping) in different Software, like DaVinci Resolve Studio does allow me to utilize 90% of cards resources (and in result less time).

Questions for Topaz developers

1. Is sustained 25–40% SM utilization expected on an RTX 5090 during 1080p → 4K Proteus/Artemis enhancement?
2. What exactly does instances=0 mean in the tvai_up filter?
3. Is there a supported way to manually tune the tvai_up instance count, worker count, frame queue depth, or pipeline depth?
4. Does vram=0.9 only control VRAM allocation limit, or does it influence processing parallelism?
5. Is Topaz expected to use NVDEC / CUDA / D3D11VA decode automatically, or is CPU/software decode intentional?
6. Are there hidden config options for RTX 40/50-series cards to improve GPU occupancy?
7. Is there a known RTX 50-series / Blackwell optimization issue in Topaz Video 1.5.0 and older?
8. Would a full export behave materially differently from preview mode, or does preview use the same tvai_up pipeline?

Based on the data, NVENC does not appear to be the bottleneck. The card is being used, but the RTX 5090 is not being fed enough sustained AI work. This looks more like a tvai_up inference scheduling / pipeline utilization issue than an encoder issue.

Thanks in advance,

-Adam

I remember Topaz Video AI being great. Not the fasted but very stable in results. I was able even to run enhancement + HDR in a single pass from 1080>4K.

Today, with newer version of the app (Topaz Video version 1.x) combining presets results in a crash (unrecoverable error). Even running them separately never completes on both PC and Mac.

Specs:

Mac:
M5 Pro + 48G of RAM

PC:
AMD 9950X3D, 64G RAM + RTX 5090

What is your experience with these newer versions?

Not sure if this was always like this but Lian Li products on software and firmware side went to s**t in the past few years.

No matter the build, all of their wireless products are simply unstable regardless if connected to motherboard headers or rear motherboards usb ports.

I wont blame the L-Connect3 or its Service but rather poor firmware on the wireless controller resetting itself all the time.

===== 2026-05-10 15:16:37.811 =====
REMOVED: USBDevice | OK | SLV3TX_V1.6 | USB\VID_0416&PID_8040\9&CABBDF3&0&3
REMOVED: USBDevice | OK | SLV3RX_V1.6 | USB\VID_0416&PID_8041\9&CABBDF3&0&2
===== 2026-05-10 15:16:38.783 =====
ADDED:   USBDevice | OK | SLV3TX_V1.6 | USB\VID_0416&PID_8040\9&CABBDF3&0&3
ADDED:   USBDevice | OK | SLV3RX_V1.6 | USB\VID_0416&PID_8041\9&CABBDF3&0&2
===== 2026-05-10 15:17:00.012 =====
REMOVED: USB | OK | Generic USB Hub | USB\VID_1A86&PID_8091\8&15CD6C09&0&11
REMOVED: USBDevice | OK | SLV3TX_V1.6 | USB\VID_0416&PID_8040\9&CABBDF3&0&3
REMOVED: USBDevice | OK | SLV3RX_V1.6 | USB\VID_0416&PID_8041\9&CABBDF3&0&2
===== 2026-05-10 15:17:00.992 =====
ADDED:   USB | OK | Generic USB Hub | USB\VID_1A86&PID_8091\8&15CD6C09&0&11
ADDED:   USBDevice | OK | SLV3TX_V1.6 | USB\VID_0416&PID_8040\9&CABBDF3&0&3
ADDED:   USBDevice | OK | SLV3RX_V1.6 | USB\VID_0416&PID_8041\9&CABBDF3&0&2
===== 2026-05-10 15:17:29.031 =====
REMOVED: USBDevice | OK | SLV3RX_V1.6 | USB\VID_0416&PID_8041\9&CABBDF3&0&2
===== 2026-05-10 15:17:29.948 =====
REMOVED: USBDevice | OK | SLV3TX_V1.6 | USB\VID_0416&PID_8040\9&CABBDF3&0&3
ADDED:   USBDevice | OK | SLV3RX_V1.6 | USB\VID_0416&PID_8041\9&CABBDF3&0&2
===== 2026-05-10 15:17:30.894 =====
ADDED:   USBDevice | OK | SLV3TX_V1.6 | USB\VID_0416&PID_8040\9&CABBDF3&0&3
===== 2026-05-10 15:18:42.682 =====
REMOVED: USBDevice | OK | SLV3TX_V1.6 | USB\VID_0416&PID_8040\9&CABBDF3&0&3
REMOVED: USBDevice | OK | SLV3RX_V1.6 | USB\VID_0416&PID_8041\9&CABBDF3&0&2
===== 2026-05-10 15:18:43.611 =====
ADDED:   USBDevice | OK | SLV3TX_V1.6 | USB\VID_0416&PID_8040\9&CABBDF3&0&3
ADDED:   USBDevice | OK | SLV3RX_V1.6 | USB\VID_0416&PID_8041\9&CABBDF3&0&2
===== 2026-05-10 15:19:22.334 =====
REMOVED: USBDevice | OK | SLV3TX_V1.6 | USB\VID_0416&PID_8040\9&CABBDF3&0&3
REMOVED: USBDevice | OK | SLV3RX_V1.6 | USB\VID_0416&PID_8041\9&CABBDF3&0&2
===== 2026-05-10 15:19:23.260 =====
ADDED:   USBDevice | OK | SLV3TX_V1.6 | USB\VID_0416&PID_8040\9&CABBDF3&0&3
ADDED:   USBDevice | OK | SLV3RX_V1.6 | USB\VID_0416&PID_8041\9&CABBDF3&0&2