MoonsideGames
/
Refresh
1
0
Fork 1
Code Issues 1 Pull Requests 2 Projects Releases 33 Wiki Activity

Some enum values are incompatible with D3D11 #11

New Issue
Closed
opened 2022-02-22 03:01:17 +00:00 by TheSpydog · 4 comments
TheSpydog commented 2022-02-22 03:01:17 +00:00

While constructing a skeleton for a D3D11 backend I encountered a few enums that don't have a direct translation from Vulkan to D3D (or other rendering APIs, afaik), so I wanted to discuss what to do about them.

  • D3D does not have a D16S8 format. The only supported depth+stencil formats are DXGI_FORMAT_D24_UNORM_S8_UINT and DXGI_FORMAT_D32_FLOAT_S8X24_UINT (which is 64 bits in size). Not sure what to do about this one.
  • D3D does not support Point as a rasterization fill mode. It only has Wireframe and Solid options. It appears that MoltenVK opted not to implement Point, so maybe we shouldn't offer it either.
  • D3D does not support CULL_FRONT_AND_BACK. Honestly I'm not really sure when you'd ever want this feature...
  • D3D does not support the CONSTANT_ALPHA/ONE_MINUS_CONSTANT_ALPHA blend factor values. ANGLE was able to emulate this behavior by rewriting the constant color, but I'm not sure if that's a route we want to go down.
  • D3D 11.0 does not support LogicOps. They were added by D3D 11.1+. If we implement them, that'd raise the min spec to Windows 8.
  • D3D does not support the Cubic filtering mode.
  • D3D specifies a border color via a float[4] containing color values, whereas Vulkan/Refresh expect an enum value. I'm not sure how to accurately translate the INT_*_BLACK/WHITE values if we're required to use floats.

I'm of the opinion that not much would be lost by removing these values from Refresh's API surface, with the exception of D16S8. What do you think?

