Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Borderlands 2 runs out of video memory (or so it says) #170

Closed
rkfg opened this issue Jun 14, 2019 · 26 comments
Closed

Borderlands 2 runs out of video memory (or so it says) #170

rkfg opened this issue Jun 14, 2019 · 26 comments

Comments

@rkfg
Copy link

rkfg commented Jun 14, 2019

Here's a screenshot when it happens:
2019-06-13_00-54-24

Don't mind the grey rectangles, it's a selection from the screenshot program. The main window isn't redrawing when the error happens. This time it happened when I got to the main menu but it can also "crash" (not really crash as it's not a segfault or whatever) midgame. The error is weird because I have plenty of VRAM (8 Gb) and the game doesn't allocate this much. Usually happens after an hour of playing or so.

Software information

Borderlands 2, all settings maxed out.

System information

  • GPU: GTX 1070
  • Driver: 430.26
  • Wine version: Proton 4.2-7
  • DXVK version: 1.2.1 built from master

For whatever reason I can't produce log files. My command line in Steam is DXVK_HUD=full DXVK_LOG_LEVEL=debug DXVK_LOG_PATH=/home/rkfg %command% but there are no new files in my home directory.

PS: many thanks for this project! Some might say it's not that important as D3D9 games are old and don't need beefy hardware to work smoothly on modern hardware but it's blatant lies. My FPS is like 50% better and more stable (almost no hitches) in BL2 with D9VK than with default OpenGL backend and it's even more correct! On OpenGL I see small black squares flickering on the geometry and some crosshairs and D9VK doesn't produce them.

@rkfg
Copy link
Author

rkfg commented Jun 14, 2019

Maybe related: in #36 a huge amount of samplers mentioned. I found out it only happens when "Texture fade" option is enabled, samplers count grows like crazy! I turned it off and now it's steady at around 80. Maybe that's the cause of this out of memory issue. I'll play further to confirm.

@fgblomqvist
Copy link

Was just about to report this myself. Played roughly 3 hours without any issues, but then it started crashing frequently (or rather, freezing). Sometimes I would get the same little error box saying it was out of memory. I'm running on a 2080 Ti with 11GB of VRAM, all graphic settings maxed out. Same proton/D9VK as rkfg. Tried running it without D9VK and it works fine then (but worse performance).

Worth noting is that my boss-intro-scenes are often screwed up as well (tons of random black-ness). Probably a separate issue though.

@rkfg
Copy link
Author

rkfg commented Jun 14, 2019

In the end my game froze, no error message box this time, no interesting info in the game's own log. The RES memory of the game process shrunk to just 18 Mb though.

@rkfg
Copy link
Author

rkfg commented Jun 14, 2019

Did any of you manage to get a D9VK log file? I'm running the game with Proton, installed D9VK into the prefix as described and as you can see on the screenshot I can enable the HUD. But the logging options either don't work or I do something wrong.

Regarding samplers and texture fade: when this option is enabled I see textures fading each time I open a box. It's like the game reloads them every time so it might very well be the reason of samplers number going up quickly. I have the HD textures DLC installed.

@K0bin
Copy link
Contributor

K0bin commented Jun 14, 2019

I'd say this is caused by D9VKs implementation of GetAvailableTextureMem. Maybe hook that up with VK_EXT_memory_budget and return values that are actually correct.

@fgblomqvist
Copy link

I'll try to get a log tomorrow for this. Should be able to monitor the VRAM usage as well to make sure this is not affecting the rest of the OS. At one time, when BL2 froze, my Discord froze as well. Odd.

@pchome
Copy link
Contributor

pchome commented Jun 15, 2019

Maybe worth to try and compare 0.11 release.

I was able to play through the whole Tina's DLC w/o any OOM errors (in April or so). Now I tried new Lilith's DLC (+Handsome Collection) and got an error immediately after start (D9VK built from git master).

Mem usage snapshot during the error (longer session)

Several short sessions w/ 0.11 are fine so far.

