Splitting a view for job threads

[iamdak]

Hello,

I'm refactoring my code base to use entt and I'm looking for ideas on the best way to handle code executed by my job system. Right now, it (roughly) takes in an array of work data along with the total array size and max work data to handle per work group. The crash course suggests using "std::for_each" and "std::execution::par" for achieving parallelism but I'm wondering if there's any way to continue using my existing job system.

I understand that there will likely be performance implications but I'm looking for a way to break up the list of entities in a view into n-sized groups. That may mean having access to the count and list of view entities and I pass the base index and count to the work group (similar to how I'm using it now with my array-based data). Or it may mean creating views ranging from a base index to the max work group size. Or maybe something else?

My apologies if this has already been discussed; I tried searching to no avail but I'd also appreciate the correct terms that I should be looking for. I'm an old fart C programmer so maybe there's an standard lib solution that I can explore. The closest thing I found that works(?) is using the view's handle() function but it seems a bit messier than may be intended:

auto View = Database.view<Component::TransformMatrix, Component::OrientationFixed>( entt::exclude<Component::OrientationTween> );		
int DataSize = View.handle().size();
const entt::sparse_set * DataSet = &View.handle();
entt::entity entity = (*DataSet)[DataIndex];

Thank you!

[Green-Sky]

afaik, the direct access only works for single-component-views or groups, since they are effectively iterating that storage directly.
BUT, that was 2-3 versions ago, so stuff might have changed.
That being said, you can always look up how std::for_each does it.

[Green-Sky]

also, eons ago, i tried to wire up the organizer (and view splitting) with taskflow https://github.com/Green-Sky/entt_playground/blob/main/projects/multithreading_taskflow/mt_fireworks.cpp
but it is now very outdated, and as you can see, i never really got it to work :(

[skypjack]

If you want inner parallelism with your job system (opposed to outer parallelism, that is, running different systems that use different resources aka component types in parallel), I think the easiest approach to start with is something along this line:

• Single component views are trivial, just get their iterators and sizes, split the range into multiple parts and spawn enough tasks to do the work
• Multi component views can be reduced to the single type view case as it follows:
  • Get the handle and therefore its iterators and size
  • Split the range in multiple parts, spawn enough tasks and bind to them the original view
  • Iterate the subrange and check if the entity belongs to the view, if yes then .get(e) all the components to do the work

This should get the job done quickly. Then you can measure, spot the bottlenecks if any and optimize further if necessary (this is unlikely to happen but it's hard to say without looking at the original codebase).

[skypjack]

how exactly to do this

Yeah, sure, I'd be glad to help but can you define this a little better please? 🙂
The quote covers a few points and I don't know which one is giving you problems.

[untiedgames]

Sorry for the confusion- Specifically, for both single/multi component views, how to...

get their iterators and sizes, split the range into multiple parts

view.begin() returns an iterator, but view.begin() + my_start_index doesn't compile- no operator+. How do you split the view using the iterator without being able to specify where to start/end the sub-view?

[iamdak]

Here is a snippet of my code that does this. The take aways are:

// Create a view and get it's total size:
auto View = Database.view<Component::SkinnedMesh, Component::Animation>();
int DataSize = (int)View.handle().size();

// Iterate over some range defined by my task system:
auto View = Database->view<Component::SkinnedMesh, Component::Animation>();
const entt::sparse_set & DataSet = View.handle();

for ( int iItem=BaseIdx; iItem<BaseIdx+Count; iItem++ ) {
	entt::entity entity = DataSet[iItem];
	...
}

---

class AnimationsUpdateTask : public iam::Task {
public:
	AnimationsUpdateTask( entt::registry * EngineDb, float dTime ) : Database(EngineDb), DeltaTime(dTime) {}

	entt::registry * Database;
	float            DeltaTime;

	virtual void Run( int GroupId, int BaseIdx, int Count, mem UserData ) {
		auto View = Database->view<Component::SkinnedMesh, Component::Animation>();
		const entt::sparse_set & DataSet = View.handle();

		for ( int iItem=BaseIdx; iItem<BaseIdx+Count; iItem++ ) {
			entt::entity entity = DataSet[iItem];

			Component::SkinnedMesh & SkinnedMesh = View.get<Component::SkinnedMesh>( entity );
			Component::Animation   & Animation   = View.get<Component::Animation  >( entity );

			if ( Animation.Length > 0 ) {
				while ( Animation.Time >= Animation.Length ) {
					Animation.Time -= Animation.Length;
				}
			}

			iam::Graphics::CalculateMatrices( SkinnedMesh.Joints, SkinnedMesh.JointCount, Animation.Time, Animation.Actor, Animation.AnimationActor );
			Animation.Time += DeltaTime;
		}
	}
};

void System::Animations::Update( entt::registry & Database, float DeltaTime ) {
	auto View = Database.view<Component::SkinnedMesh, Component::Animation>();
	int DataSize = (int)View.handle().size();
	if ( DataSize > 0 ) {
		AnimationsUpdateTask Task( &Database, DeltaTime );
		Task.Dispatch( iam::Core::GetGlobalTaskManager(), DataSize, 128, &Database );
		Task.Wait();
	}
}

[untiedgames]

Thanks, I think that's what I was missing- Use view.handle() to access the underlying data structure, which has an access function suited to indices. That should do the trick! I wonder if it should be mentioned in the crash course alongside the other ways to use views? None of the methods listed there supported splitting the view like this.

[skypjack]

Thanks @iamdak for dropping an example here👍 you saved me some time today. 🙂
@untiedgames I think mt deserves its own md file actually. What do you suggest instead? Where do you think we should put this info?