Jump to content
  • Advertisement

Recommended Posts

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?

Share this post


Link to post
Share on other sites
Advertisement

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.

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.

Edited by Laval B

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!