Emulator Issues #10888
code veronica performance regression after november 2017
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
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
#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.
#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
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
void AbstractStagingTexture::ReadTexels(const MathUtil::Rectangle& rect, void* out_ptr,
ASSERT(m_type != StagingTextureType::Upload);
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());
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;
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.