doitsujin / dxvk

Vulkan-based implementation of D3D8, 9, 10 and 11 for Linux / Wine
zlib License
12.97k stars 832 forks source link

NvAPI testing #853

Closed SveSop closed 5 years ago

SveSop commented 5 years ago

Since @pchome made that standalone meson compile version of nvapi, i have been experimenting a wee bit with various stuff there. The question could be if there is something to be done to "fix" nvapi so it more or less gets useful for those weird nvapi cases.

I do not own a game that have any serious issues with this, and searching here kinda ended up in a non-conclusive 100% way to recreate problems (for me), cos i dont want to buy 4-5-6 games just to test. I would lub some feedback on what game "is the worst" if you are not faking AMD card, and setting dll-overrides for nvapi to "disabled".

What i have experienced so far, is as ppl have described, and that is even if you fake AMD card, and the nvapi.dll exist, it will end up being used anyway.

I have added a few fake things to the nvapi source, and i know it wont actually DO any hardware setting changes, but maybe faking calls and returning "sane" answers is enough for a few games? Worth a test in my book i guess.

https://github.com/SveSop/nvapi_standalone

Grab it, compile it and test it. (Script explanation in the README).

The absolutely awesome thing about this standalone source (big thanks pchome) is that when installed via dll-overrides, you just compile and replace the install folder to test a "new version", so its easy to fiddle with.

As of now, I have just faked as much of my GTX970 as possible (easily changed, and if interested i can explain how). I do not think it really matters much tho, but its a fun experiment. I have zero coding experience, so if obvious errors or ways to do things easier is spotted, tips are most welcome :+1:

What i would love tho, is for a comparison of WINEDEBUG="-all,+nvapi" logs between the regular staging nvapi and mine, especially for games that have huge issues with this. Probably best to post it as issues on my GIT. Eg. "wine-staging.log" "wine-nvapi-standalone.log", so i can try to pinpoint if there is anything obvious that COULD help.

Not saying it actually will solve anything, but hey.. fun project nevertheless.

PS. To make sure the game/app does what it can to use nvapi, you should put this in the dxvk.conf file: dxgi.nvapiHack = False (Requires RECENT git - cf9de54 or newer) Or ofc you can override it with:

dxgi.customDeviceId = 10de
dxgi.customVendorId = 13c2

in the dxvk.conf file.

K0bin commented 5 years ago

The problem is that games actually use the D3D11 extensions that NvAPI provides. Those would have to be implemented in DXVK and I'm pretty sure doitsujin doesn't want to do that.

UE4 for example uses:

NvAPI_D3D11_BeginUAVOverlap NvAPI_D3D11_EndUAVOverlap NvAPI_D3D11_SetDepthBoundsTest

CryEngine uses:

NvAPI_D3D11_CreateFastGeometryShaderExplicit

Some other games might even be relying on something like

NvAPI_D3D11_MultiDrawInstancedIndirect to render some geometry that might be straight up missing if you just implement a stub.

SveSop commented 5 years ago

@K0bin Do you have an example game/demo i could test for this? I tested some UE4 "engine demos", but they did not poll for this, so it might not be the "engine", but perhaps something turned on per game perhaps?

K0bin commented 5 years ago

I just looked at the source code of UE4.

doitsujin commented 5 years ago

My main issue with nvapi is that it adds even more stuff that's going to break games and makes debugging a pain. Implementing some of the D3D11 extensions in DXVK wouldn't even be that hard, wiring them up to nvapi probably also wouldn't be that hard, but you'd have to get everything right - the DLL loading and initialization mechanism, reporting device capabilities, and then of course the plumbing that's needed to implement the extensions. And we already know that the wine-staging implementation does break games.

And getting everything right is kind of hard when half of it isn't even documented. It's not a public API, and we shouldn't treat it like one.

jp7677 commented 5 years ago

@SveSop If you want something to play with, Batman Arkham Knight implements two Nvidia gameworks features called "Interactive Paper Debris" and "Interactive Smog & Fog". Both features combine DX11 with NVidia PhysX. PhysX itself works on wine staging, use Fluidmark to verify this. Arkham Knight currently fails when these features are enabled because nvcuda.dll.cuD3D11GetDevice is stubed in nvapi. See also https://github.com/doitsujin/dxvk/issues/788

Please be also aware of: https://github.com/doitsujin/dxvk/issues/580

Edit: Typo.

K0bin commented 5 years ago

Wine Staging doesn't implement the CUDA<->D3D interop necessary for PhysX and even this was implemented, it wouldn't work with DXVK.

SveSop commented 5 years ago

It's a lot of functions that are not public yeah.. But there are quite a few documented functions that atleast describe their functions on the nvapi dev reference page: https://docs.nvidia.com/gameworks/content/gameworkslibrary/coresdk/nvapi/index.html

This is ofc mostly for reporting, and not actual internal functions and what the functions DO, but implementing REAL functioning nvapi in Linux probably wont be easy (Ie. having apps do overclocking and whatnot). It probably could come a long way with implementing stuff from the nvctrl.lib available for someone with a tad more programming experience than me using google and nano ;) https://github.com/NVIDIA/nvidia-settings/tree/master/src/libXNVCtrl

I am not talking "true" dx11 functions here, but possibly use nvctrl to actually grab stuff from the driver in some way? Dunno..

pchome commented 5 years ago

@doitsujin

And we already know that the wine-staging implementation does break games.

Probably due to NvAPI_D3D11_SetDepthBoundsTest doing something wrong.

Previously, enabled nvapi breaks :bat::man::tm: games and Just Cause 3 for me, but now I'm using locally patched version w/o NvAPI_D3D11_* functions (auto reported as unimplemented(?)). And I have no issues so far, I even have working PhysX in Batman* games.

Of cause there is still non-working cuda D3D1* stuff, therefore "Simulate water on GPU" && "Nvidia gameworks" options won't work.

So, if it's possible to make this few (one?) D3D1* functions in nvapi to work correctly with DXVK -- this already would be a huge progress.

doitsujin commented 5 years ago

I'm not just talking about it breaking DXVK here, it also breaks the dx9 version of Skyrim iirc. Probably others, too.

SveSop commented 5 years ago

https://www.guru3d.com/files-get/monster-hunter-official-benchmark-download,1.html Seems to be a cryengine demo thingy that generates a lot of

0087:trace:nvapi:NvAPI_D3D11_SetDepthBoundsTest (0x139550c, 0, 0.000000, 1.000000)
0087:err:nvapi:NvAPI_D3D11_SetDepthBoundsTest Failed to get wined3d device handle!

So, does the function just perform a test on the wined3d device, and report back to the demo the result? Or does it change the way wined3d renders something :) EDIT: Oh yeah.. it DOES change something ref. dlls/d3d11/device.c

artivision commented 5 years ago

Some Nvapi D3D11 extensions might have equivalent functions on Vulkan. So there is no need for Nvapi at all, just add what is compatible with Vulkan and for all drivers. I also like api uplifting (like the one D3D9_to_11 attempted to do making D3D9 games multi threaded), there is no reason to want to reproduce D3D11's exact behavior.

K0bin commented 5 years ago

Some Nvapi D3D11 extensions might have equivalent functions on Vulkan

Almost everything in NvAPI can either implemented using core Vulkan or using an equivalent NV_* Vulkan extension.

So there is no need for Nvapi at all, just add what is compatible with Vulkan and for all drivers.

There is no NvApi at all on Linux and the relevant parts of NvApi interact with the D3D11 driver which DXVK basically replaces. So we knew from the start that this is the only way to implement that.

like the one D3D9_to_11 attempted to do making D3D9 games multi threaded

That project is dead and it's impossible to multi thread D3D9 properly. D3D9 is an api thats not designed for multithreading and thus you can't use multiple threads in an implementation of it. The entire rendering depends on the order of commands from start to finish.

there is no reason to want to reproduce D3D11's exact behavior.

There is a very good reason to reproduce D3D11s exact behavior: compatibility. There are some exceptions but if you don't implement D3D11s exact behavior, games won't work.

massatt212 commented 5 years ago

their is a guy with a project call DXUP its working with DX9 games on Shader 1 or something so dont know much about it check it out https://github.com/Joshua-Ashton/dxup

misyltoad commented 5 years ago

That project is dead and it's impossible to multi thread D3D9 properly. D3D9 is an api thats not designed for multithreading and thus you can't use multiple threads in an implementation of it. The entire rendering depends on the order of commands from start to finish.

That is not entirely true. D3D9 does support multithreading if you give it a flag called D3DCREATE_MULTITHREAD which essentially locks the device every time you call anything with it.

