Mesh: Parallelize extraction of UV maps #105793

Merged

Hans Goudey merged 4 commits from HooglyBoogly/blender:mesh-extract-uv-parallel into main

2023-03-19 16:18:30 +01:00

Hans Goudey commented

2023-03-15 14:08:05 +01:00

Member

Since UVs are now stored as 2D vectors in meshes, they can be copied
directly to the vertex buffers. Somewhat surprisingly, multithreading
the copying into the vertex buffer provides a good speedup on a CPU
with many cores at least.

Here is a test uploading two UV maps created in geometry
nodes with a 1 million quad mesh, with a Ryzen 7950x:

	Before	After	Speedup
Average	24.3 ms	7.5 ms	3.2x
Min	17.6 ms	7.0 ms	2.5x

I added the copying utilities to the array utils header, since the
need for them has come up in a few different places already, and the
existing function with a selection argument didn't make sense here.

I hope we can use this data-parallelism more in the mesh extraction
process in the future.

Since UVs are now stored as 2D vectors in meshes, they can be copied directly to the vertex buffers. Somewhat surprisingly, multithreading the copying into the vertex buffer provides a good speedup on a CPU with many cores at least. Here is a test uploading two UV maps created in geometry nodes with a 1 million quad mesh, with a Ryzen 7950x: | | Before | After | Speedup | | ------- | ------- | ------ | ------- | | Average | 24.3 ms | 7.5 ms | 3.2x | | Min | 17.6 ms | 7.0 ms | 2.5x | I added the copying utilities to the array utils header, since the need for them has come up in a few different places already, and the existing function with a selection argument didn't make sense here. I hope we can use this data-parallelism more in the mesh extraction process in the future.

Hans Goudey added the

EEVEE & Viewport

labels 2023-03-15 14:08:06 +01:00

Hans Goudey requested review from Jacques Lucke 2023-03-15 14:10:23 +01:00

Hans Goudey requested review from Clément Foucault 2023-03-15 14:10:23 +01:00

Hans Goudey added this to the EEVEE & Viewport project 2023-03-15 14:10:28 +01:00

Germano Cavalcante commented

2023-03-15 14:31:21 +01:00

Member

Mesh extractors already have their own way of handling multithreading (see extractor.use_threading).

This is done in a way that avoids having to access, multiple times, distant addresses in the arrays of a Mesh and thus losing performance in the memory cache.

Using threading in a function that is already a callback to be used in multithreading can end up harming other areas.

I would suggest testing extractor.use_threading = true first.

Mesh extractors already have their own way of handling multithreading (see `extractor.use_threading`). This is done in a way that avoids having to access, multiple times, distant addresses in the arrays of a Mesh and thus losing performance in the memory cache. Using threading in a function that is already a callback to be used in multithreading can end up harming other areas. I would suggest testing `extractor.use_threading = true` first.

Germano Cavalcante commented

2023-03-15 14:36:38 +01:00

Member

