Project

General

Profile

Emulator Issues #10888

code veronica performance regression after november 2017

Added by zlice over 3 years ago. Updated 20 days ago.

Status:
Working as intended
Priority:
Normal
Assignee:
-
% Done:

0%

Operating system:
N/A
Issue type:
Bug
Milestone:
Regression:
Yes
Relates to usability:
No
Relates to performance:
Yes
Easy:
No
Relates to maintainability:
No
Regression start:
Fixed in:

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

works_vs_doesnt.diff (131 KB) works_vs_doesnt.diff zlice, 02/15/2018 09:17 PM

History

#1 Updated by JosJuice over 3 years ago

  • Relates to performance changed from No to Yes
  • Regression changed from No to Yes
  • Subject changed from code veronica downgrade after november 2017 to code veronica performance regression after november 2017

#2 Updated by JMC4789 over 3 years ago

  • Assignee set to Stenzek

#3 Updated by Stenzek over 3 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.

#4 Updated by JMC4789 over 3 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.

#5 Updated by zlice about 3 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

#6 Updated by zlice about 3 years ago

tried on different hardware and there's no issue...close this. sorry about that.

#7 Updated by JMC4789 about 3 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.

#8 Updated by zlice about 3 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

#9 Updated by JMC4789 about 3 years ago

  • Assignee deleted (Stenzek)

I tested on my AMD and the performance seems fine still. Not sure what's going on still.

#10 Updated by zlice about 3 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.

#11 Updated by zlice about 3 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"
~~~ c
void AbstractStagingTexture::ReadTexels(const MathUtil::Rectangle& rect, void* out_ptr,
u32 out_stride)
{
ASSERT(m_type != StagingTextureType::Upload);
if (!PrepareForAccess())
return;

ASSERT(rect.left >= 0 && static_cast(rect.right) <= m_config.width && rect.top >= 0 &&
static_cast(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(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(rect.GetWidth() * m_texel_size), m_map_stride);
int copy_height = rect.GetHeight();
char* dst_ptr = reinterpret_cast(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;
}
}

#12 Updated by ZephyrSurfer 20 days 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.

#13 Updated by zlice 20 days 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.

#14 Updated by zlice 20 days 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.

#15 Updated by zlice 20 days ago

tested latest git^

#16 Updated by JMC4789 20 days 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.

Also available in: Atom PDF