Thanks for the detailed report and the trace.
Looking at the trace, it's fairly obvious what's going on here, and I'm even seeing the frametime fluctuations when replaying it on my 6900XT. Only reason it's not a huge problem in the game itself is because it's locked to 60 FPS.
Instead of drawing text one character at a time with some font texture atlas - like any normal game would - this instead renders text entirely on the CPU. Which would still be fine if it just derped the rendered text into a texture via UpdateSubresource and used that texture to put it on screen, but that would be far too easy and efficient, so instead it's doing something like this:
void update_text(ID3D11Device* dev, ID3D11DeviceContext* ctx, ID3D11Texture2D* text_texture) {
dev->CreateTexture2D(..., &readback); /* D3D11_USAGE_STAGING, so basically a cpu-visible buffer */
ctx->CopyResource(readback, text_texture);
/* oops, need to wait for the copy to finish on the GPU, which in turn
* happens after the entire frame has been rendered... */
ctx->Map(readback, 0, D3D11_MAP_READ, ...);
[...] /* memcpy mapped texture data into internal buffer */
ctx->Unmap(readback, 0);
dev->Release(readback);
... /* do some shit to draw one character into internal buffer on CPU,
* GPU is completely idle during this time */
dev->CreateTexture2D(..., &upload); /* D3D11_USAGE_STAGING again */
ctx->Map(upload, 0, D3D11_MAP_WRITE, ...);
... /* memcpy internal buffer to mapped texture memory */
ctx->Unmap(upload, 0);
ctx->CopyResource(text_texture, upload);
dev->Release(upload);
}
More or less the exact same shit that the old Atelier games were doing. Can happen multiple times per frame, because why not.
TL;DR the game is stupid as fuck and makes us wait for the entire frame to finish rendering on the GPU just to add a single character of text. If changing kernel drivers helps then that's going to be either due to high submission overhead, or due to high latency between GPU work completing and the VkSemaphore actually getting signaled, which is certainly something that Intel should look at, but the problem is never going to fully go away on weaker GPUs.
Hmm, interesting since this was not an issue on ROG Ally Z1 Extreme. At least not that I notice and I usually play with frame time graph enabled. Still not quite getting your explanation but does your atelier fix can potentially fix this issue?
I don't really expect my old mod to work, a) Ys 8 is 32-bit and b) the mod makes some assumptions that may not hold true in this game. Here's a 32-bit build in case you want to try it out, but it's entirely untested.
Welp, at least they fix it by Ys X. It does run an a different engine so probably not same behavior there.
Nothing extracted yet.
When text appears, FPS drops from 45+ to 16 or less. I am unable to attach the video here so please take a look at the mesa issue ticket (https://gitlab.freedesktop.org/mesa/mesa/-/issues/14429). The video shows the frame-time jump during conversation text loading. Similar issue also in menu during initial load of a page can be seen in the video as frame-time spikes.
Same issue on Ys IX: Monstrum Nox. Likely due to the same engine used. The frame-time jumps actually worse there but I cannot get the backtrace for the game.
Switching to
xefromi915seems to fix the issue with frame-time jump during text loading. But introduce a different issue of constant stuttering if the GPU load is high in all game I tried.Software information
Ys VIII: Lacrimosa of DANA from GOG and launched using Heroic Launcher with umu launcher.
System information
Inxi output:
Proton-cachyos is built with DXVK-GPLASYNC support but issue still persist when the async feature is disabled.
Apitrace file(s)
Log files