Final Fantasy X HD crashes with DxvkMemoryAllocator: Memory allocation failed

[ShadowsFriend]

While the last time I opened an issue regarding this game my toolchain was at fault (#187), this time this is probably not the case. The game crashes pretty fast at what seems to be always the same moment during the intro after starting a new game when using dxvk while working with wined3d. Loading a game does not help either for it also crashes pretty soon after doing so. This time I was able to dump the shaders, which I will attach to the report. I have also tried to acquire an apitrace, which turned out to be difficult because apitrace throws an exception most of the time. After a lot of tries I managed to get it to run once but replaying the trace using dxvk did work without obvious problems, which is why I decided to not provide it with the report.

Software information

Final Fantasy X HD on steam with the low graphics preset

System information

• GPU: NVIDIA GeForce GTX 660
• Driver: 390.48
• Wine version: 3.5 vanilla
• DXVK version: https://github.com/doitsujin/dxvk/commit/d68d62f837fe9c6898565bbfd5eafa7172173398 (and a lot of older versions over the time)

Log files

• d3d11.log: FFX_d3d11.log
• dxgi.log: FFX_dxgi.log

Shader dump

• FFX_shaderdump.zip

[doitsujin]

Your logs indicate that this is not caused by a shader compilation issue. Please add a wine backtrace and, if possible, an apitrace file.

[ShadowsFriend]

Well, this is a pretty strange bug overall. I started the game without steam to get a clean console output from wine and suddenly it did not crash at the same point anymore and actually displays a dxvk error. [1] contains the console output. And [2] is a link to an apitrace containing the points where the game usually crashes. Strangely I cannot replay that one on dxvk because I get an unhandled page fault -- replaying on wined3d works fine, though. Another interesting thing might be, that I get the crash at the usual earlier position again, when I turn up the graphic settings.

[1] console_output.log [2] https://drive.google.com/open?id=118j8tIguMmQyZxBwThaTAFQi65UehIVO

Edit: The long black screen before the intro is not usually there. This only happens when the game is started with apitrace.

[doitsujin]

Thanks, will take a look at the trace. The log doesn't really tell me much at the moment.

[ShadowsFriend]

I did a little testing with more recent versions of dxvk and this remains to be a very strange issue. Once, surprisingly, the intro progressed further than it ever did before but during all consecutive starts -- after I set anisotropic filtering to 16x but also after I set it back to the previous value again -- the game crashed. I also decided to try it with the debug layers on and I actually got some errors. They do, however, appear before any crash and therefore may not be related to them at all. Nonetheless, I attached a log under [1] for it may contain otherwise useful information for you.

[1] output_validation.log

[doitsujin]

There seems to be some poor error reporting somewhere. In util_error.h, please replace

    DxvkError(std::string&& message)
    : m_message(std::move(message)) { }

with

    DxvkError(std::string&& message)
    : m_message(std::move(message)) {
      std::cerr << m_message << std::endl;
    }

and post a fresh log after the game crashed.

[ShadowsFriend]

Thank you for the quick reply! I needed to include iostream as well but here is the error message:

DxvkMemoryAllocator: Failed to allocate 100663296 bytes
terminate called after throwing an instance of 'dxvk::DxvkError'

[doitsujin]

The apitrace you provided replays fine on my system. I added some more debug output to the memory allocator which should show what exactly the game is trying to do, please test with 320cebb8f975434d46ab91987108fe86742ee9a6 and post new logs.

[ShadowsFriend]

Here[1] you go. I might add that, in the meantime, I have updated to wine 3.6 and nvidia 396.18 which allowed me to test it with both the old and the new SPIR-V compiler, resulting in no difference between the outputs. At first, I thought it takes longer to crash with the new one but after another try this turned out to be not true, for it took also longer on the second start with the old compiler. The log message on both compilers is the same, with the only thing changing between tries being the size of the allocation request, which is larger when it takes longer to crash. Additionally, I was also able to test the game on another computer -- albeit a few days ago meaning I did not have the extended allocator debug output yet -- equpped with a NVIDIA GeForce GTX 670 where the game crashes with an allocation error, too. Unfortunately, I currently have no access to an AMD card, which would otherwise be nice to conduct a few tests on as well.

[1] FFX_console_output.log

[ShadowsFriend]

I have hacked a bit of debugging into the heap allocator and was able to determine that vkAllocateMemory returns VK_OUT_OF_DEVICE_MEMORY for the two supported and adequate memory types which leads to the crash.

[ShadowsFriend]

I am sorry for the triple post but apparently I managed to get it to work. After setting the Large Address Aware flag in the game's executable the crashing stopped. It seems dxvk allocates more memory than wined3d and therefore exceeds the address space limitations of 32-bit applications when used for FFX HD.

Edit: If I increase the required memory by upping the graphics settings too much, especially by activating any form of MSAA, I am still able to crash the game. The memory constraints seem to be really tight on this one.

[doitsujin]

Hm, interesting. Thanks for digging into this.

Part of the issue is that DXVK uses persistently mapped buffers which are allocated in host memory (and it kind of has to in order to get any reasonable performance), whereas in OpenGL the driver can manage residency dynamically and enforce memory restrictions more efficiently. I'll admit that I never considered the scenario that a process may run out of memory to allocate, especially since most modern games come as 64-bit executables nowadays

Is there a way to globally force Large Address Awareness for wine? I think all 32-bit applications behave as if the flag was set when running on a 64-bit Windows system anyway so that should be a reasonable workaround.

[ShadowsFriend]

As far as I know, while all 32-bit applications on modern 64-bit Windows versions get the full 4GB address space, they do not use it by default. If I understand it correctly, the reason for this is that in some applications the MSB of pointers might not behave as expected, because the application expects the address space being limited to 2GB anyway. Using signed data types for pointers or doing other funny things with the MSB would be examples of such delicate cases[1]. The setting of the LAA flag just tells the OS that it can trust the application to use all their pointers' bits correctly. To illustrate the aforementioned, this very game seems to be an example of an application occasionally misbehaving when LAA ist set. At a certain point in the game, the camera locks and the continuation of a fight is not triggered when using the executable with LAA activated.

I do actually not know whether there is a way to globally force LAA in wine. While I have seen patches activating it being mentioned, I have not searched thoroughly enough to make a definitive statement. Although considering the possible issues, that might not be the best idea anyway.

[1] https://stackoverflow.com/questions/2288728/drawbacks-of-using-largeaddressaware-for-32-bit-windows-executables/4735005

[exolyte]

I don't think there's a way to force it globally. I've been using this patch for a while and haven't run into any trouble yet, but I haven't used a whole lot of 32bit apps either.

[Glog78]

Ok i used a tool to set laa flag to ... it worked wonderfull till the first fight with yuna in besaid. The summon work but when it should change to the aeon it basically stopped. @ShadowsFriend do you know if that might be because of LAA or because of another reason ?

[ShadowsFriend]

Although I do not know for sure, that is exactly the scene I was referring to as not working in my previous post. And interestingly enough, I found a comment[1] on the Steam forums also describing that problem after applying a 4GB patch. And because the poster is most likely using Windows, I would assume that this issue is indeed a consequence of activating LAA. [2] is another thread by the same person that than discusses the issue. And the OP only gets the issue solved by verifying the game files, which, obviously, removes the LAA flag again by downloading the original executable.

[1] https://steamcommunity.com/app/359870/discussions/0/357288572115084914/#c357288572121429371 [2] https://steamcommunity.com/app/359870/discussions/0/357288572121497929/

[NextGenRyo]

How did you get to run DXVK with this game? When I enable it the game wont start (I use lutris to handle things) without DXVK I get a lot of black textures and random crashes. I use the latest NVIDIA drivers and im on Manjaro.

[ShadowsFriend]

The answer for how to get this game to run with DXVK is probably that you do not, although I have not tried since my posts in this thread. Apart from that, I was able to complete the story using wined3d. I have, however, changed my graphics card from the NVIDIA GTX 660 mentioned above to an AMD Radeon RX 580 in the meantime. When I played the game while still using the old card, I got regular black textures, from characters being displayed completely black to everything being black, which was usually solvable by restarting the game. With the new card I occasionally encountered colorful flashing after extended periods of play but rare enough that it did not matter enough to really impact the overall enjoyment.

[Sur3]

How comes this bug is closed when dxvk still crashes when running the game:

warn:  DXGI: MakeWindowAssociation: Ignoring flags
0009:fixme:wbemprox:client_security_SetBlanket 75778C84, 032DA908, 10, 0, (null), 3, 3, 00000000, 0x00000000
0009:fixme:wbemprox:client_security_Release 75778C84
0009:fixme:wbemprox:enum_class_object_Next timeout not supported
0009:fixme:wbemprox:client_security_SetBlanket 75778C84, 032DAB40, 10, 0, (null), 3, 3, 00000000, 0x00000000
0009:fixme:wbemprox:client_security_Release 75778C84
004e:fixme:avrt:AvSetMmThreadCharacteristicsW (L"Audio",0578FEDC): stub
info:  Presenter: Actual swap chain properties:
info:    Format:       VK_FORMAT_B8G8R8A8_UNORM
info:    Present mode: VK_PRESENT_MODE_FIFO_KHR
info:    Buffer size:  1920x1200
info:    Image count:  4
info:    Exclusive FS: 1
err:   DxvkMemoryAllocator: Mapping memory failed with VK_ERROR_MEMORY_MAP_FAILED
err:   DxvkMemoryAllocator: Mapping memory failed with VK_ERROR_MEMORY_MAP_FAILED
err:   DxvkMemoryAllocator: Mapping memory failed with VK_ERROR_MEMORY_MAP_FAILED
err:   DxvkMemoryAllocator: Mapping memory failed with VK_ERROR_MEMORY_MAP_FAILED
err:   DxvkMemoryAllocator: Mapping memory failed with VK_ERROR_MEMORY_MAP_FAILED
err:   DxvkMemoryAllocator: Mapping memory failed with VK_ERROR_MEMORY_MAP_FAILED
err:   DxvkMemoryAllocator: Memory allocation failed
err:     Size:      12582912
err:     Alignment: 16
err:     Mem flags: 0x7
err:     Mem types: 0xf
err:   Heap 0: 768 MB allocated, 574 MB used, 988 MB allocated (driver), 7634 MB budget (driver), 7936 MB total
err:   Heap 1: 176 MB allocated, 158 MB used, 176 MB allocated (driver), 229 MB budget (driver), 256 MB total
err:   Heap 2: 64 MB allocated, 32 MB used, 77 MB allocated (driver), 5907 MB budget (driver), 5929 MB total
terminate called after throwing an instance of 'dxvk::DxvkError'

abnormal program termination

[ShadowsFriend]

Because there is no fix. As per comment https://github.com/doitsujin/dxvk/issues/263#issuecomment-381490505 the way memory is handled is different between DXVK and OpenGL and thus the program runs into the memory limit. Apart from asking Square Enix to provide a true 64-bit version of the game – which will not happen, obviously – there is probably no way to make it run with DXVK.

[NextGenRyo]

But I run it with DXVK and works fine. Beautiful graphics. Tested it a few minutes ago just to make sure it still works.

[Sur3]

Yeah it runs fine until it reaches the memory limits. I think when the memory is full there needs to be some memory management to offload old memory blocks somewhere else or completely drop them and reload them when used again..

[NextGenRyo]

How long it take for the memory to fill up? I wanna try testing it.

On Tue, 28 Apr 2020, 14:03 Sur3, notifications@github.com wrote:

Yeah it runs fine until it reaches the memory limits. I think when the memory is full there needs to be some memory management to offload old memory blocks somewhere else or completely drop them and reload them when used again..

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/doitsujin/dxvk/issues/263#issuecomment-620592484, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABHOYDCLZXPRNDRLGYGVSMDRO3HY7ANCNFSM4EZUAHLA .

[Glog78]

The fastest way to test it for me is ... put all settings to high and than let the intro animation run. Usually it crashes in the fireplace scene before he stands up and goes behind the stones without LAA enabled.

[NextGenRyo]

OK I played and I played up to Besaid after you meet Wakka and I had no problems at all. Maybe try just with default settings or something?

[Glog78]

If you have PROTON_FORCE_LARGE_ADDRESS_AWARE set the game works till summoning the first AEON. This is known and happens on Windows too with Large Adress Aware Bit set. So i assume that you currently play with Large Adress Aware Bit enabled. But since i haven't tested for a long while now i can also retry with Proton's next 5.0-7 package today evening.

[NextGenRyo]

Its true I did have large address aware on that time, even though I never do, but for testing I thought I would use it. Now I tested again from the beggining again without Large Address Aware and played to the exact same bit with no problems still.

[Glog78]

Ok the game's vram usage is still raising (much slower than in my last tests). That means it's kinda playable till you hit the 2GB max in vram usage (which this time let me play till after the first savepoint at max settings 1920p). After you hit the 2GB mark it stops working even you can leave gracefully (esc -> quit seems to work). I wouldn't call it completly fixed but somehow playable now.

[Sur3]

Also be aware that proton 5 has LAA enabled by default now. I'm playing with a 32bit wine-staging, as I couldn't get past the aeon with proton, but it generally crashes very fast if I use dxvk and if I use WineD3D it doesn't crash often, but the graphics glitches are getting worse every minute. So I either can play with fine graphics (dxvk) for a very short time or with glitched graphics (wine3d3) for a longer time.

[NextGenRyo]

I use this wine-tkg from https://github.com/Tk-Glitch/PKGBUILDS/tree/master/wine-tkg-git its like GE wine but slighly more patches. Maybe this has somehting that helps.

I played with DXVK no Large Address Aware set up, up to Besaid and worked fine. Only exited the game on my own will.