EDIT: April build vs now

@edwin-v
Copy link

edwin-v commented Jun 15, 2019

I've tried quite a few builds with BL2/Proton and results vary from day to day. The current master crashes for me as well, but doesn't show anything. Master on Wednesday had "brightness problems" (snow in the start areas was completely bright white). The latest build from before the commit gap before Wednesday worked reasonably well, but had a few annoying graphical glitches that looked like they had to do with lighting (moire style patterns) and messes up the character introduction screens. The build from about a week before that had serious lighting problems. So it looks like the areas that are being worked on at the moment heavily affect BL2 and I haven't been able to find one that was good for this game. Unfortunately wined3d also has quite a few glitches.

I'll have a try with the 0.11 build now as suggested. (Edit: 0.11 appears the same as the one from before Wednesday).

@Comevius
Copy link

Comevius commented Jun 15, 2019

For me it usually freezes or crashes after an hour or so. Setting TextureMB from 120 to 1000 in the [MemoryBudgets] section of WillowEngine.ini makes the game crash much more often, either before the main menu or soon after the game is loaded. Turning off Texture Fade makes the game crash less often.

  • GPU: GTX 1050 Ti
  • Driver: 430.26
  • Wine version: Proton 4.2-7
  • DXVK version: d9vk-0.12 release 19cefff

Launcher_d3d9.log

err:   DxvkMemoryAllocator: Memory allocation failed
  Size:      18874368
  Alignment: 256
  Mem flags: 0x7
  Mem types: 0x681
  • DXVK version: d9vk master 88e5369

Launcher_d3d9.log

err:   DxvkMemoryAllocator: Memory allocation failed
  Size:      16777216
  Alignment: 256
  Mem flags: 0x6
  Mem types: 0x681
err:   DxvkMemoryAllocator: Memory allocation failed
  • DXVK version: d9vk-0.11 release 2a0c153

Launcher_d3d9.log

err:   DxvkMemoryAllocator: Memory allocation failed
  Size:      16777216
  Alignment: 256
  Mem flags: 0xe
  Mem types: 0x681

@K0bin
Copy link
Contributor

K0bin commented Jun 15, 2019

Setting TextureMB to a bigger value will probably cause it to keep more textures alive.
For most textures D3D9 also has a copy in system memory and when the game reaches the 32 bit address space limit, it crashes.

@rkfg
Copy link
Author

rkfg commented Jun 15, 2019

Solved my no log issue. The cause is that Proton overrides DXVK_LOG_LEVEL with none, even if it's specified from command line. To enable logging I copied user_settings.sample.py to user_settings.py in Proton's directory (usually %steamroot%/steamapps/common/Proton 4.2 or such) and changed the log setting inside it to "DXVK_LOG_LEVEL": "debug". Now the log file is created correctly. Will post my output when the game freezes next time.

@Comevius
Copy link

Setting TextureMB to a bigger value will probably cause it to keep more textures alive.
For most textures D3D9 also has a copy in system memory and when the game reaches the 32 bit address space limit, it crashes.

That makes sense. I disabled the Ultra HD Texture Pack, and there are no issues now as far as I can tell after testing the game for 25 minutes with TextureMB set to 1000.

@fgblomqvist
Copy link

fgblomqvist commented Jun 15, 2019

Tried producing a log today and it worked well. I actually happen to be at a spot where the game will crash every single time the save is loaded (instantly as soon as the save almost finished loading).

Here is the log (22MB):
steam-49520.log

Here's the end of it:

