DXVK SDK

[pchome]

Feature request, asking for:

• up-to-date DXVK interface headers (.h and .idl)
• utils

It could be one more archive file on release page. Separate git repo and ability to include it as subproject would be even greater, but I'll thank you even for just headers.

Utils (e.g) would help to create tools/libs interacting with dxvk.conf (see Proton's dxvk_config.dll), or whatever else DXVK-specific. Using whole DXVK or manually tear it apart for headers is not good experience, something official would be great.

[misyltoad]

https://github.com/Joshua-Ashton/dxvk-native is more what you are after.

I need to rebase it though.

[pchome]

Thanks. I should take a close look, but at quick glance it's not exactly what I asking for.

I need only d*_interfaces.{h,idl} and src/utils/ in some standalone form. So I could just build and link utils in my project, or extract archive and start my own src/whatever/*.*.

Well, you could literally copy/paste this files into your repo, so it will be treated as official repo. Currently only known official source is https://github.com/doitsujin/dxvk-ags/blob/master/src/dxvk/dxvk_interfaces.h, but status is unknown (outdated and c++ only (?)).

EDIT: I had my own IDL file a while ago, but it was based on the file above. I'm not sure if it correct. (https://github.com/pchome/dxvk-nvapi-module/blob/master/dxvk.idl)

[doitsujin]

And why do we need this?

[pchome]

Why not? Everyone who need them (headers) currently copying them from other projects. Except me I can name Proton's vr/xr and all kind of dxvk-nvapi implementations.

I cant say searching the whole github for this or tracking changes in DXVK internals is the right thing to do for developers. Why not have official dxvk-headers which will be updated if something will change (e.g. say hello to recent xr changes).

[kakra]

Well you could just make dxvk the sub module in git, and just use headers/utils from it. Then, for build and distribution, just sync the headers over from the sub module. What DXVK probably really needs is a way to officially install headers so downstream package maintainers can make use of that. SDKs are usually for mostly closed software where you need to provide headers only so other developers can use your API. But DXVK is open source, one could just install the headers along with the compiled library.

[pchome]

Sorry, I'm bad in explaining things. Especially explaining things using foreign language. Basically I mean this: @kakra

What DXVK probably really needs is a way to officially install headers so downstream package maintainers can make use of that.

But you can't just add install_headers or so, because they contain things like #include "../path/to_different.h" and various internal stuff. I doubt developers want to reformat big part of their code, so I suggested to separate them.

[misyltoad]

Package maintainers have literally no reason to have these headers.

[doitsujin]

Well the thing is, DXVK isn't exactly a library that people are supposed to be interfacing with. There's little reason to.

The only interface that's more or less stable is the one used in the OpenVR/OpenXR bridges, but that's so basic that it can't really be used for anything but those. The D3D extensions used in dxvk-ags aren't really what I would consider stable as long as dxvk-ags is the only thing that uses those (i..e might break at any point).

[kakra]

IOW, an nvapi implementation should become part of DXVK itself? Could still be made optional through compile time options...

I'm pretty sure an integration of nvapi is either easy ("no it doesn't belong here / I don't want it") or hard ("who will maintain it? how feature complete does it need to be? code quality?"). Whatever it is, nvapi can be useful for some games that use it to query the system performance perimeter and auto-adjust the quality settings on first start. There are some games which default to ultra-low (aka potato mode) settings because they cannot query nvapi. Also, games with auto-quality during gameplay do not always work properly.

So there would be a benefit of having it around. If this will be part of dxvk or standalone is of course a different question. And then there's also the question of how feature complete an implementation has to be for the above mentions auto-quality settings working properly. I think that needs some more evaluation before considering anything.

[jp7677]

@kakra I’ve played a bit with nvapi on top of DXVK and came up with https://github.com/jp7677/dxvk-nvapi It does uses the DXVK interfaces and the (open sourced) nvapi headers and builds exactly like DXVK, thus l guess close to what you are suggesting. The practical usage is though somewhat limited. Essentially it comes down to offer ‘SetDepthBoundsTest’ which results in may be 1% perf increase, thus nearly negligible. I’ve added some sysquery stuff incl. returning driver version and some memory info, but to be honest that is more or less just ceremony for filling some fields in a single GPU tool. I think the nvapi hack in DXVK is way easier to achieve the same for actual games. Don't get me wrong, I liked playing with that and it does something, but I just think the extra complexity does not justifies the actual wins for actual games. If only AMD would have kept proper backwards compatibility in their much simpler amd-ags library...

PS: in regard to the initial request of officially providing a DXVK, well, it would be a lot of work for may be 2 hobby projects? I think there are more useful things to do in DXVK/VK3D3-Proton land.

[jp7677]

Another note about nvapi: one of the more interesting features of nvapi is querying support for "special" Nvidia shader instructions. I'm really no expert in this area, but from my understanding this is more a less a driver hack or backdoor in the Windows D3D11 driver. While an nvapi implementation might just return that those instructions are supported, they are actually not by DXVK, since DXVK doesn't handle that backdoor (and I guess it is really not that easy to add support for that).

So what I want to say is, if you want to have an nvapi implementation that offers a feature set that actual games might expect and that can make a difference, there is also a lot more work needed in other areas.

(See https://developer.nvidia.com/unlocking-gpu-intrinsics-hlsl for some background.)

[Endle]

The header files should come with mingw On my computer (Fedora33) I have

mingw32-headers-7.0.0-2.fc33.noarch : MinGW Windows cross-compiler Win32 header files
Repo        : @System
Matched from:
Filename    : /usr/i686-w64-mingw32/sys-root/mingw/include/dxgi1_6.h

mingw64-headers-7.0.0-2.fc33.noarch : MinGW Windows cross-compiler Win64 header files
Repo        : @System
Matched from:
Filename    : /usr/x86_64-w64-mingw32/sys-root/mingw/include/dxgi1_6.h

I could use them if I add these paths manually

dxvk_include_path = include_directories('./include')
dxvk_include_path = include_directories('./include',
  '/usr/i686-w64-mingw32/sys-root/mingw/include',
  '/usr/x86_64-w64-mingw32/sys-root/mingw/include')

However, although I have 10.2.1 compiler, the mingw-header shipped by fedora is too old (7.0), I can't compile doitsujin/dxvk on my computer directly. (mingw-header 7.0 only has IDXGIFactory 1-5)

$ i686-w64-mingw32-gcc --version
i686-w64-mingw32-gcc (GCC) 10.2.1 20200723 (Fedora MinGW 10.2.1-2.fc33)
Copyright (C) 2020 Free Software Foundation, Inc.

I can compile Joshua-Ashton/dxvk-native as it includes new header files

[doitsujin]

So what I want to say is, if you want to have an nvapi implementation that offers a feature set that actual games might expect and that can make a difference, there is also a lot more work needed in other areas.

I did actually take a closer look at what's actually needed, and it basically boils down to turning half the DXVK code base into Nvidia vendor hacks. The amount of stuff they added to the API is absolutely insane and not something I'm willing to do.

[pchome]

@doitsujin

The amount of stuff they added to the API is absolutely insane and not something I'm willing to do.

Meanwhile I playing with minimal implementation and every game I tried are fine with this so far. So you could do only API calls which interact with DXVK interfaces and it should work cross-vendor when GPU override option set to nvidia.

I also added an stub to report a compute capable GPU for PhysX, so I can have hardware PhysX in games like Borderlands 2, which requires nvcuda from Wine Staging, but adds a bit of gaming fun. But I do not propose this.

Keeping it minimal and focused on gaming and DXVK maybe not a bad idea. There are some D3D12 APIs too (like NvAPI_D3D12_SetDepthBoundsTestValues) btw.

[SveSop]

I have fiddled quite a bit with the nvapi code, and i have basically ended up with a couple of conclusions for my part.

1. nvapi and its "open" headers do not provide a lot of advanced functions, as this seems part of their SDK under some sort of NDA or something, so i dont think that is something that can be implemented in DXVK.
2. Games using various nvapi functions is not really well documented either, so it is a lot of fail-and-try to get stuff working, and maintaining this as a proper library is more or less out of the question.

Luckily dxvk's "nvapi hack" works most of the times, and the performance difference gained by using nvapi function like SetDepthBounds is mostly in the <1% range. Those games that utilizes PhysX (Batman series maybe?) could ofc benefit from having nvcuda enable those cuda functions. Staging implemented nvapi works pretty well at this, but it (again) wholly depends on what functions the game implements. Eg. if a game that would use cuda also checks for driverversion from nvapi - the staging one will most likely fail as the driver is reported as 337.88 or some aged driver not supported.

It is kinda fun fiddling with as a hobby project, and i have gotten some basic functions reported when running GPU Caps Viewer (Temps/clockspeeds++) that i pick from the NVML library and nvidia-settings. Sadly doing that slows stuff down a lot (probably cos i am not a programmer with skills), so i made a "lite" version that mostly only reports memory, driver version and support the SetDepthBounds functions. NVML lacks a lot of nvapi functions tho.

I just feel the benefit vs. work is somewhat lacking, not to mention any possible problems using this in a opensource manner if you end up implementing functions that nVidia feels is under their SDK/NDA/whatever license they use? (Do not know enough about such things). It could become a problem if it ends up in widespread use maybe.

[pchome]

Why are we talking about nvapi here? I think about SDK like possibility to implement such things outside the main DXVK repository w/o cloning whole DXVK (and not bother upstream with "lets include thing X"). I know such SDK should be very specific, but still. I can easily do it myself, but better for it to be supported by upstream and have some contributions.

1. nvapi and its "open" headers do not provide a lot of advanced functions, as this seems part of their SDK under some sort of NDA or something, so i dont think that is something that can be implemented in DXVK.

I don't think so. Headers provided to public are for developers, and the other "closed" part likely just deprecated and internal stuff. Some of such functions used only by the old PhysX itself (v3 and v4 now opensource and likely don't use old stuff too). I don't think it's about NDA, I guess they (Nvidia) even could provide us at least function signatures if we ask them. Implementing NvAPI we don't do regular development and may need those missing and deprecated parts.

Luckily dxvk's "nvapi hack" works most of the times, and the performance difference gained by using nvapi function like SetDepthBounds is mostly in the <1% range.

Those "<1%, not worth to implement" will sum, repeat this phrase for 10 different things and you will lose noticeable improvement opportunity for some games.

[SveSop]

1. nvapi and its "open" headers do not provide a lot of advanced functions, as this seems part of their SDK under some sort of NDA or something, so i dont think that is something that can be implemented in DXVK.

I don't think so. Headers provided to public are for developers, and the other "closed" part likely just deprecated and internal stuff. Some of such functions used only by the old PhysX itself (v3 and v4 now opensource and likely don't use old stuff too). I don't think it's about NDA, I guess they (Nvidia) even could provide us at least function signatures if we ask them. Implementing NvAPI we don't do regular development and may need those missing and deprecated parts.

It could very well be loads of deprecated stuff not included in the SDK, but the main issue is that we would kind of reverse-engineer the whole nvapi library, as the headers do not really hint at the actual functions the library does. The function signatures is not really public, but it has to be available for developers that make apps to use the functions. What i found i found by googling, and not from nVidia - and i have absolutely no clue if it is problematic to include in a opensource library. You can also use IDA or other disassemblers and memory/function tools to figure this out (as i am sure many/most have done).

I have done a lot by looking at what apps like GPU Caps Viewer does when fired under wine. It makes a call, and nvapi either comes back with the function, or a unimplemented stub. By googling and reading various source examples i have figured out what the calls are, but i still end up with loads of unimplemented with a function address not found anywhere. I suppose if you sign up for nVidia's dev whatever, you would be given this?

https://developer.nvidia.com/nvapi Guess the "lib files" is binary blobs tagged together with the headers... I see several places the mention of

Requires NDA Edition for full control of this feature.

That would mean no-dice on using it for opensource tho..

Frame Rendering Ability to control Video and DX rendering not available in DX runtime. Requires NDA Edition for full control of this feature.

Would be a perfect example for something that could be useful for DXVK perhaps?

I am also sure someone with some programming skills could do a lot with this, and i do like the idea of a wine version of nvapi. nvml is already available for Linux, and it has a lot of functions.. no doubt. But whatever related to D3D11/12 would ofc not be there.

Luckily dxvk's "nvapi hack" works most of the times, and the performance difference gained by using nvapi function like SetDepthBounds is mostly in the <1% range.

Those "<1%, not worth to implement" will sum, repeat this phrase for 10 different things and you will lose noticeable improvement opportunity for some games.

Yeah.. 1% here, and 1% there will eventually add up :)

[pchome]

Would be a perfect example for something that could be useful for DXVK perhaps?

The thing is, Nvidia had no choice but to create "layer" on top of D3Dx. Because D3Dx is the third party library. But, DXVK is D3Dx implementation. So, most of "layering" simply do not needed, DXVK already do some stuff "better" by default, or via options. For example there is barrier control option, you don't need nvapi to enable this. Also even if you implement such stuff and make an game use it don't mean it will work same way as on Windows. Because of how GPU/CPU/Memory resources used differently by Linux and Vulkan.