DeviceMemory::DeviceMemory() throws error with VK_ERROR_TOO_MANY_OBJECTS

[timoore]

vsgCs throws this error when using Google Photorealistic Terrain and zooming in on an area.

Hardware: AMD Integrated Graphics (Renoir)
Driver version: 2.0.193
API version: 1.2.182

This driver has a relatively modest value for maxMemoryAllocationCount: 4096. The Google 3D Tiles are complex objects.

I don't totally understand the DeviceMemory code, but it looks to me like a call to vkAllocateMemory is made for each VSG buffer object compiled. Is that right? I see a MemorySlots object in DeviceMemory that looks like it is intended to satisfy small allocations from one DeviceMemory object, but I don't see how it is used.

[robertosfield]

Buffet and MemoryPoolboth has support for managing multiple entries within them, and the VSG where possible will allocate within them but perhaps csgCs is using a code path that doesn't use them.

…

On Sat, 26 Aug 2023, 22:53 Tim Moore, ***@***.***> wrote: vsgCs throws this error when using Google Photorealistic Terrain and zooming in on an area. Hardware: AMD Integrated Graphics (Renoir) Driver version: 2.0.193 API version: 1.2.182 This driver has a relatively modest value for maxMemoryAllocationCount: 4096. The Google 3D Tiles are complex objects. I don't totally understand the DeviceMemory code, but it looks to me like a call to vkAllocateMemory is made for each VSG buffer object compiled. Is that right? I see a MemorySlots object in DeviceMemory that looks like it is intended to satisfy small allocations from one DeviceMemory object, but I don't see how it is used. — Reply to this email directly, view it on GitHub <#942>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKEGUEKGEHUWHVYF5LO2OLXXJV7NANCNFSM6AAAAAA373B5CE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[timoore]

Buffet and MemoryPoolboth has support for managing multiple entries within them, and the VSG where possible will allocate within them but perhaps csgCs is using a code path that doesn't use them.

vsgCs does create a lot of small uniform buffers, including vsg::PbrMaterialValue, in the obvious way i.e., without worrying about doing its own allocation from larger buffers. Is there any VSG application that does it differently?

vsg::Image allocation work wells using the MemoryPool mechanism. vsg::Buffer is doing its own thing with the memory slots. Is there any reason not to allocate Buffer memory from MemoryPool as well?

[timoore]

Actually, vsgCs is probably not doing as much sharing of constant uniform data as it could; let me see if that mitigates the problem.

[robertosfield]

Ideally all arrays, uniforms and image should be allocated from the MemoryBufferPool.

Some older uniform code didn't use allocation from the pool if they were relying upon controlling the memory properties to ensure they could be written directly to by the CPU. Now we have vsg::TransferTask it's easy to have the memory allocated on the GPU and just let the dirty mechanism sort out the transfer, This is better as it provides the buffering required to avoid rendering and updating betting out of sync.