steam-49520.log (end)
52927.113:0027:0028:trace:seh:cxx_frame_handler handling C++ exception rec 0x239dae0 frame 0x239de64 trylevel 12 descr 0x18c5868 nested_frame (nil)
52927.113:0027:0028:trace:seh:dump_exception_type flags 0 destr (nil) handler (nil) type info 0x18b9714
52927.113:0027:0028:trace:seh:dump_exception_type     0: flags 1 type 0x1958470 {vtable=0x18a38f4 name=.PA_W ()} offsets 0,-1,0 size 4 copy ctor (nil)
52927.113:0027:0028:trace:seh:dump_exception_type     1: flags 1 type 0x1958480 {vtable=0x18a38f4 name=.PAX ()} offsets 0,-1,0 size 4 copy ctor (nil)
52927.113:0027:0028:trace:seh:dump_function_descr magic 19930522
52927.113:0027:0028:trace:seh:dump_function_descr unwind table: 0x18c588c 44
52927.113:0027:0028:trace:seh:dump_function_descr     0: prev -1 func (nil)
52927.113:0027:0028:trace:seh:dump_function_descr     1: prev 0 func 0x14c3580
52927.113:0027:0028:trace:seh:dump_function_descr     2: prev 1 func 0x14c358b
52927.113:0027:0028:trace:seh:dump_function_descr     3: prev 1 func 0x14c3596
52927.113:0027:0028:trace:seh:dump_function_descr     4: prev 1 func 0x14c35a1
52927.113:0027:0028:trace:seh:dump_function_descr     5: prev 1 func 0x14c35ac
52927.113:0027:0028:trace:seh:dump_function_descr     6: prev 1 func 0x14c35b7
52927.113:0027:0028:trace:seh:dump_function_descr     7: prev 6 func 0x14c35c2
52927.113:0027:0028:trace:seh:dump_function_descr     8: prev 7 func 0x14c35cd
52927.113:0027:0028:trace:seh:dump_function_descr     9: prev 7 func 0x14c35d8
52927.113:0027:0028:trace:seh:dump_function_descr     10: prev 6 func 0x14c35e3
52927.113:0027:0028:trace:seh:dump_function_descr     11: prev 1 func 0x14c35ee
52927.113:0027:0028:trace:seh:dump_function_descr     12: prev 1 func 0x14c35f9
52927.113:0027:0028:trace:seh:dump_function_descr     13: prev 1 func 0x14c3604
52927.113:0027:0028:trace:seh:dump_function_descr     14: prev 1 func 0x14c360f
52927.113:0027:0028:trace:seh:dump_function_descr     15: prev 1 func 0x14c361a
52927.113:0027:0028:trace:seh:dump_function_descr     16: prev 1 func 0x14c3625
52927.113:0027:0028:trace:seh:dump_function_descr     17: prev 16 func 0x14c3630
52927.113:0027:0028:trace:seh:dump_function_descr     18: prev 17 func 0x14c363b
52927.113:0027:0028:trace:seh:dump_function_descr     19: prev 17 func 0x14c3646
52927.113:0027:0028:trace:seh:dump_function_descr     20: prev 16 func 0x14c3651
52927.113:0027:0028:trace:seh:dump_function_descr     21: prev 1 func 0x14c365c
52927.113:0027:0028:trace:seh:dump_function_descr     22: prev 1 func 0x14c3667
52927.113:0027:0028:trace:seh:dump_function_descr     23: prev 22 func 0x14c3672
52927.113:0027:0028:trace:seh:dump_function_descr     24: prev 23 func 0x14c367d
52927.113:0027:0028:trace:seh:dump_function_descr     25: prev 23 func 0x14c3688
52927.113:0027:0028:trace:seh:dump_function_descr     26: prev 22 func 0x14c3693
52927.113:0027:0028:trace:seh:dump_function_descr     27: prev 1 func 0x14c369e
52927.113:0027:0028:trace:seh:dump_function_descr     28: prev 0 func 0x14c36a9
52927.113:0027:0028:trace:seh:dump_function_descr     29: prev -1 func (nil)
52927.113:0027:0028:trace:seh:dump_function_descr     30: prev 29 func 0x14c36b4
52927.113:0027:0028:trace:seh:dump_function_descr     31: prev 30 func 0x14c36d6
52927.113:0027:0028:trace:seh:dump_function_descr     32: prev 31 func 0x14c36f8
52927.113:0027:0028:trace:seh:dump_function_descr     33: prev 32 func 0x14c371a
52927.113:0027:0028:trace:seh:dump_function_descr     34: prev 33 func 0x14c373c
52927.113:0027:0028:trace:seh:dump_function_descr     35: prev 32 func 0x14c373c
52927.113:0027:0028:trace:seh:dump_function_descr     36: prev 31 func 0x14c373c
52927.113:0027:0028:trace:seh:dump_function_descr     37: prev 30 func 0x14c373c
52927.113:0027:0028:trace:seh:dump_function_descr     38: prev 29 func 0x14c373c
52927.113:0027:0028:trace:seh:dump_function_descr     39: prev 38 func 0x14c3747
52927.113:0027:0028:trace:seh:dump_function_descr     40: prev 39 func 0x14c3752
52927.113:0027:0028:trace:seh:dump_function_descr     41: prev 29 func 0x14c375d
52927.113:0027:0028:trace:seh:dump_function_descr     42: prev 41 func 0x14c377f
52927.113:0027:0028:trace:seh:dump_function_descr     43: prev 42 func 0x14c37a1
52927.113:0027:0028:trace:seh:dump_function_descr try table: 0x18c5854 1
52927.113:0027:0028:trace:seh:dump_function_descr     0: start 0 end 28 catchlevel 43 catch 0x18c5844 1
52927.113:0027:0028:trace:seh:dump_function_descr         0: flags 1 offset -616 handler 0x4c1d3a type 0x1958470 {vtable=0x18a38f4 name=.PA_W ()}
52927.113:0027:0028:trace:seh:dump_function_descr expect list: (nil)
52927.113:0027:0028:trace:seh:dump_function_descr flags: 00000001
52927.113:0027:0028:trace:seh:call_catch_block matched type 0x18b9720 in tryblock 0 catchblock 0
52927.113:0027:0028:trace:seh:_CreateFrameInfo (0x239d5ec, 0x239db9c)
52927.113:0027:0028:trace:seh:__regs_RtlUnwind code=e06d7363 flags=3
52927.113:0027:0028:trace:seh:__regs_RtlUnwind eax=00000000 ebx=0239de64 ecx=0239d500 edx=00141010 esi=0239dae0 edi=018c5844
52927.113:0027:0028:trace:seh:__regs_RtlUnwind ebp=0239d6c8 esp=0239d510 eip=7d3b24e6 cs=0023 ds=002b fs=0063 gs=006b flags=00200246
52927.113:0027:0028:trace:seh:__regs_RtlUnwind calling handler at 0x7bc85e60 code=e06d7363 flags=3
52927.113:0027:0028:trace:seh:__regs_RtlUnwind handler at 0x7bc85e60 returned 1
52927.113:0027:0028:trace:seh:cxx_local_unwind calling unwind handler 0x14c35f9 trylevel 12 last 0 ebp 0x239de70
52927.113:0027:0028:trace:seh:cxx_local_unwind calling unwind handler 0x14c3580 trylevel 1 last 0 ebp 0x239de70
52927.113:0027:0028:trace:seh:call_catch_block calling catch block 0x18c5844 addr 0x4c1d3a ebp 0x239de70
52927.113:0027:0028:trace:seh:__CxxUnregisterExceptionObject (0x239d5ec)
52927.113:0027:0028:trace:seh:_FindAndUnlinkFrame (0x239d5ec)
52927.113:0027:0028:trace:seh:_IsExceptionObjectToBeDestroyed 0x239db9c
52927.113:0027:0028:trace:seh:__DestructExceptionObject (0x239dae0)
52927.113:0027:0028:trace:seh:call_catch_block done, continuing at 0x4c1d18
warn:  D3D9DeviceEx::SetRenderState: Unhandled render state 180
warn:  D3D9DeviceEx::SetRenderState: Unhandled render state 183
err:   DxvkMemoryAllocator: Memory allocation failed
  Size:      2097152
  Alignment: 256
  Mem flags: 0xe
  Mem types: 0x681