misyltoad commented 5 years ago

(like the one D3D9_to_11 attempted to do making D3D9 games multi threaded), there is no reason to want to reproduce D3D11's exact behavior.

I don't think you understand what a thread is. You can't just magically make things multithreaded by using a wrapper -- it requires changing the engine, not the rendering interface. Besides, we return success codes and other values, things can't magically thread if we aren't just firing and forgetting.

misyltoad commented 5 years ago

their is a guy with a project call DXUP its working with DX9 games on Shader 1 or something so dont know much about it check it out https://github.com/Joshua-Ashton/dxup

My main target right now is SM2/2B.

artivision commented 5 years ago

(like the one D3D9_to_11 attempted to do making D3D9 games multi threaded), there is no reason to want to reproduce D3D11's exact behavior.

I don't think you understand what a thread is. You can't just magically make things multithreaded by using a wrapper -- it requires changing the engine, not the rendering interface. Besides, we return success codes and other values, things can't magically thread if we aren't just firing and forgetting.

I understand that if you uplift D3D9 calls to D3D11 ones, they will be run on more threads by default. Now if that breaks the game it's another matter. The same if you convert D3D9 textures to a simple 2D D3D11 surface, because that is basically what 9 technology is for 11. I also understand that if D3D11 likes to do a certain thing in one thread an Vulkan likes to do it in two, then you can try letting DXVK to uplift that in two. Now if that breaks 1/2 games then you revert, but if breaks 1/10 then you keep it and work around the 1/10.

K0bin commented 5 years ago

Sorry but everything in that comment is wrong.

if you uplift D3D9 calls to D3D11 ones, they will be run on more threads by default

No they wont.

The same if you convert D3D9 textures to a simple 2D D3D11 surface, because that is basically what 9 technology is for 11.

As long as the texture formats match this is pretty straightforward and should just work.

I also understand that if D3D11 likes to do a certain thing in one thread an Vulkan likes to do it in two

Unlike D3D9 or 11 Vulkan is very explicit and allows the application to use as many threads as it wants. The application also has to handle synchronization though and certain things are serial by nature.

then you can try letting DXVK to uplift that in two

