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

[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]

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.

[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

[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

[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?

[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)

[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]

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]

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.