You don’t write anything to the virtual texture so much as use it as a lookup.
The virtual texture is like a precomputed stack of math that the engine can figure out before runtime, so when the render call is actually executed, some of the math you might have to figure out along the way in a normal material (w/o a VT), is already done for you or at least in a form where the math can be run fast, a quick-path.
When you build the virtual texture volumes (SVT’s), you are building out those (effectively) look-up tables, you are not actually rendering anything into the texture per-se. What you see in the content-browser as a little-mini-texture is more the math-being-evaluted in the browser and of course, it looks like what you pointed it at… THIS is the costly step, what you likely think about in terms of a ‘write’. Otherwise, at runtime, it’s not really a render so much as a reference.
SO! In that sense, at runtime, you can consider VT lookups ‘cheaper’ than a regular texture-lookup. Writing to the texture more means updating the lookup’s, but then you still have to evaluate those and get the actual thing you want to render, etc. ‘Writing’ isn’t so much rendering a texture like a render-target so much as updating an index.
VT’s are tiled, so they can be such that you only read/write a specific set of the VT, really only what you need to, that’s the point (vs always rendering the entire thing).
As for the no-draw call, anything rendered-into the virtual texture is not an actual mesh, it’s a top-down projection into to VT. So when he is painting grass he’s not really painting meshes but just the lookup information to the textures the grass uses on itself. In this case the VT is more like a big mixing bucket one can render stuff into and the VT holds the aggregate-result.
This has some debugging information if it’s helpful: Runtime Virtual Texturing | Unreal Engine Documentation