-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ThreadManager: Add simple priority queues #16812
Conversation
This seems fine, but for some reason doesn't solve the problem. Will look more later, for now here are the stacks when force-quitting in the hanged state:
|
Hm, it does only have 2 CPU threads but it should work. We might need to do some task logging like this:
Would be useful to see what task it last pulls from the queue and what else is on the queue at the time. -[Unknown] |
I resolved my dependency/deadlock problem in a different way in #16802, but I think I still want this in. One use case is to prioritize pipeline creation higher than texture replacement loading, for example. There's some tiny conflict, could you resolve? I'll review in detail then, but at a cursory look this looks good. |
cbb9175
to
6c4411a
Compare
Currently, not actually respected.
This allows basic differentiation of priorities.
b3becce
to
2cada63
Compare
Updated and set the priority to high for the multi pipeline task. -[Unknown] |
Cool. Sorry for the delay, I'll review and most likely merge tomorrow. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given the name of the PR I was expecting the data structure known as priority queue, which would have been a bit of overkill for this :) This simpler approach is more appropriate and good enough for the intended use.
This adds a cheap priority mechanism to mark certain tasks as higher priority, as a basic way to manage dependencies.
Of course, if a HIGH is enqueued while a LOW is executing, it won't change anything. But as long as HIGH/NORMAL/LOW are enqueued near the same time, this ensures that the HIGHs would be scheduled first. Before, that wasn't guaranteed (even if you enqueued the tasks in the right order), because things would go onto the global queue and get picked up, which would also vary by thread count.
-[Unknown]