Looking back, I now see that the affected function is extract_uv_init (which isn't really used in multithreading), so the previous concern doesn't apply.

Looking back, I now see that the affected function is `extract_uv_init` (which isn't really used in multithreading), so the previous concern doesn't apply.

Hans Goudey commented

2023-03-15 14:41:46 +01:00

Author

Member

I don't think it makes sense to introduce the overhead of a function call per face just to copy this array. We're not accessing "distant addresses multiple times" here, we're just copying data that probably isn't accessed elsewhere in the mesh extraction process anyway.

A while ago I tested refactoring most of the extraction system to work more like this and it was a nice improvement, since most extractors access are dealing with separate memory anyway, and most are quite simple, making the function call overhead significant.

Using threading in a function that is already a callback to be used in multithreading can end up harming other areas.

I'm not sure I agree in general-- it seems generally good to have multiple methods of achieving parallelism. That's why, for example, multiple geometry nodes are evaluated in parallel, but each also uses parallelism on its own.

I don't think it makes sense to introduce the overhead of a function call per face just to copy this array. We're not accessing "distant addresses multiple times" here, we're just copying data that probably isn't accessed elsewhere in the mesh extraction process anyway. A while ago I tested refactoring most of the extraction system to work more like this and it was a nice improvement, since most extractors access are dealing with separate memory anyway, and most are quite simple, making the function call overhead significant. >Using threading in a function that is already a callback to be used in multithreading can end up harming other areas. I'm not sure I agree in general-- it seems generally good to have multiple methods of achieving parallelism. That's why, for example, multiple geometry nodes are evaluated in parallel, but each also uses parallelism on its own.

Jacques Lucke requested changes 2023-03-17 12:36:25 +01:00

source/blender/blenlib/BLI_array_utils.hh Outdated

						
				@ -13,0 +24,4 @@

				inline void copy(const Span<T> src, MutableSpan<T> dst, const int64_t grain_size = 4096)

				{

				  BLI_assert(src.size() == dst.size());

				  threading::parallel_for(src.index_range(), grain_size, [src, dst](const IndexRange range) {

Jacques Lucke commented

2023-03-17 12:34:13 +01:00

Member

Shouldn't really help to capture src and dst explicitly here, just use &.

Shouldn't really help to capture `src` and `dst` explicitly here, just use `&`.

HooglyBoogly marked this conversation as resolved

source/blender/draw/intern/mesh_extractors/extract_mesh_vbo_uv.cc Outdated

						
				@ -77,6 +77,7 @@ static void extract_uv_init(const MeshRenderData *mr,

				                            void *buf,

				                            void * /*tls_data*/)

				{

				  SCOPED_TIMER_AVERAGED(__func__);

Jacques Lucke commented

2023-03-17 12:34:22 +01:00

Member

Remove timer.

Remove timer.

HooglyBoogly marked this conversation as resolved

source/blender/draw/intern/mesh_extractors/extract_mesh_vbo_uv.cc Outdated

						
				@ -113,3 +113,1 @@

				            CustomData_get_layer_n(cd_ldata, CD_PROP_FLOAT2, i));

				        for (int ml_index = 0; ml_index < mr->loop_len; ml_index++, uv_data++, layer_data++) {

				          memcpy(uv_data, layer_data, sizeof(*uv_data));

				        for (const int i : IndexRange(MAX_MTFACE)) {

Jacques Lucke commented

2023-03-17 12:36:10 +01:00

Member

I'm a bit confused why there is a nested loop now.

I'm a bit confused why there is a nested loop now.

HooglyBoogly marked this conversation as resolved

Hans Goudey reviewed 2023-03-18 02:09:54 +01:00

source/blender/draw/intern/mesh_extractors/extract_mesh_vbo_uv.cc Outdated

						
				@ -113,3 +113,1 @@

				            CustomData_get_layer_n(cd_ldata, CD_PROP_FLOAT2, i));

				        for (int ml_index = 0; ml_index < mr->loop_len; ml_index++, uv_data++, layer_data++) {

				          memcpy(uv_data, layer_data, sizeof(*uv_data));

				        for (const int i : IndexRange(MAX_MTFACE)) {

Hans Goudey commented

2023-03-18 02:09:45 +01:00

Author

Member

Ah, yikes, sorry about that!

Ah, yikes, sorry about that!

HooglyBoogly marked this conversation as resolved

Hans Goudey requested review from Jacques Lucke 2023-03-18 02:10:13 +01:00

Hans Goudey force-pushed mesh-extract-uv-parallel from f6615dc456 to 2b9822055f

2023-03-19 01:02:28 +01:00

Compare

Jacques Lucke approved these changes 2023-03-19 06:54:15 +01:00

Hans Goudey merged commit 63a44e29ac into main

2023-03-19 16:18:30 +01:00

Hans Goudey referenced this issue from a commit

2023-03-19 16:18:31 +01:00

Mesh: Parallelize extraction of UV maps

Hans Goudey deleted branch mesh-extract-uv-parallel

2023-03-19 16:18:31 +01:00

Sign in to join this conversation.

No reviewers

No Label

Animation & Rigging

Asset Browser Project Overview

Automated Testing

Blender Asset Bundle

Dependency Graph

Development Management

EEVEE & Viewport

Images & Movies

Motion Tracking

Nodes & Physics

Pipeline, Assets & IO

Platforms, Builds & Tests

Render & Cycles

Render Pipeline

Sculpt, Paint & Texture

Video Sequencer

Virtual Reality

Blender 2.8 Project

Milestone 1: Basic, Local Asset Browser

Good First Issue

Animation & Rigging

Development Management

EEVEE & Viewport

Nodes & Physics

Pipeline, Assets & IO

Platforms, Builds & Tests

Render & Cycles

Sculpt, Paint & Texture

Needs Info from Developers

Needs Information from User

No Milestone

No project

No Assignees

3 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#105793

No description provided.