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
Elite Dangerous logs and trace #36
Comments
I wonder... if I'm remembering this correctly... does the non-Horizons version behave differently? IIRC you can choose between them in the launcher. |
@roothorick Yep, the non-Horizons client just gets a login error which is of course unrelated. I think there's a demo of the game to try -- might do that next. |
According to this video, the game seems to (sort of) work with latest |
The video just covers the demo which doesn't include all of the functionality as far as I'm aware. I'll give this another shot sometime this week or weekend and report back :). |
The game is freezing because most terrain shaders need 40+ seconds to compile. If you have DXVK_LOG_LEVEL=debug set, you can see it for yourself. Just be patient and it will continue, despite looking like it's frozen. After the first start it will be quick. |
for me the demo version is able to launch but gets stuck within 1 minute. The non horizon version only shows a black screen on launch, sometimes it loads the background music(still with the blackscreen). Logs: Demo version Non horizon version |
@varris1 sent me some of the shaders that take up to two minutes each to compile on the driver. We're talking about DXBC shaders with over 20'000 instructions, which translate to anything up to 170'000 SPIR-V instructions. This is a game bug. Frontier probably thought it was a good idea to force loop unrolling in the HLSL compiler when it clearly wasn't. |
The offending shader has 170k instructions. Just to put this into perspective, the biggest regular shaders I've seen across a large number of games have 3-4k instructions at most (those work fine, but even that takes a while to compile). You cannot expect any Vulkan driver to make sense of the mess that this game generates. |
Hah, yes I searched a bit and got numbers indicating a few hundred instructions is 'normal'. That's why I removed my comment. Sorry. |
So there is no hope on seeing this game working on Linux unless Frontier fixes it on their side(which is never going to happen)? |
Would the shader cache cover these extreme shaders? Or ask differently, with a current DXVK version, are the "freezes" gone once the shader cache is filled? |
Completely Offtopic but to answer you guys: I got to try E:D on an account of a friend a few days ago. Used Lutris with DXVK 0.9 and current wine. E:D Horizons would freeze my entire system shortly after hitting 18% in the planet generation thing. Normal E:D and E:D Battle Arena started but threw an error that I should start the game from the launcher (I did) as there was a version mismatch. So this only seems to affect Horizons while the other modes suffer from other problems. |
@jp7677 the problem is that the shader takes ridiculously long to compile (might even be several hours, not sure if anyone tried letting it run). The state cache isn't going to help here since the shader still needs to be compiled by the driver, and while the driver's shader cache is nice, it'll only solve that problem until the next update. |
@doitsujin ok, thanks for your insights. |
@doitsujin but how is dx11 able to handle that? |
@winiciuscota That's something you need to ask driver developers. My guess is that since DXBC is already optimized by Microsoft's HLSL compiler and has its own register model, drivers just skip some optimization passes and may run much faster register allocation algorithms, which can speed up compilation quite a bit. |
Game is now running in Wine at least with DXVK, turns out the CRC error was due to a Microsoft Cryptography machineid keys being mismatched in wine: Proton still has a freezing issue which may or may not be due to the fact it doesn't have mono. |
@fls2018 this bug/issue doesn't affect E:D. It only occurs in the E:D Horizon DLC |
I am playing horizons. Edit: I'm on nvidia with the latest Vulkan 396.54.09 driver, maybe that's the difference. |
Ah, sorry. That is interesting/weird. |
@fls2018 Have you tried the game without the Horizon DLC? |
Let me explain this a bit. There are two game clients for Elite Dangerous. Core version is DX10 compatible and have regular shaders compilation at the beginning of the game. However, Horizons version, which allows you to land on planets, uses compute shaders, and requires DX11.3. So when planetary generation happens as mentioned in OP, it is where compute shaders are getting compiled. As for whole story - CRC error got fixed, along with other smaller issues for ED, that's why there's now working ED Horizons version under Wine with dxvk. |
Also it seems Nvidia works, and AMD doesn't, judging by this bug report. |
I just got Elite Dangerous (core, not Horizions) working. Haven't tested it extensively. Horizons still hangs for me on "preparing planet generation system". I think that's the AMD-specific issue. Otherwise shader generation is very quick on my system.
|
Horizons works with AMD if you replace TerrainComputeShaders.csa with TerrainComputeShadersNvidia.csa in the game files. It kind of hints the issue with the non-nvidia shaders is not the scalability of shader compilation, but then the nvidia file is a bit smaller so I guess it could be. It could be interesting if someone with an nvidia gpu tried switching the files the other way. |
Wow, that worked! At least it loaded correctly. Going to test planet landing now.
|
Well, landing on a planet worked without a problem! |
|
@agates can you test if putting the following into a
You might need to set This should make the game think it's running on a GTX 1060. |
@doitsujin That appears to have worked. |
@agates alright, guess I'm going to enable that workaround by default for this game. Can you please post the full executable name of the game? Capitalization matters. |
The games executable is: EliteDangerous64.exe But you may also need the launcher: EDLaunch.exe |
The launcher should be irrelevant. Workaround already implemented in 3d2e5a7. |
Adding it would be pointless as 32-bit version of the game is discontinued. Also all testing is now done on 64-bit prefix anyway. |
The workaround is only necessary for the full game with the horizons expansion anyways, right? |
Also true. Base game doesn't have compute shaders and regular shaders already worked fine. |
Never mind I didn't think of that as I don't have AMD myself, I deleted my post. The demo is kind of useful though particularly in troubleshooting, a lot of people on the frontier forums are trying this out and a lot of the steps up until now have been challenging for some to follow. Getting the demo running is usually the first goal for most. |
That's a good point, but I don't think the demo has planetary landing anyway :). Unless it's been updated to include it. |
Hi guys. My ED: Horizons exposes the exact same behavior that the OP had in his first post. Although this issue should already be solved, for me it isn't. Help is much appreciated. |
@Hoimar I can think of a few things to try to narrow it down. First and easiest, try a different DXVK version. I would try the version I tested with using the DXVK config file. If it happens to work, bisect the DXVK versions until it breaks so you can find it change. I don't think this is the cause, but if it happens to be then it would be useful to catch. You can also try copying the affected compute shader file mentioned above. Then, I would test with the Padoka PPA, instead of oibaf, which includes the newer LLVM you mentioned. This can definitely affect shader compilation. https://launchpad.net/~paulo-miguel-dias/+archive/ubuntu/mesa/ To adequately switch PPAs, you might want to purge first oibaf with this utility: https://askubuntu.com/questions/307/how-can-ppas-be-removed |
UPDATE: So after giving my system a rather huge swap file, ED had enough space to load etc., so it got through the shader compilation stage and I could start Horizons. BUT: It takes ages everytime I start Horizons to get past the "preparing planet generation system" stage (about 5-10min). Also, the Frontier crash reporter still pops up every time. But once ingame, it works at least. Thanks for your answer, @agates , I'll try your recommendations next. |
Aha, I do have 32GB of ram in my system. It would not surprise me if that's the main differentiator. EDIT: When you said it ate your system memory I saw 8GB and for some reason assumed it was the graphic memory |
As we suspected @agates, the shader compilation was the problematic part of the whole. So switching the PPA from oibaf to padoka (LLVM 7.0.1 -> 8.0.0, Mesa stays the same) did the trick. It launches within 1min (also no crash reporter, I suspect it pops up when the ED Client becomes unresponsive) and works like a charm. Cheers |
There appears to be two issues since the 3.3 update, one is the terrain issue but that's related to the latest Nvidia driver (also affects Windows on older hardware than Maxwell). Second is I'm finding significant performance degradation with the new Volumetric Effects that were added in 3.3 on Linux vs Windows. I'm seeing up to a third of the performance I would be normally in some specific locations that probably leverage the new effects (Iota Hydri station, some asteroid rings). Graphics appears to be fully utilized in these scenarios but lower GPU power draw? Clocks also seem to be normal. |
This has returned for Odyssey, I'm trying to confirm that it's still correctly pretending to be an nvidia card but I'm not sure where to check. edit: Swapping edit again: It does work eventually if you leave it long enough. |
The game freezes at "preparing planet generation system" after shader generation completes. This is before the main menu loads.
Software information
Elite Dangerous: Horizons
System information
Apitrace file(s)
Log files
The text was updated successfully, but these errors were encountered: