[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] WebVulkan



If the browser implements the Custom Host Allocator and keeps track of the explicit GPU side allocations through the WebVulkan API, then it should have more insight into the actual GPU and driver memory utilization of WebVulkan content.  This would enable the browser to better enforce limits on how many resources content can use and protect the user better from malicious or broken sites.

What in particular about the WebVulkan memory model do people feel is incompatible with the web?

Cheers,
- Kearwood “Kip” Gilbert


On Aug 5, 2016, at 11:34 AM, Kearwood Kip Gilbert <kgilbert@mozilla.com> wrote:

SPIRV supports multiple memory models, addressing models, Storage Classes, etc…

Perhaps we could define WebVulkan as supporting a subset of these?

Also, GPU drivers provide cross-process isolation of the GPU memory.  Perhaps the browser could add an additional layer of security by instantiating a separate GPU process for each WebVulkan context?  If we depend on the GPU driver’s existing security models, would we need to manage a blacklist of driver versions with known vulnerabilities?

Thanks for the excellent discussion!

Cheers,
- Kearwood “Kip” Gilbert

On Aug 5, 2016, at 10:33 AM, Florian Bösch <pyalot@gmail.com> wrote:

On Fri, Aug 5, 2016 at 7:09 PM, Brandon Jones <bajones@google.com> wrote:
The memory model Vulkan exposes is simply not something we can do in the browser. That's not a subject that's up for debate, it's a fact.
Come again? No? Why? How? What? Who decided that?