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
SPU: Cache reservation memory direct access handle (optimization) #11240
Conversation
elad335
commented
Dec 7, 2021
•
edited
edited
- Optimize resevation validation while waiting for events by prefetching shared memory handle of reservation in order to needing not lock VM mutex each iteration.
- Allow diverse combinations of events mask whenever reading events, previously some were not allowed and had had terminated thread execution.
162520d
to
53e2ba9
Compare
1e3919c
to
2ae83fa
Compare
Cleaned and updated pr. |
rpcs3/Emu/Memory/vm.cpp
Outdated
if (m_common) | ||
{ | ||
return {addr, nullptr}; | ||
return {this->addr, m_common}; |
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.
What is the point of copying handle (m_common) that doesn't go anywhere?
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.
Carried on without it and added proper functionality in SPU side.
60d1c71
to
fd38488
Compare
Utilities/Thread.cpp
Outdated
@@ -2235,8 +2235,8 @@ thread_base::native_entry thread_base::finalize(u64 _self) noexcept | |||
s_thread_pool[pos] = tls; | |||
|
|||
atomic_wait::list<2> list{}; | |||
list.set<0>(s_pool_ctr, 0, s_stop_bit); | |||
list.set<1>(s_thread_pool[pos], tls); | |||
list.template set<0>(s_pool_ctr, 0, s_stop_bit); |
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.
It's only necessary inside another template where it could be ambiguous.
82869c0
to
75f0afe
Compare
This could be anecdotal, but the perf gains by Neko's earlier PR #11904 have been all but negated by this PR on my end. In P5 for example - 0.0.22-13536 #11904 - 80 FPS compared to the previous master which was 72 FPS 0.0.22-13547 #11240 (this build) - back down to 73 FPS Seems like something in this PR reduced the benefit of Nekotekina's previous VM refactoring PR, at least for Persona 5. EDIT:- Fixed by #11929 |