Skip to main content
GameDev.net gamedev.net
🔒 Locked

GPU memory allocator

Started by acerskyline Jan 31, 2019 at 7:17 PM 7 replies 3.7k views
Original Post
acerskyline
acerskyline

Why do we need GPU memory allocator?

One of the most important reason for CPU memory allocator is to minimize memory segmentation and increase cache hit ratio. These goals are achieved by allocating a consecutive block of memory and provision this block memory to application.

Now, let's assume I do not need dynamic allocation, do I still need CPU memory allocator? IMO the only potentially plausible advantage is the cache hit ratio.

In terms of GPU memory, most of my little demos do not need dynamic buffer or texture allocation (load & unload). They are all loaded at initialization and will never require unloading until the end of the application. Is there any reasons to use memory allocator in this situation?

pcmaster
pcmaster

In your situation, as simple as you describe, you don't need that.

But how about texture streaming? Imagine you have several TB of texture and geometry data but your GPU only has a few GB. You'll be streaming textures and geometry of possibly different sizes in and out, every frame. So you need a GPU memory allocator. It's goal will also be to minimise fragmentation.

The same goes for CPU.


Laval B
Laval B

Like pcmaster above said, with a simple use case such as yours, simply use the api directly, you don't need an allocator. The reason why you will need one with a more complicated scenarios is mostly because drivers only allow a relatively small number of allocations (for technical and implementation specific reasons). This means you need to allocate a few big memory blocks and then sub-allocate from these blocks for the needed gpu resources like buffers and textures.

Of course, this gives you opportunities to optimise either by leveraging locality of references or by following some vendor specific rules.

We think in generalities, but we live in details.
  - Alfred North Whitehead
acerskyline
acerskyline

Thanks for your answers!

MichaelMurphy
MichaelMurphy
On 2/1/2019 at 10:50 AM, pcmaster said:

In your situation, as simple as you describe, you don't need that.

But how about texture streaming? Imagine you have several TB of texture and geometry data but your GPU only has a few GB. You'll be streaming textures and geometry of possibly different sizes in and out, every frame. So you need a GPU memory allocator. It's goal will also be to minimise fragmentation. I wrote the article exactly about this tip at https://edubirdie.com/essay-writing-help-online. I can share this it if you like.

The same goes for CPU.


Are there some another way with not using a GPU memory allocator?

pcmaster
pcmaster

Could you reformulate your question? I'm not sure I understand.

Laval B
Laval B
On 2/7/2019 at 8:09 AM, MichaelMurphy said:

Are there some another way with not using a GPU memory allocator?

As mentioned before, in simple cases there is no need for an allocator, simply use the api directly. If your application needs an allocator and you don't want to develop one yourself, there are solutions like amd VMA allocator library. You can also look at DOOM3 bfg which has its own allocator (in neo/renderer/Vulkan Allocator_VK.h/cpp). These libraries are for Vulkkan but the idea can be used with DX12.

We think in generalities, but we live in details.
  - Alfred North Whitehead
Gnollrunner
Gnollrunner

I actually remember I had to write something like that in DX9. I was bulging two entire models of my planet and swapping them. But at some point it started hanging and the only way I was able to fix it was manage memory myself.

However, I'm doing some similar stuff now and I haven't had a problem with DX11.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.