Jetson AGX Thor: VIC BW flat under GPU contention at high EMC; both drop at 665.6 MHz?

Robotics & Edge Computing Jetson Systems Jetson Thor
1

Hi,

On Jetson AGX Thor we are measuring DRAM contention between VIC and GPU, and
would like to confirm whether the behavior below is expected.

Setup

  • VIC: VPI rescale, 4K RGBA8 1:1 (~8 B/px read+write), VIC @ 1107 MHz
  • GPU: device copy at various loads
  • EMC locked (bwmgr min=max): 4266 / 3200 / 665.6 MHz

Results (approx.)

EMC (MHz) Peak DRAM (GB/s) VIC alone VIC w/ GPU GPU alone GPU w/ VIC
4266 ~250 ~30 ~30 (flat) high drops ~VIC
3200 ~180 ~30 ~30 (flat) high drops ~VIC
665.6 ~39 slightly↓ both ↓ — both ↓

Notes:

  • VIC alone is ~28–34 GB/s across 4266/3200; barely moves until 665.6.
  • tegrastats: VIC ~95%@1107 while EMC util stays low at high EMC.
  • Other VPI VIC ops (copy/convert/flip/…) do not exceed this ~34 GB/s class.

We currently interpret this as VIC being engine-limited (TRM DP-11881-002
§5.3: Throughput PPC 4; Linux DG: vic 1107 MHz → ~4.4 GPix/s → ~35 GB/s for
RGBA8 R+W), so at high EMC it only needs ~12–16% of DRAM and stays flat,
while GPU absorbs the deficit. At 665.6 MHz VIC already needs most of the
budget, so both drop. Datasheet DS-11945 §2.8 describes MSS arbitration /
client classes but does not say how VIC vs GPU share saturated DRAM.

Questions

  1. Is this expected?
  2. Any public doc on MSS QoS / arbitration between VIC and GPU?
  3. Is PPC×VIC_clk×bytes(R+W) the intended way to budget VIC DRAM traffic?

Thanks.

4

Hi,

Jetson is a shared memory system so the results look expected.
But we don’t have a public doc for the memory subsystem.

Below is the most relevant document for your reference:

Thanks.

5

Thanks for the clarification. I would like to better understand the bandwidth arbitration behavior between VIC and GPU.

In our measurements, we observe two different behaviors:

  • At 4266/3200 MHz, when GPU traffic is added, the VIC bandwidth remains almost unchanged (~30 GB/s), while the GPU bandwidth decreases by approximately the amount consumed by VIC.
  • At 665.6 MHz, where the total available DRAM bandwidth is much lower (~39 GB/s in our measurement), adding GPU traffic causes both VIC and GPU bandwidth to decrease.

This makes it look like the MSS treats VIC and GPU differently depending on whether the memory system is saturated:

At high EMC: VIC bandwidth appears to be satisfied first, and GPU takes most of the bandwidth contention.

At low EMC / near saturation: both VIC and GPU are throttled.

Could you clarify what arbitration/QoS mechanism in the MSS causes this behavior?

Specifically:

  1. Does VIC have a higher priority or some minimum-bandwidth guarantee compared with GPU?
  2. Is the arbitration based on client QoS classes, average/peak bandwidth requests, or another mechanism?
  3. Why would VIC appear to be protected at 3200/4266 MHz, but not fully protected when EMC is limited to 665.6 MHz?
  4. Is there any public documentation describing the MSS arbitration policy between VIC and GPU under DRAM saturation?

Thanks!

6

Hi,

We don’t have such a document.
But could you try to maximize the VIC clock to see if there is any difference?

Thanks.