Integrated graphics game crashes: amdgpu: Not enough memory for command submission

Hi. I bought a new Ryzen 5 3400g processor for doing some basic Linux gaming on the integrated Raven Ridge graphics. It’s pretty fast for integrated graphics if you use fast ram.

Problem is, most of my wine games are crashing intermittently with this error:
‘amdgpu: Not enough memory for command submission.’

I’m running a Ubuntu Budgie 18.04, kernel v5.1.16 (because I had to update it to get 3d acceleration support for the Ryzen 5 3400g integrated gpu), 32GB ddr4 3000mhz (set to 3000mhz in the UEFI), I set the memory shared with graphics to the maximum of 2GB in the UEFI settings, no overclock or any other adjustments to the UEFI settings. Crashes happen regardless of graphics settings it seems.

I went into winetricks and set the video memory size to 2000MB, and also on video memory size=default, neither stops the crashing.

Very disappointing, because I’m not having any other showstopping problems for gaming on Linux with this machine.
Also happens in Skyrim SE under Steam Proton, but I haven’t tried setting the video memory in winetricks in proton yet.

Maybe this is something I need to post on the DXVK github? I thought I’d post it here first in case anyone’s found a solution or workaround already.

First, be aware that Zen 2 is a new architecture that requires the newest drivers to properly work. That said, I read that the APUs are actually Zen+, not Zen 2. Either way, my first suggestion is make sure all your driver versions (mesa-vulkan-drivers, kernel, etc.) have full Ryzen 3400g support.

Then, test native games to see if it’s a Wine or DXVK problem. Where does that error line come from? Is it a Wine prompt? A DXVK log? Those will disappear if you try a native game.

Then, you can try a game which works on Wine drivers, but would work better with DXVK on. You can toggle DXVK off and see if the error persists, eliminating DXVK from the equation.

I’ve used the 2400g APU for quite a while and I’ve never specified video memory size. With 32GB, I think you’re being really conservative about it. Also, if you check some youtube videos on APU shared memory size, you’ll notice it doesn’t matter if you set it to 256mb or 2gb, the APU will use as much as needed. That said, I set mine to 256MB and I played Warframe with DXVK (using way more than 256MB, for sure).

I also didn’t have to use any winetricks. I know this varies from game to game, but I’m not sure the video size string is useful for all titles, just some select few. (and it’s an old workaround which may not be necessary)

It’s working okay for me on Manjaro so I also suspect Mesa issues. Try 19.04 maybe?

Thanks for the replies guys, good to hear you’re not having the same problem with the Vega Raven Ridge graphics that I’m having. :slight_smile:

Yea, maybe it’s a driver or kernel issue.

I’m using the oibaf repo, so I’ll try removing that and see if there’s any change, also might have a go at seeing if older kernels work.

The amdgpu out of memory error message I’m getting is displayed in the Lutris wine log for the game.

I’ll boot up 19.04 from a live USB too, and see if that’s any better.

I haven’t had any crashes in native games yet, but if I can’t get the issue fixed I might see if I’ve got anything Linux native that’s vram hungry, and see if I get the same issue.

Thanks for your suggestions!

Just a heads up: although the oibaf PPA is usually more updated than padoka, I had a lot more problems with it. I can remember more than 3 times where everything was working and then 1 package broke during some update (or reinstall). So I migrated to padoka and everything started working again (although it was about 2 weeks ‘late’ on updates. That didn’t matter at all)

Try changing from oibaf to padoka only if everything fails. It’s quite a hassle to change from one to the other without reinstalling your system… I can copy a tedious method I came up to solve it, if you get to that point.

Oh that’s interesting. I just switched over to Padoka using sudo ppa-purge ppa:oibaf/graphics-drivers, and then added padoka and updated my system packages.

Is there more that I need to do to switch over properly? Everything seems to be going well so far, except I’m still having the same problem with the AMDGPU error, and the games crashing.

I also looked at the error log and saw that it’s spamming this when the game crashes:

warn: D3D11Texture2D::QueryInterface: Unknown interface query
warn: f8fb5c27-c6b3-4f75-a4c8-439af2ef564c
warn: D3D11Texture2D::QueryInterface: Unknown interface query
warn: f8fb5c27-c6b3-4f75-a4c8-439af2ef564c
warn: D3D11Texture2D::QueryInterface: Unknown interface query

I didn’t notice that before but maybe I ignored it because I saw the AMDGPU vRAM related one one first.

