<p>Suppose there is a frame, which is larger that the device memory (I mean, dozens of Gb). And I would like to render to it from a set of textures, which is larger than the host memory (I mean, dozens to hundreds of Gb). Each texture is rendered to a different part of the frame.<br>
To give more context, I'm baking the texture of a 3D-model, using its several projections.</p>

<p>I see two ways to handle it.<br>
1. Go out of core texture-first, i.e. for each texture perform rendering several times to render each part of the frame.<br>
2. Go out of core frame-first, i.e. for each frame part load every texture and render the frame part, then shift frame part and repeat.</p>

<p>The first way is definitely unfeasible, as PCI throughput is insufficient to load-unload the whole memory of a device for each renderpass.<br>
The second way is much better, but it does not scale with frame dimensions, as it requires loading all the textures from disk and rendering them for each part of the frame.</p>

<p>So, is there any alternative to this I miss?</p>

CC BY-SA 4.0
2019-08-07T13:51:28.967Z
"*Suppose there is a frame, which is larger that the device memory*" What do you mean by a "frame" here? In graphics terms, a "frame" is usually the amount of rendering and computation you need to do to display an image to the user within a given quantity of time. As such, "frame" doesn't really have a memory size. Are you talking about a frame *buffer*?
Nicol Bolas
CC BY-SA 4.0
2019-08-07T14:38:51.070Z
@NicolBolas, I think so, I just tried to sound generic. I meant the buffer, which we draw onto during the frame. I believe, its this thing https://www.khronos.org/opengl/wiki/Renderbuffer_Object in opengl. In Vulkan terminology it's several huge color attachments that do not fit into device memory.
Vladimir Nazarenko
<algorithm><vulkan>
Out of core rendering
Vladimir Nazarenko
# Out of core rendering

(Asked by: username_0 on 2019-08-07)

Suppose there is a frame, which is larger that the device memory (I mean, dozens of Gb). And I would like to render to it from a set of textures, which is larger than the host memory (I mean, dozens to hundreds of Gb). Each texture is rendered to a different part of the frame.  
To give more context, I'm baking the texture of a 3D-model, using its several projections.

I see two ways to handle it.  
1. Go out of core texture-first, i.e. for each texture perform rendering several times to render each part of the frame.  
2. Go out of core frame-first, i.e. for each frame part load every texture and render the frame part, then shift frame part and repeat.

The first way is definitely unfeasible, as PCI throughput is insufficient to load-unload the whole memory of a device for each renderpass.  
The second way is much better, but it does not scale with frame dimensions, as it requires loading all the textures from disk and rendering them for each part of the frame.

So, is there any alternative to this I miss?

**Tags:** algorithm, vulkan

> **Comments:**
> **username_1**: "*Suppose there is a frame, which is larger that the device memory*" What do you mean by a "frame" here? In graphics terms, a "frame" is usually the amount of rendering and computation you need to do to display an image to the user within a given quantity of time. As such, "frame" doesn't really have a memory size. Are you talking about a frame *buffer*?  
> **username_0**: @username_1, I think so, I just tried to sound generic. I meant the buffer, which we draw onto during the frame. I believe, its this thing https://www.khronos.org/opengl/wiki/Renderbuffer_Object in opengl. In Vulkan terminology it's several huge color attachments that do not fit into device memory.  

---

## 0 answers

