- From: Myles C. Maxfield <mmaxfield@apple.com>
- Date: Mon, 28 Aug 2017 11:34:17 -0700
- To: "Bourges-sevenier, Mikael" <Mikael.Sevenier@amd.com>
- Cc: "public-gpu@w3.org" <public-gpu@w3.org>, Kai Ninomiya <kainino@google.com>
- Message-id: <EBA92146-8966-4E61-B316-63F6EE3A3C8C@apple.com>
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 <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.) >
Received on Monday, 28 August 2017 18:34:43 UTC