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

Add option to ADCE to remove output variables from interface. #4994

Merged
merged 1 commit into from
Nov 23, 2022

Conversation

greg-lunarg
Copy link
Contributor

This can cause interface incompatibility and should only be done if ADCE has been applied to the following shader in the pipeline. For this reason this capability is not available through the CLI but rather only non-default through the API. This functionality is intended as part of a larger cross-shader dead code elimination sequence and not a standalone optimization.

@greg-lunarg
Copy link
Contributor Author

@Keenuts PTAL. This is the last functional PR in the cross-shader optimization suite. I will submit the EDIC cleanup PR after this and will be done. Thanks for your help with all this code!

Copy link
Contributor

@Keenuts Keenuts left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the late review! LGTM to me, jute one open question

//
// If |remove_outputs| is true, allow outputs to be removed from the interface.
// This is only safe if the caller knows that there is no corresponding input
// variable in the following shader. It is false by default.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's false by default on the pass constructor, here we still have is mandatory, is that expeted?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

...here we still have is mandatory...

Not sure what you mean when you say it is mandatory here. It is ok if the following shader had an unused interface variable removed, but we do not remove it in this shader. The Vulkan spec says that is ok. It is strictly an optimization to remove it. It is not mandatory.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I meant the comment says it's false by default, but you require the parameter without default value. (the underlying pass constructor takes has the default value set to false, not this one)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah. I see. Yeah. Not sure why I did it this way. Technically, there were two overloads so it wasn't really mandatory, but I changed to a more standard and simpler way to do this.

Fixed.

@greg-lunarg
Copy link
Contributor Author

@Keenuts I believe I have addressed all your concerns. PTAL.

This can cause interface incompatibility and should only be done
if ADCE has been applied to the following shader in the pipeline.
For this reason this capability is not available through the CLI
but rather only non-default through the API. This functionality is
intended as part of a larger cross-shader dead code elimination
sequence.
@greg-lunarg
Copy link
Contributor Author

@Keenuts I believe I have addressed all your concerns. PTAL.

Copy link
Contributor

@Keenuts Keenuts left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks!

@greg-lunarg greg-lunarg merged commit 81ec2aa into KhronosGroup:master Nov 23, 2022
@airlied
Copy link
Contributor

airlied commented Feb 15, 2023

This broke the ABI on Linux again. Can we stop doing that?

I fixed this up once before in #4653 I'll take another look at fixing it again.

@Keenuts
Copy link
Contributor

Keenuts commented Feb 15, 2023

Is there a rule to keep ABI stable across versions? For the API I imagine it's implicit, as having a non-stable API makes it hard to use this, but not sure about the ABI.
If that's the case (implicitly or explicitly) we should document it. (SPIRV-cross by ex explicitly states API & ABI are not stable AFAIK)

(@s-perron ?)

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.

None yet

3 participants