Topic-Free Mega Thread - v 1.11.2020

lol, there’s still lots of work to do. D3D10/11/12 share a lot in common, so that makes it both simple and difficult. I can support most of the same features as I do in D3D11 with enough time and effort, but that should ideally come with a lot of code refactoring to clean up the core.

If I clean up the common components enough, I can probably reach backwards an API to D3D10 too without too much effort. It seems like a good idea at this point. I don’t really know about Vulkan, but I can definitely polish off D3D12 and get some benefits in the process.

2 Likes

Code conformity and compatibility across most everything of DXGI (10 - 12) sounds like it’d be excellent. :slight_smile:

Unsure about D3D9 and the earlier plugins and work for getting that up and back to full functionality but I like what I’m hearing.

EDIT: Or how it’s called.

EDIT: VLK support is interesting too especially when throwing DXVK into something D3D9 (And more but for this D3D9) just makes it work better. :stuck_out_tongue:

EDIT: Well relatively speaking…10 - 20 FPS with dips and then with that it’s up to 120+ in some cases due to Navi / RDNA GPU issues is a bit more than “better” although even when technically functional it just tends to be faster anyway.
(Unsupported on Windows for all sorts of reasons but usable and beneficial. :smiley: )

EDIT: Only main drawback is the hack solutions AMD did to resolve some D3D11 performance and compatibility issues so for these titles (I believe Assassin’s Creed Unity is one.) performance just fails.
(They don’t really work under DXVK/Vulkan.)

Otherwise it’s a neat 30 - 60% gain which can also apply to NVIDIA but often a bit less due to less problematic D3D11 driver code and more stable D3D9 driver code and GPU functionality.

Render support in Vulkan, I imagine, would be easier seeing how it relies on external overlay hooks. So getting SK to render in a Vulkan games just requires SK to interface with Vulkan properly and then register itself as an overlay in the registry of Windows.

E.g.
https://gitlab.freedesktop.org/mesa/mesa/-/tree/master/src/vulkan/overlay-layer

Kinda… I mean, if Special K were merely an overlay the way that RTSS / Steam are, Vulkan layers would be totally awesome. But I generally do more inside of a game than just draw stuff over top the game :slight_smile:

I really dread SPIR-V. It makes -modifying- shaders in Vulkan ridiculous. Here in D3D land, the same tools I built to modify shaders in D3D11 work backwards and forward down to D3D10 and D3D12 with just a little bit of API-specific sugar sprinkled on top. But SPIR-V is different, and each engine could have its own language and conventions… I don’t really want anything to do with modifying Vulkan shaders.


That probably looks fun if you’re a compiler writer… it looks like trouble to me :stuck_out_tongue:

Got it working on MHW DX12, needed to disable some 3rd part applications because i was getting a dxgi.dll error on the main menu.

Saying that… i dont have the swapchain management options on it ? And it does not give me the status of the windows display, what kind of frame buffer or color format ?

That was added to the test build in the Wiki forum post…

D3D12 Missing Features - Development - Special K Discussion (differentk.fyi)

Use that build, I’ll be updating that while I finish the first couple of items on that list. Other items will probably be unimplemented for a while.

1 Like

Nice. :slight_smile:

Also Ubisoft at least didn’t break anything too badly with Valhalla but the game needs some work on the huge number of glitches and oversights.

EDIT: Daily tasks for minimal rewards, yesterday another straw dummy was a bounty target for some crime and today this dummy apparently thieved.

It’s not Skyrim at least.

NVIDIA never updated their API for D3D12…

https://docs.nvidia.com/gameworks/content/gameworkslibrary/coresdk/nvapi/group__dx.html#ga9066280b51437fcd4d791782fc3afdd5

FUNCTION NAME: NvAPI_D3D_IsGSyncCapable

DESCRIPTION: This API gets G-Sync capability for the given device context. This is only reliable after the first present call has completed.

Parameters
[in]	pDeviceOrContext	The D3D9, D3D10, D3D11 device, or D3D11 device context
[in]	NVDX_ObjectHandle	The handle of primary surface
[out]	pIsGsyncCapable	if G-Sync can be enabled, *pIsGsyncCapable is true.
SUPPORTED OS: Windows 7 and higher

