Tile Rendering: Optimizing Cost-Effectiveness and Rendering Time
What is Tile Rendering?
Tile rendering is a technique that divides the rendering area of a 3D camera into sections, enabling an image to be rendered across multiple servers (or on a single machine with multiple render passes). The individual pieces are then reassembled using a third-party tool. This approach reduces the pixel load per server.
This method of splitting up the render has various names, including multi-band, strip rendering, crop rendering, or tile rendering. Each segment can thus be referred to as a band, strip, crop, or tile.
What is it used for?
Rendering high-resolution images is often time-consuming, costly, and demands substantial memory resources. Users of render farms like RANCH Computing seek to save time without investing in more hardware, so they need to manage their budgets effectively. To assist with this, we examined the most efficient way to divide an image.
At first glance, it might seem that increasing the number of servers on a single image would always be beneficial. However, each server working on a frame segment must load the entire scene, and this load time remains nearly the same regardless of tile resolution. Since users are billed based on total rendering time, choosing the correct tile count is critical. Dividing the render into too few tiles could take too long—or fail if the project exceeds server memory. On the other hand, splitting it into too many tiles could incur undesired extra costs for clients.
Practical Case Study
Let’s examine a practical case. We’ll use a GPU project, as GPU-based rendering, which is faster, is more sensitive to various influencing factors.
The tests were performed under the following conditions:
- A single server type with a Dual Xeon E5-2690 V4 processor, 128GB of RAM, and four RTX 3090 cards with 24GB VRAM.
- A reference scene rendered without tiling in various resolutions.
| Resolution | Number of pixels |
|---|---|
| 1920×1080 | 2,073,600 px |
| 3840×2160 | 8,294,400 px |
| 7680×8640 | 33,177,600 px |
| 15360×8640 | 132,710,400 px |
| 30720×17280 | 530,841,600 px |
- The same reference scene rendered with equal-sized tiles for each resolution, with a fixed length.
| 2 tiles | 3 tiles | 4 tiles | 6 tiles | 12 tiles |
|---|
Render Time
Let’s start by analyzing the render times for each resolution of our reference scene. The table below lists the total time to render all tiles at a given resolution, where all tiles are rendered in parallel, and the render duration corresponds to the longest tile’s render time.
| Time (s) | 2k | 4k | 8k | 15k | 30k |
|---|---|---|---|---|---|
| Entire image | 174 | 342 | 1022 | 3744 | / |
| 2 tiles | 159 | 230 | 591 | 2121 | / |
| 3 tiles | 131 | 189 | 459 | 1579 | 168938 |
| 4 tiles | 118 | 171 | 332 | 1353 | 4455 |
| 6 tiles | 135 | 148 | 278 | 873 | 3029 |
| 12 tiles | 128 | 134 | 203 | 517 | 1579 |
As expected, render time decreases as the number of tiles increases. However, this reduction isn’t linear, even excluding the chaotic results for the 30k render. There is a noticeable time gain between rendering the entire image versus splitting it into two tiles, but this gain tapers off as more tiles are added.
These renders also show that even when the pixel count is identical between a resolution and one tile of the same image resolution split into four tiles, render times are not strictly identical. This difference arises mainly because the pixels themselves differ.
Additionally, not all tiles in a given resolution and split render at the same speed, for the same reasons mentioned above.
Memory Usage
Let’s look at memory usage. For a GPU project, the bulk of memory demand is handled by the graphics card memory, commonly called VRAM, which is distinct from RAM. Increasing VRAM can only be achieved by switching to a model with more video memory. Most mid-range and high-end GPUs have between 8GB and 24GB of VRAM.
The memory usage comparison of popular graphics cards can be found here:
- NVIDIA Cards: https://www.nvidia.com/en-us/geforce/graphics-cards/compare/
- AMD Cards: https://www.amd.com/en/products/specifications/graphics.html
Since memory usage can fluctuate during rendering, the peak VRAM usage is recorded in the table below.
| VRAM (MB) | 2k | 4k | 8k | 15k | 30k |
|---|---|---|---|---|---|
| Entire image | 5435 | 6107 | 8697 | 19302 | OUT |
| 2 tiles | 5221 | 5579 | 6943 | 12115 | OUT |
| 3 tiles | 5221 | 5443 | 6319 | 9831 | 24169 |
| 4 tiles | 5063 | 5359 | 6032 | 8689 | 20441 |
| 6 tiles | 5097 | 5245 | 5745 | 7495 | 15403 |
| 12 tiles | 4925 | 5103 | 5441 | 6397 | 10325 |
We observe that as the resolution increases, the differences in VRAM usage between different tile counts become more pronounced. The gap is only about 500 MB between the entire image and the 12-tile split at 2K. However, for the 15K image, memory usage is reduced by a factor of three.
Additionally, as indicated in the test specifications, our reference GPU has 24 GB of memory. This is why rendering at the highest resolution failed to render the entire image as well as the 2-tile split (265,420,800 px). Furthermore, rendering with 3 tiles was much more challenging than the other configurations. Of the 3 tiles, only 2 rendered, and with extremely long render times. Since 24 GB of VRAM was fully utilized, the render engine had to swap to RAM. However, this process currently does not allow for optimal usage of both types of memory and significantly slows down rendering performance. Notably, using a 12-tile split allows VRAM usage to drop below the symbolic 11 GB threshold, enabling rendering on any RANCH GPU server.
Although RAM usage is generally less critical in GPU rendering, it should not be overlooked. Scene loading is CPU-dependent and thus relies on RAM. Additionally, certain processes remain RAM-dependent during rendering.
A computer with only 16 GB of RAM, for instance, would be unable to render certain tile resolutions, even if it has a GPU with sufficient VRAM.
| RAM (MB) | 2k | 4k | 8k | 15k | 30k |
|---|---|---|---|---|---|
| Entire image | 6150 | 7159 | 11804 | 30579 | OUT |
| 2 tiles | 5913 | 6448 | 8717 | 18067 | OUT |
| 3 tiles | 5737 | 6130 | 7718 | 13578 | 46785 |
| 4 tiles | 5682 | 6009 | 7270 | 11510 | 35527 |
| 6 tiles | 5717 | 5862 | 6651 | 9803 | 25624 |
| 12 tiles | 5510 | 5830 | 6109 | 7473 | 15733 |
Like VRAM, RAM consumption decreases as the number of tiles increases and rises with higher resolutions.
Cost
Now let’s talk about the costs associated with these renders, based on rendering time. One RANCH Credit (RC) equals €1, though this can be reduced with bulk recharges or promotions. Since users are billed for server usage time, the cost trends align closely with the render time.
We observe that rendering the image on a single server costs about 5-6 credits less than using 12 servers, on average. However, this price difference correlates with time savings between two splits. For a 2k image, rendering with 12 tiles costs 86% more for a render time that is only 26% faster. In such cases, tiling offers little advantage for a minor time gain.
In contrast, the 15k resolution reverses these proportions: the cost rises by 24%, while render time improves by 86%. When time is short and budget allows, tiling is thus much more appealing. In extreme cases, such as the 30k image, tiling becomes necessary simply to enable the render to complete.
In certain cases, like our 30k image, it’s not just about rendering faster but about being able to render at all. The minimum tile count required to fully render this image on our reference server is 4, due to the 24 GB VRAM limit. Comparing the cost increase between 4 and 6 tiles, there is only a difference of 1.14 RC, or less than 1%, for a render time reduction of 23 minutes and 46 seconds, making the render 32% faster. Between 6 and 12 tiles, the cost increase is just under 6%, with a render time improvement of 24 minutes and 10 seconds, or almost 48%; however, there are three times as many tiles as in the previous comparison. On a per-2-tile scale, this translates to an increase of less than 2% and a 16% faster render, or a difference of 1.91 RC and 8 minutes and 3 seconds. The time savings are significant but less impactful than going from 4 to 6 tiles. Ultimately, the price difference between 4 and 12 tiles is less than 7% (6.54 RC) for a render time improvement of over three-quarters of an hour, or nearly 65%.
If we make the same comparison for the 15K image, the first thing we notice is that the render time gain between 4 and 6 tiles is roughly the same as for 30K. However, the project cost with 6 tiles is lower than with 4 tiles. This difference can be attributed to the lower total computation time on each server due to faster rendering of certain parts of the image. In other words, if all tiles from a single split were rendered on a single server, the render time for the 4-tile split would be slightly higher than for the 6-tile split.
| 15K – Duration | 4 servers | 6 servers |
|---|---|---|
| tile 1 | 00:16:58 | 00:11:14 |
| tile 2 | 00:19:19 | 00:13:05 |
| tile 3 | 00:22:33 | 00:13:56 |
| tile 4 | 00:15:16 | 00:13:04 |
| tile 5 | – | 00:11:34 |
| tile 6 | – | 00:10:53 |
| TOTAL | 01:14:06 | 01:13:46 |
It should be noted that our GPU-Low priority includes a mix of servers with RTX 3090s and RTX 2080 Ti cards, the latter having only 11 GB of VRAM. Depending on memory usage, it may be necessary to select the GPU-24 priority to ensure 24 GB of memory.
Conclusion
If we consider cost alone, it will always be more economical to render the entire image when technically possible. Conversely, if we focus solely on render time, increasing the number of tiles is more advantageous. It’s worth noting, however, that the greater the difference in the number of pixels to compute, the more significant the time savings will be.
Our case study highlights a general technical reality but does not, of course, reflect every possible scene. Since each scene is unique, they will have different computational complexities, and rendering a 2K scene might sometimes take longer than rendering another scene at 4K. It’s therefore up to the creator outsourcing their render to know their scene well and determine whether investing in speed is worthwhile. The first logical choice will always be based on hardware constraints. Beyond that, it will likely be preferable to use fewer tiles to optimize costs for long renders at standard resolutions (2K, 4K). For high resolutions, however, more tiles can significantly reduce render time without a substantial increase in cost.
Ideally, it would be possible to determine zones of different sizes based on the complexity of specific parts of an image, to facilitate computation and even out render times. Currently, it is not possible to automatically and effectively determine these zones. However, with advancements in artificial intelligence and rendering engines, it is highly likely that this feature will be achievable in the future.
