Re: Shader security model discussions: breaking it down?

One thing that has come up in the meeting is that it would be nice to have
examples of code we want to be able to run, even synthetic ones. This would
help get everyone agree on what "hardcore/big compute" is so we can discuss
it more.

On Tue, Aug 29, 2017 at 3:46 PM, Ben Constable <bencon@microsoft.com> wrote:

> 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>
> 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> 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>
> *Sent:* Thursday, August 24, 2017 1:47:56 PM
> *To:* 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.)
>
>
>
>
>
>
>