Advertisement

GPU memory allocator

Started by January 31, 2019 07:17 PM
7 comments, last by Gnollrunner 5 years, 11 months ago

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?

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.

 

Advertisement

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

Thanks for your answers!

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?

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

Advertisement
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

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.

This topic is closed to new replies.

Advertisement