Where do you got the impression that DXVK is a fork? It is not.
Do you know that CodeWeavers is also working together with Valve? https://www.codeweavers.com/about/blogs/aeikum/2019/8/20/a-year-since-protons-launch [External Link]
It is really not that black and white (or good and evil) as you are presenting it, there is much more collaboration than it seems.

View this comment - View article - View full comments

Quoting: Alm888

Quoting: jens@Alm888, are you sure that you are using Fedora?

Did you read this?

Be it my will, I would also opted out from "wine-staging" (that is already masquerading as pure wine in Fedora) and go full vanilla.

In short, yes, I am.

Quoting: jensRegarding your facts about DXVK messing with wine core libs, please refrain from commenting if you lack the knowledge. It seems that you have never setup anything with DXVK and you just base your facts on stuff you have read somewhere on the internet.

That's some empty words and accusations. You did not provide any evidence it is not as I said. And I know enough about how this all feud between WINE team and DXVK author started.

Sorry, missed your quote about wine-staging indeed, my fault, I apologize.
That said, considering that your happy with the delta between wine staging and vanilla wine, but making such a fuss about DXVK, I guess your are just on a personal crusade against DXVK. I guess you just refuse that project not due to technical reasons, but just emotionally because they did things differently than you would have liked it. Please take a step backwards and think about who the drama queen in this play actually is. I give you a hint, it is not one of the developers...

View this comment - View article - View full comments

Quoting: BeamboomLooks like Nvidia is ramping up their game now that ATI is starting to close in on them.

Well, the Vulkan beta driver has been there since ages and usually you’ll see a new release the day Vulkan spec updates are published with new extensions for desktop usage.
This driver branch just got a bit more attention lately :)

View this comment - View article - View full comments

@Alm888, are you sure that you are using Fedora? You should at least know then that Fedora already ships wine-staging instead of vanilla wine. Do you know the difference between these? Fedora is already quite gaming focused, so this is just a consequent move.

Regarding your facts about DXVK messing with wine core libs, please refrain from commenting if you lack the knowledge. It seems that you have never setup anything with DXVK and you just base your facts on stuff you have read somewhere on the internet.

Edit: the fact that Fedora already ships wine staging should may be added to the article because it places the Fedora proposal in a different light imho.

View this comment - View article - View full comments

Thanks for the additional info!

View this comment - View article - View full comments

Quoting: YoRHa-2B

Quoting: aufkrawallI hope this will allow to reduce the weird performance hit by DXVK in some titles. E.g. the round achievement screen in HotS runs like ~50% faster with native D3D11 on Pascal.

Not going to happen. While (some) nvapi extensions can improve performance if used correctly, expect single-digit gains at best.

Games running 50% faster on Windows isn't exactly uncommon on (especially older) Nvidia generations and is just more a result of certain aspects of Vulkan not being a great fit for the hardware, as well as D3D drivers doing black magic in the background like optimizing shaders based on application-provided parameters etc which we're not doing, and in CPU-bound cases, just overall CPU overhead which in turn is mostly caused by key aspects of the respective APIs being quite different.

AMD is more consistent because their drivers (including OpenGL fwiw, see radeonsi) end up doing more or less the same things that DXVK on top of one of their Vulkan drivers would.

And there's always a chance that your performance issues aren't related to D3D at all.

Also, this whole thing really just couldn't come at a worse point in time, I'm very busy with vkd3d at the moment, Joshua has been working on that as well, and I'm not sure if there's anyone else ready to pick it up and start working on it.

Do you think it is actually feasible to turn these extension libraries into something workable within Proton at all?
My impression is that this is going to be quite difficult. On the one side AMD unfortunately messed up the versioning of their AGS SDK and on the other side the NVAPI SDK is way to big to get an alternative implementation into a state that works for all games that do use NVAPI. My guess is that it will ever work for only a small selection of games like aforementioned UE4 games. Dunno if Proton will ever get a kind of profile for games where NVAPI (or AGS) is enabled based on the title.

View this comment - View article - View full comments

Quoting: Guest

Quoting: GuestNVidia still suprises me from time to time o.O

Everytime you think they will never properly support anything open source they do.

