Wine's Vulkan Code Seeing Performance Improvements, Further Enhancing DXVK

[oiaohm]

Fair enough. Doesn't change the fact you love arguing with people who know what they're talking about because they're actual developers, unlike you. And obviously being wrong in the process.

Also you have done the same thing to me so I don't trust you either. Just because someone is a developer does not mean they don't make mistakes.

[Weasel]

No I have in fact found a very interesting little bug. The bug got me this time but it interesting.

https://github.com/wine-mirror/wine/search?q=__i386__&unscoped_q=__i386__

Go though what that returns there is no vulkan_private.h some of the time. Yes you get two different counts179 when its there and 178 when it not. Yes vulkan_private.h the only file that pulls the disappearing act when doing a search for __i386__ using area.

Its also the only section of code where __i386__ is used in a header without any inlines or other functional code. So there is something slightly unstable about github search maybe it relates to using a system that has not be logged in and the file ending in _private.h. Maybe if github does not trust your system for some reason it hides stuff from search results? Its small enough that most of the time you would not notice of course it would have to be something that caught me out.

Fair enough. Doesn't change the fact you love arguing with people who know what they're talking about because they're actual developers, unlike you. And obviously being wrong in the process.

[oiaohm]

Yes, please stop spouting nonsense indeed and actually look at the code.

https://github.com/wine-mirror/wine/...vate.h#L23-L26

Interesting so something is proxied in different way to the opengl conversion code and that creates a code search bug.

> Basically there is no special code for 32 bit Vulkan in wine.

Like, did you even look at the code before making that comment? :v

Yes but I missed it due to a interesting search bug.

Imagine making a clown out of yourself in front of the dev actually working on this patch series. (see Joshua himself)

No I have in fact found a very interesting little bug. The bug got me this time but it interesting.

https://github.com/wine-mirror/wine/search?q=__i386__&unscoped_q=__i386__

Go though what that returns there is no vulkan_private.h some of the time. Yes you get two different counts179 when its there and 178 when it not. Yes vulkan_private.h the only file that pulls the disappearing act when doing a search for __i386__ using area.

Its also the only section of code where __i386__ is used in a header without any inlines or other functional code. So there is something slightly unstable about github search maybe it relates to using a system that has not be logged in and the file ending in _private.h. Maybe if github does not trust your system for some reason it hides stuff from search results? Its small enough that most of the time you would not notice of course it would have to be something that caught me out.

[Weasel]

Basically stop spout nonsense. struct processing in wine Vulkan is the same for 64 and 32 bit versions. None of this recent patches in fact changes that.

https://github.com/wine-mirror/wine/...lls/winevulkan

Basically there is no special code for 32 bit Vulkan in wine. If there is point it in the above links files. Guess what as normal you posted thinking you had a point but you had nothing Weasel.

Imagine making a clown out of yourself in front of the dev actually working on this patch series. (see Joshua himself)

[Snaipersky]

> Basically there is no special code for 32 bit Vulkan in wine.

Like, did you even look at the code before making that comment? :v

The hammer has dropped. Though since you're here, could you comment on how useful it would actually be to have all MS graphical API's translated to vulkan or gallium? I want to say it would be most useful for mixed api applications (directdraw and dx8, say), or is this actually of little value?

[JoshuaAshton]

> Basically there is no special code for 32 bit Vulkan in wine.

Like, did you even look at the code before making that comment? :v

[cute2dgirl]

Basically stop spout nonsense.

Yes, please stop spouting nonsense indeed and actually look at the code.

https://github.com/wine-mirror/wine/blob/6edf38c205a6f5db369bf24a7edd4623ee6e32f1/dlls/winevulkan/vulkan_private.h#L23-L26

[oiaohm]

Once again you're wrong and spout nonsense. The struct conversion is done for 32-bit VULKAN because the struct layout is different between the

Basically stop spout nonsense. struct processing in wine Vulkan is the same for 64 and 32 bit versions. None of this recent patches in fact changes that.

https://github.com/wine-mirror/wine/...lls/winevulkan

Basically there is no special code for 32 bit Vulkan in wine. If there is point it in the above links files. Guess what as normal you posted thinking you had a point but you had nothing Weasel.

[Weasel]

So saying windows 64 bit applications don't need this structure conversion is wrong its just so rare that you will hit it you will more likely be more likely to win the loto by dumb luck picking up a random ticket on the street someone lost.

Once again you're wrong and spout nonsense. The struct conversion is done for 32-bit VULKAN because the struct layout is different between the vulkan library on unix, and the vulkan library on Windows.

DXVK (and D9VK) obviously are simple .DLL files that use the actual vulkan DLL, and it's the (fake) vulkan DLL that needs to convert from the "32-bit Windows struct layout" to the "32-bit Unix layout" before passing it to the system (unix) library.

On 64-bit both Vulkan struct layouts are the same so there's no conversion needed: the fake wine Vulkan dll will just pass through calls to the unix library.

This has nothing to do with D3D, it's Vulkan. It only affects DXVK because it uses Vulkan.

[oiaohm]

Note that the improvements pretty much only affect 32-bit applications, since 64-bit apps don't require struct conversion.

Honestly, Dx8 games - and many earlier Dx9 games - are so old that performance is not really a concern, wined3d is fine for those. I think Josh mentioned wanting to add D3D8 support at some point but it has absolutely no priority whatsoever.

There are a few dx8 and dx9 games where you see high than normal cpu usage caused by dx 8/9 to opengl conversion miss matches that require decent amount of cpu time to deal with the differences wined3d. Please note I should have been more exactly when I said performance gains possible it is only in select titles that uses those dx 8/9 features that cannot map to opengl well but do map to vulkan very well.

Lot of early dx8 games engines were converted from dx7 so never really used the dx8 new features.

Dx 1-7 to opengl is a very direct mapping so there is basically nothing to gain there other than sorting out horrible allocation issues in enterprise applications that can be like opengl, dx1-7,dx8, dx 9, dx10, dx11 all working on the same memory buffer these are not games any more but pure ass enterprise applications doing horrible things like controlling a factory floor.

Most 64 bit applications are dx10 or newer. There are a handful for dx 8/9 applications for x86-64/amd64 for windows. They were programs for "Windows XP Professional x64 Edition" yes that was dx8/9 system. We are talking application count here less than 100 world wide across all enterprise that have ever existed that need dx8 for a 64 bit windows binary. So saying windows 64 bit applications don't need this structure conversion is wrong its just so rare that you will hit it you will more likely be more likely to win the loto by dumb luck picking up a random ticket on the street someone lost.

The fun attempting to support all windows applications that have ever existed is dx 1-12 + interactions with opengl and vulkan on 32 bit and 64 bit. Of course does get simpler when you ingore these horrible corner cases like "Windows XP Professional x64 Edition" created.