- From: Jeff Gilbert <jgilbert@mozilla.com>
- Date: Wed, 23 Aug 2017 23:05:49 -0700
- To: Kai Ninomiya <kainino@google.com>
- Cc: public-gpu@w3.org, JF Bastien <w3c@jfbastien.com>
- Message-ID: <CAOztSJ1aBYwPWsP1dYuAiXafOVyDFdL6oKs--4XKtNX45z2nyw@mail.gmail.com>
What is the proposal then for running on Vulkan, where this is not supported? Are we expanding the scope of this API to include OpenCL workloads? That seems like a huge step of scope creep beyond what we've discussed previously. On Aug 24, 2017 12:54 AM, "Kai Ninomiya" <kainino@google.com> wrote: > It was discussed on the call today that logical addressing mode could be > too restrictive for some applications. We did not determine whether it is > or not; there is an action item to do research into real-world GPU compute > applications (e.g. in MSL, CUDA, OpenCL) and how they use pointer > addressing features so we can make an informed decision. > > On Wed, Aug 23, 2017 at 9:51 PM Jeff Gilbert <jgilbert@mozilla.com> wrote: > >> Where does the proposal of non-logical-addressing spirv come from? My >> understanding is that Vulkan requires logical addressing only. >> >> On Aug 24, 2017 12:22 AM, "JF Bastien" <w3c@jfbastien.com> wrote: >> >>> On Wed, Aug 23, 2017 at 9:00 PM, Maciej Stachowiak <mjs@apple.com> >>> wrote: >>> >>>> >>>> >>>> On Aug 23, 2017, at 8:46 PM, Kai Ninomiya <kainino@google.com> wrote: >>>> >>>> As was mentioned in today's call, there may or may not be agreement on >>>> what is required of our security model. >>>> >>>> As a first step I want to make sure agree on a *lower bound* on the >>>> strictness of the security model before we go into debates about further >>>> restrictions. My understanding: >>>> >>>> * Any memory or data access of any kind MUST NOT make data visible to >>>> the Application other than (a) default values or (b) any data produced by >>>> the program. >>>> >>>> >>>> Can you define your terms a bit more? What specifically do "the >>>> Application" and "the program" mean in this case? Do these terms refer to >>>> the same thing? Do they refer to just the shader program or the combination >>>> of all shader programs plus the webpage (or other CPU-level application) >>>> invoking them? >>>> >>>> At first glance your point seemed clear, but then I thought about what >>>> it means for textures. Clearly shaders should be allowed to access the >>>> contents of textures provided to them. But are those either "default >>>> values" or "values produced by the program"? It depends on what "program" >>>> means. >>>> >>> >>> I think you also want to define what functions are allowed to do: >>> >>> - Can I read the executable code? >>> - Can I direct-call a function with mismatched argument count / >>> return count? >>> - Can I indirect-call a function with mismatched argument count / >>> return count? >>> - Can I imbalance the data stack (pop more than I've pushed)? >>> - Can I call arbitrary addresses, or overwrite a return address? >>> - Is recursion allowed, and is it bounded? >>> >>> IIUC most GPU programs have perfect call information when compiled, so I >>> could theoretically inline everything? If our languages enforces this then >>> we're significantly simplifying the problem. >>> >>> You also want to specify how calls into and out of WebGPU work. >>> WebAssembly calls this interaction with the "embedder". For example, in a >>> JavaScript embedding you can't use i64 in your interface. There currently >>> aren't any races possible, but I think WebGPU has to put extra thought into >>> this to avoid ToCToU headaches while minimizing copying. >>> >>> >>> * This must be implementable in a performant way on all current, >>>> existing target platforms. (Platform-specific optimizations like robustness >>>> guarantees or page table controls optional.) >>>> >>>> >>> What are "all" platforms? WebAssembly limits itself to a set of >>> portable targets >>> <https://github.com/WebAssembly/design/blob/master/Portability.md>. >>> Others can implement WebAssembly but will suffer a mild performance loss. >>> >>> >>> I think the lower bound needs to include the constraints for writing as >>>> well, not just reading. I'd hope there is consensus on this, though I was >>>> not on the call. >>>> >>> >>> Yes, writing as well :) >>> >>> >>> >>>> Also, these constraints must hold for the combination of the shader >>>> language and the API itself. Races between the CPU and the GPU must not >>>> allow memory safety constraints to be violated. >>>> >>>> >>>> Beyond that, I'd like to figure out how to break down the discussion >>>> before moving forward. Example questions (but I don't want to discuss these >>>> questions YET): >>>> >>>> >>>> I am so tempted to answer these questions, but refraining for now. >>>> >>>> >>>> * Do we want fully general pointer behavior, the SPIR-V restricted >>>> pointer behavior mentioned today, logical addressing only, or something >>>> else? What high-level language features, algorithms, and techniques might >>>> require more flexibility? >>>> >>>> >>>> * Is it possible to provide any kind of "fault" behavior? - e.g., >>>> termination of execution in such a way that IF outside data is accessed by >>>> the Device, the Device is terminated before that data can become visible to >>>> the Application. If it's possible, is it useful? >>>> >>>> >>>> * Can our security model be "optional" for an insecure-mode, "native" >>>> (C/C++) version of the API? (Useful for native platform portability as well >>>> as apps with both native and web versions.) >>>> >>>> >>> WebAssembly just says that such implementations are non-conforming. You >>> can still do it, we don't have a trademark enforcing conformance. Keeps the >>> spec simple. >>> >>> >>> What other questions can we add to this list? >>>> >>>> >>> More questions: >>> >>> *Fault ordering.* We discussed whether fault behavior should be >>> guaranteed to happen in program order or not. Fil gave the example of >>> WebAssembly where that's the case, but with multiple warps going I'm not >>> sure it's reasonably feasible. I don't want us to explore feasibility now, >>> just adding that question to the list, let's figure it out later. >>> >>> *Nondeterminism.* Another question is whether you want full determinism >>> on corner cases or not. WebAssembly clamps it down substantially >>> <https://github.com/WebAssembly/design/blob/master/Nondeterminism.md>. >>> You might even choose to leave it implementation-defined what happens on an >>> out of bounds memory access: an implementation could be allowed to >>> terminate *or* wrap around. I'm not advocating either way, just adding >>> more to the design space. You'll definitely want to figure out how to >>> resolve races in the face of threads and SIMD (not mandate a single >>> outcome, but have some memory model). >>> >>>
Received on Thursday, 24 August 2017 06:06:13 UTC