I tried running a few games without any updated mesa and video drivers, but the performace was so sluggish I decided I had to go try Padoka instead.

I found that Rise of The Tomb Raider seems to be Linux native, so I ran that, and it was sluggish without updated drivers, but it didn’t crash.
I’ll try it again soon, turn up the graphics quality settings, and see if I can get it to crash.

Yea, Rise of the Tomb Raider runs nicely Linux native on the settings I set it up with a few days ago for benchmarking. Played it for a while and no crashing.

So far I’ve found that Assassins Creed Odyssey and Star Wars Battlefront crash very reliably in Lutris still.

I think I’ll try booting up Ubuntu 19.04 next, and see if that has the same problems.

Just realised I’d made a few pretty crucial mistakes:

On this page, https://github.com/lutris/lutris/wiki/Installing-drivers, it says to install one Padoka repo for Vega and the other for non-vega. I think I had the non-vega one install initially, so I installed ppa:paulo-miguel-dias/mesa instead.

I also realised that I hadn’t uninstalled my libvulkan1 libvulkan1:i386 files from when I was using my nvidia card.
I removed those, but am still getting the same problem. I wonder if I’ve still got some nvidia packages left hanging over from my previous machine.
I tried out Ubuntu 19.04 from a live USB, but it was giving me errors relating to some chromium related font package. Online forums said you have to downgrade the package to get rid of the error, but when I tried to do that, apt was going to remove gnome, and basically the entire system, so figured that was pointless.

I’ll try an Ubuntu 18.04.2 live USB and see if I can get it working on that. If so, then it means I’ve stuffed something on my install.

Ok, so I ended up installing Ubuntu Budgie 18.04 because I forgot I needed to upgrade the kernel in order to get llvm 9.0 (I think?) for Vulkan to work on the APU, and that requires a reboot, so rather than seting up a persistent USB I just made a partition and installed it.

I set everything up, and the crashing was the same, and the error messages were the same.
I tried kernel versions 5.2 and 4.20, both have Vulkan support on the APU, but same problem on both.

In desperation, I then upgraded the OS to 19.04, and had the same problem there. Fortunately I didn’t have the same problem I had with the fonts package on the 19.04 liveusb, but now I’m stumped for an explanation of what’s causing the crashes and the error message.

I wonder if there’s some setting I need to change in the UEFI?

Woah, slow down with the spiral of thoughts there. LLVM 9.0 is gotten by compiling the package yourself OR getting a PPA, it doens’t ‘come in the kernel’. What happens is that oibaf ships llvm 9, while padoka (may) ship llvm 8. As far as I know, 8.x should be enough.

Also, libvulkan1 is the name of the Mesa package for nvidia, it doesn’t do anything for AMD. mesa-vulkan-drivers and its i386 equivalent are the only things that matter for AMD.

What I recommend is simply try to install a fresh ubuntu 18.10/19.04, put padoka ppa, install mesa vulkan drivers and update everything as needed. Your AMDGPU drivers come from the kernel, and you may need to have a pretty high kernel version to support it. I’m unsure about that, because 3400g uses vega cores, and vega cores seem to be pretty much stable from 2200g and 2400g from the previous era.

So, in order:

  • check which kernel supports your CPU
  • check which kernel supports your GPU
  • get the proper kernel with Ukuu or a PPA, if not provided natively on Ubuntu
  • check the minimum package version requirements for mesa-vulkan-drivers on DXVK
  • Test native OPENGL games (dota2)
  • Test native Vulkan games (Tomb Raider, Dota2 with vulkan DLC + changing in-game)

As a last resort, try a couple different distributions that may have the package set you need for your new processor.

  • Pop Os feels good enough as an ubuntu alternative that has good GUI elements and updated packages.
  • Manjaro seems to be going in a good way as well.
  • Personally, I use Fedora 30 because it has a good mix between having new packages and remaining stable.

I’m recommending this as your last option because I believe things are fixable in Ubuntu and I don’t want you to be distrohopping and having to learn everything new from a new distribution for nothing. I felt some ‘growing pains’ getting 2400g to work a year ago, but it was definitely manageable on Linux Mint 18.3 (which has quite outdated packages)

p.s.: https://launchpad.net/~paulo-miguel-dias/+archive/ubuntu/mesa this is the Padoka I used. Read the description and realize how it mentions it has llvm 9.0 right there.