DXVK just uses a single thread for rendering (there's also a couple for the state cache and one for command list fences but lets ignore those). D3D11 doesn't allow DXVK to use more than that because of the way it works. You can't 'uplift' that and the fact that Vulkan supports as many threads as you like is irrelevant here.

artivision commented 5 years ago

Sorry but everything in that comment is wrong.

if you uplift D3D9 calls to D3D11 ones, they will be run on more threads by default

No they wont.

The same if you convert D3D9 textures to a simple 2D D3D11 surface, because that is basically what 9 technology is for 11.

As long as the texture formats match this is pretty straightforward and should just work.

I also understand that if D3D11 likes to do a certain thing in one thread an Vulkan likes to do it in two

Unlike D3D9 or 11 Vulkan is very explicit and allows the application to use as many threads as it wants. The application also has to handle synchronization though and certain things are serial by nature.

then you can try letting DXVK to uplift that in two

DXVK just uses a single thread for rendering (there's also a couple for the state cache and one for command list fences but lets ignore those). D3D11 doesn't allow DXVK to use more than that because of the way it works. You can't 'uplift' that and the fact that Vulkan supports as many threads as you like is irrelevant here.

It was an example! You can uplift anything. If one api can to do 1 think with 1 call and the other can do 5 the convert this way and save power. Or is there something that you can convert to 16 bits with 2x benefit on newer gpus, do it. Or can you hack use Async Compute, do it. And goes on and goes on.

doitsujin commented 5 years ago

Then how about submitting a PR that allows perfect multi-core scaling in D3D11? Nvidia's and AMD's Windows driver teams might also be interested.

It's quite obvious that you don't have the slightest idea what you're even talking about, please stop and stay on topic.

pchome commented 5 years ago

@pchome

And I have no issues so far

Well, in Metro 2033 (original) I have issues w/ nvapi enabled in dx11 mode.

massatt212 commented 5 years ago

I thought dxvk has a nvapi hack that spoofs all Nvidia cards to look like AMD cards

doitsujin commented 5 years ago

@pchome do you know what exactly is going on on that front?

If anyone is seriously interested in fixing up nvapi and wiring it up to DXVK, I can implement the required features (like depth bounds, UAV overlap, multi draw indirect) in DXVK and provide an interface to use them, but I think the first step would be to actually get a basic implementation to run that doesn't support any of the D3D extensions (and reports it to the application accordingly).

pchome commented 5 years ago

@doitsujin Sorry, I don't fully understand your question.

But if you asking what wrong with the game - I don't know, but it can be figured out by WINEDEBUG="+nvapi,+nvcuda".

Sources: https://github.com/wine-staging/wine-patched/tree/master/dlls/nvapi https://github.com/wine-staging/wine-patched/tree/master/dlls/nvcuda

I can name three titles where DXVK (or nv.dlls) fails: Just Cause 2 (nvcuda, Simulate water on GPU), Batman AK (nvcuda?, Nvidia gameworks) and `nv?, Metro 2033 (ADVANCED PhysX option don't meter)`.

If you want me to provide such logs -- I'll do it.

doitsujin commented 5 years ago

But if you asking what wrong with the game - I don't know, but it can be figured out by WINEDEBUG="+nvapi,+nvcuda".

Well yes, can you provide the logs?

pchome commented 5 years ago

Current chapter, no glitches w/ nvapi enabled (Oo): steam-43110-nvidia.log Loading different chapters to find out: steam-43110-nvidia-2.log Loading directly to glitchy chapter ("Hunter"): steam-43110.log

Edit: suspect : https://github.com/wine-staging/wine-patched/blob/master/dlls/nvcuda/nvcuda.c#L1713

doitsujin commented 5 years ago

Ok, so that's because they use Cuda for... what exactly? PhysX?

Is there a way to tell a game that cuda is unavailable, e.g. by disabling nvcuda?

pchome commented 5 years ago

Ok, so that's because they use Cuda for... what exactly? PhysX?

There is lamps and fog (dust) ... Maybe I can blow on it to check out if it interact ? :)

Is there a way to tell a game that cuda is unavailable, e.g. by disabling nvcuda?

Yes, I simply disabling entire nv*.dll's by WINE overrides.

pchome commented 5 years ago

PhysX?

https://wiki.winehq.org/Wine-Staging_CUDA

For games there is also a separate NVIDIA library called PhysX which makes use of CUDA and provides some predefined physic simulations.

Hiding CUDA support from applications can be done by deactivating the nvcuda.dll through winecfg. Open winecfg, go to the Libraries tab, add an override for nvcuda and change it to disable by pressing the edit button. If you would like to re-enable the support, you just need to remove this line again.

Edit: I'm actually doing this through .config/protonfixes/localfixes/43110.py (https://github.com/simons-public/protonfixes)

from protonfixes import util

def main():
    """ Metro 2033
    """
    util.protontricks('d3dcompiler_47 d3dx11_42 d3dx11_43')

    #util.disable_dxvk()
    #util.disable_esync()
    #util.disable_d3d11()
    util.disable_nvapi()
pchome commented 5 years ago

Metro 2033 , 1280x720 shots.

dx11 nvapi ON: metro-2033-dx11-nvapi dx11 nvapi OFF: metro-2033-dx11-nvapi-off dx9 nvapi OFF: metro-2033-dx9-nvapi-off

dx9 nvapi ON (moved forward a bit): metro-2033-dx9-nvapi

So nvapi breaks even for dx9. But only in this location so far. Now I moving forward w/ dx11 && nvapi enabled, and no such issues encountered. Maybe I'll meet such glitches again in next room w/ lamp, newspapers and a carpet on the wall...

@doitsujin

If anyone is seriously interested in fixing up nvapi and wiring it up to DXVK, ...

Well, gamers can't/won't help you. We are all interested in, but only few of us can really help.

E.g. I know what need to be fixed for Just Cause 2 to work, but I don't know how.

Maybe I'm right, maybe not. But I'm want this to be fixed.

So I'll be happy w/ DXVK specific patch to nvapi, if it possible.

As for "counters" -- I dont care about counters, sorry @SveSop, nvctrl will likely work, but commonly it don't used outside testing tools, and will work only for Nvidia blob users. So due to my laziness, or common sense, there is no such patches in my repo.

SveSop commented 5 years ago

@pchome Yeah, the reason for fiddling with this was mostly for fun from my part, and one that reported he got a "too old driver" thing when using nvapi (Cos default nvapi reports a very very old driver string). So i started fiddling with it as a learning experience. I am trying to implement nvctrl atm as you can pull memory/gpu usage and loads of stuff from that, but so far i dunno how to do it, as i just get a unhandled page fault after implementing a function reading from the libXNVCtrl library. (It's probably some crap i do wrong tho, if you even can make wine dll's use functions from linux libraries like that?)

nvapi provides cuda, so if a game wants to use physx/cuda functions, nvapi "reports" this (through nvcuda i guess). There is ofc no problem just ditching everything of this, but if it COULD be implemented, it could possibly yield some benefit? Not sure how d3d11 <-> cuda ties together, but dxvk might not play nicely with that?

Creating "dummy" nvapi.dll's that just provide a NVAPI_LIBRARY_NOT_FOUND as a reply from the NvAPI_Initialize sometimes makes apps give up, but i have seen stuff like eg. monitoring apps that keeps polling functions and get replies nevertheless (and don't give up, so it might cause lower fps).

So to make sure nvapi is "never" used, you need 1: Fake AMD card (as already default), 2: dll-override to "disabled" for the nvapi(family) dll's, 3: Possibly dummy "fake" dll's that does not provide functions.

Why? Cos programmers do stuff they do. Take WoW for instance, the WoW log (gx.log) references Detected NvAPI and checking if it's valid..., but i am not able to find ANY nvapi functions being called, even tho i think this might also be listed when you fake AMD card. Probably some weird remnant text blob that has not been removed, even tho nvapi is not actually used? I think we will find stuff like this from many games still....

SveSop commented 5 years ago

If anyone would like to do some experiments with nvctrl, i have a simple snippit i have made from various examples i found. Requires libxnvctrl-dev package to compile. nvidia documentation here: https://github.com/NVIDIA/nvidia-settings/tree/master/src/libXNVCtrl

nvinfo.c.gz Compile with: gcc -O2 -fPIC nvinfo.c -lX11 -lXNVCtrl -o nvinfo running ./nvinfo should produce something like:

GeForce GTX 970
GPU Load:  1%
GPU temp:  42 C
Coolers:  1
Sensors:  1
Total vram:  4096 MB
GPU Clock: 135 MHz
MEM Clock: 324 MHz

And as i said above, i have had no luck (with my non-existing programming skills) to implement these functions to nvapi to actually provide "real" gpu load and stuff. There is not near as much info in the nvctrl library compared to nvapi tho, but as i said.. it would be fun to be able to run eg. heaven and have live nvapi updates of gpu temp/usage/whatnot :)

SveSop commented 5 years ago

Figured out how to do it.. Atleast was able to implement showing real gpu and memory mhz via nvapi. (Tested with GPU Caps Viewer). Gonna see if i can implement more stuff (even tho i know it wont fix dxvk performance issues by doing so).

SveSop commented 5 years ago

