Emulator Issues #10888
closedcode veronica performance regression after november 2017
0%
Description
issue:
Resident Evil Code Veronica runs at half the fps as it used to (Resident Evil 0 appears to be slower too, but not as bad)
i ran these..
git checkout $(git rev-list -n 1 --before="2017-11-21" master)
git checkout $(git rev-list -n 1 --before="2017-11-22" master)
and thought the issue was
https://github.com/dolphin-emu/dolphin/commit/efb97598629b96378edd783af82936185d8a99ce
then i created 2 directories and did a diff on them from the above git commands.
there are different files than the commit i originally thought was the issue
plenty of OpenGL changes (which is what i'm using) and a couple VideoCommon
Files
Updated by JosJuice over 6 years ago
- Subject changed from code veronica downgrade after november 2017 to code veronica performance regression after november 2017
- Regression changed from No to Yes
- Relates to performance changed from No to Yes
Updated by Stenzek over 6 years ago
Can you bisect this to a single commit? That diff is way too large to make any guess as to what the issue might be. It also includes HybridXFB, which is a likely candidate.
The commit you have listed is unlikely to affect performance to a measurable degree. It only adds a few extra instructions to the vertex shaders, and we're not vertex shader bound by any stretch. Unless there is a bug in your graphics driver/shader compiler.
Updated by JMC4789 over 6 years ago
I tried to bisect it and it came back to HybridXFB, not the thing you linked to.
I also checked it further and found out that turning on Immediately Present XFB Copies (which is equivalent to the old defaults) will return your performance to normal.
Unless you can provide more information on where it's slow or something along those lines, I don't have anything we can do anyway.
Updated by zlice over 6 years ago
Took me a bit to realize it's "edit" and not "reply"
If I knew the commit I would make a pull request, was hoping someone familiar would have an "aha"
"Immediately Present XFB Copies" (or any combination or hacks and options) has not improved anything. Immediate XFB actually made it a few frames worse when I just tried.
It is only slow during gameplay (and the intro epilogue). The beginning/intro (which I assume is all 2D) the fps are fine.
I'll see what I can figure out.
Thanks
Updated by zlice over 6 years ago
tried on different hardware and there's no issue...close this. sorry about that.
Updated by JMC4789 over 6 years ago
I'm willing to keep this open to help you figure out what's going on. Just because it's only happening on one PC doesn't mean something weird isn't going on. Are you by chance using savestates? Using them on Resident Evil games will ruin performance.
Updated by zlice over 6 years ago
not using save sates, figured that out a while back
amd drivers (radeon or amdgpu) don't work, can't try amdgpu-pro
nvidia drivers work fine
Updated by JMC4789 over 6 years ago
- Assignee deleted (
Stenzek)
I tested on my AMD and the performance seems fine still. Not sure what's going on still.
Updated by zlice over 6 years ago
Good news is I found the problem
Bad news is TextureConversionShader.cpp can't be found by cmake and I know very little about cmake builds
https://github.com/dolphin-emu/dolphin/commit/9da9f26b9049ab590217750d8d582590a3409754
Not sure why it doesn't work on my R9 290, but it kills it.
Updated by zlice over 6 years ago
narrowed it down
TextureConverter.cpp calls ReadTexels()
if i comment out the ReadTexels() call or the below everything runs smooth
not sure what ReadTexels is copy what/for
still clueless as to why this chugs on R9 290
"Source/Core/VideoCommon/AbstractStagingTexture.cpp"
void AbstractStagingTexture::ReadTexels(const MathUtil::Rectangle<int>& rect, void* out_ptr,
u32 out_stride)
{
ASSERT(m_type != StagingTextureType::Upload);
if (!PrepareForAccess())
return;
ASSERT(rect.left >= 0 && static_cast<u32>(rect.right) <= m_config.width && rect.top >= 0 &&
static_cast<u32>(rect.bottom) <= m_config.height);
// Offset pointer to point to start of region being copied out.
const char* current_ptr = m_map_pointer;
current_ptr += rect.top * m_map_stride;
current_ptr += rect.left * m_texel_size;
/*
// Optimal path: same dimensions, same stride.
if (rect.left == 0 && static_cast<u32>(rect.right) == m_config.width &&
m_map_stride == out_stride)
{
std::memcpy(out_ptr, current_ptr, m_map_stride * rect.GetHeight());
return;
}
*/
size_t copy_size = std::min(static_cast<size_t>(rect.GetWidth() * m_texel_size), m_map_stride);
int copy_height = rect.GetHeight();
char* dst_ptr = reinterpret_cast<char*>(out_ptr);
for (int row = 0; row < copy_height; row++)
{
std::memcpy(dst_ptr, current_ptr, copy_size);
current_ptr += m_map_stride;
dst_ptr += out_stride;
}
}
Updated by ZephyrSurfer over 3 years ago
While I no longer have a R9 290, this does seem like a specific enough bisect for the raised issue to warrant some checks on this.
I wonder if it's still reproducible on other AMD cards.
Updated by zlice over 3 years ago
ZephyrSurfer wrote:
While I no longer have a R9 290, this does seem like a specific enough bisect for the raised issue to warrant some checks on this.
I wonder if it's still reproducible on other AMD cards.
I'll try tonight, have a 5700, 290 is in pieces xp.
Updated by zlice over 3 years ago
well better hardware, different drivers (and other libraries), pretty sure vulkan wasnt working as well as opengl a few years back.
CV and 0 work fine afiact. 0 even gets past the train crawlspace cutscene.
may as well close this. the few things i remember finding, i was told were 'emulation issues' that had hack bypasses removed.
Updated by JMC4789 over 3 years ago
- Status changed from New to Working as intended
I'll just close this then. If anything comes up again let us know!
Marking as "working" but obviously there was something going on. But I don't think we fixed anything either.