52930.318:0027:0059:trace:seh:MSVCRT_raise (22)
Unable to read VR Path Registry from C:\users\steamuser\Local Settings\Application Data\openvr\openvrpaths.vrpath
Unable to read VR Path Registry from C:\users\steamuser\Local Settings\Application Data\openvr\openvrpaths.vrpath
52930.319:0027:0059:fixme:msvcrt:__clean_type_info_names_internal (0x2795cc) stub
terminate called after throwing an instance of 'dxvk::DxvkError'
Setting breakpad minidump AppID = 49520
Steam_SetMinidumpSteamID:  Caching Steam ID:  76561198075526353 [API loaded no]
pid 4702 != 4701, skipping destruction (fork without exec?)

The log level was info. Not sure if it should have been debug.
Finally, since my save file seems to be great for debugging atm, here it is:
Save0001.zip

For me, it crashes before I can see the character. Tried it about 6 times and got the same result every time. Got the out of memory dialog a few times, and a few times not. Monitoring the GPU, the VRAM usage goes up to between 2-2.5GB every time. Sits at about 0.9GB without the game running.

The game is running on max graphics with the Ultra HD texture pack installed. Haven't modified any files. I can successfully play without D9VK without any issues (but still performance degradation).

EDIT:
For record, it does not work with 0.11 either.

