Skip to content
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

Alternative strategies for elements barrier #121

Closed
wants to merge 1 commit into from

Conversation

raphlinus
Copy link
Contributor

This patch provides an #ifdef METAL for switching between two different
strategies for the barriers in the elements shader. With it enabled, the
barriers are in workgroup uniform control flow, which is compatible with
translation to Metal, but fails to compile in FXC, as FXC's uniformity
analysis fails. With it disabled, the lookback logic (including
barriers) runs only in a single thread, which compiles in FXC (though
not tested), but creates problems in Metal.

In testing on Android, the METAL version seems slightly faster. On AMD
5700 XT, there is no measurable difference.

I'm inclined not to commit this, but it's potentially useful if we want
to explore cs_5_0 compatibility.

This patch provides an #ifdef METAL for switching between two different
strategies for the barriers in the elements shader. With it enabled, the
barriers are in workgroup uniform control flow, which is compatible with
translation to Metal, but fails to compile in FXC, as FXC's uniformity
analysis fails. With it disabled, the lookback logic (including
barriers) runs only in a single thread, which compiles in FXC (though
not tested), but creates problems in Metal.

In testing on Android, the METAL version seems slightly faster. On AMD
5700 XT, there is no measurable difference.

I'm inclined not to commit this, but it's potentially useful if we want
to explore cs_5_0 compatibility.
@raphlinus
Copy link
Contributor Author

As discussed, this doesn't feel like it's worth the complexity because we're not targeting cs_5_0. For DX12, we'll probably pursue DXC instead of FXC. Also, we may end up with tree reduction instead of decoupled look-back for more robust compatibility.

But if we ever do want to try to port decoupled look-back to FXC, this is probably the way to do it.

@raphlinus raphlinus closed this Nov 5, 2021
@eliasnaur
Copy link
Collaborator

For completeness, I'll note that you can run D3D11 on top of D3D12 through official Microsoft API:

https://github.com/microsoft/D3D11On12

For Gio, I'll probably end up expanding the D3D11 backend to attempt a D3D11On12 context and only use piet sm 6 shaders if that succeeds. If that works, we won't have to maintain two D3D renderers.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants