-
Notifications
You must be signed in to change notification settings - Fork 851
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add DXVK profiles to express Vulkan requirements #2826
Conversation
I also created a file for DXVK 1.10.3 which could be useful to express the different is term of requirements with master. Maybe this could be part of a 1.10.4 release?
|
VP_DXVK_baseline.json
Outdated
}, | ||
"features": { | ||
"VkPhysicalDeviceFeatures": { | ||
"geometryShader": true, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
indentation
Looks like I would check against the |
I am also not super sure how one would express optional features with this. eg. in your profile |
If this is useful for people then sure, why not. Seems easy enough for us to maintain. See Josh's concerns about the extension lists though, since we really don't need any of the promoted extensions unless we explicitly enable the corresponding device features.
We don't plan to make another 1.x release. |
I am looking at the |
Note that if you are interested into that, we have a Python script that convert the JSON file into .cpp/.h code. This could be used for you initialization code and to ensure that the JSON files always match the source. |
How would we encode optional features with this? |
I am editing the level9 profile to give you an idea and pushing it when it's done... (in few minutes) |
I updated
But sadly, doing the same with I think ideally, we need something like:
|
I could only find GetDeviceFeatures in D3D9 and D3D11 directories. How does it work with D3D10? |
D3D10 is identical to D3D11 FL10_0 or FL10_1 respectively. Our implementation is just a thin wrapper around D3D11. |
I separated D3D9 and D3D11 (and 10 then) into two different profiles files has there are not necessarilly requiring the same features. Let me know what you think. |
I would personally prefer if this was one json rather than two, I don't see why we need two. |
Ok, I'll make only one. |
I think the whole D3D11 feature level stuff could also be stripped down. Feature levels below 11_0 have next to no practical relevance nowadays, and I'm thinking we could have something like this as profiles:
|
fa23b9e
to
51a715e
Compare
Thanks for all the feedback! I merged back the profiles in a single file. The D3D9 and D3D11 sections remain separated in a way because the requirements expressed in the code actually diverge. I also followed the profiles suggested by @doitsujin but note that I originally followed the project source which effectively expressed fine grain granularity of feature levels down to feature level 9. But if it's what makes sense to you, I am fine with it! Any more feedback ? |
VP_DXVK_requirements.json
Outdated
"description": "DXVK for D3D9 minimum requirements", | ||
"contributors": { | ||
"Philip Rebohle": { | ||
"company": "DXVK" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should really say Valve for me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll update tomorrow, thanks.
Just a nit. One question: I'm currently implementing missing bits to support Feature Level 12_0, and we will require certain device properties (rather than just device features) to have specific values in order to expose that. Can the profiles express this? As an example, we'd want |
Yes all properties are supported but also formats if that's useful to you. I'll create tomorrow a capability JSON block for level12 without the corresponding profile just to show you. |
shaderDemoteToHelperInvocation is listed as optional but this is required for Vulkan 1.3 which we use. |
51a715e
to
a1991ef
Compare
Regarding shaderDemoteToHelperInvocation
By:
To match the Vulkan 1.3 requirement. I updated the profiles file accordingly. |
@doitsujin such for d3d11_level12_0 in the JSON file to find the VkPhysicalDeviceSparseProperties example. The block is never referenced in a profile so it can remain here as WIP doc without affecting the definision of the DXVK profiles / requirements. |
@Joshua-Ashton, @doitsujin Anything missing to approve this PR? |
I created a Vulkan profiles JSON file to express DXVK minimum requirements for each D3D level. This JSON files are defined by Vulkan Profiles schemas avaiable here and can be used as part of the Vulkan SDK Profiles Toolset. (PDF, Presentation)
I based myself on https://github.com/doitsujin/dxvk/wiki/Driver-support but it would certainly be necessary to validate that my interpretation is correct.
This Vulkan profiles JSON file could help users of the project to track new requirements. For the case of IHVs, it will allows them to prioritize implementing new features and for ISVs it will help them to figure out the ecosystem of devices where the project versions could run.
Further use of this file could be to express future requirements by adding "roadmap" profiles or "optimal" profiles to express the requirement for the best level of performance with DXVK.
Finally, having these information baked into this file allows some level of automation to the users of the projects and make sure that each revision of the project comes the corresponding explicit set of Vulkan requirements.
I am creating this PR first for the purpose of discussion and evaluate whether you could be interested by such features.