@Comevius
Copy link

That makes sense. I disabled the Ultra HD Texture Pack, and there are no issues now as far as I can tell after testing the game for 25 minutes with TextureMB set to 1000.

Nevermind. It just crashed with the same DxvkMemoryAllocator error without the Ultra HD Texture Pack and with TextureMB set to 1000. I guess I set it back to 120.

@rkfg
Copy link
Author

rkfg commented Jun 16, 2019

The game froze and well, the same is in the log:

err:   DxvkMemoryAllocator: Memory allocation failed
  Size:      33554432
  Alignment: 256
  Mem flags: 0xe
  Mem types: 0x681

Looks like we're hitting the 32 bit limit (I have 32 Gb of RAM and of course an amd64 system). When you play and visit different locations with many different textures it might exhaust the address space pretty quickly.

@rkfg
Copy link
Author

rkfg commented Jun 16, 2019

It seems on Medium textures the game works without this issue. The VRAM usage floats around 2100, the game usually crashes when it hits 3100 or so. That's all with UHD textures enabled.

@ericwomer
Copy link

ericwomer commented Jun 17, 2019

For me it usually freezes or crashes after an hour or so. Setting TextureMB from 120 to 1000 in the [MemoryBudgets] section of WillowEngine.ini makes the game crash much more often, either before the main menu or soon after the game is loaded. Turning off Texture Fade makes the game crash less often.

* GPU: GTX 1050 Ti

* Driver: 430.26

* Wine version: Proton 4.2-7