RETURN STATUS: This API can return any of the error codes enumerated in NvAPI_Status. If there are return error codes with specific meaning for this API, they are listed below.

It literally only discusses D3D9/10/11 and if you try to call it with the equivalent constructs from D3D12 it fails. I think I’m the only person in the world who ever used that feature anyway :stuck_out_tongue:

2 Likes

Just looked at that, seems a few things references D3D12 and support for GSync itself should work so the internals in the driver must have something.

There’s VRR but then you might not get the full GSync functionality (Same with FreeSync2 Premium on AMD.) hmm curious.

Well probably it’s just the documentation not being up to date here NVIDIA has plenty of extensions and DirectX 12 features plus Vulkan through a number of extensions same as AMD.

Interesting.

Don’t their own G-Sync Indicator rely on that NVAPI call? Or perhaps it doesn’t… I don’t remember seeing that go away when technically VRR isn’t active any longer (e.g. situations where SK would indicate that VRR is inactive).

lol Reset, and gaf are safe havens for the collective hive. You would be better off on 4chan for civil discourse.

Update on 457.30 I need to remember to check the status updates more often because NVIDIA updates theirs.
https://www.nvidia.com/en-us/geforce/forums/game-ready-drivers/13/407202/geforce-45730-game-ready-driver-feedback-thread-re/

Sounds like fixes are coming for some of these in the next NVIDIA driver too.

Well… I think all the information from PCGW (except for the more in-depth history stuff at the beginning) have been moved over to the official wiki now.

So I can finally call it “finished” in terms of first version! :smiley: :+1:

It’ll probably continue to be expanded upon going forward, but right now it is more than capable of serving as Special K’s primary wiki / documentation.


Some of the things I want to look more into later down the line:

  • Force Direct3D 9EX section — this technically forces flip model in DirectX 9 games. While it isn’t compatible with all games, it bares to mention on the Video Management page regardless.

  • Look into possibility of moving more game-specific guides to the wiki.

    • FAR is the one that have been added to the wiki already, in a more condescend form from my original tweak guide. I also added a section about trying out the latest version of Special K and the improvements it brings to the table (flip model + HDR).

      • Maybe even set up a similar massive table of all former versions of FAR as well? While technically not required, it would be helpful as a single source for any potential version.
    • No idea how the other game guides looks like… I imagine they might need major restructuring as I believe Kal went sorta crazy with the Steam Guides’ BBCode/HTML elements.

  • Uhhh… think of more things to cover? Perhaps feature a screenshot of the Special K control panel on the front page to allow new users to get an eye for it at a glance.

2 Likes

And the 6000-series cards get a big massive nope from me.

Not only is the performance all over the place even without AMD’s ray tracing tech, but they somehow made their launch situation more disastrous than NVidia with their 30 series. Less retail stock (whot?) and AMD team affiliate systems are doing very questionable shit.

D3D12 Global Injection is unreliable thanks to all the poorly tested overlays out there doing the same thing :-\

For stability purposes for the foreseeable future, local injection is going to have to be the way to go. I don’t feel like debugging these other overlays.

Local Injection MHW won’t even start, and the logs are all blanks :frowning:

Does D3D12.dll work better?
Then there’s a whole host of potential config settings and compatibility.

First of it’s probably these.

[API.Hook]
d3d8=false
d3d9=false
d3d9ex=false
d3d11=true
d3d12=true
ddraw=false
LastKnown=128
OpenGL=false
Vulkan=true

Testing if a mix of d3d11=true and d3d12=true works or if d3d11=false is required.
Flip model and overrides after that and using mods to disable the games checks and scans in memory but it should start up first.
(The crash from this happens on the first load as you initialize the main menu from what I recall.)

oddly enough, local injection with d3d12.dll wont even trigger …

That’s normal, you have to use global injection for that game due to its anti-tamper.

@GPUnity:

Does that Adobe suite you’re unfortunately stuck paying for include any kind of HTML / XML / CSS design? Remember that mock achievement popup you made a while back? I’m thinking my replacement for CEGUI may be Chromium Embedded Framework, it would allow me to show documentation in-game and potentially make skinnable popups based on more traditional web authoring software. It’d finally solve the design goal I had w/ CEGUI in the first place, of letting users customize parts of the UI that aren’t performance critical.

1 Like