Re: Shader security model discussions: breaking it down?

I noticed a comment in the meeting notes:

Another population: using GPUs to speed up their existing programs. C++,
Swift, etc.

Even here, there are people who accelerate general, often large,
applications, and who need absolutely the highest application performance.
This group is unlikely to leverage the web as a distribution platform.

The group that does choose the web as a distribution platform will have a
higher focus on portability, and be willing to sacrifice a measure of
performance and functionality. At least for an MVP, we might be reaching a
bit for to target full compatibility with OpenCL.

Alex

On Wed, Aug 30, 2017 at 3:51 PM, Alex Kluge <akluge@vizitsolutions.com>
wrote:

>   Would a Vulkan compute example be useful here? I've done a lot with
> OpenGL, and can work out something like a 2D finite difference solver for
> Vulkan. Along the way I can look for issues that might arise with respect
> to security such as the default contents for textures and arrays, what
> happens when you index beyond the expected limit of an array, etc. Finite
> difference and finite element problems are classics for GPUs as they are
> highly parallel, and don't have a lot of random memory access.
>
>   There are also probably opportunities for denial of service attacks too,
> such as running long compute tasks, or tasks that consume all available
> memory.
>
>
>       Alex
>
> On Tue, Aug 29, 2017 at 2:55 PM, Corentin Wallez <cwallez@google.com>
> wrote:
>
>> 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_K
>>> HR_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.)
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>