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

Re: [Public WebGL] WebVulkan



While it’s true that implementing WebGL on top of Vulkan can give the browser knowledge of tracking driver memory usage and GPU memory usage, there is further benefit in if this is exposed all the way to content…

When implementing asynchronous mip-level texture and geometry streaming in my own engines for open world games, I try to maximize utilization of the GPU resources in a way that optimizes the set of assets loaded for the current location of the camera.  If I allocate too few resources, performance and quality suffers.  If I allocate too many resources, I risk having my process terminated or further allocations denied.  This is made difficult with WebGL and OpenGL ES as the size of the asset on disk does not directly correlate to the GPU and driver resource utilization.  Finally, there is no control over the lifetime of these resources, and thus no way to know for sure when to discard assets and load other LOD levels.

With WebVulkan, we could specify non-abstract limits on GPU resource availability that content is allowed to use without penalty.  WebVulkan content will have the knowledge it needs to select the right resources for the host without exceeding the limits enforced by the browser.

Of course, this is just one of many benefits a WebVulkan API could provide.  It’s just one that I haven’t seen discussed yet :-)

Cheers,
	- Kearwood “Kip” Gilbert

> On Aug 5, 2016, at 12:02 PM, Steve Baker <steve@sjbaker.org> wrote:
> 
> I think you're confusing how useful it would be for browsers to use Vulkan
> internally from how useful it would be to expose it to JavaScript.
> 
> Sure, Vulkan's memory allocation features would benefit the browser
> internally - but this doesn't necessarily mean that it would have to be
> exposed to JavaScript.   There is no problem (in principle) with browsers
> deciding to use Vulkan to implement WebGL and achieve all of the goals
> you're talking about here.
> 
> I do believe that there would be value in exposing that stuff to
> JavaScript - but not for this reason.
> 
>  -- Steve
> 
> 
> Kearwood \"Kip\" Gilbert wrote:
>> 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
>>>> <mailto:pyalot@gmail.com>> wrote:
>>>> 
>>>> On Fri, Aug 5, 2016 at 7:09 PM, Brandon Jones <bajones@google.com
>>>> <mailto: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?
>>> 
>> 
>> 
> 
> 
> -- Steve
> 


-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------