Quoting: sr_ls_boyThis is the current progress of wine dx11 support

d3dcompiler_43: 70.6%
d3dcompiler_46: 64%
d3dcompiler_47: 58.6%
d3d10: 86.2%
d3d10_1: 43.3%
d3dx10_39: 97.8%
d3dx10_43: 73.3%
d3d11: 9.5%
d3dx11_42: 18.2%
d3dx11_43: 29.5%

Pay no attention to the 9.5% percentile.
That hasn't moved at all in the longest
time.

That's a script which I made, and it's probably misleading. Those are just top level dlls. Actual underlying stuff is progressing quite well.

View this comment - View article - View full comments

Good overview of the issue! I wonder what exactly can programmers do to avoid such situation. Worrying about underlying CPU type sounds like a wrong approach (too hardware specific).

View this comment - View article - View full comments

Quoting: Cyril

Quoting: Comandante ÑoñardoJust for curiousity. Can the DRMFREE version of Metro Redux run with this?

Such a shame that the Linux version isn't on GOG... (Like many others too)

I've heard the Linux version is broken anyway (that's why GOG didn't accept it), so not a big deal I suppose.

View this comment - View article - View full comments

Feel free to try. I didn't buy it yet. Even TW3 I was reluctant to buy, because of how CDPR failed to port it, but someone gave me a spare GOG key, so I could test it in Wine.

Thinking of it, I actually prefer that if the game isn't really native, that it should use open wrappers (like winelib), rather than closed ones (eON, Feral's, etc). In this sense, CDPR could partner with CodeWeavers, and sponsor their DX11 development efforts, then at least they wouldn't be breaking their promises.

View this comment - View article - View full comments

Not sure about others, but I've heard Skyrim runs very well already. At least the classic one (was there a remaster)? I'm not keeping track of Bethesda games. The last good TES game was Morrowind, and for that we have OpenMW. :)

Regarding general progress, DX11 is pretty big, so I guess it might take a while before it all will be implemented. But still, some games can work well even before that. TW3 is a good test case, because it's using really a lot of DX11 features and quite heavy ones.

View this comment - View article - View full comments

Quoting: LeflWell Shmerl has a decent computer, but 43 FPS in a AAA Game in Wine that is using DX11(?).

That's on max settings (except for hairworks and ambient occlusion). On min settings I get 50-60fps (1920x1200). And that's with RX480. Vega probably will allow playing it at 60fps proper even on max settings (since it looks GPU bound here).

Quoting: liamdaweHe's using an AMD card with the open source driver, while Mesa has come a long way, there's tons of performance improvements left to do. Not only that, but you have to remember this is being run in Wine and Wine is not even remotely finished itself.

Yes indeed, I hope Mesa and Wine will still improve further.

By the way, to run the game you either need Wine staging, or apply at least these two patches to regular Wine:

* https://github.com/wine-compholio/wine-staging/blob/master/patches/ntdll-Grow_Virtual_Heap/0001-ntdll-Remove-memory-limitation-to-32GB-on-64-bit-by-.patch [External Link]

* https://github.com/wine-compholio/wine-staging/blob/master/patches/wined3d-buffer_create/0001-wined3d-Do-not-pin-large-buffers.patch [External Link]

Without the first it simply crashes, and without second it runs at around 1 - 5fps.

View this comment - View article - View full comments

@Areso: I suppose it's not. But Unity with OpenGL really isn't optimized for heavy graphics.

View this comment - View article - View full comments

Quoting: ZeloxLike you say, the game isnt running that great atm.

And I was hoping for a better frame rate at release.

Yeah performance is abysmal for me with anything but lowest settings (RX480). Looks like it's using Unity 5.4.2f2, so it's OpenGL only (no Vulkan yet). Hopefully they'll switch to Vulkan at some point (for which they need Unity 5.6).

View this comment - View article - View full comments

Quoting: sr_ls_boyWhile they're at it, they could update the copy ofthe std c++ lib
in their runtime.

libstd++ should not be bundled in the runtime, it's an abysmally bad idea (unless you make sure all linking is limited to exactly the same version, like for example using static linking).

One of the libraries that's affected by this is Mesa-DRI. Example:

ldd /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
...
        libLLVM-3.9.so.1 => /usr/lib/x86_64-linux-gnu/libLLVM-3.9.so.1 (0x00007f4a0c254000)
        libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f4a0bed0000)
...

Note how it depends on libstdc++. And it's an important part of the graphics stack.

GNU C++ ABI guarantees (mostly) forward compatibility. I.e. if you are using application built against older libstdc++, dynamic linking with new one will work. But, there is no backwards compatibility. If you are using something built against newer libstdc++, and it dynamically links against older one, stuff can go haywire.

And that what happens, if in Steam runtime (or any other such bundle) you have a stale libstdc++, the game links against that, and then system library like Mesa-DRM links against newer one, and in result both envs are mixed, and something ends up calling stuff from new and from old in a sequence that causes a segfault (consider for example allocating memory with new one, and then deallocating with old one or any other such scenario).

https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html [External Link]

Versioning gives subsequent releases of library binaries the ability to add new symbols and add functionality, all the while retaining compatibility with the previous releases in the series. Thus, program binaries linked with the initial release of a library binary will still run correctly if the library binary is replaced by carefully-managed subsequent library binaries. This is called forward compatibility.

The reverse (backwards compatibility) is not true. It is not possible to take program binaries linked with the latest version of a library binary in a release series (with additional symbols added), substitute in the initial release of the library binary, and remain link compatible.

View this comment - View article - View full comments

If it's not related to deals with partners which they can't discuss, usually those reasons are related to the fact that they exclude some people ;) I personally don't see anything wrong with admitting that fact though.

View this comment - View article - View full comments