Once PhysX was open sourced, their contribution to the Vulkan Ray tracing extensions and now NVAPI o.O What next their entire driver or at least proper support for Nouveau? :D

Strictly speaking they haven't open sourced NVAPI, but instead the interfaces so that NVAPI can be re-implemented within wine. I mean it's still nice, but it really is the bare minimum.

Well, this is more or less the same that AMD is doing for AMD AGS. The AGS SDK contains the headers and libraries to link against, see https://github.com/GPUOpen-LibrariesAndSDKs/AGS_SDK [External Link]

So yeah, it is not making NVAPI Open Source, but still the standard way how these kind of SDK's are offered imho.

Having the headers officially available makes it much easier to provide "alternative" implementation. For AMD AGS there is already https://github.com/doitsujin/dxvk-ags [External Link] which maps the interesting AGS methods to DXVK.

I've tried a bit in the past to apply this to NVAPI and succeeded for one method. Having the headers now makes part of it much less of a Google try-and-error approach. For the curious: https://github.com/jp7677/dxvk-nvapi [External Link]
Note that I do have a programming background, but not in C or C++. I'm also barely familiar with the graphics domain. I know how to spell "shader" and have a rough picture how to position the different 3D API's, but that's it ;). This repository is really just intelligent copy/paste from DXVK-AGS and several other sources, so all credits should mostly go there. It's also quite a hassle to set this up for minimal gain.

View this comment - View article - View full comments

Quoting: Beamboom

Quoting: jensDo you have any experiences with git and branches? Just consider "stable" and "vulkan-beta" to be long lived branches. Sometimes the commits from the "vulkan-beta" branch will be merged into stable (I guess at the start of a new major stable branch). At some point the "vulkan-beta" branch is rebased against the "stable" branch, thus all changes from the "vulkan-beta" will be applied on top of "vulkan-beta".

See eg. https://www.atlassian.com/git/tutorials/merging-vs-rebasing [External Link]

So what you're saying is that the stable branch and the beta branch are two different branches who just so happen to have a version number very close to each other? So this beta branch is not branched off a 450.56 main code base (of whom 450.57 stable is a later version of), but is a version totally on it's own?

From my understanding the Vulkan Dev branch is indeed not branched of 450.56, but rebased against 450.56. Thus 450.56.1 contains all commits from 450.56 plus all Vulkan Development commits that didn't get merged into 450, on top of it.

Thus yeah, you could say that both branches are independent, but will be synchronized once in a while with merges (vulkan-dev into stable) and rebases (stable into vulkan-dev).

The change logs are unfortunately aren't that exhaustive but e.g. stable 450.57 does not contains all commits from vulkan-dev 440.66.15. I think (but not sure) that vulkan-dev at 440.66.12 was merged into 450. Since the vulkan dev branch was rebased against 450.56, it does not contains the commits between 450.56 and 450.57 from the stable branch.

I hope this still makes sense ;)

View this comment - View article - View full comments

Quoting: Beamboom... and yet another bloody weird case of Nvidia versioning.

Just recently they released a new STABLE driver version 450.57. Subversion 57 of the 450 driver.

... And now they continue with a new beta, version 450.56.01?! So like, this is a new driver that's a beta of the version prior to the stable 450.57??

WTF?

Do you have any experiences with git and branches? Just consider "stable" and "vulkan-beta" to be long lived branches. Sometimes the commits from the "vulkan-beta" branch will be merged into stable (I guess at the start of a new major stable branch). At some point the "vulkan-beta" branch is rebased against the "stable" branch, thus all changes from the "vulkan-beta" will be applied on top of "vulkan-beta".

See eg. https://www.atlassian.com/git/tutorials/merging-vs-rebasing [External Link]

View this comment - View article - View full comments

Quoting: dubigrasu

Quoting: jens"define yourself by the things you love and not by the thing you hate"

Nice, who said that? (I see is a quote from something?)

Thanks for the response, yeah, I guess some places could be a lot nicer when everyone (me including) would have that quote more often in the back of their minds!

I've read it somewhere here on GOL in another discussion, unfortunately not sure anymore where exactly that was and no idea where it originates from (I haven't looked for though).

View this comment - View article - View full comments