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

Implement relaxed rule for opaque struct members #3365

Merged

Conversation

sbourasse
Copy link
Contributor

This PR is a companion to another PR we recently opened on KhronosGroup/GLSL : KhronosGroup/GLSL#218
It implements the procedure described in the suggested changes to GL_EXT_vulkan_glsl_relaxed.

Samplers are extracted out of structures and moved to the topmost level available. In the context of uniform, that's the global uniform block. For structures passed as function parameters, we create invisible parameters and properly route arguments to them.

We also extend the vk.relaxed.frag test shader to demonstrate these added capabilities.

@CLAassistant
Copy link

CLAassistant commented Oct 16, 2023

CLA assistant check
All committers have signed the CLA.

@arcady-lunarg arcady-lunarg added the kokoro:run Trigger Google bot runs label Oct 16, 2023
@kokoro-team kokoro-team removed the kokoro:run Trigger Google bot runs label Oct 16, 2023
@arcady-lunarg
Copy link
Contributor

Looks like ASAN found some issues with your patch, do you want to address them before I take a look to review the changes? Also, is there some sequencing needed between this and the PR to then GLSL repo?

@sbourasse
Copy link
Contributor Author

I wanted to try and merge both PR at about the same time so repos can remain in sync, but if changes are requested on the GLSL part, this could mean additional work on this side. I don't mind waiting on the other one if you don't want to invest time on a change that's not yet approved.

I haven't entirely figured out how memory ownership is handled within the codebase, so I figured there would be some leaks in the end. I'll look into them by the end of the week.
In the meantime and depending on your own schedule, I wouldn't mind a first review. I kind of forced my changes into the codebase so any feedback is appreciated.

@ncesario-lunarg
Copy link
Collaborator

I haven't entirely figured out how memory ownership is handled within the codebase

Some classes use the TPoolAllocator rather than the standard C++ allocator. Allocations made from the pool allocator are "free" (this is covered at the end of the README). I plan on making these allocations more obvious, so that it's easier to know which allocations must be cleaned up and which ones don't need to.

Copy link
Collaborator

@ncesario-lunarg ncesario-lunarg left a comment

Choose a reason for hiding this comment

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

I think some of the logic around newParams in the vkRelaxedRemapFunctionParameter needs to be reworked. Let me know if you have more questions about memory allocations in the parser.

glslang/MachineIndependent/ParseHelper.cpp Outdated Show resolved Hide resolved
memberType->getQualifier().storage = param.type->getQualifier().storage;
memberType->clearArraySizes();

TParameter* memberParam = new TParameter();
Copy link
Collaborator

Choose a reason for hiding this comment

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

TParameter does not use the pool allocator (by default at least), so this is using the standard allocator and would need to be cleaned up. I'm not sure if this is the right way to go about this. You could use the pool allocator, but it seems like you could also retrieve the necessary parameters from function after vkRelaxedRemapFunctionParameter is called (though you may need to add an additional field to TParameter to pick out the parameters you want)?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I replaced the last function parameter with a vector of integer to avoid changing TParameter, but maybe it would be better to properly flag parameters that are implicitly created during this pass ?


ForEachOpaque(type, identifier,
[&publicType, &loc, this](const TType& type, const TString& path) {
TString& structMemberName = *(new TString(path));
Copy link
Collaborator

Choose a reason for hiding this comment

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

This is another spot ASAN is complaining about. You can use NewPoolTString, but does this need to be dynamically allocated here?

Copy link
Contributor Author

@sbourasse sbourasse Oct 24, 2023

Choose a reason for hiding this comment

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

True, this should be a straight copy
Nevermind. It looks like we need the allocation, because declareVariable takes a TString& as argument

glslang/MachineIndependent/ParseHelper.cpp Outdated Show resolved Hide resolved
@sbourasse sbourasse force-pushed the bourasse/relaxed-opaque-fix branch from c62630d to 9ab942f Compare October 24, 2023 13:49
@sbourasse
Copy link
Contributor Author

Thanks for reviewing ! My latest changes should fix leaks

@arcady-lunarg arcady-lunarg added the kokoro:run Trigger Google bot runs label Oct 26, 2023
@kokoro-team kokoro-team removed the kokoro:run Trigger Google bot runs label Oct 26, 2023
Copy link
Contributor

@arcady-lunarg arcady-lunarg left a comment

Choose a reason for hiding this comment

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

I have a couple of minor nits but overall this seems fine. It's a lot of fairly complicated code but that code is only used in relaxed mode.

$1.function->addParameter(param);
$$.function = $1.function;
$$.intermNode = $2;
if (!(parseContext.spvVersion.vulkan > 0
Copy link
Contributor

Choose a reason for hiding this comment

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

I would prefer you invert the condition of the if-statement so that it's not negated, I think it's easier to read "if (vulkanRelaxed && containsOpaque) { // do something unusual } else { // do the normal thing".

@@ -7321,12 +7329,14 @@ void TParseContext::coopMatTypeParametersCheck(const TSourceLoc& loc, const TPub
}
}

bool TParseContext::vkRelaxedRemapUniformVariable(const TSourceLoc& loc, TString& identifier, const TPublicType&,
bool TParseContext::vkRelaxedRemapUniformVariable(const TSourceLoc& loc, TString& identifier, const TPublicType& publicType,
Copy link
Contributor

Choose a reason for hiding this comment

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

publicType appears to be unused, you should keep it anonymous to prevent a compiler warning.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It's forwarded to vkRelaxedRemapUniformMembers. I looked across the file for another publicType that seemed unused but didn't find any.

$$.intermNode = parseContext.intermediate.growAggregate($1.intermNode, $3, $2.loc);
if (!(parseContext.spvVersion.vulkan > 0
&& parseContext.spvVersion.vulkanRelaxed)
|| !$3->getType().containsOpaque())
Copy link
Contributor

Choose a reason for hiding this comment

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

Same comment re inverting the condition to make it clearer.

Copy link
Contributor

@arcady-lunarg arcady-lunarg left a comment

Choose a reason for hiding this comment

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

Thanks, looks good now.

@arcady-lunarg arcady-lunarg added the kokoro:run Trigger Google bot runs label Nov 28, 2023
@kokoro-team kokoro-team removed the kokoro:run Trigger Google bot runs label Nov 28, 2023
@arcady-lunarg arcady-lunarg merged commit c59b876 into KhronosGroup:main Nov 29, 2023
21 checks passed
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.

5 participants