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

how best to add validation for Kernel SPIR-V #5597

Open
bashbaug opened this issue Feb 28, 2024 · 1 comment
Open

how best to add validation for Kernel SPIR-V #5597

bashbaug opened this issue Feb 28, 2024 · 1 comment
Assignees

Comments

@bashbaug
Copy link
Contributor

I'd like to start adding some basic validation checks that are missing for Kernel SPIR-V and I am looking for guidance how best to do this. If it is helpful to provide a specific example, I would like to check that all built-in variables are in the Input storage class and that they all have the expected type, see: https://registry.khronos.org/OpenCL/specs/3.0-unified/html/OpenCL_Env.html#_built_in_variables

One of the first issues I'm finding is that a lot of this type of validation is only enabled for Vulkan environments. For example:

spv_result_t BuiltInsValidator::ValidateSingleBuiltInAtDefinition(
const Decoration& decoration, const Instruction& inst) {
const spv::BuiltIn label = spv::BuiltIn(decoration.params()[0]);
if (!spvIsVulkanEnv(_.context()->target_env)) {
// Early return. All currently implemented rules are based on Vulkan spec.
//
// TODO: If you are adding validation rules for environments other than
// Vulkan (or general rules which are not environment independent), then
// you need to modify or remove this condition. Consider also adding early
// returns into BuiltIn-specific rules, so that the system doesn't spawn new
// rules which don't do anything.
return SPV_SUCCESS;
}

Would it be best to keep the current BuiltIn-specific rules as-is, call them only for Vulkan, and define other rules for Kernel SPIR-V? Or, would it be best to call the same BuiltIn-specific rules for both Vulkan and Kernel SPIR-V and to update them to handle both types of SPIR-V?

Thanks in advance for any advice you can provide!

@alan-baker
Copy link
Contributor

Reusing the infrastructure is preferable for both builtins and general validation. I could see adding a generic environment based filter before validating any particular builtin.

For general validation the checks should be based on the appropriate requirement (e.g. either HasCapability(Kernel) or spvEnvIsOpenCL(env)).

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

No branches or pull requests

3 participants