This is kind of related to an old discussion with PCSX2 having poor OGL performance which was rudely archived with no resolution as seen here https://community.amd.com/t5/opengl-vulkan/dreadful-opengl-performance/td-p/212252/
However recently one of our guys has been working on a Vulkan renderer and has been investigating poor performance on AMD when using "pipeline barrier from COLOR_ATTACHMENT -> FRAGMENT SHADER, but the memory flags are COLOR_ATTACHMENT -> INPUT_ATTACHMENTT, which is framebuffer-local (VK_DEPENDENCY_BY_REGION_BIT)" as he is doing what is described here: https://www.khronos.org/registry/vulkan/specs/1.2-extensions/html/vkspec.html#renderpass-feedbackloo...
What he noticed was despite what settings he was passing, it was doing full barrier and invalidating everything, which probably causes a write back of everything to VRAM, and this is VERY slow, Nvidia doesn't suffer from this same problem.
Now I don't know that OpenGL is doing the same thing, but performance is even worse there when using barriers, so I wouldn't be surprised if it was the same.
The code for the barrier is as follows
static void ColorBufferBarrier(GSTexture* rt)
{
const VkImageMemoryBarrier barrier = {VK_STRUCTURE_TYPE_IMAGE_MEMORY_BARRIER, nullptr, VK_ACCESS_COLOR_ATTACHMENT_READ_BIT | VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT, VK_ACCESS_INPUT_ATTACHMENT_READ_BIT, VK_IMAGE_LAYOUT_GENERAL, VK_IMAGE_LAYOUT_GENERAL, VK_QUEUE_FAMILY_IGNORED, VK_QUEUE_FAMILY_IGNORED, static_cast<GSTextureVK*>(rt)->GetTexture().GetImage(), {VK_IMAGE_ASPECT_COLOR_BIT, 0u, 1u, 0u, 1u}};
vkCmdPipelineBarrier(g_vulkan_context->GetCurrentCommandBuffer(), VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT, VK_PIPELINE_STAGE_FRAGMENT_SHADER_BIT, VK_DEPENDENCY_BY_REGION_BIT, 0, nullptr, 0, nullptr, 1, &barrier);
}
