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://github.com/google/clspv> project that compiles OpenCL to
Vulkan-compatible SPIRV targets the logical addressing mode, and uses the
SPV_KHR_variable_pointer
<https://www.khronos.org/registry/spir-v/extensions/KHR/SPV_KHR_variable_pointers.html>
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://www.khronos.org/registry/vulkan/specs/1.0/html/vkspec.html#spirvenv-module-validation>
>  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
> * 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.)
>
>
>