RE: Shader security model discussions: breaking it down?

Jeff and Kai mentioned this on a another fork – taking OpenCL kernels and running them in WebGPU compute feels like a rather large feature creep to me, and discussing with Rafael he tells me that this is his feeling too.

OpenCL (and Cuda) have evolved their own set of performance enhancing features that are not even really supported on desktop D3D / Vulkan / etc. Running hardcore compute kernels on current graphics stacks seems like a big challenge to build right now, let alone in a portable way across platforms. Adding safety / security on top seems like a huge amount of work, and beyond of the scope of at least the MVP if not the whole project.

From: Corentin Wallez [mailto:cwallez@google.com]
Sent: Tuesday, August 29, 2017 8:34 AM
To: Myles C. Maxfield <mmaxfield@apple.com>
Cc: Bourges-sevenier, Mikael <Mikael.Sevenier@amd.com>; public-gpu@w3.org; Kai Ninomiya <kainino@google.com>
Subject: Re: Shader security model discussions: breaking it down?

Your interpretation is correct, Vulkan requires the logical addressing model, always, for both compute and graphics. Sorry we failed to bring this up in the meeting.

My understanding is that OpenCL can use the physical addressing mode. The clspv<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclspv&data=02%7C01%7Cbencon%40microsoft.com%7C054dae39adc849e202a108d4eef380eb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636396176991667289&sdata=I5lGiv4PP3LeC1%2FlRY2RF0mTzMpttQ0Tk8POCDDZC3o%3D&reserved=0> project that compiles OpenCL to Vulkan-compatible SPIRV targets the logical addressing mode, and uses the SPV_KHR_variable_pointer<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.khronos.org%2Fregistry%2Fspir-v%2Fextensions%2FKHR%2FSPV_KHR_variable_pointers.html&data=02%7C01%7Cbencon%40microsoft.com%7C054dae39adc849e202a108d4eef380eb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636396176991667289&sdata=bxkxV2wPkDml8scOKOpIV35mWByeqtTOsnXNNt58nSc%3D&reserved=0> extension that allows conditionally setting pointers (so you can't statically know which buffer things come from, even if you inline everything). This is an extension and isn't required in core Vulkan.

Things like deviceEnqueue aren't present in HLSL either and I don't see them in Metal. clspv takes OpenCL 1.2 as an input which doesn't have that capability.

On Mon, Aug 28, 2017 at 2:34 PM, Myles C. Maxfield <mmaxfield@apple.com<mailto:mmaxfield@apple.com>> wrote:
I would love to know more about this.

Currently, the Vulkan Spec<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.khronos.org%2Fregistry%2Fvulkan%2Fspecs%2F1.0%2Fhtml%2Fvkspec.html%23spirvenv-module-validation&data=02%7C01%7Cbencon%40microsoft.com%7C054dae39adc849e202a108d4eef380eb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636396176991667289&sdata=z3jHVyJI6JJpZi%2FhNyPS2naK1GNoPtoktlyjtnbOiJk%3D&reserved=0> says:
"A SPIR-V module passed to vkCreateShaderModule must conform to the following rules:
...
The Logical addressing model must be selected.”

This seems to imply that all Vulkan shaders must be using the logical address mode. Yet, OpenCL code doesn’t seem to have this restriction. Am I misunderstanding?

In the general case, other languages may support features which Vulkan does not support. For example, OpenCL seems to support the DeviceEnqueue capability, which Vulkan doesn’t seem to support. What does Vulkan do when it reuses a kernel which uses such capabilities?

Or, put more simply: Is it possible (by any way at all) to run a compute shader in Vulkan which does not use the Logical Addressing Mode?

—Myles


On Aug 25, 2017, at 3:17 PM, Bourges-sevenier, Mikael <Mikael.Sevenier@amd.com<mailto:Mikael.Sevenier@amd.com>> wrote:

OpenCL kernels as well as other languages that can be compiled to SPIRV can be reused by Vulkan.
--mike

________________________________
From: Kai Ninomiya <kainino@google.com<mailto:kainino@google.com>>
Sent: Thursday, August 24, 2017 1:47:56 PM
To: public-gpu@w3.org<mailto:public-gpu@w3.org>
Subject: Re: Shader security model discussions: breaking it down?

A few more things relevant to both forks of this thread. Corentin pointed me to a few things:
* This is the extension for variable pointers that John talked about at the meeting:
https://www.khronos.org/registry/spir-v/extensions/KHR/SPV_KHR_variable_pointers.html<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.khronos.org%2Fregistry%2Fspir-v%2Fextensions%2FKHR%2FSPV_KHR_variable_pointers.html&data=02%7C01%7Cbencon%40microsoft.com%7C054dae39adc849e202a108d4eef380eb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636396176991667289&sdata=bxkxV2wPkDml8scOKOpIV35mWByeqtTOsnXNNt58nSc%3D&reserved=0>
* In addition to logical addressing, Vulkan also requires that SPIR-V programs not contain cycles (Vulkan 1.0 appendix A). So I misspoke about inlinability - it is indeed one of our constraints and it's one we probably can't avoid because it's required by Vulkan.

A consequence, IIUC, is that with logical addressing, without cycles, without variable pointers, it must be statically determinable which buffer a load instruction loads from. (Branches can/must be used to work around this.)