Hi Dan1lo, thanks for your steps breakdown on the process to follow. I’m not entirely sure on how to go about the following:

  • check which kernel supports your CPU
  • check which kernel supports your GPU
  • check the minimum package version requirements for mesa-vulkan-drivers on DXVK

I’ve done all those things to an extent, but I’m finding it difficult to locate specific information that details precisely all of the information I’d want to verify the items on this checklist.

I’m using https://launchpad.net/~paulo-miguel-dias/+archive/ubuntu/mesa, and I’ve updated my packages after upgrading to kernel to version 5.2.3-050203-generic.

I’ve just tested Dota2 in opengl, and no problems there. I also tried some vulkan Linux native games, and they’re all working great.

I have been having one problem with Doom 4, which crashes the video driver under OpenGL (the system continues running, but the screen totally locks up, no access to runlevels or anything), but I’m pretty sure I had the same problem with that running on an nVidia GTX 1060 machine I was testing a while back, so I’m thinking it’s just a bug in that game.
Vulkan works fine, but interestingly I get about 5-10 FPS slower with Vulkan in Doom 4 on the APU than with OpenGL, so it’s unfortunate I can’t get OpenGL mode to stop crashing.

I also tried Skyrim Special Edition via Steam Proton, and that’s now working as perfectly as can be expected under wine too. So maybe I’m starting to have some success :slight_smile:

I also ran Starcraft 2 for a while in Lutris, and that seemed to be fine. It only seems to be certain games that are crashing in wine. I suppose it could just be some kind of quirk in wine compatibility with the driver components for Vega APUs, or something like that.
I’ll keep tinkering with it and write some notes on my experiences down, and post any findings on which games are crashing, with any info about my experiences with what triggers the crashes etc.

I noticed for example that Star Wars Battlefront 2015 only seems to crash in game when I start pressing buttons on the keyboard. Moving the mouse around seems ok, so I might try hooking up a controller and see what happens there. Perhaps it could be unrelated entirely to the graphics drivers etc, but then I don’t know why I’d be getting the vram error message in the Lutris log if that’s the case.

Assassins Creed Odyssey was loading into the game for 30 seconds or so prior to switching to Padoka, and now crashes as soon as I get past the loading screen.
I did change its Lutris settings around a fair bit, so it may resolve itself after finding the right settings.

At least I know that it’s only certain wine games that are having this problem, and I can start taking notes on the specifics I find out about the games that crash. Then hopefully some pattern emerges that I can look into, and hopefully get to the bottom of what specific problem those games have with my system.

Oh yes, and my fresh install of Ubuntu Budgie 18.04 had the same crash message. As it also did when I upgraded it to 19.04.

Good finds! If native games are working, it may be some type of trick you have to do on those specific games that crash or give weird errors. A weird example from my Windows era was trying to run Titan Quest and being greeted with a “No Virtual Memory Found!” error… which 16 GB of available ram :smiley:

About OpenGL/Vulkan running better/worse: Vulkan doesn’t automatically make things run better. What it does for Linux users is offer a way to make Directx games run through Vulkan. So… going from not working to working in whatever way means an infinite boost in performance! When comparing Graphic APIs by themselves, it depends on how they programmers actually put them in the game (for example, I feel like Vulkan on Dota 2 is kinda poorly made).

There’s a small chance that you have incompatibilities due to Budgie. I quickly checked and saw it’s based on GNOME. Most complaints come from KDE (Plasma) users + games, but I’d keep an eye on that subject.

If ACO worked before and is buggy after applying Padoka, there may be some incompatibilities with that specific Mesa version. I remember three specific cases:

  • Default repository (ubuntu/linux mint) giving me very poor or unusable DXVK, but working Dota 2
  • Padoka giving usable DXVK and Dota 2
  • oibaf with new features and better DXVK, but breaking Dota 2

and whatever other combination of those. The point being: sometimes a DXVK version and a Mesa driver version may mismatch, causing some things to break. In extreme cases (oibaf being EDGING), it may also break native Vulkan, which is not right at all.

Yep. I’ve given up on ACO and Star Wars Battlefront for the moment. Most things I want to run are running appart from that, and quite well too. So I can’t really complain.

Only thing is, the what seems to be the video driver crashing, is really annoying.

When a game’s not running that well like for me with Doom 4 in OpenGL mode, and for example I was able to get my install of Spellforce 3 working again after dropping back the wine version to 4.9 and the DXVK version to 1.2, but it was still unstable enough to hang and take out the video driver with it.

