Force components to be allocated with specific alignment / custom allocator?

[jonesmz]

This is a preliminary question, and not something that's fully fleshed out.

Anyway, I have a situation where I want to use SIMD on some of the data stored in EnTT, which requires the data be aligned to a specific alignment size. Currently, I'm copying that data out of EnTT, and into a manually allocated buffer, doing my algorithm, and then copying the data back into EnTT.

I'm curious if EnTT has pre-existing support for indicating data alignment, or just providing a custom allocator, so that I (might) skip some of that data copying.

A related, but not exactly the same, situation is that I may want to communicate some data that is stored in EnTT to a GPU as a single buffer. Are there any facilities that EnTT offers that I should use to do that?

[skypjack]

You can use custom pools here. That is, you can replace the storage part of a pool on a per-type basis. It should solve your problem, am I wrong?
As for the single buffer, there is the raw and size pair from the basic pool. Don't know if it fits here, but it seems so:

auto view = registry.view<T>();
auto size = view.size(); // number of elements
auto *raw = view.raw(); // pointer to first element

[skypjack]

Oh, yeah, that's because I've updated the view but I've not updated the registry yet. You're right. 😅 Sorry for the noise.

[qwiff-dogg]

@skypjack Is there any news regarding the use of custom allocators with a registry in 3.9 and 3.10? I'm looking at the changelogs and can't really tell.

[skypjack]

Versions 3.9 and 3.10 added allocator (and uses_allocator support) to sparse sets, storage, dense map, dense set, dispatcher, locator, resource handling, and so on.
The registry isn't in this list yet for a few reasons:

• Time 🤷‍♂️
• Other priorities besides this 🤷‍♂️
• I want to put entities in their own storage to avoid doing the work to support allocator twice (since the former is planned anyway)

However, there are a few ways already to inject and use your allocator with a registry. For example, if it's default constructible you can just use the storage_traits and make it the default:

template<typename Entity, typename Type>
struct storage_traits<Entity, Type> {
    using storage_type = sigh_storage_mixin<basic_storage<Entity, Type, my_allocator>>;
};

Otherwise, you can add a mixin that finds the right allocator somewhere and injects it to the base class. These aren't the only options but they should give you a grasp of what I mean at least.

[qwiff-dogg]

@skypjack Thanks for the reply. I finally had some time to look into this.

For 3.10 I use the same solution as I did with 3.8.

1. Provide my own storage_traits referencing the custom allocator type.
2. Include my own version of entt/registry/fwd.hpp with default template args for basic_sparse_set and basic_storage referencing the custom allocator type, instead of std::allocator.

Without step 2), you'll get the compile errors I mentioned in my earlier reply.

[skypjack]

Oh, yeah, the registry isn't ready yet in this sense. Granted. Work in progress.
So far, only a registry-less model works perfectly fine. In all other cases, you've to trick the type resolution.
The problem with the registry is that all pools are lazily initialized. Therefore, we'll have to provide the allocator type explicitly.
But yeah, just a matter of time, I'm working on this stuff too among the other things.