Skip to content

Conversation

@RandomShaper
Copy link
Member

See #112452 for an explanation of why this would be beneficial.

TL;DR Keeping the lock held over the command queue of the rendering server in separate thread mode is not needed because there's a single thread dealing with such server, Therefore, the lock is only needed for thread safety of the command queue itself, which means the lock can be released while commands are run, allowing other threads to add commands without waiting.

Not tested at all due to lack of time...

@RandomShaper RandomShaper added this to the 4.6 milestone Nov 7, 2025
@RandomShaper RandomShaper requested review from a team as code owners November 7, 2025 11:41
@RandomShaper RandomShaper added topic:core topic:rendering needs testing performance cherrypick:4.4 Considered for cherry-picking into a future 4.4.x release cherrypick:4.5 Considered for cherry-picking into a future 4.5.x release labels Nov 7, 2025
if (unique_flusher) {
// A single thread will pump; the lock is only needed for the command queue itself.
lock.temp_unlock();
cmd->call();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

here cmd is pointing to memory in the command_mem LocalVector. Is there a risk that while unlocked, the vector could resize and invalidate this memory address? If so, I think a different collection type would be needed that has pointer stability around resizes (like a std::deque). Although those types might have less CPU caching benefits.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right about the potential pointer invalidation. However, we're trusting the call-and-back itself is immune to that, so the line below about handling realloc should be enough. It'd be good to prove the former point more formally, though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

cherrypick:4.4 Considered for cherry-picking into a future 4.4.x release cherrypick:4.5 Considered for cherry-picking into a future 4.5.x release needs testing performance topic:core topic:rendering

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants