“Does the SN7100 have DRAM?” looks like a hardware trivia question. For a retail AR try-on deployment it is nothing of the sort — it is one input to a per-device rendering-tier budget that decides whether a phone runs the full on-device pipeline, a reduced tier, or the cloud fallback. Answer it wrong for a class of devices in your served mix and you find out mid-campaign, when warm phones start dropping frames and the OS quietly kills the session for running out of memory. The trap is treating the chip name as a sufficient answer. Two phones can carry the same SoC and behave differently under a virtual try-on load because the memory that actually feeds the renderer — its capacity, its bandwidth, and how it degrades once the die heats up — is not fully described by the marketing tier. A memory profile is a constraint you read before launch, not a datasheet line you glance at afterward. Does the SN7100 have DRAM? Almost certainly yes — but the useful answer is not “yes.” Practically every modern application-class SoC ships with DRAM: it needs somewhere to hold the framebuffer, the model weights, the intermediate tensors, and the OS working set. The question a naive reader is really asking is “will this device run my try-on pipeline?”, and DRAM presence alone does not answer that. What matters is the memory profile, three numbers that travel together: Capacity — how much DRAM the system exposes to your process after the OS, the camera stack, and other foreground apps take their share. A device that advertises a large total can leave you a much smaller usable budget. Bandwidth — how fast the renderer can move bytes between DRAM and the compute units. For a real-time try-on overlay this often binds tighter than raw compute, because each frame streams texture, geometry, and segmentation buffers. Packaging — whether the DRAM is on-package (LPDDR stacked near or with the SoC) or off-package, which changes latency and the thermal coupling between memory traffic and the compute die. Treat any single spec number as decision-grade evidence only when you have named its source and measured it on the target device. Everything below is about turning that profile into a rendering-tier decision — the same discipline we apply to memory capacity versus the real bottleneck on larger GPUs, scaled down to the phone in a shopper’s hand. Why a DRAM profile decides the on-device rendering tier A virtual try-on pipeline is a chain of memory-hungry stages: capture the camera frame, segment the body or face, fit a mesh, rig the garment or accessory, render it into the scene, and composite. Each stage allocates buffers, and several of them run every frame inside a sub-200 ms response budget. Miss that budget consistently and the overlay feels detached from the shopper’s movement, which is the difference between a feature people use and one they close. Memory constrains this in two ways that compute does not. First, capacity sets a hard ceiling: if the working set of your model weights plus the render targets exceeds usable DRAM, the OS reclaims memory aggressively, and on mobile that ends in an out-of-memory kill rather than graceful slowdown. Second, bandwidth sets the sustained frame rate: fusing passes to cut round trips to DRAM is exactly why techniques like fusing GPU passes into a single kernel for frame-locked AR overlays matter — they reduce how many times a frame’s data crosses the memory bus. This is why device tiering is a memory decision before it is anything else. On the GPU-engineering side, the same reasoning shows up in how unified virtual memory shapes XR rendering budgets: where the buffers physically live, and how the runtime pages them, is the constraint that sets the achievable frame rate. Our GPU engineering practice treats the per-device memory profile as the first input to that budget, not an afterthought — because it decides which devices in a retail AR mix earn full on-device rendering and which get demoted. How thermal throttling turns a healthy memory profile bad The measurement that fools people is the cold one. Run a try-on session for ten seconds on a phone straight out of a pocket and the memory subsystem looks fine. Run it for two minutes in a warm store, back-to-back sessions, and the picture changes. As the die heats up, the memory controller and the DRAM itself throttle to stay inside thermal limits. Effective bandwidth drops, memory-access latency climbs, and the compute units that share the thermal envelope clock down at the same time. The renderer that comfortably held 60 fps cold now misses its frame deadline, and in a mesh-fitting pipeline a slower frame is not just choppier — it can also mean fewer refinement iterations per frame, so the garment fit visibly degrades. In our experience across edge rendering work, this warm-device collapse is the failure that gets missed most often because it never shows up in a cold bench run — treat it as an observed pattern, not a benchmarked figure, and design your test to reproduce it. Mid-tier phones feel this hardest. They have less thermal headroom, tighter memory budgets, and they are the bulk of the mix a mainstream retailer serves. Flagships coast; the mid-tier is where your tiering logic earns its keep. The same core-and-clock reasoning behind what multi-core versus single-core means for edge AR/VR rendering applies to memory: sustained behaviour under thermal load, not peak specs, is the number that predicts what a shopper actually experiences. A memory-aware device-tiering rubric Use the memory profile — measured warm, not cold — to assign each device class to a rendering path. The thresholds below are illustrative starting points; calibrate them against your own pipeline’s working set and your served phone mix. Signal (measured under sustained warm load) On-device full tier On-device reduced tier Cloud-render fallback Usable DRAM after OS + camera stack Comfortably above working set Above a stripped working set only Below stripped working set Sustained memory bandwidth (warm) Holds frame budget at full mesh detail Holds budget only at reduced detail Cannot hold budget Frame-time stability over a 2-min session Stays inside sub-200 ms budget Occasional misses, no OOM Frequent misses or OOM kills Thermal headroom Throttles late or not at all Throttles but recovers Throttles hard, no recovery The reduced tier is the important middle: drop mesh resolution, cut refinement iterations, lower texture detail, or fuse render passes so a memory-constrained device still delivers a usable try-on rather than a broken one. The fallback path exists for the tail of devices where no on-device configuration holds the budget. Getting the SN7100 answer right — its real usable capacity and warm bandwidth — is one row in this table, not the whole decision. How should a retailer test their served device mix? The test that matters mirrors the deployment. Pick representative devices from the phone mix your analytics show shoppers actually use — weighted toward the mid-tier, not the flagships your team happens to carry. Run the full try-on pipeline, not a synthetic memory benchmark, because the working set and access pattern are what bind. And run it warm: back-to-back sessions until the device reaches a steady thermal state, then measure frame-time distribution and watch for OOM events. The three questions that gate a tier assignment: What is the usable memory budget on this device after the camera and OS take their share? Not the advertised total — the number your process actually gets. Does sustained bandwidth hold the frame budget once the device is warm? Measure the tail of the frame-time distribution, not the median. Does the session survive a realistic run length without an OOM kill? A single kill mid-session is a one-star review; design the test to trigger it if it’s going to happen. The measurement discipline here — sustained behaviour under realistic load rather than peak specs — is the same one behind reading what memory bandwidth actually means for real utilisation on datacenter hardware. The scale differs; the reasoning does not. Lightweight model variants help here too: choosing something like a MobileSAM-class segmentation model tuned for constrained GPUs shrinks the working set enough to move a device up a tier. FAQ Does the SN7100 have DRAM? Yes — like practically every application-class SoC, it uses DRAM to hold the framebuffer, model weights, intermediate tensors, and OS working set. But “yes” is not the useful answer for a deployment. What matters is the memory profile: usable capacity, bandwidth, and packaging, measured on the target device. How much memory and what bandwidth does the SN7100 expose, and how is it packaged relative to the SoC? The decision-grade figures are the usable capacity your process gets after the OS and camera stack take their share, the sustained bandwidth between DRAM and the compute units, and whether the DRAM sits on-package or off-package (which changes latency and thermal coupling). Treat any single advertised spec as decision-grade only once you have named its source and measured it on the actual device. Why does a chip’s DRAM profile matter for assigning an on-device rendering tier in a virtual try-on pipeline? A try-on pipeline runs memory-hungry stages — segmentation, mesh fitting, rendering, compositing — every frame inside a sub-200 ms budget. Capacity sets a hard ceiling that ends in an OOM kill when exceeded, and bandwidth sets the sustained frame rate. Both are memory constraints that decide whether a device earns the full on-device tier, a reduced tier, or the cloud fallback. How does available DRAM interact with thermal throttling to degrade frame rate and try-on accuracy on warm mid-tier phones? As the die heats up, the memory controller and DRAM throttle: effective bandwidth drops and latency climbs while the compute units clock down. A renderer that held its frame budget cold then misses deadlines warm, and in a mesh-fitting pipeline fewer refinement iterations per frame also degrade the visible garment fit. Mid-tier phones feel this hardest because they have the least thermal and memory headroom. What memory threshold pushes a device from on-device rendering to the cloud-render fallback path? The fallback trigger is when no on-device configuration — even a reduced tier with lower mesh detail and fused passes — holds the sub-200 ms budget under sustained warm load, or when usable DRAM falls below even a stripped working set. Frequent frame-time misses or any OOM kill in a realistic run length are the practical signals. Devices above that line get the reduced tier rather than the fallback. How should a retailer test whether devices in their served mix can sustain the sub-200 ms try-on budget given their memory constraints? Run the full pipeline, not a synthetic benchmark, on representative devices weighted toward the mid-tier your analytics show shoppers use. Run it warm — back-to-back sessions to steady thermal state — and measure the tail of the frame-time distribution plus any OOM events. The three gating questions are usable memory budget, whether warm bandwidth holds the budget, and whether the session survives a realistic run length. Where this leaves the launch decision The honest position is that “does the SN7100 have DRAM” is the wrong question to optimize for, even though it’s the one people type. The question that decides your campaign is: across the phone mix I actually serve, which devices sustain the try-on budget once they’re warm, and what do I do with the ones that don’t? That is a per-device memory budget, and the chip’s DRAM profile is one input to it — necessary, not sufficient. When this classification is wrong, it fails as a rendering-tier misassignment: a device you promised full on-device rendering can’t hold it under thermal load, and the OOM kills and frame collapse arrive after launch instead of before. Our A1 GPU Audit exists to build that per-device rendering budget from measured warm behaviour, so the tier boundaries are set on evidence rather than marketing tiers.
