Does model-viewer support WebGPU ?
Chrome ships WebGPU
361–370 of 405 posts
Re: Chrome ships WebGPU
#362Earlier quoted context omitted.
i want the chrome apps model to come back - put your permission requests in a manifest, and when the user clicks and install button the app gets its permissions. so "web apps" that the user cares enough about to install get useful features, but pages that you just visit briefly don't.
> i want the chrome apps model to come back - put your permission requests in a manifest, and when the user clicks and install button the app gets its permissions. So you will get the Android case where flashlight apps where asking for everything, including location data and contact access, and people were giving it to them
you can't protect everybody from themselves all the time.
some people are just gonna agree to everything, and you can't stop it. don't ruin apps for everybody just because some guy who couldn't care less shared some data with an app you think they shouldn't have.
Re: Chrome ships WebGPU
#363Earlier quoted context omitted.
Aras is right, but the elephant in the room is still shitty mobile GPUs. Most of those new and fancy techniques don't work on mobile GPUs, and probably won't for the foreseeable future (Vulkan should actually have been two APIs: one for desktop GPUs, and one for mobile GPUs - and those new extensions are doing exactly that - splitting Vulkan into two more or less separate APIs, one that sucks (for mobile GPUs) and on…
>> "shitty mobile GPUs." Uh, no ; it power and heat management so battery and fire risk that limits SFF -- It would be good for mobile devices to have external GPU/battery attachments via a universal connector... this will boost efficacy of devices... but you may not always need the boost provided by the umbilical - but when you do need it - just put it outside the machine, and connect it when needed...
egpu enclosures are just that yet somehow cost $400 without the gpu
Re: Chrome ships WebGPU
#364This is very exciting! (I had suspected it would slip to 114) WebGPU implementations are still pretty immature, but certainly enough to get started with. I've been implementing a Rust + WebGPU ML runtime for the past few months and have enjoyed writing WGSL. I recently got a 250M parameter LLM running in the browser without much optimisation and it performs pretty well! ( https://twitter.com/fleetwood___/status/16384…
Oh great! I am one of the contributors for Burn (Rust Deep Learning Framework). We have a plan adding a WebGPU backend ( https://github.com/burn-rs/burn/issues/243 ). Here is more about the framework Burn: https://burn-rs.github.io/
Burn looks interesting... so I notice in the sample code you mention:
use burn_tch::TchBackend;
I don't see "TchBackend" mentioned in the docs. Is Tch = torch and Burn can be used as a Torch (or tch-rs) wrapper? Or am I imagining too much from a miscellaneous three letter prefix?
I've been looking for a good way to do standard modern AI stuff in Rust, and was leaning towards tch-rs because it exists and seems reasonably frequently maintained, but if you have some sort of reason to use Burn instead then I'm curious to hear it.
Re: Chrome ships WebGPU
#365Earlier quoted context omitted.
You've got it backwards.
Google Ads, 2020-07-31: What is not acceptable is the use of opaque or hidden techniques that transfer data about individual users and allow them to be tracked in a covert manner, such as fingerprinting. We believe that any attempts to track people or obtain information that could identify them, without their knowledge and permission, should be blocked. We’ll continue to take a strong position against these practices…
1. In the context of browsers Google's competitors are Safari and Firefox. And in this context Google is always consistently behind: either unwilling to implement the same privacy protections, or implementing them years later, or coming up with non-solutions
2. It's funny how you link to a Google propaganda piece on FLoC. Whereas Google's competitors (context: browsers) actually try to reduce fingerprinting, tracking, and thrid-party cookies, Google is trying to have the cake and eat it too with FLoC. Which was such a blatant attempt to keep fingerprinting and tracking alive that everyone immediately disabled it within months of Google's experiments with it.
Edit: Tracking and fingerprinting is Google's bread and butter, literally: 80% of its money comes from targeted advertising.
Re: Chrome ships WebGPU
#366Earlier quoted context omitted.
> with mobile being actually much more important than desktop How so? I always thought the more common use case for GPU acceleration on the web for mobile were 2D games (Candy crush etc). Even on low end devices these are already plenty fast with something like Pixi, no?
We live in a bubble where we don't notice it, but desktop as a platform is... not dying exactly, but maybe returning to 90s levels of popularity. Common enough, but something tech-minded people use, and not necessarily for everybody. Mobile is rapidly becoming the ubiquitous computing paradigm we all thought desktop computers would be. In that world, WebGPU is much more important on mobile than on desktop.
Desktop is pretty much alive, it is called laptops.
My Thinkpad P80 + docking station doesn't own anything to classical desktops.
Re: Chrome ships WebGPU
#367This is a huge milestone. It's also part of a much larger journey. In my work on developing Vello, an advanced 2D renderer, I have come to believe WebGPU is a game changer. We're going to have reasonably modern infrastructure that runs everywhere: web, Windows, mac, Linux, ChromeOS, iOS, and Android. You're going to see textbooks(*), tutorials, benchmark suites, tons of sample code and projects to learn from. WebGPU…
Compute is hardly modern, we could have had it on WebGL already if it wasn't for Google.
Re: Chrome ships WebGPU
#368Earlier quoted context omitted.
Getting Apple on board? Wasn't Apple the originators of the propsal? https://webkit.org/blog/7380/next-generation-3d-graphics-on-... https://webkit.org/wp-content/uploads/webgpu-api-proposal.ht...
Apple has a Khronos allergy, and both SPIRV and GLSL are Khronos standards. Also the original 3D API proposal from Apple was essentially a 1:1 Javascript shim for Metal, which looked quite different from WebGPU. Apple also originally proposed a custom shading language which looked like - but wasn't quite - HLSL. Compared to that, WGSL is the saner solution (because translation from and to SPIRV is relatively straight…
Mostly caused by how Khronos has managed OpenCL, and ironically Vulkan is slowly adopting HLSL as the main shading language, as they don't plan to invest into improving GLSL any further.
Re: Chrome ships WebGPU
#369Earlier quoted context omitted.
No idea what the comment about Rust means, but we already have several shader languages. There was literally no reason to invent another incompatible one
Most current shader languages are very close to C in terms of syntax and behavior and these are some of the worst aspects of C as a language. I guess they could have went with SPIR-V but generally a compilation step shouldn't be required in web standards.
MSL, HLSL and PSSL are C++ dialects.
Re: Chrome ships WebGPU
#370Earlier quoted context omitted.
>> "shitty mobile GPUs." Uh, no ; it power and heat management so battery and fire risk that limits SFF -- It would be good for mobile devices to have external GPU/battery attachments via a universal connector... this will boost efficacy of devices... but you may not always need the boost provided by the umbilical - but when you do need it - just put it outside the machine, and connect it when needed...
egpu enclosures are just that yet somehow cost $400 without the gpu
Any idea why this is? They seem very expensive for what they are.