Check out our Monthly Survey Page to see what our users are running.
Latest Comments by jens
Quench that weekend thirst with the release of Wine 5.14
2 August 2020 at 12:07 pm UTC Likes: 2

Quoting: mphuZ
Quoting: gradyvuckovicDoes this put us any closer to a Proton update? Proton 5.14 for example?
I hope very soon. The new major version of Proton has never been so delayed (14 versions have already passed)...

I don’t know what Valves plans are, though I wouldn’t be surprised if the next rebase happens with Wine 6.0, which I think should arrive in December or January. As far as I know Wine currently sees a lot of restructuring and some long term development (PE move, media foundation, may be anti cheat). May be it is wise for Valve to continue with cherry picking until all these things are settled down. And to be fair, Proton 5.0 still does a pretty good job and it’s not that long until the end of the year.

Linux distro Fedora 33 may get DXVK as the default for Wine
23 July 2020 at 9:32 am UTC Likes: 2

Quoting: Alm888
Quoting: tuubiIn case you're interested, WineHQ provides an official repository for Fedora builds.
Thank you! I will keep that in mind when I switch to a fresher version of Fedora. Right now I am restricted to F30 due to certain scientific software.

Reading this, may be another distribution than Fedora would fit your use cases somewhat better ... Fedora moves fast and F30 is already EOL.

Linux distro Fedora 33 may get DXVK as the default for Wine
23 July 2020 at 7:02 am UTC Likes: 6

Quoting: Alm888Is it so x2? WINE project was the first to implement those libs. But then came Mr. Rebohle and reinvented them (thus, NIH syndrome) instead of adapting/improving the existing ones. And the conflict begun.
"Fun" fact: the core of the conflict? Mr. Rebohle is using C++ instead of C and did not want to mess with C-wrtitten WINE libraries. So, it is a programming language holy war at its core!
Saying it was "a Wine devs decision" is like saying the tail wags the dog.

Please don’t create drama when there is no drama. Both D3D implementations do live happily next to each other, both have a different focus, both have a different approach and a different project style. There was never any big drama or war regarding programming languages. What you are referring too was all just make up internet drama by outsiders that wanted to see a lot of drama.
Look at the wine commits, you’ll sometimes find the names of the DXVK authors there. Look at the DXVK commits, also there you’ll find names of CodeWeavers people.

Linux distro Fedora 33 may get DXVK as the default for Wine
22 July 2020 at 8:10 pm UTC Likes: 2

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
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.

Linux distro Fedora 33 may get DXVK as the default for Wine
22 July 2020 at 7:30 pm UTC Likes: 3

Quoting: Alm888
Quoting: jens@Alm888, are you sure that you are using Fedora?
Did you read this?
QuoteBe 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...

NVIDIA 450.56.02 Vulkan Beta Driver is out for Linux
22 July 2020 at 6:18 pm UTC Likes: 1

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

Linux distro Fedora 33 may get DXVK as the default for Wine
22 July 2020 at 6:08 pm UTC Likes: 3

@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.

NVIDIA open sourced part of NVAPI SDK to aid 'Windows emulation environments'
13 July 2020 at 5:58 pm UTC

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.

NVIDIA open sourced part of NVAPI SDK to aid 'Windows emulation environments'
11 July 2020 at 9:56 am UTC Likes: 5

Quoting: mirv
Quoting: Vortex_AcheronticNVidia 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

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 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
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.