WRC5:Intel GPU: can't start the game - display driver doesn't support native D3D9 adapters

[DenKos363]

Hello guys. Could you please help me, maybe I did something wrong? In the internet I found a lot of information about gallium-nine support for AMD GPU's, but nothing about Intel, so I am trying to run the game on it.

I am trying to run the game using gallium-nine. Below you may see output gotten with PROTON_LOG=1 I compiled mesa with gallium support and new iris driver, I added gallium-nine to the steam wine prefix (in ninewinecfg I see that all 3 checkboxes are enabled, support enabled).

HW info: GPU: HD Graphics 5500 (Broadwell GT2) Kernel: 5.0.0-050000-generic OS: Ubuntu 18.04

159914.395:0029:002a:trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\dbghelp.dll" : builtin
159914.543:0029:002a:err:d3d9nine:common_load_d3dadapter Failed to load d3dadapter9.so.1 set by D3D_MODULE_PATH (/home/ubutu/mesa_versions/mesa-git-12.06-iris/lib/x86_64-linux-gnu/d3d/)
Native Direct3D 9 will be unavailable.
For more information visit https://github.com/iXit/wine-nine-standalone
159914.543:0029:002a:err:d3d9nine:d3dadapter9_new Your display driver doesn't support native D3D9 adapters.

[axeldavy]

Venemo, who works on iris support, says there is issues with mesa master. I don't know exactly which version would work, best would be to wait a week or two this gets fixed.

[Venemo]

There is a regression in mesa 19.1 and master, which affects iris + nine. We are currently working on fixing it. I would suggest to wait a couple of weeks until this is resolved.

[DenKos363]

hm, thanks for fast reply. I checked 19.1 (one of the early commits with enabled iris) and the same result. Will wait for updates, thanks again. Should this issue be created in mesa BZ or it is already exist there?

[Venemo]

It's enough that we have this issue here, no need to duplicate it in the mesa BZ.

[Venemo]

Technical details:

Since this commit nine will manually allocate a GPU resource and give that to the driver to use in slot 0, whereas previously it used the in-memory user_buffer. This is all good and may yield more optimal behavior than before.

However, iris treats cbuf0 in a special way: what you can see in iris_setup_uniforms is that iris turns all system values into cbuf0 uniforms and shifts all other uniform usage that were previously in cbuf0 to match this. So, essentially, in the current implementation, iris must have both the sysvals and the cbuf0 uniforms in the same GPU resource.

Possible solutions:

1. Copy the user-supplied resource into the buffer that is allocated by upload_uniforms. This is easy and I made a patch that does this but in practice it performs really badly.
2. Change nine so that it keeps using user_buffer on iris. This is a hack, and may result in sub-par performance, and a maintainability burden.
3. Change iris in such a manner that it puts the sysvals into a separate UBO slot, and allow the state tracker to use cbuf0 just like any other, for its own purposes.

I think 3. is the correct solution here, because it reduces the complexity of the driver (so it won't need to treat cbuf0 differently) while also improving its flexibility.

[Venemo]

@DenKos363 Just one more thought for you: iris is not yet the default intel driver, so you need to set the MESA_LOADER_DRIVER_OVERRIDE=iris environment variable if you want to use it.

[DenKos363]

@Venemo sure, I know this and do so. Below you may see script I am using for running the game. Thank you one more time. Will wait for updates and be happy to test the fix as soon as it will be provided.

export LIBGL_DRIVERS_PATH=/home/ubutu/mesa_versions/mesa-git-12.06-iris/lib/x86_64-linux-gnu/dri/
export MESA_LOADER_DRIVER_OVERRIDE=iris
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/ubutu/mesa_versions/mesa-git-12.06-iris/lib/x86_64-linux-gnu/
glxinfo -B
D3D_MODULE_PATH=/home/ubutu/mesa_versions/mesa-git-12.06-iris/lib/x86_64-linux-gnu/d3d/ "$@"

[Venemo]

Here is a work-in-progress MR to fix iris with nine: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1104

[Venemo]

@DenKos363 Something seems not right in your environment. The error message you get indicates that it didn't load nine at all.

[tomboy-64]

When you get something working, I'd be happy to test it. I have the same hw as op and looking to get gallium-nine working with Starcraft 2. I'm running on gentoo, currently kernel 5.1.9.

The current patch compiles with head, but mesa seems to crash out on anything, even ninewinecfg.exe.

[Venemo]

@tomboy-64 Starcraft 2 works for me with this patch: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1104

Though note that both iris and nine's iris support are experimental at this time, meaning there are still issues that we need to iron out. Two issues I know of are that I don't see any shadows in SC2, and the GPU hangs when I click the quit button.

[DenKos363]

Hello guys, sorry for long reply. I managed to successfully apply gallium-nine to the game and run it, but found 2 issues:

1. with this commit (e81392868e6827360762fff38baf2c10c1f3b7f0 is the first bad commit) game started crashing with this assertion: [1;32mNative Direct3D 9 v0.4.0.294-release is active. For more information visit https://github.com/iXit/wine-nine-standalone[0m 81249.157:0029:002a:fixme:d3d9nine:DRIPresentGroup_GetMultiheadCount (0x1ae2c0), stub! 81249.157:0029:002a:fixme:d3d9nine:DRIPresentGroup_GetMultiheadCount (0x1ae2c0), stub! ../src/gallium/drivers/iris/iris_resource.c:855: iris_resource_get_handle: Assertionaux_state == ISL_AUX_STATE_RESOLVED || aux_state == ISL_AUX_STATE_PASS_THROUGH' failed.`

2. Before this commit game launches with a black screen - and then (after some time) - crashes.

here is a report in Bugzilla https://bugs.freedesktop.org/show_bug.cgi?id=111150

[dhewg]

Does iris+nine work for you guys by now?

[DenKos363]

hi, sorry for delay, I would close this issue for now, because I was able to apply drivers to the game. Other issues are not related no gallium-nine, at least for now. Thanks for the help