Yes. The SN7100 platform ships with DRAM. That is the answer most people came for, and it is also the least useful of the three facts hiding inside the question — presence, capacity, and bandwidth are not the same fact, and only two of them tell you anything about whether an AR render path will survive on a warm phone.

The distinction matters because of who usually types this query. It is rarely someone shopping for a handset. It is someone sizing a build who needs a yes or no before they can go further. The trap is treating the yes as a checkbox: “the chip has memory, therefore any device carrying it can hold our render path.” Devices carrying the same SoC do not necessarily expose the same memory configuration, and the configuration is what your renderer actually lives inside.

What does “does the SN7100 have DRAM” actually tell you?

Very little on its own. Read the answer as three separate facts:

• Presence — yes, there is DRAM. Confirms the platform is a general-purpose target rather than a fixed-function one.
• Capacity — how much of it a given device ships with, which varies by handset SKU even when the SoC does not.
• Bandwidth — how fast the memory can be fed, and how that rate is shared with the display and camera pipeline.

A useful rule of thumb: capacity decides whether your workload loads at all; bandwidth decides whether it holds frame rate once loaded. Read capacity first, because it is a hard wall — an over-budget model is killed by the OS, not slowed down. Then read bandwidth, because that is where a try-on session quietly loses its frame budget.

The sharing question is the part most spec-reading skips. On a mobile SoC, DRAM is a shared resource: the camera pipeline is writing frames into it, the display compositor is reading from it, and your inference and render passes are competing with both. What is installed and what is available to a rendering workload are different numbers, and the gap widens on non-flagship devices under thermal load, where clocks drop and the memory controller is doing the same work at a lower rate.

What it changes for a virtual try-on build

Concretely: it changes your estimate of how many sessions can run on-device versus routing to a cloud fallback. That single ratio drives both inference cost and perceived latency across the phone mix you actually serve. Getting the memory read right at spec-reading time is what keeps a session inside a sub-200 ms response budget on mid-tier hardware; getting it wrong surfaces as out-of-memory kills and frame-rate collapse on warm devices during a live campaign, not in the lab.

What it does not change: your model architecture, your quantisation choices, or your accuracy targets. Memory configuration sets the envelope. It does not tell you which model belongs inside the envelope — that is a separate decision, made against measured behaviour on the device, not against a spec sheet.

In our GPU engineering work, per-chip memory figures land in a per-device memory profile table alongside sustained clock behaviour, thermal headroom, and observed render-tier ceilings. One row per device, not one row per SoC. That profile is what sets render tier and fallback thresholds for a retail AR deployment; a bare “has DRAM: yes” contributes nothing to it.

The device-tiering argument behind those thresholds — why the same SoC produces different render ceilings across handsets, and how we group devices into tiers — is developed in our work on GPU performance tiering across consumer devices.

So the honest version of the answer is: yes, and the yes is where the work starts. What is the available bandwidth on your worst-supported device, at steady state, with the camera running?