While constructing a skeleton for a D3D11 backend I encountered a few enums that don't have a direct translation from Vulkan to D3D (or other rendering APIs, afaik), so I wanted to discuss what to do about them. - D3D does not have a `D16S8` format. The [only supported depth+stencil formats](https://docs.microsoft.com/en-us/windows/win32/api/dxgiformat/ne-dxgiformat-dxgi_format) are `DXGI_FORMAT_D24_UNORM_S8_UINT` and `DXGI_FORMAT_D32_FLOAT_S8X24_UINT` (which is 64 bits in size). Not sure what to do about this one. - D3D does not support Point as a rasterization fill mode. It only has [Wireframe and Solid](https://docs.microsoft.com/en-us/windows/win32/api/d3d11/ne-d3d11-d3d11_fill_mode) options. It appears that MoltenVK [opted not to implement Point](https://github.com/KhronosGroup/MoltenVK/issues/1396), so maybe we shouldn't offer it either. - D3D [does not support `CULL_FRONT_AND_BACK`](https://docs.microsoft.com/en-us/windows/win32/api/d3d11/ne-d3d11-d3d11_cull_mode). Honestly I'm not really sure when you'd ever want this feature... - D3D does not support the `CONSTANT_ALPHA/ONE_MINUS_CONSTANT_ALPHA` blend factor values. ANGLE was able to [emulate this behavior](https://github.com/KhronosGroup/WebGL/issues/2938) by rewriting the constant color, but I'm not sure if that's a route we want to go down. - D3D 11.0 does not support LogicOps. They were [added by D3D 11.1+](https://docs.microsoft.com/en-us/windows/win32/api/d3d11_1/ne-d3d11_1-d3d11_logic_op). If we implement them, that'd raise the min spec to Windows 8. - D3D does not support the [Cubic filtering mode](https://docs.microsoft.com/en-us/windows/win32/api/d3d11/ne-d3d11-d3d11_filter). - D3D specifies a [border color](https://docs.microsoft.com/en-us/windows/win32/api/d3d11/ns-d3d11-d3d11_sampler_desc) via a `float[4]` containing color values, whereas Vulkan/Refresh expect an enum value. I'm not sure how to accurately translate the `INT_*_BLACK/WHITE` values if we're required to use floats. I'm of the opinion that not much would be lost by removing these values from Refresh's API surface, with the exception of D16S8. What do you think?
cosmonaut commented 2022-02-22 03:24:08 +00:00
Owner

First off, thanks for investigating this.

D3D does not have a D16S8 format. The only supported depth+stencil formats are DXGI_FORMAT_D24_UNORM_S8_UINT and DXGI_FORMAT_D32_FLOAT_S8X24_UINT (which is 64 bits in size). Not sure what to do about this one.

D16S8 can be implemented with D24S8, not a problem.

D3D does not support Point as a rasterization fill mode. It only has Wireframe and Solid options. It appears that MoltenVK opted not to implement Point, so maybe we shouldn't offer it either.

Yeah that's fine, Point rendering is Bad anyway.

D3D does not support CULL_FRONT_AND_BACK. Honestly I'm not really sure when you'd ever want this feature...

Yeah I honestly have no idea what the use case for this is. Let's take it out.

D3D does not support the CONSTANT_ALPHA/ONE_MINUS_CONSTANT_ALPHA blend factor values. ANGLE was able to emulate this behavior by rewriting the constant color, but I'm not sure if that's a route we want to go down.

This is a weird one. I've never used this feature and can't really think of a use case off the top of my head so it's probably fine to not support it.

3D 11.0 does not support LogicOps. They were added by D3D 11.1+. If we implement them, that'd raise the min spec to Windows 8.

I really like having more expressive blend modes so I'm reluctant to take this out. Windows 7 is a very small user base at this point so it's probably not much of a loss.

D3D does not support the Cubic filtering mode.

Again, no idea where we'd need this so it's probably fine to take it out.

D3D specifies a border color via a float[4] containing color values, whereas Vulkan/Refresh expect an enum value. I'm not sure how to accurately translate the INT_*_BLACK/WHITE values if we're required to use floats.

I'm fine with mandating that colors are floats here.

First off, thanks for investigating this. > D3D does not have a D16S8 format. The only supported depth+stencil formats are DXGI_FORMAT_D24_UNORM_S8_UINT and DXGI_FORMAT_D32_FLOAT_S8X24_UINT (which is 64 bits in size). Not sure what to do about this one. D16S8 can be implemented with D24S8, not a problem. > D3D does not support Point as a rasterization fill mode. It only has Wireframe and Solid options. It appears that MoltenVK opted not to implement Point, so maybe we shouldn't offer it either. Yeah that's fine, Point rendering is Bad anyway. > D3D does not support CULL_FRONT_AND_BACK. Honestly I'm not really sure when you'd ever want this feature... Yeah I honestly have no idea what the use case for this is. Let's take it out. > D3D does not support the CONSTANT_ALPHA/ONE_MINUS_CONSTANT_ALPHA blend factor values. ANGLE was able to emulate this behavior by rewriting the constant color, but I'm not sure if that's a route we want to go down. This is a weird one. I've never used this feature and can't really think of a use case off the top of my head so it's probably fine to not support it. > 3D 11.0 does not support LogicOps. They were added by D3D 11.1+. If we implement them, that'd raise the min spec to Windows 8. I really like having more expressive blend modes so I'm reluctant to take this out. Windows 7 is a very small user base at this point so it's probably not much of a loss. > D3D does not support the Cubic filtering mode. Again, no idea where we'd need this so it's probably fine to take it out. > D3D specifies a border color via a float[4] containing color values, whereas Vulkan/Refresh expect an enum value. I'm not sure how to accurately translate the INT_*_BLACK/WHITE values if we're required to use floats. I'm fine with mandating that colors are floats here.
TheSpydog commented 2022-02-22 04:41:54 +00:00
Poster

I'm fine with mandating that colors are floats here.

Sorry, to clarify, do you mean that we should remove the INT_ enums? Or just that in a D3D11 backend we should use floats for all of the border color values, whether they say they're int or not?

> I'm fine with mandating that colors are floats here. Sorry, to clarify, do you mean that we should remove the INT_ enums? Or just that in a D3D11 backend we should use floats for all of the border color values, whether they say they're int or not?
cosmonaut commented 2022-02-22 21:53:32 +00:00
Owner

I was thinking about taking out the INT enums, I mostly just want to review how colors work in Refresh in general. But if I understand correctly I think if we want to keep ints we can just convert to float by dividing by 255.

I was thinking about taking out the INT enums, I mostly just want to review how colors work in Refresh in general. But if I understand correctly I think if we want to keep ints we can just convert to float by dividing by 255.
cosmonaut commented 2022-03-02 19:10:47 +00:00
Owner

Resolved by 61e83cfba8

Resolved by https://gitea.moonside.games/MoonsideGames/Refresh/commit/61e83cfba83c6d602b0d0c93fcd057eb42f4469a
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
d3d11
abi_break
main
1.15.4
1.15.3
1.15.2
1.15.1
1.15.0
1.14.1
1.14.0
1.13.1
1.13.0
1.12.0
1.11.0
1.10.0
1.9.0
1.8.2
1.8.1
1.8.0
1.7.1
1.7.0
1.6.1
1.6.0
1.5.4
1.5.3
1.5.2
1.5.1
1.5.0
1.4.0
1.3.0
1.2.2
1.2.1
1.2.0
1.1.0
1.0.0
0.1.0
Labels
Clear labels
No items
No Label
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: MoonsideGames/Refresh#11
There is no content yet.
Delete Branch "%!s(<nil>)"

Deleting a branch is permanent. Although the deleted branch may exist for a short time before cleaning up, in most cases it CANNOT be undone. Continue?