[HN Gopher] What's Next for WebGPU
___________________________________________________________________
What's Next for WebGPU
Author : mariuz
Score : 186 points
Date : 2024-11-21 22:18 UTC (1 days ago)
(HTM) web link (developer.chrome.com)
(TXT) w3m dump (developer.chrome.com)
| brcmthrowaway wrote:
| Being spun off to a different company.
| doctorpangloss wrote:
| Whom is WebGPU for, besides Unity?
| AshleysBrain wrote:
| Our browser based game engine Construct
| (https://www.construct.net) supports rendering with both WebGL
| and WebGPU.
| doctorpangloss wrote:
| When I visit a Construct 3 Ultra Pixel Survive on Mobile
| Safari on the latest production iOS with either WebGPU
| enabled and disabled, I only see black:
|
| https://www.construct.net/en/free-online-games/ultra-
| pixel-s...
|
| Which Construct 3 game should I try on Mobile Safari?
|
| I know there are other game engines. Supporting Mobile Safari
| is very very hard. It has its own flavor of everything. I
| would never speak in absolutes about some web standard and
| how it will work on Mobile Safari.
| itishappy wrote:
| Runs great on Android!
| doctorpangloss wrote:
| Then you agree that WebGPU isn't for Construct, it's for
| Unity.
| itishappy wrote:
| No. How does that follow?
| nox101 wrote:
| You realize that WebGPU has not shipped in Safari right?
| There's a reason it's still behind a developer flag. It's
| not finished.
| doctorpangloss wrote:
| Construct 3 doesn't work with WebGPU disabled either. I'm
| sure it has official support for Mobile Safari, just not
| official enough to work when someone visits a Construct 3
| experience.
|
| I'm not dunking on the engine. It's just to say, well
| this is what graphics programming in browser is: making
| shit work on mobile Safari.
| dahart wrote:
| Responding to your pre-edited comment.
|
| > whom is WebGPU for? [...] it's a huge rigamarole.
|
| Where is this comment coming from? WebGPU enables compute
| shaders, and there are applications in anything that uses a
| GPU, from ML to physics to audio to ... you name it. What is
| making you think game engines would be the only users? I bet a
| lot of companies are looking forward to being able to use
| compute shaders in JS apps and web pages.
|
| > Godot has had zero development for WebGPU support.
|
| Why would Godot be an indicator? I love Godot and their
| efforts, but it's less than 1% of game engine market share, and
| a much smaller less well funded team. Of course they're not on
| the bleeding edge. Unity is closer to 30% market share and is
| actively engaging with WebGPU, so it seems like you're
| downplaying and contradicting a strong indicator.
| doctorpangloss wrote:
| I edited my comment.
|
| > WebGPU enables compute shaders, and there are applications
| in anything that uses a GPU, from ML to physics to audio to
| ... you name it.
|
| I know.
|
| If you have to go through a giant product like Unity for
| example to use WebGPU because Apple will essentially have its
| own flavor of WebGPU just like it has its own flavor of
| everything, is it really cross platform?
|
| Does Apple support Vulkan? No. It was invented for
| middlewares!
|
| Apple has a flag to toggle on WebGPU on iOS today. I know
| dude. What does that really mean?
|
| They have such a poor record of support for gamey things on
| Mobile Safari. No immersive WebXR, a long history of breaking
| WASM, a long history of poor WebGL 2 and texture compression
| support. Why is this going to be any different?
| dahart wrote:
| I'm still not sure what the point is. WebGPU is an API, is
| that that you mean by middleware? What's the issue? Apple
| will do their own thing, and they might not allow WebGPU on
| Safari. What bearing does that have on what people using
| Linux, Windows, Firefox, and Chrome should do? And where
| exactly is this cross platform claim you're referring to?
| doctorpangloss wrote:
| The issue is, it's likely that a company with $2 BILLION
| spent on product development and a very deep relationship
| with Apple, like Unity, will have success using WebGPU
| the way it is intended, and nobody else will. So then, in
| conclusion, WebGPU is designed for Unity, not you and me.
| Unity is designed for you and me. Are you getting it?
| Eiim wrote:
| You haven't substantiated why nobody else could make use
| of WebGPU. Are Google the only ones who can understand
| Beacons because they make $300B/year? GPU is hard, but it
| doesn't take billions to figure out.
| jms55 wrote:
| > The issue is, it's likely that a company with $2
| BILLION spent on product development and a very deep
| relationship with Apple, like Unity, will have success
| using WebGPU the way it is intended, and nobody else
| will.
|
| Not really. Bevy https://bevyengine.org uses WebGPU
| exclusively, and we have unfortunately little funding -
| definitely not $2 billion. A lot of the stuff proposed in
| the article (bindless, 64-bit atomics, etc) is stuff we
| (and others) proposed :)
|
| If anything, WebGPU the spec could really use _more_
| funding and developer time from experienced graphics
| developers.
| doctorpangloss wrote:
| I agree with you, Bevy is a worthy cause.
|
| Why are people downvoting? The idea of Great High
| Performance Graphics Effortlessly on All Platforms is
| very appealing. It is fundamentally empathetic. It is an
| opium to game developers whose real antagonist is Apple
| and Nintendo, and who want a more organic journey in game
| development than Unity Learn. Is it a realizable goal?
| Time will tell.
|
| Everyone should be advocating for more focused efforts,
| but then. Are you going to say, Bevy is better than
| Godot? It's subjective right? Open source efforts are
| already spread so thin. An inability to rally behind one
| engine means achieving 2013's Unity 5 level of
| functionality is years away.
|
| Looking at it critically, in fact much effort in the open
| source ecosystem is even anti games. For example
| emulators used to pirate Nintendo Switch games have more
| mature multiplatform graphics engine implementations than
| Godot and Bevy do. It would be nice if that weren't true,
| you might tell me in some sense that I am wrong, but
| c'mon. It's crazy how much community effort goes into
| piracy compared to the stuff that would sincerely benefit
| game developers.
|
| WebGPU is authored by giant media companies, and will
| have purposefully hobbled support by the most obnoxious
| of them all, Apple - the one platform where it is kind of
| impractical to pirate stuff, but also, where it is kind
| of impractical to deliver games through the browser.
| Precisely because of the empathetic, yet ultimately
| false, promises of WebGPU.
| dahart wrote:
| Why are you bringing up Godot again? Are you worried
| Godot will be left behind or unable to compete with
| Unity? Are you working on Godot? Why are you focused
| exclusively on games? What are the 'false promises' of
| WebGPU, and why do you think it won't deliver compute
| shaders to every browser that supports it, like it says?
| I'm just curious, I get the sense there's an underlying
| issue you feel strongly about and a set of assumptions
| that you're not stating here. I don't have a lot invested
| in whether WebGPU is adopted by everyone, and I'm trying
| to understand if and why you do. Seems like compute
| shaders in the browser will have a lot of interest
| considering the wild success of CUDA. Are you against
| people having access to compute shaders in the browser?
| doctorpangloss wrote:
| > What are the 'false promises' of WebGPU
|
| That you can write a "compute shader" once, and it will
| run "anywhere." This isn't the case with any accelerated
| compute API, so why is WebGPU going to be different?
|
| Reality will be Chrome Windows Desktop WebGPU, Chrome
| Android (newish) WebGPU, Mobile Safari iOS 18 WebGPU,
| iPad WebGPU, macOS Safari WebGPU, macOS Chrome WebGPU,
| iOS default in app browser WebGPU, Instagram and Facebook
| in app browser WebGPU...
|
| This isn't complicated! If that's reality, I'd rather
| have:
|
| Apple Compute Shaders for Browser. Windows Chrome Compute
| Shaders for Browser. Android Chrome Compute Shaders for
| Browser.
|
| Because I'm going to go through a middleware like Unity
| to deal with _both_ situations. But look at which is
| simpler. It 's not complicated.
|
| > I'm trying to understand if and why you do.
|
| I make games. I like the status quo where we get amazing
| game engines for free.
|
| I cannot force open source developers to do anything.
| They are welcome to waste their time on any effort. If
| Bevy has great WebGL 2 support, which runs almost without
| warts everywhere, even on iOS, for example, it makes no
| sense to worry about WebGPU at all, due to the nature of
| the games that use Bevy. Because "runs on WebGPU" is
| making-believe that you can avoid the hard multiplatform
| engine bits. Engines like Construct and LOVE and whatever
| - 2D games don't need compute shaders, they are not very
| performance sensitive, use the browser as the middleware,
| and the ones that are, they should just use a huge
| commercial game engine. People have choices.
| dahart wrote:
| > That you can write a "compute shader" once, and it will
| run "anywhere."
|
| Can you post a link to that quote? What exactly are you
| quoting?
| raincole wrote:
| There are already open source projects making use of
| WebGPU, e.g. wgpu.
| dahart wrote:
| It seems like you've jumped to and are stuck on a
| conclusion that isn't really supported, somewhat ignoring
| people from multiple companies in this thread who are
| actively using WebGPU, and it's not clear what you want
| to have happen or why. Do you want WebGPU development to
| stop? Do you want Apple to support it? What outcome are
| you advocating for?
|
| Unity spends the vast majority of its money on other
| things, and Unity isn't the only company that will make
| use of WebGPU. Saying nobody will have success with it is
| like saying nobody will succeed at using CUDA. We're just
| talking about compute shaders. What is making you think
| they're too hard to use without Apple's help?
| CharlesW wrote:
| > _Apple will do their own thing, and they might not
| allow WebGPU on Safari._
|
| Safari has WebGPU support today, albeit behind a feature
| flag until it's fully baked. https://imgur.com/a/b3spVWd
|
| Not sure if this is good, but animometer shows an Avg
| Frame time of ~25.5 ms on a Mac Studio M1 Max with Safari
| 18.2 (20620.1.16.11.6). https://webgpu.github.io/webgpu-
| samples/sample/animometer/
| flohofwoe wrote:
| The demo is doing a setBindGroup per triangle, so not
| exactly surprising since this is a well known bottleneck
| (Chrome's implementation is better optimized but even
| there setBindGroup is a surprisingly slow call). But
| since both implementations run on top of Metal there's no
| reason why Safari couldn't get at least to the same
| performance as Chrome.
| asyx wrote:
| Apple submitted Metal as a web spec and they turned this
| into WebGPU and Apple got everything they asked for to
| avoid apple going rogue again. The fear that Apple of all
| companies is going to drop WebGPU support is really not
| based in reality.
| flohofwoe wrote:
| > because Apple will essentially have its own flavor of
| WebGPU
|
| Apple's WebGPU implementation in Safari is entirely spec
| compliant, and this time they've actually been faster than
| Firefox.
| rwbt wrote:
| I wish Apple made a standalone Webgpu.framework spinning
| it off of WebKit so that apps can link to it directly
| instead of having to link to Dawn/wgpu.
| flohofwoe wrote:
| Sounds like an interesting idea at first until the point
| where they will probably create a Swift/ObjC API around
| it instead of the standard webgpu.h C API, and at that
| point you can just as well use Metal - which is actually
| a bit less awkward than the WebGPU API in some areas.
| rwbt wrote:
| Maybe it makes more sense as a community project. Not
| sure how difficult it'd be to extract it from Webkit...
| lukaqq wrote:
| Web video editor(https://chillin.online), we are eagerly
| looking forward to the WebGPU API maturing and being extended
| to all major browsers, enabling faster rendering, bringing more
| effects, and facilitating the rendering and editing of 3D
| assets.
| edflsafoiewq wrote:
| Devs in the future? There was a long time between when WebGL2
| released and when it finally worked "everywhere" too.
| nox101 wrote:
| The number 1 use of WebGL is Google Maps by several orders of
| magnitude over any other use. At some point they'll likely
| switch to WebGPU making it the number 1 use of Google Maps.
| Google went over what this enables when they shipped it. Lots
| of features including being able to highlight relevant roads
| that change depending on what you searched for.
|
| https://www.youtube.com/watch?v=HrLyZ24UcRE
|
| Apple maps and others also use it
| pornel wrote:
| I'm new to GPU programming, and WebGPU and Rust's wgpu seem
| pretty nice to me (except the bindings!). The API is high-level
| enough that it's easy to learn. It hasn't grown deprecated
| parts or vendor-specific extensions yet.
| vFunct wrote:
| I could use more 2-d line support for CAD applications as well as
| font drawing.
| Waterluvian wrote:
| Same. I do a ton of 2D map stuff and it's always quite
| uncomfortable to do in shaders or very slow in a Canvas
| context.
|
| The last time I tried with pixi.js the problem was smoothly
| zooming polygons with a constant width border thicker than
| hairline. Doing that was basically just generating new textures
| on every frame.
| efnx wrote:
| Just out of curiosity, what is uncomfortable about writing
| shaders, in your opinion?
| skywal_l wrote:
| debugging
| efnx wrote:
| I agree completely.
| jsheard wrote:
| Font drawing is very much out of scope for a 3D API, that's
| something you (or a library) would implement on top of WebGPU.
| Likewise for line drawing, the API may expose some simple line
| primitives that the hardware supports natively, but if you want
| anything fancier then you're expected to do it yourself with
| shaders which is already possible in WebGPU.
|
| The 3D API is just meant to be a minimal portable abstraction
| over common low-level hardware features, composing those
| features into higher level constructs is intentionally left as
| an exercise for the user.
| lmariscal wrote:
| I mean, they are extending support for Canvas2D, which from
| what I believe would allow for easier text rendering.
| vFunct wrote:
| The problem is now you have to have all sorts of additional
| libraries you need to load across a network.
|
| Web APIs need more standardized functionality built in,
| including high-level ones, and not rely on additional
| libraries, because they have to download across a network.
|
| It's like having to install an app every time you visit a
| site.
| nox101 wrote:
| Asking for lines is like asking for your CPU to support macros.
| The GPU is low-level, lines are high level. You build the high
| level on top of the low-level with libraries etc...
| wffurr wrote:
| The Canvas2D interop feature should make it very easy to draw
| text to a 2D canvas and then pull that into WebGPU as a
| texture.
| flohofwoe wrote:
| WebGPU does have line primitives of course, but only the type
| of lines that's supported in the underlying 3D APIs (e.g.
| 1-pixel wide). Since the whole purpose of WebGPU is to provide
| a thin API over the common feature set of D3D12, Metal and
| Vulkan that's totally expected though.
| Lichtso wrote:
| There are libraries building on top of WebGPU for that, like:
|
| https://github.com/linebender/vello
|
| and (shameless plug):
|
| https://github.com/Lichtso/contrast_renderer
| macawfish wrote:
| Linux support please!
| stackghost wrote:
| Honest question: Can someone explain to me why people are excited
| about WebGPU and WASM and similar technologies?
|
| To me, one of the greatest things about the web is that the DOM
| is malleable in that you can right click -> view source -> change
| things. This is dead in an era where the server just sends you a
| compiled WASM dll.
|
| It seems to me that the inevitable result of things like WASM and
| WebGPU will be "rich media web 4.0 applications" that are just
| DRM, crypto miners, and spyware compiled so that they're more
| difficult to circumvent, and delivered via the browser. An excuse
| to write web apps with poor performance because "well the user
| just needs a stronger GPU". It seems like an express train back
| to the bad old days of every website being written in flash.
|
| I honestly cannot see the upsides of these technologies. Is it
| gaming? Why would I want to play a 3D game in my fucking
| _browser_ of all places? That 's a strict downgrade in almost
| every way I can think of. Why would anyone want that? Is it "AI"?
| Why would I want to run an LLM in the browser, I could just run
| it natively for better performance?
|
| All I can see and have seen over the last several years is a
| steady parade of new technologies that will make the internet
| (and in some cases the lives of every day people) objectively
| worse while enriching a handful of big tech douchebags.
|
| Why are we going down this path? Who is asking for this stuff?
| Why the fuck would I want to expose my GPU to a website?
| do_not_redeem wrote:
| Why do you think wasm is harder to circumvent? The only way to
| instantiate a wasm module in the browser is through (drum roll)
| javascript. Install noscript if you're worried. The days of
| view source -> edit are basically over anyway due to every
| site's 1MB+ minified JS blobs.
|
| > Why would I want to run an LLM in the browser, I could just
| run it natively for better performance?
|
| Why would you try out a new app in a sandboxed browser, when
| instead you could give it complete access to your entire
| computer?
| stackghost wrote:
| If the app can run arbitrary code on my GPU it's not exactly
| sandboxed, is it?
| do_not_redeem wrote:
| Are you launching Chrome with --disable-gpu-sandbox? If
| not, it's sandboxed.
| stackghost wrote:
| If websites can run compute shaders on my hardware,
| that's not a sandbox.
| tedunangst wrote:
| If websites can run JavaScript on your hardware, is that
| not sandboxed?
| crazygringo wrote:
| Sandboxing is about preventing code from accessing data
| it's not supposed to. Data like files or memory belonging
| to other tabs or other processes. Or data streams like
| your webcam or microphone. Data outside of its, well,
| sandbox.
|
| So how are compute shaders accessing data they're not
| supposed to? How do you think they're escaping the
| sandbox?
| do_not_redeem wrote:
| It seems like you're just making up your own definitions
| now because you don't like the tech. What do think a
| sandbox is, exactly? And what do you think Chrome's GPU
| sandbox does, if it's not a sandbox?
| dahart wrote:
| For that matter, why would you expose your CPU to a website? Or
| your monitor? It could show you _anything_! ;)
|
| Maybe you are not be aware of the number of good web apps that
| use some WebGL under the hood? You might be using office
| applications in your browser already that use WebGL when it's
| available, and the reason is it makes things faster, more
| responsive, more scalable, and more efficient. Same would go
| for WebGPU.
|
| There's no reason to imagine that the web will do bad things
| with your resources that you didn't ask for and don't have
| control over. There have been hiccups in the past, but they got
| fixed. Awareness is higher now, and if there are hiccups,
| they'll get fixed.
| skydhash wrote:
| I don't mind the browser using the GPU to speed up graphical
| operations. But I do mind random sites and apps going further
| than that. Native apps have better access, but there's an
| higher selection criteria than just opening a URL.
| stackghost wrote:
| >There's no reason to imagine that the web will do bad things
| with your resources that you didn't ask for and don't have
| control over.
|
| The web is like this _right now_. Why would things magically
| become a utopia?
| fulafel wrote:
| > There's no reason to imagine that the web will do bad
| things with your resources that you didn't ask for and don't
| have control over.
|
| Read some security update news from browser vendors and
| vulnerability researcher posts. There's some weak signals
| about vendors acknowledging the difficulty of securing the
| enormous attack surface of browsers built on unsafe
| foundations, eg MS "enhanced security mode" and Apple
| "lockdown mode".
| Flux159 wrote:
| > Why would I want to play a 3D game in my fucking browser of
| all places?
|
| To provide users a way to instantly play a game without having
| to download all assets at once. Give developers a potential way
| to avoid app store royalties of up to 30% on desktop or mobile.
| With wgpu in rust, you can also target WebGPU as a shared 3d
| runtime that will run across OS's natively rather than having
| to target Vulkan, Metal, and DirectX.
|
| > Why would I want to run an LLM in the browser, I could just
| run it natively for better performance?
|
| What about users who don't know how to download a model and run
| it locally? I would argue this is the vast majority of users in
| the world. Also, this specific use case is probably not going
| to be generalized with WebGPU yet due to model sizes, but
| rather other APIs like the Prompt API in Chrome which will use
| Gemini Nano embedded into the browser (assume it will
| eventually get standardized).
| https://developer.chrome.com/docs/ai/built-in-apis
|
| I agree with you that WASM and WebGPU will be used for adware,
| targeting, and spyware - but if you don't want to use them, you
| should disable them in your browser settings - there's
| definitely value add for other users even if you can't see any
| benefits.
| stackghost wrote:
| >To provide users a way to instantly play a game without
| having to download all assets at once
|
| There's a reason QuakeLive didn't catch on and it's because
| streaming resources to the player makes for awful UX.
|
| >What about users who don't know how to download a model and
| run it locally?
|
| Those users also don't know how to compile MS Word from
| source but they have been getting along just fine with
| installers.
| dartos wrote:
| The ability to paste a URL into a browser and have that be
| everything you need to do to play a game is pretty
| compelling for many kinds of games.
|
| That's what made flash games so big back in the day.
| pjmlp wrote:
| URLs can also be mapped into native applications, it is a
| matter of the right OS.
|
| https://developer.android.com/training/app-links
| dartos wrote:
| That's a different flow though.
|
| Pasting URL into browser, then having access to game
|
| Vs
|
| Pasting url in browser Get link to install app Install
| app Navigate to the original url again.
|
| Technical capabilities don't always change user
| experience
| pjmlp wrote:
| Application streaming, no need for installation before
| using.
| int0x29 wrote:
| That needs a hell of a lot of sandboxing before I get
| anywhere near it. Which sounds like a good use for WASM
| and WebGPU.
| skydhash wrote:
| > _To provide users a way to instantly play a game without
| having to download all assets at once_
|
| No need for the web in that case, which is inefficient. You
| can do with like those 1MB installers and stream those
| assets.
|
| > _but if you don 't want to use them, you should disable
| them in your browser settings_
|
| Which the majority won't. People don't even go in their phone
| settings, apart from connecting to WiFi and changing their
| wallpaper.
| zztop44 wrote:
| I don't want to download a random executable from some
| unknown source. However, I trust the browser sandbox.
| skydhash wrote:
| > _I don't want to download a random executable from some
| unknown source_
|
| Why would you do that?
|
| ---
|
| There's few applications that warrant having direct
| access to the GPU and other devices. And for those, a
| native app would be a much efficient way (for the user).
| text0404 wrote:
| yeah but users don't care about technical efficiency,
| they care about having seamless experiences that aren't
| interrupted by long downloads, app/context switching, and
| loading screens.
| skydhash wrote:
| Which the web doesn't provide. Try opening Figma and
| Sketch at the same time or Mail.app and Gmail. Google Doc
| is closer to Wordpad than Libreoffice.
| MindSpunk wrote:
| Browsers will never run games that aren't toys or use very
| simple assets in a way that doesn't completely suck. High
| quality assets need gigabytes of data. You either require
| users to download all the assets upfront (the thing we're
| trying to avoid) or streaming the assets dynamically.
|
| You end up having to re-implement steam to keep a local copy
| of the assets on the client device yourself, expect browsers
| to do the same to manage caching the gigabytes of data
| transparently, or design your game around a very slow storage
| device or use tiny assets.
|
| Flash games worked because they fit very nicely into the
| 'tiny assets' category.
| sroussey wrote:
| PWA to cache everything locally?
| pjmlp wrote:
| Application streaming sorts that out, with much better
| tooling for 3D development.
| 01HNNWZ0MV43FF wrote:
| Users wanted an app sandbox.
|
| HTML documents were sort-of like an app sandbox.
|
| Evolution is now adding an app sandbox to HTML.
|
| There is little we can do to resist it. I don't like it either
| - I hate HTML.
| stanleykm wrote:
| why would you want to expose your cpu to a website? why would
| you want to expose your keyboard to a website? why would you
| want to use a website at all? why don't you go outside, read a
| book, look at a duck, and pick a flower instead? do we exist
| just to complain? is this meaning?
| lukaqq wrote:
| You should try Chillin(https://chillin.online), browser-based
| video editor. Powered by WebGL, WASM, and WebCodecs, Chillin
| provides a full suite of video editing capabilities on the web.
| Trust me, Chillin is smoother than most native video editors,
| even on mobile. I believe Chillin can leverage WebGPU to bring
| even more powerful rendering features.
|
| Yes, running LLMs on the web may not have significant
| advantages due to the speed limitations, but other models, such
| as those for bg removal, speech-to-subtitles, and translation,
| could become practical and efficient thanks to WebGPU.
| koolala wrote:
| It's interesting to me you don't like any WebGL websites. I
| remember first trying Minecraft Java in the browser and it was
| awesome.
|
| Runescape! I grew up playing Runescape! How could anyone not
| want games like Runescape to exist?!?
| bigstrat2003 wrote:
| > How could anyone not want games like Runescape to exist?!?
|
| I mean, I wouldn't say I don't want it to exist. But
| Runescape is one of the shittiest, most boring games I've
| _ever_ played. It 's not exactly a strong argument for why we
| should run stuff in the browser
| peutetre wrote:
| > _Can someone explain to me why people are excited about
| WebGPU and WASM and similar technologies?_
|
| WebAssembly brings all languages to the browser. Why shouldn't
| I be able to use C#, Rust, Go, Dart, Python, or whatever else
| in browser?
|
| WebAssembly brings better performance. That's what Webamp
| found: https://jordaneldredge.com/blog/speeding-up-winamps-
| music-vi...
|
| And what Amazon found: https://www.amazon.science/blog/how-
| prime-video-updates-its-...
|
| And what Google found: https://web.dev/case-studies/google-
| sheets-wasmgc
|
| Why make things perform worse when they can perform better?
|
| Why shouldn't I be able to make an application that compiles to
| the Windows, macOS, and Linux desktops and also to the browser?
| This one does: https://bandysc.github.io/AvaloniaVisualBasic6/
| crabmusket wrote:
| Figma, my dude
| bigstrat2003 wrote:
| I agree. Trying to shove everything into the browser is
| absolutely stupid. Native apps are better than doing things in
| the browser in almost all cases. But that's not trendy, so
| people don't chase after it.
| encom wrote:
| We won't stop until the _entire_ web has been enshittified.
| akira2501 wrote:
| > Native apps are better
|
| Native operating systems are garbage at maintaining user
| privacy and become maintenance burdens when too many
| applications have been installed and even uninstalled on the
| machine.
|
| While not perfect, a browser tab is a stronger sandbox than
| you can easily get in any other context.
| jms55 wrote:
| Bindless is pretty much _the_ most important feature we need in
| WebGPU. Other stuff can be worked around to varying degrees of
| success, but lack of bindless makes our state changes extremely
| frequent, which heavily kills performance with how expensive
| WebGPU makes changing state. The default texture limits without
| bindless are also way too small for serious applications - just
| implementing the glTF PBR spec + extensions will blow past them.
|
| I'm really looking forward to getting bindless later down the
| road, although I expect it to take quite a while.
|
| By the same token, I'm quite surprised that effort is being put
| into a compatibility mode, when WebGPU is already too old and
| limiting for a lot of people, and when WebGL(2) is going to have
| to be maintained by browsers anyways.
| Animats wrote:
| > Bindless is pretty much _the_ most important feature we need
| in WebGPU. Other stuff can be worked around to varying degrees
| of success, but lack of bindless makes our state changes
| extremely frequent, which heavily kills performance with how
| expensive WebGPU makes changing state.
|
| Yes.
|
| This has had a devastating effect on Rust 3D graphics. The main
| crate for doing 3D graphics in Rust is WGPU. WGPU supports not
| just WebGPU, but Android, Vulkan, Metal, Direct-X 12, and
| OpenGL. It makes them all look much like Vulkan. Bevy, Rend3,
| and Renderling, the next level up, all use WGPU. It's so
| convenient.
|
| WGPU has lowest common denominator support. If WebGPU can't do
| something inside a browser, then WGPU probably can't do it on
| other platforms which could handle it. So WGPU makes your gamer
| PC perform like a browser or a phone. No bindless, no multiple
| queues, and somewhat inefficient binding and allocation.
|
| This is one reason we don't see high-performance games written
| in Rust.
|
| After four years of development, WGPU performance has gone
| down, not up. When it dropped 21% recently and I pointed that
| out, some people were very annoyed.[1]
|
| Google pushing bindless forward might help get this unstuck.
| Although notice that the target date on their whiteboard is
| December 2026. I'm not sure that game dev in Rust has that much
| runway left. Three major projects have been cancelled and the
| main site for Rust game dev stopped updating in June 2024.[2]
|
| [1] https://github.com/gfx-rs/wgpu/issues/6434
|
| [2] https://gamedev.rs/
| jms55 wrote:
| > This is one reason we don't see high-performance games
| written in Rust.
|
| Rendering is _hard_, and Rust is an uncommon toolchain in the
| gamedev industry. I don't think wgpu has much to do with it.
| Vulkan via ash and DirectX12 via windows-rs are both great
| options in Rust.
|
| > After four years of development, WGPU performance has gone
| down, not up. When it dropped 21% recently and I pointed that
| out, some people were very annoyed.[1]
|
| Performance isn't most of the wgpu maintainer's (who are paid
| by Mozilla) priority at the moment. Fixing bugs and
| implementing missing features so that they can ship WebGPU
| support in Firefox is more important. The other maintainers
| are volunteers with no obligation besides finding it
| enjoyable to work on. Performance can always be improved
| later, but getting working WebGPU support to users so that
| websites can start targeting it is crucial. The annoyance is
| that you were rude about it.
|
| > Google pushing bindless forward might help get this
| unstuck. Although notice that the target date on their
| whiteboard is December 2026.
|
| The bindless stuff is basically "developers requested it a
| ton when we asked for feedback on features they wanted (I was
| one of those people who gave them feedback), and we had some
| draft proposals from (iirc) 1-2 different people". It's
| wanted, but there are still major questions to answer. It's
| not like this is a set thing they've been developing and are
| preparing to release. All the features listed are just
| feedback from users and discussion that took place at the
| WebGPU face to face recently.
| kookamamie wrote:
| > implementing missing features so that they can ship
| WebGPU support in Firefox
|
| Sounds like WGPU, the project, should be detached from
| Firefox?
|
| To me the priority of shipping WGPU on FF is kind of mind-
| boggling, as I consider the browser irrelevant at this
| point in time.
| adastra22 wrote:
| Is WGPU even a Mozilla project? I think he is just saying
| that those paid developers (paid by Mozilla) have that
| priority, and everyone else is volunteer. Not that WGPU
| is a Firefox project.
| jblandy wrote:
| Yes, this.
| kookamamie wrote:
| Thanks, I checked the WGPU project's roots and you're
| right - it's not Mozilla's project, per-se.
| littlestymaar wrote:
| The irrelevant browser is the one paying developers to
| build wgpu though...
| brookman64k wrote:
| Just to avoid potential confusion: WebGPU and WGPU are
| different things.
| slimsag wrote:
| (a) WebGPU -> Specification or browser API
|
| (b) WGPU, gfx-rs/wgpu, wgpu.rs -> Rust crate implementing
| WebGPU
|
| (c) wgpu -> the prefix used by the C API for all WebGPU
| native implementations.
|
| (d) 'wgpu' -> a cute shorthand used by everyone to
| describe either (a), (b), or (c) with confusion.
| pjmlp wrote:
| Outside of the browser the answer is middleware.
|
| WGPU has to decide, either stay compatible with WebGPU,
| and thus be constrained by the design of a Web 3D API, or
| embrace native code and diverge from WebGPU.
| slimsag wrote:
| This is the right answer^
|
| But even more, the level at which WebGPU exists (not too
| high level, not too low level) necessitates that if a
| native API graphics abstraction sticks with the WebGPU's
| API design and only 'extends' it, you actually end up
| with three totally different ways to use the API:
|
| * The one with your native 'extensions' -> your app will
| only run natively and never in the browser unless you
| implement two different WebGPU rendering backends. Also
| won't run on Chromebook-type devices that only have GLES-
| era hardware.
|
| * The WebGPU browser API -> your app will run in the
| browser, but not on GLES-era hardware. Perish in the
| verbosity of not having bindless support.
|
| * The new 'compatability' mode in WebGPU -> your app runs
| everywhere, but perish in the verbosity of not having
| bindless, suffer without reversed-z buffers because the
| underlying API doesn't support it.
|
| And if you want your app to run in all three as best as
| possible, you need to write three different webgpu
| backends for your app, effectively, as if they are
| different APIs and shading languages.
| adrian17 wrote:
| > The WebGPU browser API -> your app will run in the
| browser, but not on GLES-era hardware. Perish in the
| verbosity of not having bindless support.
|
| Note, regarding "GLES-era": WGPU does have a GLES/WebGL2
| backend; missing WebGL1 is unfortunate, but at least it
| covers most recent browsers/hardware that happens to not
| have WebGPU supported yet.
|
| (and there's necessarily some added overhead from having
| to adapt to GLES-style api; it's especially silly if you
| consider that the browser might then convert the api
| calls and shaders _again_ to D3D11 via ANGLE)
| jblandy wrote:
| WGPU dev here. I agree with everything JMS55 says here, but
| I want to avoid a potential misunderstanding. Performance
| is _definitely_ a priority for WGPU, the open source
| project. Much of WGPU 's audience is very concerned with
| performance.
|
| My team at Mozilla are active contributors to WGPU. For the
| moment, when we Mozilla engineers are prioritizing _our own
| work_ , we are focused on compatibility and safety, because
| that's what we need most urgently for our use case. Once we
| have shipped WebGPU in Firefox, we will start putting our
| efforts into other things like performance, developer
| experience, and so on.
|
| But WGPU has other contributors with other priorities. For
| example, WGPU just merged some additions to its nascent ray
| tracing support. That's not a Mozilla priority, but WGPU
| took the PR. Similarly for some recent extensions to 64-bit
| atomics (which I think is used by Bevy for Nanite-like
| techniques?), and other areas.
|
| WGPU is an open source project. We at Mozilla contribute to
| the features we need; other people contribute to what they
| care about; and the overall direction of the project is
| determined by what capable contributors put in the time to
| make happen.
| jms55 wrote:
| > But WGPU has other contributors with other priorities.
| For example, WGPU just merged some additions to its
| nascent ray tracing support. That's not a Mozilla
| priority, but WGPU took the PR. Similarly for some recent
| extensions to 64-bit atomics (which I think is used by
| Bevy for Nanite-like techniques?), and other areas.
|
| Yep! The 64-bit atomic stuff let me implement software
| rasterization for our Nanite-like renderer - it was a
| huge win. Same for raytracing, I'm using it to develop a
| RT DI/GI solution for Bevy. Both were really exciting
| additions.
|
| The question of how performant and featureful wgpu is is
| mostly just a matter of resources in my view. Like with
| Bevy, it's up to contributors. The unfortunate reality is
| that if I'm busy working on Bevy, I don't have any time
| for wgpu. So I'm thankful for the people who _do_ put in
| time to wgpu, so that I can continue to improve Bevy.
| efnx wrote:
| Author of Renderling here. Thanks for the shout out Animats!
|
| Bindless is a game changer - pun intended. It can't happen
| soon enough.
|
| Just curious, what are the three major projects that were
| cancelled?
|
| I also want to mention that folks are shipping high
| performance games in Rust - the first title that comes to
| mind is "Tiny Glade" which is breathtakingly gorgeous, though
| it is a casual game. It does not run on wgpu though, to my
| knowledge. I may have a different definition of high
| performance, with lower expectations.
| Animats wrote:
| > What are the three major projects that were cancelled?
|
| Here are some:
|
| - LogLog Games [1]. Not happy with Bevy. Not too unhappy
| about performance, although it's mentioned.
|
| - Moonlight Coffee [2]. Not a major project, but he got as
| far as loading glTF and displaying the results, then quit.
| That's a common place to give up.
|
| - Hexops. [3] Found Rust "too hard", switched to Zig.
|
| Tiny Glade is very well done. But, of course, it's a _tiny_
| glade. This avoids the scaling problems.
|
| [1] https://news.ycombinator.com/item?id=40172033
|
| [2] https://www.gamedev.net/blogs/entry/2294178-abandoning-
| the-r...
|
| [3] https://devlog.hexops.com/2021/increasing-my-
| contribution-to...
| adastra22 wrote:
| Tiny glade isn't tiny on the rendering side. It does
| gorgeous, detailed landscapes.
| pjmlp wrote:
| Indeed, they also do most of the stuff custom.
| littlestymaar wrote:
| None of those are "major projects" by any definition of
| the word though. And none of the three has anything to do
| with wgpu's performance.
|
| Rust for game engine has always been a highly risky
| endeavor since the ecosystem is much less mature than
| everything else, and even though things have improved a
| ton over the past few years, it's still light-years away
| from the mainstream tools.
|
| Building a complete game ecosystem is very hard and it's
| not surprising to see that Rust is still struggling.
| slimsag wrote:
| It's crazy you've cited Hexops as an example:
|
| 1. It's a game studio not a project (CEO here :))
|
| 2. It's very much still alive and well today, not
| 'cancelled'
|
| 3. We never even used WebGPU in Rust, this was before
| WebGPU was really a thing.
|
| It is true that we looked elsewhere for a better language
| for us with different tradeoffs, and have since fully
| embraced Zig. It's also true that we were big proponents
| of WebGPU earlier on, and have in recent years abandoned
| WebGPU in favor of something which is better for graphics
| outside the browser (that's its own worthwhile story)..
|
| But we've never played /any/ role in the Rust gamedev
| ecosystem, really.
| z3phyr wrote:
| I think the future is getting rid of all the APIs and
| driver overhead, compile directly to GPU compute and
| write your own software renderers in a language targeting
| GPUs (Could be Zig)
| raincole wrote:
| As far as I know, Unity doesn't support bindless either.
| However thousands of Unity games are released on Steam every
| year. So it's safe to say performance isn't the main (or
| major) reason why Rust gamedev isn't getting much traction.
| Animats wrote:
| That limits Unity's scene size. See [1].
|
| [1] https://discussions.unity.com/t/gpu-bindless-resources-
| suppo...
| 0x457 wrote:
| Yes, it introduces limits (duh), but doesn't change the
| fact that there are plenty of Unity3d games that not only
| sold well, but also perform well.
| klysm wrote:
| The tone of the thread was perfectly fine until you made a
| passive aggressive comment
| adastra22 wrote:
| Tbh I was annoyed reading it too as an open source developer.
| The people you are talking to are volunteering their time,
| and you weren't very considerate of that. Open source
| software isn't the same support structure as paid software.
| You don't file tickets and expect them to be promptly fixed,
| unless you do the legwork yourself.
| jblandy wrote:
| There have been a bunch of significant improvements to WGPU's
| performance over the last few years.
|
| * Before the major rework called "arcanization", `wgpu_core`
| used a locking design that caused huge amounts of contention
| in any multi-threaded program. It took write locks so often I
| doubt you could get much parallelism at all out of it. That's
| all been ripped out, and we've been evolving steadily towards
| a more limited and reasonable locking discipline.
|
| * `wgpu_core` used to have a complex system of "suspected
| resources" and deferred cleanup, apparently to try to reduce
| the amount of work that needed to be done when a command
| buffer finished executing on the GPU. This turned out not to
| actually save any work at all: it did exactly the same amount
| of bookkeeping, just at a different time. We ripped out this
| complexity and got big speedups on some test cases.
|
| * `wgpu_core` used to use Rust generics to generate,
| essentially, a separate copy of its entire code for each
| backend (Vulkan, Metal, D3D12) that it used. The idea was
| that the code generator would be able to see exactly what
| backend types and functions `wgpu_core` was using, inline
| stuff, optimize, etc. It also put our build times through the
| roof. So, to see if we could do something about the build
| times, Wumpf experimented with making the `wgpu_hal` API use
| dynamic dispatch instead. For reasons that are not clear to
| me, switching from generics to dynamic dispatch made WGPU
| _faster_ --- substantially so on some benchmarks.
|
| Animats posts frequently about performance problems they're
| running into, but when they do it's always this huge pile of
| unanalyzed data. It's almost as if, they run into a
| performance problem with their code, and then rather than
| figuring out what's going on themselves, they throw their
| whole app over the wall and ask WGPU to debug the problem.
| That is just not a service we offer.
| Animats wrote:
| This is in reference to [1].
|
| [1] https://github.com/gfx-rs/wgpu/issues/6434
| ossobuco wrote:
| He's reporting a 23% drop in performance and seems to have
| invested quite some time in pinning down what's causing it,
| plus he's provided a repro repository with benchmarks.
|
| I honestly don't get your annoyed response; any OSS project
| wishes they had such detailed bug reports, and such a
| performance regression would concern me very much if it
| happened in a project I maintain.
| ladyanita22 wrote:
| I thought WGPU only supported WebGPU, and then there were
| translation libraries (akin to Proton) to run WebGPU over
| Vulkan.
|
| Does it directly, internally, support Vulkan instead of on-
| the-fly translation from WebGPU to VK?
| flohofwoe wrote:
| WGPU (https://wgpu.rs/) is one of currently three
| implementations of the WebGPU specification (the other two
| being Google's Dawn library used in Chrome, and the
| implementation in WebKit used in Safari).
|
| The main purpose of WebGPU is to specify a 3D API over the
| common subset of Metal/D3D12/Vulkan features (e.g. doing an
| 'on-the-fly translation' of WebGPU API calls to
| Metal/D3D12/Vulkan API calls, very similar to how (a part
| of) Proton does an on-the-fly translation of the various
| D3D API versions to Vulkan.
| pjmlp wrote:
| Within the constrains of the browser sandbox and 10 year
| old hardware, which is when its design started.
| flohofwoe wrote:
| I think it's more about low-end mobile GPUs which WebGPU
| needs to support too (which is also the main reason why
| Vulkan is such a mess). The feature gap between the low-
| and high-end is bigger than ever before and will most
| likely continue to grow.
| pjmlp wrote:
| I am yet to see anyone deliver in WebGL something at the
| level of Infinity Blade that Apple used to demo OpenGL ES
| 3.0 capabilities of their 2011 iPhone model, a mobile
| phone GPU from almost 15 years ago.
|
| Unless we are talking about cool shadertoy examples.
| flohofwoe wrote:
| That's more a business problem than a technical problem.
| Web games are in a local maximum of minimal production
| cost (via 2D assets) versus maximized profits (via
| free-2-play), and as long as this works well there won't
| be an Infinity Blade because it's too expensive to
| produce.
| pjmlp wrote:
| Yeah, but then what do we want this technology for,
| besides visualisations and shadertoy demos?
|
| Streaming solves the business case, with native APIs
| using server side rendering.
| flohofwoe wrote:
| At least it breaks up a chicken-egg problem, and the most
| interesting use cases are the ones that nobody was
| expecting anyway.
|
| > Streaming solves the business case, with native APIs
| using server side rendering.
|
| And yet history is littered with the dead husks of game
| streaming services ;)
| pjmlp wrote:
| The chicken egg problem caused by killing Flash games,
| and that nowadays no one cares about the browser, because
| everyone doing Flash moved into mobile phones or Steam,
| with better APIs?
|
| Game Pass, GeForce Now, are doing alright.
|
| Stadia failed, because Google doesn't get games industry.
| miloignis wrote:
| Tiny Glade?
| https://store.steampowered.com/app/2198150/Tiny_Glade/
| pjmlp wrote:
| Where is the URL for the game on the browser?
| astlouis44 wrote:
| Try this Unreal Engine 5 WebGPU demo:
| https://play.spacelancers.com/
| pjmlp wrote:
| Demo, not game.
|
| Shadertoy is full of impressive demos.
| ladyanita22 wrote:
| You're describing the WebGPU spec and its different
| implementations.
|
| OP claimed WGPU had native support for VK, DX and others.
| But as far as I know, WGPU just supports WebGPU being
| translated on the fly to those other backends, with the
| obvious performance hit. If I'm wrong, I'd be interested
| to know, as this would make WGPU a more interesting
| choice for many if, in reality, the code was native
| instead of translation.
|
| Edit: https://docs.rs/wgpu/latest/wgpu/#backends it seems
| they indeed support native code in almost every backend?
| flohofwoe wrote:
| I don't understand the question...
|
| Those three WebGPU implementation libraries _are_
| compiled to native code (they are written in Rust or C
| /C++), and at least WGPU and Dawn are usable as native
| libraries outside the browser in regular native apps that
| want to use WebGPU as a cross-platform 3D API.
|
| Yet still, those native libraries _do_ a runtime
| translation of WebGPU API calls to DX /Vk/Metal API calls
| (and also a runtime translation of either WGSL or SPIRV
| to the respective 3D backend API shading languages) - in
| that sense, quite similar to what Proton does, just for a
| different 'frontend API'.
| flohofwoe wrote:
| Tbf, tons of games have been created and are still being
| created without bindless resource binding. While WebGPU
| _does_ have some surprising performance bottlenecks around
| setBindGroup(), details like that hardly make or break a game
| (if the devs are somewhat competent they 'll come up with
| ways to workaround 3D API limitations - that's how it's
| always been and always will be - the old batching tricks from
| the D3D9 era still sometimes make sense, I wonder if people
| simply forgot about those or don't know them in the first
| place because it was before their time).
| z3phyr wrote:
| Another reason is that exploratory programming is hard by
| design in Rust. Rust is great if you already have a spec and
| know what needs to be done.
|
| Most of the gamedev in my opinion is extremely exploratory
| and demands constant experimentation with design. C/C++ offer
| fluidity, a very good and mature debug toolchain, solid
| performance ceiling and support from other people.
|
| It will be really hard to replace C++ in
| performance/simulation contexts. Security takes a backseat
| there.
| diggan wrote:
| > When it dropped 21% recently and I pointed that out, some
| people were very annoyed.[1]
|
| Someone was seemingly "annoyed" by an impatient end-user
| asking for an status update ("It's now next week. Waiting.")
| and nothing more. They didn't seem to be annoyed about that
| you pointed out a performance issue, and instead explained
| that their current focus is elsewhere.
| nox101 wrote:
| > The default texture limits without bindless are also way too
| small for serious applications
|
| I'm not disagreeing that bindless is needed but it's a bit of
| hyperbole to claim the texture limits are too small for serious
| applications given the large list of serious graphics
| applications that shipped before bindless existed and the large
| number of serious graphics applications and games still
| shipping that don't use them.
| jms55 wrote:
| It's partly because WebGPU has very conservative default
| texture limits so that they can support old mobile devices,
| and partly it's a problem for engines that may have a bunch
| of different bindings and have increasingly hacky workarounds
| to compile different variants with only the enabled features
| so that you don't blow past texture limits.
|
| For an idea of bevy's default view and PBR material bindings,
| see:
|
| * https://github.com/bevyengine/bevy/blob/main/crates/bevy_pb
| r...
|
| * https://github.com/bevyengine/bevy/blob/main/crates/bevy_pb
| r...
| elabajaba wrote:
| They're talking about the 16 sampled texture binding limit
| which is the same as webgl2. If you look at eg. the list of
| devices that are stuck with that few texture bindings they
| don't even support basic GL with compute shaders or vulkan,
| so they can't even run webgpu in the first place.
| Animats wrote:
| Yes. If you're stuck with that limitation, you pack up
| related textures into a big texture atlas. When you enter a
| new area, the player sees "Loading..." while the next batch
| of content is loaded. That was the state of the art 15 years
| ago. It's kind of dated now.
| modeless wrote:
| You don't have to settle for the default limits. Simply request
| more.
| adastra22 wrote:
| Yeah I went down the rabbit hole of trying to rewrite all our
| shaders to work on webgpu's crazy low limits. I'm embarrassed
| to say how long I worked that problem until I tried
| requesting higher limits, and it worked on every device we
| were targeting.
|
| The default limits are like the lowest common denominator and
| typically way lower than what the device actually supports.
| jms55 wrote:
| We do when there available, but I think the way browsers
| implement limit bucketing (to combat fingerprinting) means
| that some users ran into the limit.
|
| I never personally ran into the issue, but I know it's a
| problem our users have had.
| modeless wrote:
| That makes sense. I bet the WebGPU WG would be interested
| in hearing about that experience. They might be able to
| make changes to the buckets.
| pjmlp wrote:
| It only goes to show the limitations of browser 3D APIs, and
| the huge mistake some folks do for native games using it
| instead of a proper middleware engines, capable of exposing
| modern hardware.
| jms55 wrote:
| I don't necessarily disagree. But I don't agree either.
| WebGPU has given us as many positives as it has negatives. A
| lot of our user base is not on modern hardware, as much as
| other users are.
|
| Part of the challenge of making a general purpose engine is
| that we can't make choices that specialize to a use case like
| that. We need to support all the backends, all the rendering
| features, all the tradeoffs, so that our users don't have to.
| It's a hard challenge.
| pjmlp wrote:
| Basically the goal of any middleware engine, since the dawn
| of time in the games industry.
| jblandy wrote:
| The nice thing about WebGPU's "compat mode" is that it's
| designed so browsers don't have to implement it if they don't
| want to. Chrome is really excited about it; Safari has no plans
| to implement it, ever.
|
| I agree that compat mode takes up more of the WebGPU standard
| committee's time than bindless. I'm not sure that's how I would
| prioritize things. (As a Mozilla engineer, we have more than
| enough implementation work to do already, so what the committee
| discusses is sort of beside the point for us...)
|
| What would be really helpful is if, once the bindless proposal
| <https://hackmd.io/PCwnjLyVSqmLfTRSqH0viA?view> gets merged
| into the spec repo
| <https://github.com/gpuweb/gpuweb/tree/main/proposals>, a
| contributor could start adapting what WGPU has now to match the
| proposal. Implementation experience would be incredibly
| valuable feedback for the committee.
| ribit wrote:
| Quick note: I looked at the bindless proposal linked from the
| blog post and their description of Metal is quite outdated.
| MTLArgumentEncoder has been deprecated for a while now, the
| layout is a transparent C struct that you populate at will with
| GPU addresses. There are still descriptors for textures and
| samplers, but these are hidden from the user (the API will
| maintain internal tables). It's a very convenient model and
| probably the simplest and most flexible of all current APIs.
| I'd love to see something similar for WebGPU.
| worik wrote:
| They say:
|
| "This is the next step in the standardization process, and it
| comes with stronger guarantees of stability and intellectual
| property protection."
|
| I understand stability, and in the general sense I see that
| people feel they need to protect their IP, but in this specific
| case what is meant by "intellectual property protection"?
| choonway wrote:
| I think it means protection from intellectual property claims
| in the future.
| vasilvv wrote:
| W3C generally requires Working Group participants to provide
| IPR licensing commitments for the spec in question [0]. As far
| as I understand, higher level of specification maturity implies
| stronger level of obligations, though the specifics of what
| specifically changes when were never clear to me.
|
| [0] https://www.w3.org/policies/patent-policy/#sec-Requirements
| sakesun wrote:
| I'm curious why supporting ML algorithms is important inside
| browser ? Will my machine be improperly utilized by the sites I
| visit ?
| Grimblewald wrote:
| It can absolutely be used for bad, and I know many sites do use
| it for bad. However, it does good as well, and I think it's
| important to develop but also it should come with similar
| permission requests that use of microphone or camera do.
|
| I do research and develop ANN's for data analysis within
| chemistry. Making it possible for less tech literate people to
| visit a site, select a model, load their dataset, and get
| answers, is quite handy. The best part is because I can use
| their hardware to do it all, it all stays private, no one has
| to upload any sensitive research data etc. and I don't have to
| ship to various devices etc. I know if they have a mainstream
| updated browser they can likely use the tool. No endless
| requests for help, no mystery issues to solve, things just
| work.
| chrismorgan wrote:
| > _it should come with similar permission requests that use
| of microphone or camera do._
|
| Such permissions requests have been associated I think
| exclusively with input and output, not computation.
| Grimblewald wrote:
| Right, but I think it should change. I think consumers
| should have a say when a website wants to compute things
| that are out of scope for a normal page of
| text/information. I certainly dont want my laptop hot,
| slow, an poorly responsive because some news site's
| borderline malware is running several poorly built and
| implemented models that aim to track and predict my
| behaviour from mouse movement etc.
| sakesun wrote:
| Lot of downvote for my curiosity
| tkzed49 wrote:
| I wish there were a good way to profile WebGPU code. I've seen
| this (very useful) article[1] on setting up PIX, but I'm
| ambitious. I want to see everything from draw call timings to
| flamegraphs of shader code.
|
| Right now I feel like the only way to write efficient WebGPU code
| is to deeply understand specific GPU architectures. I hope some
| day there's a dev tools tab that shows me I'm spending too much
| time sampling a texture or there's a lot of contention on my
| atomic add.
|
| [1]: https://toji.dev/webgpu-profiling/pix.html
| jms55 wrote:
| Timestamp queries will give you essentially time spans you can
| use for profiling, but anything more than that and you really
| want to use a dedicated tool from your vendor like NSight, RGP,
| IGA, XCode, or PIX.
|
| > Right now I feel like the only way to write efficient WebGPU
| code is to deeply understand specific GPU architectures. I hope
| some day there's a dev tools tab that shows me I'm spending too
| much time sampling a texture or there's a lot of contention on
| my atomic add.
|
| It's kind of the nature of the beast. Something that's cheap on
| one GPU might be more expensive on another, or might be fine
| because you can hide the latency even if it's slow, or the CPU
| overhead negates any GPU wins, etc. The APIs that give you the
| data for what you're asking are also vendor-specific.
| tkzed49 wrote:
| That's fine--same with CPUs, right? But if I do something
| that's slow on _my_ CPU, at least there's tooling that will
| show me!
|
| I know that the reason is a lot of technical complexity (plus
| little standardization between vendors), but I think the end
| goal should be to make GPU programming more accessible.
| pjmlp wrote:
| Can forget about it.
|
| Developer tooling for debugging 3D Web APIs has been a
| continuous request since WebGL 1.0, from 2011.
|
| Until now the only thing that ever came out of it was SpectorJS
| and it shows its age.
|
| For a while Firefox did have a debugger, that they eventually
| removed from developer tools.
|
| You are left with writing the application twice, so that can
| make use of modern native debugging tools for graphics
| programming.
| darzu wrote:
| I've used [0] to profile WebGPU code w/ Nvidia Nsight, but yes
| better tools built into Chrome would be very nice.
|
| [0] https://frguthmann.github.io/posts/profiling_webgpu/
| tkzed49 wrote:
| awesome, I'll give it a shot. I'd lost all hope of ever
| getting Nsight to hook into WebGPU
| wwwtyro wrote:
| Any word on when it'll be supported on Linux without a flag?
| nox101 wrote:
| My guess is when someone one who cares about Linux submits a
| pull request to support it.
| vetinari wrote:
| So that's how it worked with MacOS and Windows? Color me
| surprised.
|
| But bth, Google doesn't seem to care about Android either.
| Chrome supports it on Snapdragons and that's it. Do you have
| Xclipse GPU? Like, I don't know, Samsung's current flagship
| line Galaxy S24 does? Too bad, not good enough.
| sealeck wrote:
| > So that's how it worked with MacOS and Windows? Color me
| surprised.
|
| Lots of people use MacOS and Windows though, so Google has
| incentive to support these platforms.
| pjmlp wrote:
| When they see a business value on GNU/Linux Desktop WebGPU
| support for Chrome, note that other Linux kernel based systems
| from Google already support it.
| astlouis44 wrote:
| My team (third party) has developed WebGPU support for Unreal
| Engine 5, along with an asset-streaming system that solves the
| large download, multi-gigabyte game in your webpage issue by only
| loading in what a player needs to see at any given moment. It's
| constantly loading and unloading data, which helps tremendously
| with memory management.
|
| WebGPU is going to usher in a new era of web games, the biggest
| benefit being compute shaders which have never before been
| possible inside the browser.
|
| DISCLAIMER - Will only work on a Windows device running Chrome or
| a Chromium browser. Mac and iOS isn't well supported yet.
|
| Space demo - https://play.spacelancers.com/
|
| Forest demo - https://play-
| dev.simplystream.com/?token=bd4ca6db-522a-4a73-...
| iknowstuff wrote:
| Aw neither works on iOS 18.2
| astlouis44 wrote:
| Yeah WebGPU isn't officially enabled by default on Safari
| yet, but that's actually not what's stopping these demos from
| working.
|
| Once we mobile optimize, they should work well.
| bobajeff wrote:
| Nor Linux.
|
| So basically Webgpu is just another graphics API for
| targeting Windows. Yay.
| astlouis44 wrote:
| Linux isn't supported currently, doesn't mean it won't be
| in the future.
| akira2501 wrote:
| Well, until it is, I'm not wasting a minute of my time on
| it.
| conductr wrote:
| > DISCLAIMER - Will only work on a Windows device running
| Chrome or a Chromium browser.
|
| It loaded, but "work" is a stretch. It was a multiple second
| lag to react to input. Very choppy.
| hit8run wrote:
| Don't know for you but for me the next thing for WebGPU is
| uninstalling Google Chrome. Manifest v3 my ass.
___________________________________________________________________
(page generated 2024-11-22 23:00 UTC)