* DXVK version: d9vk-0.12 release [19cefff](https://github.com/Joshua-Ashton/d9vk/commit/19cefffdc80df3a8510878a83706ee0ae39174d0)

Launcher_d3d9.log

err:   DxvkMemoryAllocator: Memory allocation failed
  Size:      18874368
  Alignment: 256
  Mem flags: 0x7
  Mem types: 0x681
* DXVK version: d9vk master [88e5369](https://github.com/Joshua-Ashton/d9vk/commit/88e5369185dcd8edd23f7ffbf4807f08773166fd)

Launcher_d3d9.log

err:   DxvkMemoryAllocator: Memory allocation failed
  Size:      16777216
  Alignment: 256
  Mem flags: 0x6
  Mem types: 0x681
err:   DxvkMemoryAllocator: Memory allocation failed
* DXVK version: d9vk-0.11 release [2a0c153](https://github.com/Joshua-Ashton/d9vk/commit/2a0c153b0c9e0b754b9cfc41ea16c5bdc758fab5)

Launcher_d3d9.log

err:   DxvkMemoryAllocator: Memory allocation failed
  Size:      16777216
  Alignment: 256
  Mem flags: 0xe
  Mem types: 0x681

This also happens with America's Army Proving ground when using the master branch I get the out of memory pop up, but with 0.12 I don't get the pop up, but I get the same as here in the logs.

@edwin-v
Copy link

edwin-v commented Jun 18, 2019

I tested the latest master ( e2fcd7f ) and tried to quit to the menu from the game. I showed "Compiling shaders" and then gave the memory error. This did not happen on build 2436010 that I've use for a while before.

I don't have logs since I wasn't looking for this, but I assume it'll be the same as for the others.

@Comevius
Copy link

It seems on Medium textures the game works without this issue. The VRAM usage floats around 2100, the game usually crashes when it hits 3100 or so. That's all with UHD textures enabled.

Can confirm, with medium textures and the Ultra HD Texture Pack it no longer crashes.

@K0bin
Copy link
Contributor

K0bin commented Jun 24, 2019

Nothing about this has changed on the D9VK side. Medium textures just use less VRAM.

@telans
Copy link

telans commented Jun 24, 2019

It seems on Medium textures the game works without this issue. The VRAM usage floats around 2100, the game usually crashes when it hits 3100 or so. That's all with UHD textures enabled.

Can confirm, with medium textures and the Ultra HD Texture Pack it no longer crashes.

Yeah, same here. Uses ~500mb less. Everything else is still on high however

@BlueGoliath
Copy link

This is still an issue in .013...

@lavadrop
Copy link

I'm getting err: DxvkMemoryAllocator: Mapping memory failed VK_ERROR_MEMORY_MAP_FAILED
Just by loading into Sanctuary. I can't get into the game anymore.

Ryzen 1600 | RX 580 8 Gb | 16 Gb RAM
AMD RADV/ACO | DRM 3.27.0, 5.0.0-20, LLVM 8.0.0 | Mesa 19.2.0-devel | Vulkan 1.1.107
D9VK 0.13f
steam-49520.log

rkanati referenced this issue Jul 31, 2019
Fixes sampler leakage in Borderlands 2
Not the best solution but it's the best we have right now
@VortexAcherontic
Copy link

VortexAcherontic commented Aug 3, 2019

Today I tested the latest nightly build (#692) right after dropping into the game. This did not happened with d9vk 0.12 there I was able to play and stream the game multiple hours with "no" issues. (Except of some missing lightning VFX)

Screenshot_20190803_142559

Further more I can also confirm reducing the Texture quality to low or medium will solve the issue.

Now comes a funny thing.
If you loaded a game (so exiting the main menu and dropping into sanctuary for example) and now increasing the texture quality to high will not result in a crash.
Also if you now teleport to another map (with textures still set to high) will not crash the game.
And my VRAM keeps on 30 - 40% (independent from the texture quality. Which is realy funny. Which means if I set the quality to low or to high will, according to conky, not increase or decrease the total VRAM used by the GPU 8 GB GDDR on a GTX 1080)

Max texture quality and after changing from one map to another:
Screenshot_20190803_143725

But exiting than back to the main menu will crash the game again.

misyltoad added a commit that referenced this issue Oct 29, 2019
…re by default

This allows us to use more than 4GB of VRAM in games.

This behaviour changed in the Fall Creators update (https://www.neowin.net/news/windows-10-fall-creators-update-fixes-the-directx-9-memory-allocation-bug)
But lets keep it around in case some game depend on the old behaviour! (It's D3D9 after all...)

May impact #93, #170, #383 and #438
@Matoking
Copy link

The error still occurs with commit eccc5c9.

misyltoad added a commit that referenced this issue Nov 2, 2019
…re by default

This allows us to use more than 4GB of VRAM in games.

This behaviour changed in the Fall Creators update (https://www.neowin.net/news/windows-10-fall-creators-update-fixes-the-directx-9-memory-allocation-bug)
But lets keep it around in case some game depend on the old behaviour! (It's D3D9 after all...)

May impact #93, #170, #383 and #438
misyltoad added a commit that referenced this issue Nov 9, 2019
…re by default

This allows us to use more than 4GB of VRAM in games.

This behaviour changed in the Fall Creators update (https://www.neowin.net/news/windows-10-fall-creators-update-fixes-the-directx-9-memory-allocation-bug)
But lets keep it around in case some game depend on the old behaviour! (It's D3D9 after all...)

May impact #93, #170, #383 and #438
misyltoad added a commit that referenced this issue Nov 17, 2019
…re by default

This allows us to use more than 4GB of VRAM in games.

This behaviour changed in the Fall Creators update (https://www.neowin.net/news/windows-10-fall-creators-update-fixes-the-directx-9-memory-allocation-bug)
But lets keep it around in case some game depend on the old behaviour! (It's D3D9 after all...)

May impact #93, #170, #383 and #438
misyltoad added a commit that referenced this issue Nov 20, 2019
…re by default

This allows us to use more than 4GB of VRAM in games.

This behaviour changed in the Fall Creators update (https://www.neowin.net/news/windows-10-fall-creators-update-fixes-the-directx-9-memory-allocation-bug)
But lets keep it around in case some game depend on the old behaviour! (It's D3D9 after all...)

May impact #93, #170, #383 and #438
misyltoad added a commit that referenced this issue Nov 26, 2019
…re by default

This allows us to use more than 4GB of VRAM in games.

This behaviour changed in the Fall Creators update (https://www.neowin.net/news/windows-10-fall-creators-update-fixes-the-directx-9-memory-allocation-bug)
But lets keep it around in case some game depend on the old behaviour! (It's D3D9 after all...)

May impact #93, #170, #383 and #438
misyltoad added a commit that referenced this issue Nov 27, 2019
…re by default

This allows us to use more than 4GB of VRAM in games.

This behaviour changed in the Fall Creators update (https://www.neowin.net/news/windows-10-fall-creators-update-fixes-the-directx-9-memory-allocation-bug)
But lets keep it around in case some game depend on the old behaviour! (It's D3D9 after all...)

May impact #93, #170, #383 and #438
misyltoad added a commit that referenced this issue Dec 6, 2019
…re by default

This allows us to use more than 4GB of VRAM in games.

This behaviour changed in the Fall Creators update (https://www.neowin.net/news/windows-10-fall-creators-update-fixes-the-directx-9-memory-allocation-bug)
But lets keep it around in case some game depend on the old behaviour! (It's D3D9 after all...)

May impact #93, #170, #383 and #438
misyltoad added a commit that referenced this issue Dec 13, 2019
…re by default

This allows us to use more than 4GB of VRAM in games.

This behaviour changed in the Fall Creators update (https://www.neowin.net/news/windows-10-fall-creators-update-fixes-the-directx-9-memory-allocation-bug)
But lets keep it around in case some game depend on the old behaviour! (It's D3D9 after all...)

May impact #93, #170, #383 and #438
misyltoad added a commit that referenced this issue Dec 16, 2019
…re by default

This allows us to use more than 4GB of VRAM in games.

This behaviour changed in the Fall Creators update (https://www.neowin.net/news/windows-10-fall-creators-update-fixes-the-directx-9-memory-allocation-bug)
But lets keep it around in case some game depend on the old behaviour! (It's D3D9 after all...)

May impact #93, #170, #383 and #438
misyltoad added a commit that referenced this issue Dec 16, 2019
…re by default

This allows us to use more than 4GB of VRAM in games.

This behaviour changed in the Fall Creators update (https://www.neowin.net/news/windows-10-fall-creators-update-fixes-the-directx-9-memory-allocation-bug)
But lets keep it around in case some game depend on the old behaviour! (It's D3D9 after all...)

May impact #93, #170, #383 and #438
@misyltoad
Copy link
Owner

So I looked into this more and I absolutely cannot repro this on Windows.

This only ever happens when Wine gets involved for me so I feel there is some issue somewhere else causing this, but I have no idea right now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests