Extreme FPS drops, "Lag Walls" in Linux after switching to Open Beta

I played through the whole game as it currently exists in the main Steam branch with no unfixable, not already documented errors. After credits scrolled I decided to look up the status of the Xen beta to find out the full play-through had been pushed to the Open Beta branch just the day before!

I had to delete the glshaders.cfg file to get the Beta to load.

I noticed the FPS issue at the first Xen title sequence, but the game was totally still playable for a while. I posted in Discord about it as well:

I also have the FPS issue, running Ubuntu 18.04.1
It seems to be location based. I first hit the ‘lag wall’ at the same time the chapter text Xen appears on screen, and the music starts.
If I keep walking forward when the speed returns everything is fine. If I go back into the cave I hit the lag wall all over again. And a third time when I leave the cave again

I dropped my graphics settings to as low as I could get them, and attempted to modify the mat_queue_mode setting, but couldn’t figure out where it needed to be set.

Here’s a collection of screenshots I took with +showbudget_texture enabled:

Here’s a pastebin of everything in my console: https://pastebin.com/HsTidbBn
Here’s the status and getpos results:

] status
hostname: Black Mesa
version : 100001/24 100001 insecure
map     : bm_c4a1a at: -6382 x, -791 y, 9109 z
tags    :
players : 1 humans, 0 bots (1 max)
edicts  : 2061 used of 4096 max
# userid name                uniqueid            connected ping loss state  adr
#      3 "No one of consequence" STEAM_ID_PENDING 02:54      15    0 active loopback

] getpos
setpos -6382.572266 -791.250793 9109.290039;setang -10.877665 82.221359 0.000000

Here’s some info about my system:

$ uname -a
Linux Wheatley 4.18.0-25-generic #26~18.04.1-Ubuntu SMP Thu Jun 27 07:28:31 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Results for

$ sudo lshw > lshw.txt


Edit 2:
I noticed I have two Black Mesa folders in ~/.local/share/Steam/steamapps/common/. One is Black Mesa/ and the other is Black mesa/.
Black Mesa/ is the main folder, while Black mesa/'s files all share a timestamp of when I updated to the Beta branch:

$ ls -al
total 44
drwxr--r-- 3 aaron aaron  4096 Dec  7 21:42 .
drwxr--r-- 3 aaron aaron  4096 Dec  7 21:42 ..
-rw-rw-r-- 1 aaron aaron   925 Dec  7 21:42 gamestate.txt
-rw-rw-r-- 1 aaron aaron 13179 Dec  7 21:42 glshaders.cfg
-rw-rw-r-- 1 aaron aaron  4422 Dec  7 21:42 modelsounds.cache
drwxr--r-- 2 aaron aaron  4096 Dec  7 21:42 sound
-rw-rw-r-- 1 aaron aaron     0 Dec  7 21:42 stats.txt
-rw-rw-r-- 1 aaron aaron     4 Dec  7 21:42 voice_ban.dt

No idea if this is intentional or related, but figured it’s worth noting

Edit 3:
Ran another test, this time starting the game from CLI, here’s logs:

I was running HTOP at the time, the game was making use of multi-threading at first, but after hitting the wall a single core was at 100% and the rest were low util.
I noticed two matqueue0 processes pretty high on the CPU usage list when first starting, but they seemed to disappear after the wall.

More system information–
I don’t believe this is a strict graphics driver issue; the GPU even works on [email protected]
But in case it is anyway,

$ glxinfo | grep OpenGL
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce GTX 1070 Ti/PCIe/SSE2
OpenGL core profile version string: 4.6.0 NVIDIA 430.50
OpenGL core profile shading language version string: 4.60 NVIDIA
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 4.6.0 NVIDIA 430.50
OpenGL shading language version string: 4.60 NVIDIA
OpenGL context flags: (none)
OpenGL profile mask: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.2 NVIDIA 430.50
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
OpenGL ES profile extensions:

Are there other logs that might prove useful?
Should I try to capture kernel logs during a test?