My system is still running, sound is still going, hard drive light ticking away, but I have to power it off at the switch because the keyboard isn’t responding to commands because the whole desktop session seems to have been taken out by the video driver crashing.

I’m concerned that I’ll end up with file system errors if I have to keep powering off the PC when a game crashes the video driver.

Maybe you can try Unigine Superposition as a graphics driver tester, instead of games. If games run for a while and then break, it’s useful to check your wine logs on it (and activate wine debug, etc etc).

Keep in mind that there are a bit of incompatibilities between DXVK and Wine versions. 1.0 and 1.3 seem to have been big versions, so they require specific Wine versions on them (not sure which).

Just to be clear, your system only has 3400g as cpu+gpu, right? The hangs do sound like mesa-vulkan-drivers bugs. If you have that and mesa-vulkan-drivers:i386 updated, maybe you need even higher (git) versions. One of my tedious processes was to use oibaf and go to https://gitlab.freedesktop.org/mesa/mesa to cross-reference oibaf’s versions with specific commits. For example, if oibaf says “mesa-vulkan-drivers 1.9999~oibaf~abc123”, I’ll go to that repository and check the latest commit starting with abc123. Sometimes there would be fixes for Vega integrated graphics. In my early 2400g days, the whole computer would freeze: nothing would respond, sound would get stuck and only a hard reset would solve it. That was caused by the kernel, probably a junction of amdgpu+2400g cpu drivers at that time.

Ultimately (ugh), try Manjaro or Fedora. There’s a small chance their way of packaging stuff helps you set everything up more easily.

Great suggestions as always Dan1lo :slight_smile:

A quick note, before I go out, because I just got ACO working! :wink:

I was looking at the graphics settings wondering if there was something I should turn off that the radeon driver doesn’t support.
Then the penny dropped that the answer for a workaround was obvious:

Turn down the settings that use video ram! :wink:

Which is usually the textures. So I did that, and now it’s running solid. It runs nicely too, except that I have sad, low res looking textures:

Star Wars Battlefront doesn’t have a VRAM visualiser, so I’ll just have to use the force… :stuck_out_tongue:

To stop the crashing I noticed that the VRAM usage needs to be well below the 2GB limit, as the OS etc probably use some too I guess.

Hmmmm:
‘Unified memory: no’?

Sounds like maybe it’s disabled the function for sharing the available RAM with the GPU? I’ll have to dig around in my UEFI for a bit.

glxinfo | egrep -i ‘device|memory’
Device: AMD RAVEN (DRM 3.32.0, 5.2.3-050203-generic, LLVM 9.0.0) (0x15d8)
Video memory: 2048MB
Unified memory: no
Memory info (GL_ATI_meminfo):
VBO free memory - total: 1210 MB, largest block: 1210 MB
VBO free aux. memory - total: 3026 MB, largest block: 3026 MB
Texture free memory - total: 1210 MB, largest block: 1210 MB
Texture free aux. memory - total: 3026 MB, largest block: 3026 MB
Renderbuffer free memory - total: 1210 MB, largest block: 1210 MB
Renderbuffer free aux. memory - total: 3026 MB, largest block: 3026 MB
Memory info (GL_NVX_gpu_memory_info):
Dedicated video memory: 2048 MB
Total available memory: 5120 MB
Currently available dedicated video memory: 1210 MB
GL_AMD_performance_monitor, GL_AMD_pinned_memory,
GL_EXT_framebuffer_object, GL_EXT_framebuffer_sRGB, GL_EXT_memory_object,
GL_EXT_memory_object_fd, GL_EXT_packed_depth_stencil, GL_EXT_packed_float,
GL_NVX_gpu_memory_info, GL_NV_conditional_render, GL_NV_depth_clamp,
GL_AMD_pinned_memory, GL_AMD_query_buffer_object,
GL_EXT_gpu_shader4, GL_EXT_memory_object, GL_EXT_memory_object_fd,
GL_MESA_window_pos, GL_NVX_gpu_memory_info, GL_NV_blend_square,
GL_EXT_memory_object, GL_EXT_memory_object_fd, GL_EXT_multi_draw_arrays,

Don’t forget you may need to set your video ram in the registry for your wine prefix. You can google that, and I think you can actually set that number higher than your actual video ram, as long as you have the system ram to back it up.

Oh cool, thanks Llewen :slight_smile: I’ll look into it.

Rats. Doesn’t seem to make a difference with Assassins Creed Odyssey.
Perhaps there are other settings like that somewhere I can make use of to try to get the ram sharing to work.