Emulator

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.

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.

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

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

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.

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

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.

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;
  }
}

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.

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.

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.

tested latest git^^^