I am pretty sure there is a different way of handing the XNVCTRLQueryAttribute(display... function, cos to get it working, i need to do a XOpenDisplay, read the data, and then XCloseDisplay(display)

This seems rather brutal, cos i THINK this kind of means spawning a X11 display of some sort, but this should aldready be done by the winedrv or whatever. Any idea how i could get NVCtrl to use the "already open display"? The function is called each time the app/game polls for this, so it seems to be a somewhat slow way of doing it.

I see the nvapi get_video_memory function seems to do this via a wined3d_mutex_lock() and unlock, but i cant seem to use eg `XNVCTRLQueryAttribute(wined3d..' or similar stuff.. Tips are welcome :)

SveSop commented 5 years ago

Got some more NVCtrl functions in. Seems to be working, although i am not really happy with the connection/disconnection to X-screen function mentioned above. Tips are welcome.

So far this seems to work:

GPU Load %
GPU Memory amount
GPU Name
Bios version
Driver and branch version
GPU Vendor:Device ID's
GPU Temp
GPU / Memory clocks

cpucaps

SveSop commented 5 years ago

Some more NVCtrl usage updates, so currently "seems to work" list is:

    GPU Load %
    GPU Memory amount
    GPU Name
    GPU BusID
    Bios version
    Driver and branch version
    GPU Vendor:Device ID's
    GPU Temp
    GPU / Memory clocks
    Video Memory usage
    Video Memory controller utilization
    Get shader/cuda cores from NVCtrl
    Read GPU Voltage
    Calculate GPU fan speed

Anyone tested this on a different card than GTX970? (As it no longer "fakes" one, but should read data from NVCtrl).

doitsujin commented 5 years ago

In case anyone is still interested in wiring up D3D11 extensions to nvapi, DXVK supports some interfaces to do that (already used in AGS):

https://github.com/doitsujin/dxvk/blob/684355dfcae0b1054b7cf62bb4146a88bb03b4b7/src/d3d11/d3d11_device.h#L403-L427

https://github.com/doitsujin/dxvk/blob/684355dfcae0b1054b7cf62bb4146a88bb03b4b7/src/d3d11/d3d11_context_ext.h#L9-L64

pchome commented 5 years ago

Hell. Why am I doing this? My curiosity turned into pain.

I replaced everything but the trace in NvAPI_D3D11_SetDepthBoundsTest with call to DXVK's SetDepthBoundsTest, but have no luck to get it work.

Tested on mentioned Monster Hunter Online Benchmark:

Is there any lightweight tests for NvAPI_D3D11_SetDepthBoundsTest ? Wine test implements only check for NVAPI_INVALID_ARGUMENT.

EDIT: Okay, my fault. Getting "device" interface I trying to use "context" interface.

MHO-bech-nvapi-dbt

TBH, I don't know how to detect this SetDepthBoundsTest changes visually. All this "chromatic aberrations"(?), "DoF", etc. and small resolution makes the whole scene a bit weird.

Additional logging sample ``` 0045:trace:nvapi:NvAPI_D3D11_SetDepthBoundsTest (0xe3e6c504, 1, 0.010000, 0.962355): dxvk 0045:fixme:nvapi:NvAPI_D3D11_SetDepthBoundsTest DXVK extension support: 1 0045:fixme:nvapi:NvAPI_D3D11_SetDepthBoundsTest DXVK set DBT: 1 0045:trace:nvapi:NvAPI_D3D11_SetDepthBoundsTest (0xe3e6c504, 0, 0.000000, 1.000000): dxvk 0045:fixme:nvapi:NvAPI_D3D11_SetDepthBoundsTest DXVK extension support: 1 0045:fixme:nvapi:NvAPI_D3D11_SetDepthBoundsTest DXVK set DBT: 0 0045:trace:nvapi:NvAPI_D3D11_SetDepthBoundsTest (0xe3e6c504, 1, 0.992950, 0.994257): dxvk 0045:fixme:nvapi:NvAPI_D3D11_SetDepthBoundsTest DXVK extension support: 1 0045:fixme:nvapi:NvAPI_D3D11_SetDepthBoundsTest DXVK set DBT: 1 0045:trace:nvapi:NvAPI_D3D11_SetDepthBoundsTest (0xe3e6c504, 0, 0.000000, 1.000000): dxvk 0045:fixme:nvapi:NvAPI_D3D11_SetDepthBoundsTest DXVK extension support: 1 0045:fixme:nvapi:NvAPI_D3D11_SetDepthBoundsTest DXVK set DBT: 0 ```
ahuillet commented 5 years ago

SetDepthBounds is normally used for performance improvements while rendering the same thing, so visually you should not be able to observe a difference. You should be able to see a perf difference when the range isn't 0, 1 however.

pchome commented 5 years ago

Yes, thanks, I googled a bit already and tried to understand how it work. Anyway, I can't see any noticeable difference in a very few UE4 games from my library. Maybe +1fps, or just placebo effect.

Still looking for "lightweight" benchmark, which will show the difference, maybe early UE4. I have a bunch of problems with MHO benchmark, and can't get any numeric result from it.

ahuillet commented 5 years ago

You can hack up the range so everything gets discarded - that should let you validate that the feature is doing something. You can also look at the Vk command stream to see if vkCmdSetDepthBounds is being called with the right arguments - that should be sufficient testing for your change.

SveSop commented 5 years ago

@pchome Could you provide a snippit of the code you replaced NvAPI_D3D11_SetDepthBoundsTest function with for me to test?

doitsujin commented 5 years ago

@pchome

Maybe +1fps, or just placebo effect.

That's basically what it does in Resident Evil 2 with the AGS imlementation as well. It's consistently better, but not by much (2% at best).

pchome commented 5 years ago

@ahuillet

You can hack up the range so everything gets discarded

My knowledge of graphics programming is limited. Is "everything" mean 0,0 ?

@SveSop

Could you provide a snippit of the code you replaced NvAPI_D3D11_SetDepthBoundsTest function with for me to test?

My curren code is a mess, still wanted to do some cleanups before sharing, but should be something like this:

NvAPI_D3D11_SetDepthBoundsTest ```c static NvAPI_Status CDECL NvAPI_D3D11_SetDepthBoundsTest(IUnknown *pDeviceOrContext, NvU32 bEnable, float fMinDepth, float fMaxDepth) { ID3D11Device *d3d11_device; ID3D11DeviceContext *ctx; ID3D11VkExtDevice *dxvk_ext_device; ID3D11VkExtContext *dxvk_ext_context; TRACE("(%p, %u, %f, %f): dxvk\n", pDeviceOrContext, bEnable, fMinDepth, fMaxDepth); if (!pDeviceOrContext) return NVAPI_INVALID_ARGUMENT; if (0 > fMinDepth || fMinDepth > fMaxDepth || fMaxDepth > 1) { ERR("(%p, %u, %f, %f): Invalid argument!\n", pDeviceOrContext, bEnable, fMinDepth, fMaxDepth); return NVAPI_OK; /* Hack: Don't crash games */ /*return NVAPI_INVALID_ARGUMENT;*/ } if (FAILED(IUnknown_QueryInterface(pDeviceOrContext, &IID_ID3D11VkExtDevice, (void **)&dxvk_ext_device))) { ERR("Failed to get DXVK extension device handle!\n"); return NVAPI_ERROR; } if(!ID3D11VkExtDevice_GetExtensionSupport(dxvk_ext_device, D3D11_VK_EXT_DEPTH_BOUNDS)) { ERR("DXVK extension not supported!\n"); return NVAPI_ERROR; } if (FAILED(IUnknown_QueryInterface(pDeviceOrContext, &IID_ID3D11Device, (void **)&d3d11_device))) { ERR("Failed to get DXVK device handle!\n"); return NVAPI_ERROR; } ID3D11Device_GetImmediateContext(d3d11_device, &ctx); if (FAILED(IUnknown_QueryInterface(ctx, &IID_ID3D11VkExtContext, (void **)&dxvk_ext_context))) { ERR("Failed to get DXVK context handle!\n"); return NVAPI_ERROR; } ID3D11VkExtContext_SetDepthBoundsTest(dxvk_ext_context, bEnable, fMinDepth, fMaxDepth); return NVAPI_OK; } ```

dxvk_header.zip

widl generator ```python idl_generator = generator(widl, output : [ '@BASENAME@.h' ], arguments : [ target_arch, '-o', '@OUTPUT@', '-D__WINESRC__', '@EXTRA_ARGS@', '@INPUT@' ]) ```

+ #include "dxvk.h" in the nvapi.c file.

SveSop commented 5 years ago

@pchome Was the dxvk.h header file supposed to be included in the .zip?

pchome commented 5 years ago

No, dxvk.h generated from dxvk.idl. That's why widl generator sample included.

Edit: or just do $ widl dxvk.idl.

SveSop commented 5 years ago

So is dxvk.h generated during the build, and then able to be used as a #include statement cos it IS being "built"? Or is it just a "this is how you CAN generate it, and you put it in the /include folder"?

Cos i might be missing another statement for the meson.build to point to some include folder i guess.

(Yes, i can generate it manually like you say with widl, and then manually put the dxvk.h file in /include, but i am unsure if that was the purpose)

pchome commented 5 years ago

So is dxvk.h generated during the build

Yes. idl just easier to deal with. As you can see it's almost identical to the original header file from dxvk-ags, so easier to modify/update.

But if you want to put the dxvk.h file in /include, then do it. Not a big deal.

SveSop commented 5 years ago

I added the generation to meson.build as you described (i think atleast), and building got no error... but adding #include dxvk.h to nvapi.c got me a «not found» error.

So maybe i need to add somthing to my meson include_dir statement or something?

Or does building this with meson mean its automatically included without needing #include statement? (Sorry for being thick about it hehe)

Will look some more into it after the weekend tho

pchome commented 5 years ago

.../dlls/nvapi> $ ls

dxvk.idl  meson.build  nvapi.c nvapi.spec  tests