[HN Gopher] I want to talk about WebGPU
___________________________________________________________________
I want to talk about WebGPU
Author : pjmlp
Score : 490 points
Date : 2023-05-03 11:24 UTC (11 hours ago)
(HTM) web link (cohost.org)
(TXT) w3m dump (cohost.org)
| flohofwoe wrote:
| > The middleware developers were also in the room at the time,
| the Unity and Epic and Valve guys. They were beaming as the
| Khronos guy explained this. Their lives were about to get much,
| much easier.
|
| Lol, I wonder what their opinion is now 8 years later (at least
| those who haven't been burned out by Vulkan).
| Netcob wrote:
| One place I worked at had a guy who proudly wore a "Vulkan -
| Industry Forged" T-Shirt every day. I'll just assume he had 5-7
| identical ones.
| DonHopkins wrote:
| I had a great tie-dyed Microsoft DirectX t-shirt that a dude
| in the Microsoft booth at CGDC gave me in 1996. I loved
| wearing it to Linux and Mac trade shows, because it would
| make people's heads explode.
| dathinab wrote:
| > In fact it is so good I think it will replace Vulkan as well as
| normal OpenGL, and become just the standard way to draw, in any
| kind of software, from any programming language.
|
| I fully agree with that, for a lot of use cases WebGL has
| everything you need, means it has the potential to become the
| cross platform graphics API OpenGL dreamed to be. And as a bonus
| you have a realistic way to run whatever app you are writing in
| the browser with WASM+WebGL.
|
| I just think for AAA games Vulcan, Metal and DirectX12 will
| probably still be the way to go. But GUI libraries? Less highest
| end games? There is just no point once you can use WebGL
| everywhere. And then if you want to have a browser Demo you have
| a realistic chance to get it.
| sva_ wrote:
| Too bad that WebGPU builds on top of Vulkan, so the dependency
| (and incomplete support for some configurations) is still
| there.
| jsheard wrote:
| WebGPU is designed to split the difference between Vulkan,
| DirectX 12 and Metal, it can be implemented on top of any of
| those.
|
| In practice it'll only use Vulkan on Android and Linux, the
| main two implementations both default to DX12 on Windows even
| though they could technically use Vulkan there.
| CryZe wrote:
| wgpu at least prefers Vulkan over DirectX 12 on Windows.
| jsheard wrote:
| My mistake, they _plan_ to use DX12 by default on
| Windows, but the DX12 backend isn 't fully cooked yet so
| for now it defaults to Vulkan.
|
| https://github.com/gfx-rs/wgpu/issues/2719
| karussell wrote:
| _> for a lot of use cases WebGL has everything you need_
|
| I think the original post refers to WebGPU
| JayStavis wrote:
| I can't tell if it's just a masterful troll implying web
| graphics history repeats itself.
| api wrote:
| So wait... do we now have a situation where the browser engine
| has converged with where the Java Virtual Machine was and
| provided a container to run write-once-run-anywhere desktop
| apps compiled to WASM?
|
| All we need is the last mile -- progressive web apps -- to
| include better support for integration with desktop OSes and we
| have a way to take WASM apps and drag them to the desktop.
|
| The up and coming languages for writing these WASM apps seem to
| be Go and Rust. Here's a Rust example:
|
| https://www.egui.rs
| flohofwoe wrote:
| WebGPU can be used outside of the browser through native
| libraries:
|
| https://github.com/gfx-rs/wgpu
|
| https://dawn.googlesource.com/dawn
|
| (these are the libraries that are used in Firefox and Chrome
| to provide the WebGPU implementation, don't know if
| Apple/WebKit also has open-sourced theirs)
|
| Some non-browser WASM runtimes also have WebGPU support
| already, but unfortunately only for offscreen rendering or
| compute tasks (e.g. for writing cross-platform windowed apps
| as WASM blobs, there's a window system glue layer missing).
| Jasper_ wrote:
| > don't know if Apple/WebKit also has open-sourced theirs
|
| https://github.com/WebKit/WebKit/tree/main/Source/WebGPU
| wffurr wrote:
| I don't know about WebGPU, but WebGL is missing some key
| performance features from OpenGL ES, like client-side buffers,
| pixel buffer objects, and MSAA render-to-texture frame buffers.
| Jasper_ wrote:
| Client-side buffers are not a great idea. Pixel buffer
| objects and MSAA framebuffers exist in WebGL 2.
| lib-dev wrote:
| > It really seemed like DirectX (and the "X Box" standalone
| console it spawned)
|
| Did the name "XBox" come from the fact that in ran DirectX? Sort
| of short for DirectXBox?
| dontlaugh wrote:
| That was actually the originally proposed name, yes.
| Netcob wrote:
| Yes.
|
| MS called all their multimedia/gaming APIs DirectSomething for
| a while, then decided to group it all together into DirectX. It
| was also a time when you had to put an X into everything
| because you were XTREME.
| steve_adams_86 wrote:
| If I'm not mistaken, this would have been toward the end of
| the 90s. These were Xtreme times.
|
| Super Soakers, Jolt Cola, the Teenage Mutant Ninja Turtles,
| Sonic the Hedgehog, the FBI would come after you for
| reproducing copyrighted films (according to the warning at
| the start of the film). Definitely seems like an era in which
| something would be named DirectX.
| shmerl wrote:
| _> Except Linux has a severe driver problem with Vulkan and a lot
| of the Linux devices I 've been checking out don't support Vulkan
| even now after it's been out seven years._
|
| What? Vulkan is supported on all relevant GPUs on Linux.
|
| There is no "severe driver problem" either.
| SaintSeiya84 wrote:
| Out of (ignorant) curiosity: why? just why we need an extra
| "standard"? and why browsers keep growing to become full OS
| adding more bloat to the tech stack?
|
| Zawinski's Law: "Every program attempts to expand until it can
| read mail. Those programs which cannot so expand are replaced by
| ones which can."
|
| Zawinski himself has stated:
|
| "My point was not about copycats, it was about platformization.
| Apps that you "live in" all day have pressure to become
| everything and do everything. An app for editing text becomes an
| IDE, then an OS. An app for displaying hypertext documents
| becomes a mail reader, then an OS."
| ajkjk wrote:
| The trajectory we're on is for browsers to become consumer
| operating systems and consumer operating systems as currently
| conceived to, basically, vanish into the background. This is a
| good thing, you should want it to happen. All anybody ever
| wanted was a decent UI/UX that runs stuff, and that's just
| _software_ so there 's no real reason, besides historical
| mistakes, that it can't run the same on every machine.
|
| The dream is for Explorer/Finder/etc to no longer exist and for
| the whole computing experience to be something you just
| download and customize to your heart's content. Just imagine! A
| day when you can no longer _tell_ you 're using Windows unless
| you're unfortunately saddled with the job of making something
| run on it under the hood. That's the only way Microsoft's
| negligent idiocy is ever going to be shut down, anyway. I
| honestly can't wait.
|
| (... although, hopefully in this new world browsers can run a
| language that isn't based on Javascript and applications can be
| built in a language that isn't based on HTML.)
| meindnoch wrote:
| Thanks, I vomited a bit into my mouth.
| SaintSeiya84 wrote:
| No I don't want that, I want an OS that's an OS and a browser
| that's a browser.
| mschuetz wrote:
| Because browsers are by far the easiest, safest, and fastest
| way to distribute applications. Operating Systems still don't
| have any sort of meaningful sandboxing so downloading and
| executing binaries from any source is out of question. With web
| applications, you can do that. Instantly and uncomplicated.
| This is not going to change anymore, it's just way too useful.
| breck wrote:
| > Apps that you "live in" all day have pressure to become
| everything and do everything.
|
| Thank you. Somehow I had missed that expansion, but this makes
| the quote a lot more helpful.
|
| Perhaps it should be called "Zawinksi's Trap" -- to a
| programmer working on an app all day, the app becomes the
| operating system, leading them to justify expanding the feature
| set, which benefits them. For all other users where the app is
| not the operating system the app becomes more bloated and
| complex.
| overgard wrote:
| 3D apps in browsers can be useful, and WebGL is very limited.
| Rhedox wrote:
| I disagree with almost everything said about Vulkan in that post.
| bicijay wrote:
| Ok... care to explain why?
| iamcornholio wrote:
| I also disagree with some statements about Vulkan API. My two
| cents: > The docs are written in a sort of alien English that
| fosters no understanding-- but it's also written exactly the
| way a hardware implementor would want in order to remove all
| ambiguity about what a function call does. In short, Vulkan
| is not for you. It is a byzantine contract between hardware
| manufacturers and middleware providers, and people like...
| well, me, are just not part of the transaction.
|
| Vulkan is a Standard. It uses standardese language to define
| things. It defines all the relevant concepts like instance,
| physical device, logical device, command pools and buffers,
| etc. (Vulkan is not that different in this regard from other
| standards like C Language Standard, or C++ Language
| Standard).
|
| The Standard also explains how this different concepts relate
| to each other, how GPU and Host interoperate, how memory
| flows, how synchronization works.
|
| For example, it explains that there is a thing called
| instance, then this instance allows you to enumerate physical
| devices and obtain their properties, it explains that such
| devices have queues which can execute work. Then one or more
| physical devices can be used to create a logical device,
| which is a sort of lightweight context object. Then this
| logical device is used for allocating different resources,
| building pipelines, etc.
|
| > Every Vulkan call involves passing in one or two huge
| structures which are themselves a forest of other huge
| structures, and every structure and sub-structure begins with
| a little protocol header explaining what it is and how big it
| is. Before you allocate memory you have to fill out a
| structure to get back a structure that tells you what
| structure you're supposed to structure your memory allocation
| request in....
|
| Vulkan IS cumbersome to write using just C API, yes, but when
| you write actual program you usually wrap this functionality
| in a thin layer, and then suddenly everything becomes a lot
| less cumbersome. For example, you write initialization code
| exactly once, tailored for you specific needs, then wrap it
| in a function.
|
| Construction of all of the pipelines, render passes, command
| buffers, etc. can also be wrapped in much the same way.
|
| For example, construction of buffers and textures requires 3
| steps: 1. creation of buffer/image object; 2. memory
| allocation; 3. binding memory to the object.
|
| This functionality can be trivially wrapped in a function,
| then used many times. Then there are some libs like
| VulkanMemoryAllocator which simplify writing Vulkan even
| more. Memory synchronization is explained in
| https://github.com/KhronosGroup/Vulkan-
| Docs/wiki/Synchroniza...
|
| The thing is, Vulkan requires planning. So if you want to
| write some simple game which displays sprites on the screen,
| then you are better off with something OpenGL-like. But once
| you need an optimized rendering pipeline with HiZ culling,
| minimal CPU-GPU memory transfers, etc., then Vulkan is the
| way to go. You can use newer OpenGL versions for this, but
| the code becomes much like something you would write using
| Vulkan API anyway.
| flohofwoe wrote:
| > Vulkan is a Standard. It uses standardese language to
| define things.
|
| As a counter example, the "D3D Engineering Specs" do the
| same job, but are much more readable:
|
| https://microsoft.github.io/DirectX-Specs/
|
| PS:
|
| > You can use newer OpenGL versions for this, but the code
| becomes much like something you would write using Vulkan
| API anyway.
|
| Ironically, a lot of "modern" Vulkan might end up looking
| like old-school OpenGL again by using this new extension ;)
|
| https://registry.khronos.org/vulkan/specs/1.3-extensions/ma
| n...
| Shugyousha wrote:
| > As a counter example, the "D3D Engineering Specs" do
| the same job, but are much more readable:
|
| DirectX is not a standard so I don't think that makes
| this comparable. Most likely fewer people will have to
| read and implement it.
| mschuetz wrote:
| The issue with Vulkan is that it's so cumbersome, I just
| don't want to use it at all. Tried to switch, but went back
| to OpenGL. There isn't anything in Vulkan that warrants
| that insane amount of overhead.
|
| WebGPU is based on similar modern paradigms but it's an
| actually usable, sane, not overly verbose API. It's a pitty
| that WebGPU is deliberately gutted to make it a 5 year old
| smartphone graphics API because I'd prefer it over Vulkan
| any day.
|
| I'm glad that Vulkan is taking some steps back on render
| passes, pipelines, etc. If they keep removing unnecessary
| entry barriers, I might eventually try the switch again in
| a few years.
| badsectoracula wrote:
| > Vulkan is a Standard. It uses standardese language to
| define things. It defines all the relevant concepts like
| instance, physical device, logical device, command pools
| and buffers, etc.
|
| FWIW i also disagree with the article on that front. I
| wrote a simple demo of Vulkan[0] the day the specs became
| available and was able to learn it (or enough of it to
| write the demo) just by reading the specs themselves - i
| remember finding them very easy to read. However i already
| had graphics programming knowledge using OpenGL for many
| years before that - but it isn't like someone is going to
| learn graphics programming from OpenGL's spec either, there
| is/was the Red Book for that.
|
| That said, i agree that Vulkan itself is cumbersome to
| write - and really why i never bothered with it after
| writing the demo and getting my feet wet with it. IMO...
|
| > Vulkan IS cumbersome to write using just C API, yes, but
| when you write actual program you usually wrap this
| functionality in a thin layer, and then suddenly everything
| becomes a lot less cumbersome. [..] Construction of all of
| the pipelines, render passes, command buffers, etc. can
| also be wrapped in much the same way.
|
| ...having to paper over an API to hide its guts doesn't
| exactly sound good for that API's design. Personally at
| least i never felt i had to paper over OpenGL, or even the
| little (pre-12) Direct3D code i wrote.
|
| [0] https://i.imgur.com/rd8Xk84.gif
| whalesalad wrote:
| does anyone know what tool might have been used to develop this
| image:
| https://staging.cohostcdn.org/attachment/45fea200-d670-4fab-...
| InvisibleUp wrote:
| It looks as if it was simply drawn in Inkscape or a similar
| program.
| flohofwoe wrote:
| > so reportedly Apple just got absolutely everything they asked
| for and WebGPU really looks a lot like Metal
|
| ...tbh, I wish WebGPU would look even more like Metal, because
| the few parts that are not inpired by Metal kinda suck (for
| instance the baked BindGroup objects - which requires to know
| upfront what resource combinations will be needed at draw time,
| or otherwise create and discard BindGroup objects - which are
| actual 'heavy weight' Javascript objects - on the fly).
| thewebcount wrote:
| So much this. Metal is so elegant to use. I've tried reading
| through Vulkan docs and tutorials, and it's so confusing.
|
| Also, this seems like some major revisionist history:
|
| >This leads us to the other problem, the one Vulkan developed
| after the fact. The Apple problem. The theory on Vulkan was it
| would change the balance of power where Microsoft continually
| released a high-quality cutting-edge graphics API and OpenGL
| was the sloppy open-source catch up. Instead, the GPU vendors
| themselves would provide the API, and Vulkan would be the
| universal standard while DirectX would be reduced to a
| platform-specific oddity. But then Apple said no. Apple (who
| had already launched their own thing, Metal) announced not only
| would they never support Vulkan, they would not support OpenGL,
| anymore.
|
| What I remember happening was that Apple was all-in on helping
| Khronos come up with what would eventually become Vulkan, but
| Khronos kept dragging their feet on getting something released.
| Apple finally got fed up and said, "We need something shipping
| and we need it now." So they just went off and did it
| themselves. Direct X 12 seemed like a similar response from
| Microsoft. It always seemed to me that Vulkan had nobody but
| themselves to blame for these other proprietary libraries being
| adopted.
| mikepavone wrote:
| > What I remember happening was that Apple was all-in on
| helping Khronos come up with what would eventually become
| Vulkan, but Khronos kept dragging their feet on getting
| something released. Apple finally got fed up and said, "We
| need something shipping and we need it now." So they just
| went off and did it themselves.
|
| This is not really how it happened. AMD released Mantle back
| in 2013 based off their experience with game console specific
| APIs. From what I remember, AMD expressed some interest in
| Mantle becoming a cross-vendor standard, but were a bit
| wishy-washy early on. GDC 2014 then saw some AMD talks on
| Mantle, the announcement of DirectX 12 from Microsoft and the
| AZDO talk. Apple then announced Metal in June of that year.
| The "Next Generation OpenGL Initiative" kicked off around
| that same time with a public call for participation in
| August. Apple did join the working group at some point
| (they're one of the many companies listed in a slide from the
| announcement presentation), but I don't see any evidence that
| they were ever a major player in the standard.
|
| Now obviously, Vulkan was not an option for Apple in 2014
| when they announced Metal since the project hadn't really
| gotten started yet, but I don't see any evidence that they
| pushed Khronos to get started on a replacement for OpenGL
| earlier either. They were also lagging behind on OpenGL
| support for years before they announced Metal (they stopped
| at 4.1 which was released in 2010) and notably almost none of
| the techniques presented in the AZDO talk worked on Mac OS
| for this reason. I'm sure part of the reason they decided to
| go their own way with Metal is that you can move faster as a
| single company, but I think it would be naive to assume that
| making cross-platform development between iOS and Android
| harder wasn't a factor.
| kllrnohj wrote:
| I think your doing your own revionist history here. The
| rumors are all that Apple is the one that blocked Khronos'
| initial attempts with the "Long Peaks" proposal that was
| supposed to become OpenGL 3.
|
| And while Metal was released in 2014, Apple had already
| stopped updating OpenGL way back in 2010.
|
| Apple is also supposedly engaged in a legal dispute with
| Khronos, which is why they so vehemently rejected SPIR-V in
| webgpu.
|
| Mantle (which is what became Vulkan) also came out before
| Metal did (2013 vs. 2014)
|
| > Direct X 12 seemed like a similar response from Microsoft
|
| That seems like a stretch since nobody ever expected
| Microsoft to do anything aligned with Khronos. They'd been
| doing their own thing for a decade+, why would you think DX12
| was anything different?
| cubefox wrote:
| > What I remember happening was that Apple was all-in on
| helping Khronos come up with what would eventually become
| Vulkan, but Khronos kept dragging their feet on getting
| something released. Apple finally got fed up and said, "We
| need something shipping and we need it now."
|
| Is there any evidence for this?
| shakow wrote:
| > Is there any evidence for this?
|
| Timeline? Metal first came out 2 years before Vulkan.
| kllrnohj wrote:
| How is that evidence that Apple ever tried to engage with
| Khronos on a Metal-like API, though?
|
| Seeing as Apple had already stopped updating OpenGL
| versions about 4 years before the release of Metal, it
| seems more likely that Apple never planned on working
| with Khronos on anything.
| shakow wrote:
| Well, knowing that Apple is member of the Khronos group,
| it would be very surprising that they did not get
| involved with Vulkan.
| kllrnohj wrote:
| Do a search for Apple & Khronos and you'll find a lot
| more examples of spats between them over the last decade
| than anything else. Including an ongoing legal dispute.
|
| You also won't find any hint of involvement from Apple in
| anything Vulkan-related. Or really anything else Khronos-
| related. They've even pulled out of OpenCL - the thing
| that only Apple ever cared about in the first place.
|
| No idea why they are still a member of the group.
| Possibly they just haven't been kicked out yet, possibly
| they still want to retain voting input for _something_
| (like webgl).
| Jasper_ wrote:
| BindGroups should not be that heavyweight, and there's murmors
| of a proposal to recycle BindGroups by updating resources in it
| after the fact.
| SomeHacker44 wrote:
| The article has a humorous history of graphics APIs that I very
| much enjoyed. I did the the Vulkan tutorial for kicks one month
| on Windows (with an nVidia GPU) and it was no joke, super fiddly
| to do things in. I look forward to trying WebGL in anything that
| isn't JavaScript (some language that compiles to WebASM or
| transpiles, I guess).
| javajosh wrote:
| It was interesting...except that it omitted SVG entirely. So
| one should take it with a grain of salt.
| pjc50 wrote:
| It's already god knows how many words long.
| VikingCoder wrote:
| How many game engines run on top of SVG?
|
| How many games target SVG as their graphics pipeline?
|
| How many applications, for that matter?
|
| The comparison to PDF was better than you probably realize.
| PDF is Turing complete, and there have been ray-tracers
| implemented in it.
| cprecioso wrote:
| Not wanting to disregard your pint, but there are
| definitely applications in SVG. The user interface for the
| most famous kitchen "robot" (Thermomix) is done entirely in
| SVG, and they (through open source consultants Igalia) are
| one of the most important contributors to SVG and Canvas
| functionality in WebKit.
|
| https://blogs.igalia.com/nzimmermann/posts/2021-10-29-layer
| -...
| sph wrote:
| > Not wanting to disregard your pint
|
| Please leave my drink alone. :-(
| DonHopkins wrote:
| I think you're confusing PDF with PostScript. The whole
| point of PDF was to remove the Turing completeness from
| PostScript.
|
| PostScript ray tracer:
|
| https://gist.github.com/grkvlt/2651230
| VikingCoder wrote:
| Ahhah, I sit corrected! Thank you.
| javajosh wrote:
| Oh the comparison to PDF was perfect. PDF and Metal have
| the same recent ancestry with postscript.
|
| What ugly prejudices so many people on this thread seem to
| have. And how trivial and nonsensical. All I said was she
| should not have omitted svg in her history of graphics apis
| since she's writing an article about _browser graphics_. To
| deny that svg is a part of that, or that people don 't
| program to it... well, I was going to write "ridiculous"
| but the xkcd about people who don't know things comes to
| mind...is it possible you just don't _know_ that so many
| people make things with SVG? In any event, it seems I 've
| touched a nerve that I didn't want to, and I find it ugly,
| and this is my free time, so I'm leaving the convo.
|
| Peace.
| DonHopkins wrote:
| In what sense is Metal descendent from PostScript? The
| comparison is anything but perfect: they're practically
| polar opposites.
|
| Metal isn't a text based programming language like
| PostScript, and it has a completely different graphics
| model.
|
| PostScript isn't pixel oriented, or 3d oriented, and
| Metal doesn't have a stencil/paint graphics model or text
| rendering.
|
| They're totally different things, by totally different
| people and organizations.
|
| Metal uses SPIR-V binary byte code, which is nothing like
| PostScript, a stack based high level polymorphic cross
| between Lisp or Forth, and a descendent of Interpres,
| JaM, and Design System.
|
| As programming languages go, and as imaging models go,
| PostScript and Metal are at completely different ends of
| the spectrum.
|
| SVG, like PDF, is the PostScript stencil/paint imaging
| mode, without the Turing complete programming language,
| but expressed as XML, with some CSS thrown in. And some
| implementation of SVG even let you define event handlers
| in JavaScript, but Metal sure doesn't let you do that.
| And to top it off, SVG is "object oriented" (i.e. a DOM)
| while Metal is "immediate mode" (i.e. an API). They
| couldn't be more different.
|
| Since your facts are wrong, and you're throwing around
| insults like "ugly prejudices" and "trivial and
| nonsensical" and "ridiculous" and "people who don't know
| things" and "I've touched a nerve" and "I find it ugly",
| then it's a good thing that you're "leaving the convo",
| because you haven't contributed anything but
| misinformation and insults.
|
| More about PostScript and its history:
|
| https://news.ycombinator.com/item?id=21968175
| flohofwoe wrote:
| > ...article about browser graphics
|
| Despite the name, WebGPU isn't limited to browsers, I
| think the article sort-of implies that without explicitly
| pointing it out (until late into the article).
|
| Instead WebGPU has a good chance to become the 'missing
| link' standard cross-platform 3D API that sits above
| D3D12, Metal and Vulkan and at the same time is
| relatively straightforward to use for mere mortals.
| pjc50 wrote:
| > it seems I've touched a nerve that I didn't want to,
| and I find it ugly
|
| Well, yes, but you can see how your original comment may
| have been read as dismissive of other people's work?
| DonHopkins wrote:
| Not only that, his comments are factually incorrect,
| while glibly dismissing a well written factually correct
| article as untrustworthy, based on his incorrect
| assumption that his incorrect facts imply her true facts
| are false. "So one should take it with a grain of salt."
| Sheez. How rude.
| dahart wrote:
| > All I said was she should have not omitted SVG in her
| history of graphics APIs since she's writing an article
| about browser graphics. To deny that SVG is a part of
| that
|
| You are continuing to double down on a straw man, which
| is why you're getting all the push-back. The ugliness is
| ugliness you've single-handedly created because this is
| not an article about the history of browser graphics. It
| would have included SVG if that were the case, but it's
| not, and you're making assertions that aren't warranted
| or justified here. This was an article about GPU APIs.
| Canvas was only mentioned briefly off-hand in passing
| twice, and the history of Canvas was not discussed at
| all, nor was the history of browser development. Nobody
| denied that SVG is part of anything, you are projecting
| your off-topic wishes onto a discussion where SVG simply
| does not belong, it's tangential and not relevant to the
| article. It's not relevant here how many people make
| things with SVG.
|
| SVG is great. I wish development for SVG2 hadn't stalled
| out, I would like to see SVG2 become broadly supported,
| there are some new options for dynamic scaling I've
| wanted to use for ten years. That said, this is a
| completely separate topic from the article & thread. You
| could get your SVG fix by submitting an article to HN
| that's actually discussing SVG rather than trying to
| hijack the comment thread on an article about GPUs.
| overgard wrote:
| She omitted it because it's not an API, it's a file
| format. Even if you want to be lax about what you call an
| API, svg was never a competitor in this space. She also
| left out canvas, directdraw, direct2d, gdi, etc, because
| they're just not relevant to any of this.
| VikingCoder wrote:
| [flagged]
| mlatu wrote:
| how is svg connected to opengl?
| dist-epoch wrote:
| SVG is not considered a graphics API, just like PDF isn't.
| javajosh wrote:
| You mean YOU don't consider SVG a graphics API. But it's
| right there in the name, dude.
|
| If the article is going to bring in Canvas, it should bring
| in SVG. SVG shares more with opengl than Canvas does.
| overgard wrote:
| SVG is just a file format though, that I suppose you can
| manipulate in the DOM. By your standard glTF files would
| be an "API" also. Have you written D3D/GL/Vulkan/Metal?
| It's not even remotely similar.
| dist-epoch wrote:
| > SVG shares more with opengl than Canvas does.
|
| SVG is declarative.
|
| Canvas and OpenGL/Vulkan are imperative.
| javajosh wrote:
| These are all tools programmers use to draw to the
| screen. In the browser there are now 3 such tools: svg,
| canvas, and webgpu.
|
| svg's primitives are shapes and you program it with js
| and dom.
|
| canvas primitive is a 2D array of pixels, and you program
| it with js and an api.
|
| webgpu's primitive are pipelines (or whatever) and you
| program it with js and an api.
|
| Maybe you're hung up on using the dom instead of an api.
| But the dom is an api, and it is further specialized by
| svg. Mutating the screen is exactly equivalent to
| mutating the dom within SVG. The mental model is that of
| a persisting scene that you nudge around with changes.
| This, versus the mental model of canvas where shape
| persistence is up to you. My understanding of low-level
| 3d graphics (limited to that of a hobbyist) is that
| driver commands setup a pipeline and then nudge around a
| scene graph in a similar fashion to svg. So it is doubly
| ironic that she would omit it.
| VikingCoder wrote:
| I'm going to give you the same unwarranted snark that you
| gave the author:
|
| "In the browser there are now 3 such tools: svg, canvas,
| and webgpu."
|
| That's wildly incorrect, and anyone should take your
| comments with a huge grain of salt. There are far more
| than 3 drawing tools in the browser.
|
| Why are you excluding CSS? You can draw with it, as well.
| https://codepen.io/matheuswf95/pen/wgRMwW
|
| Why are you excluding Video HTML elements? It's possible
| to pipe directly to them from Javascript.
|
| Why are you excluding drawing in the DOM? Do you hate
| ASCII and ANSI art?
| https://www.crummy.com/software/ansi2html/
|
| Why are you excluding the JS Console? You can draw to
| that. https://dev.to/shriji/game-on-console-log-5cbk
|
| Why are you excluding the HTML Title? Someone made a game
| that you play entirely in the browser's Title?
| https://titlerun.xyz/
|
| Why are you excluding GIF? I can't find it, but I saw
| someone made a remote desktop client that encoded the
| video as a never-ending GIF stream.
|
| Why are you excluding fonts? You can create custom fonts
| and use them to draw all kinds of crazy things.
|
| We draw the line somewhere. I thought the History of
| Graphics APIs in the article was great. Sorry it
| disappointed you. I felt your attack on the author's
| credibility, "[I]t omitted SVG entirely. So one should
| take it with a grain of salt" was pedantic and rude.
| pininja wrote:
| I had a lot of fun clicking through these links. One of
| my favorites to add here is drawing with the Checkbox.
| https://www.bryanbraun.com/checkboxland/
| dist-epoch wrote:
| You can create an HTML table with 1 pixel cells, and use
| the DOM api to change individual cell background colors
| to make it work like a canvas.
|
| Does that mean that HTML tables are a graphics API?
| kvark wrote:
| As often, the guessing about historical reasoning could be all
| over the place. And not just about WebGPU (oh that never ending
| "why not SPIRV?" discussion). Claiming that Vulkan and D3D12 were
| kicked off by a GDC talk about AZDO sounds ridiculous to me.
| These APIs are about explicit control, they allowed to talk to
| the driver more and better, which is the opposite of AZDO
| approach in a way.
|
| Anyway, congratulations to WebGPU release on stable Chrome on
| some of the platforms! Looking forward to see it widely
| available.
| flohofwoe wrote:
| And I always thought AMD was to blame for Vulkan, because they
| couldn't catch up with NVIDIA's OpenGL driver performance ;)
| kllrnohj wrote:
| AMD's Mantle is the direct precursor to Vulkan. AMD donated
| it to Khronos.
| raphlinus wrote:
| I suspect this article may even be underestimating the impact of
| WebGPU. I'll make two observations.
|
| First, for AI and machine learning type workloads, the
| infrastructure situation is a big mess right now unless you buy
| into the Nvidia / CUDA ecosystem. If you're a research, you
| pretty much have to, but increasingly people will just want to
| run models that have already been trained. Fairly soon, WebGPU
| will be an alternative that more or less Just Works, although I
| do expect things to be rough in the early days. There's also a
| performance gap, but I can see it closing.
|
| Second, for compute shaders in general (potentially accelerating
| a large variety of tasks), the barrier to entry falls
| dramatically. That's especially true on web deployments, where
| running your own compute shader costs somewhere around 100 lines
| of code. But it becomes practical on native too, especially Rust
| where you can just pull in a wgpu dependency.
|
| As for text being one of the missing pieces, I'm hoping Vello and
| supporting infrastructure will become one of the things people
| routinely reach for. That'll get you not just text but nice 2D
| vector graphics with fills, strokes, gradients, blend modes, and
| so on. It's not production-ready yet, but I'm excited about the
| roadmap.
|
| [Note: very lightly adapted from a comment at cohost; one
| interesting response was by Tom Forsyth, suggesting I look into
| SYCL]
| chrisjc wrote:
| This is the discussion I hoped to find when clicking on the
| comments.
|
| > Fairly soon, WebGPU will be an alternative...
|
| So while the blog focused on the graphical utility of WebGPU,
| the underlying implementation of WebGPU is currently about the
| way that websites/apps can now interface with the GPU in a more
| direct/advantageous way to render graphics.
|
| But what you're suggesting is that in the future new
| functionality will likely be added to take advantage of your
| GPU in other ways, such as training ML models and then using
| them via an inference engine all powered by your local GPU?
|
| Is the reason you can't accomplish that today bc APIs haven't
| been created or opened up to allow such workloads? Are there
| not lower level APIs available/exposed today in WebGPU that
| would allow developers to begin the design of browser based ML
| frameworks/libraries?
|
| Was it possible to interact with the GPU before WebGPU via Web
| Assembly?
|
| Other than ML and graphics/games (and someone is probably going
| to mention crypto), are there any other potentially novel uses
| for WebGPU?
| raphlinus wrote:
| > ...in the future new functionality will likely be added to
| take advantage of your GPU in other ways, such as training ML
| models and then using them via an inference engine all
| powered by your local GPU?
|
| Yes.
|
| > Is the reason you can't accomplish that today bc APIs
| haven't been created or opened up to allow such workloads?
| Are there not lower level APIs available/exposed today in
| WebGPU that would allow developers to begin the design of
| browser based ML frameworks/libraries?
|
| That is correct, there is no way before WebGPU to access
| compute capability of GPU hardware through the Web. There
| have been some hacks based on WebGL, but those are seriously
| limited. The fragmentation of the existing API space is a
| major reason we haven't seen as much progress on this.
|
| > Was it possible to interact with the GPU before WebGPU via
| Web Assembly?
|
| Only in limited ways through WebGL - no access to workgroup
| shared memory, ability to do random access writes to storage
| buffers, etc.
|
| > Other than ML and graphics/games (and someone is probably
| going to mention crypto), are there any other potentially
| novel uses for WebGPU?
|
| Yes! There is research on doing parallel compilers on GPU
| (Aaron Hsu's co-dfns as well as Voetter's work[1]). There's
| quite a bit of work on implementing Fourier transforms at
| extremely high throughput. Obviously, physics simulations and
| other scientific workloads are a good fit. To me, it feels
| like things are wide open.
|
| [1]: https://dl.acm.org/doi/pdf/10.1145/3528416.3530249
| ianpurton wrote:
| > GPU in other ways, such as training ML models and then
| using them via an inference engine all powered by your local
| GPU?
|
| Have a look at wonnix https://github.com/webonnx/wonnx
|
| A WebGPU-accelerated ONNX inference run-time written 100% in
| Rust, ready for native and the web
| flohofwoe wrote:
| > Was it possible to interact with the GPU before WebGPU via
| Web Assembly?
|
| Only with tons of restrictions by going through WebGL, or by
| writing your own or extending an existing WASM runtime
| outside the browser which connects to system-native GPU APIs
| like D3D12, Vulkan or Metal.
|
| > are there any other potentially novel uses for WebGPU
|
| In general, the only thing that WebGPU has over calling into
| D3D12, Vulkan or Metal directly is that it provides a common
| subset of those 3 APIs (so you don't need to write 2 or 3
| implementations to cover all popular operating systems) and
| it's easier to use (at least compared to D3D12 and Vulkan).
|
| WebGPU is an important step into the right direction, but not
| a 'game changer' per se (at least outside the browser).
| tikkun wrote:
| Could someone explain what kinds of useful things will become
| possible with it?
|
| I don't get it yet, but HN seems excited about it, so I'd like
| to understand it.
|
| What I get so far - running models that can be run on consumer
| sized GPUs will become easier, because users won't need to
| download a desktop app to do so. This is limited for now by the
| lack of useful models that can be run on consumer GPUs, but
| we'll get smaller models in the future. And it'll be easier to
| make visualizations, games, and VR apps in the browser. Is that
| right and what other popular use cases where people currently
| have to resort to WebGL or building a desktop app will get
| easier that I'm missing?
| p0nce wrote:
| HN was similarly excited about Vulkan, but this is newer.
| sebzim4500 wrote:
| This fixes the main problem with Vulkan, which is that
| there were no big tech companies pushing them. WebGPU has
| Apple, Google and Microsoft all committing to support it in
| their browser/OS.
| kllrnohj wrote:
| Not quite. The main problem with Vulkan is, as the blog
| post goes into, one of _usability_. Vulkan isn 't
| designed for end developers to use, it's designed for
| middleware vendors to use. Vulkan is already being pushed
| by many major big tech companies include Google, Nvidia,
| AMD, etc... It's really _only_ Apple that 's a problem
| here.
|
| WebGPU is basically a middleware for those that just want
| to use graphics, not all of unity, unreal, etc...
| connicpu wrote:
| The Vulkan situation on Apple is incredibly funny,
| especially once you look at the landscape of gaming.
| There's games out there (I believe Final Fantasy XIV is
| like this) where the official Mac client runs in wine,
| using a DirectX -> Vulkan translation layer, on top of a
| Vulkan -> Metal translation layer.
| tormeh wrote:
| > because users won't need to download a desktop app to do so
|
| Not only that, WebGPU is OS and hardware neutral. It'll work
| regardless of what machine you have. Currently it's Nvidia or
| get lost.
| Conscat wrote:
| If this is something users actually care about, wouldn't
| Vulkan AI be a big deal? It has way more features for AI
| than WebGPU will likely ever have, and it's widely
| available today.
| sebzim4500 wrote:
| It's not so much that people want to run the models in the
| browser. They want to be able to write and publish one
| desktop app that e.g. runs a LLaMA quality model and runs
| decently across the hundreds of different GPUs that exist on
| their users' machines.
| tikkun wrote:
| So it's more of a CUDA alternative for building desktop
| apps that are GPU powered?
| dm33tri wrote:
| Nowhere near CUDA. Maybe OpenCL and Metal replacement
| because nobody bothers to support them, so just a
| fallback option for AMD and ARM chips.
| tikkun wrote:
| So then:
|
| If your app needs CUDA, you'd need to write it in CUDA.
|
| If you don't need CUDA, you'd write it for WebGPU
| instead?
|
| If you benefit from CUDA but don't strictly require it,
| then you can write it in CUDA with a WebGPU fallback.
|
| Is that right?
| [deleted]
| dwheeler wrote:
| I haven't tried it myself, but it looks like several are
| already looking at implementing machine learning with WebGPU,
| and that this _is_ one of the goals of WebGPU. Some info I
| found:
|
| * "WebGPU powered machine learning in the browser with Apache
| TVM" - https://octoml.ai/blog/webgpu-powered-machine-learning-
| in-th...
|
| * "Fastest DNN Execution Framework on Web Browser" https://mil-
| tokyo.github.io/webdnn/
|
| * "Google builds WebGPU into Chrome to speed up rendering and
| AI tasks" https://siliconangle.com/2023/04/07/google-builds-
| webgpu-chr...
| why_only_15 wrote:
| WebGPU has no equivalent to tensor cores to my understanding;
| are there plans to add something like this? Or would this be
| "implementation sees matmul-like code; replaces with tensor
| core instruction". For optimal performance, my understanding is
| that you need tight control of e.g. shared memory as well -- is
| that possible with WebGPU?
|
| On NVIDIA GPUs, flops without tensor cores are ~1/10th flops
| with tensor cores, so this is a pretty big deal for inference
| and definitely for training.
| raphlinus wrote:
| Shared memory, yes, with the goodies: atomics and barriers.
| We rely on that heavily in Vello, so we've pushed very hard
| on it. For example, WebGPU introduces the
| "workgroupUniformLoad" built-in, which lets you broadcast a
| value to all threads in the workgroup while not introducing
| potential unsafety.
|
| Tensor cores: I can't say there are _plans_ to add it, but it
| 's certainly something I would like to see. You need
| subgroups in place first, and there's been quite a bit of
| discussion[1] on that as a likely extension post-1.0.
|
| [1]: https://github.com/gpuweb/gpuweb/issues/3950
| Gordonjcp wrote:
| > unless you buy into the Nvidia / CUDA ecosystem
|
| Coming at it from a graphics processing perspective, working on
| a lot of video editing, it's annoying that just as GPUs start
| to become affordable as people turn their back on cryptobro
| idiocy and stop chasing the Dunning-Krugerrand, they've started
| to get expensive again because people want hardware-accelerated
| Eliza chatbots.
|
| Anyway your choices for GPU computing are OpenCL and CUDA.
|
| If you write your project in CUDA, you'll wish you'd used
| OpenCL.
|
| If you write your project in OpenCL, you'll wish you'd used
| CUDA.
| singhrac wrote:
| I've never once regretted my decision to write GPU code in
| CUDA... I mean, I wish there were alternatives because being
| locked into Nvidia isn't fun, but CUDA is a great developer
| experience.
| garbagecoder wrote:
| >the Dunning-Krugerrand
|
| Stolen. Genius. You made my day.
| Gordonjcp wrote:
| I stole it from someone else first, and I'm sorry to say I
| can't remember who.
|
| Credit where it's due, though, it's an awesome term.
| fanf2 wrote:
| I think I first heard it from @cstross
| cmovq wrote:
| > In fact it is so good I think it will replace Vulkan
|
| WebGPU does not support bindless resources making it a non
| starter as a Vulkan or D3D12 replacement.
| cyber_kinetist wrote:
| And it doesn't support ray tracing either!
| rezmason wrote:
| Thanks for writing this article! I am super excited about WebGPU.
| One not-so-fancy prospect worth commenting about on HN, though,
| is replacing Electron.
|
| With WASM-focused initiatives to create hardware accelerated UI
| in the browser, we may soon see a toolchain that deploys to a
| WebGPU canvas and WASM in the browser, deploys native code linked
| to WGPU outside the browser, and gives the industry a roadmap to
| Electron-style app development without the Chromium overhead.
| danShumway wrote:
| This is also my fear, but... I don't know, I think the
| potential outweighs the risks.
|
| In some ways the problem with everyone trying to render to
| canvases and skip the DOM starts from education and a lack of
| native equivalents to the DOM that really genuinely showcase
| the strengths beyond having a similar API. I think developers
| come into the web and they have a particular mindset about
| graphics that pushes them away from "there should be a
| universal semantic layer that I talk to and also other things
| might talk to it", and instead the mindset is "I just want to
| put very specific pixels on the screen, and people shouldn't be
| using my application on weird screen configurations or with
| random extensions/customizations anyway."
|
| And I vaguely think that's something that needs to be solved
| more by just educating developers. It'll be a problem until
| something happens and native platforms either get support for a
| universal semantic application layer that's accessible to the
| user and developers start seeing the benefits of that, or... I
| don't know. That's maybe a long conversation. But there has to
| be a shift, I don't think it's feasible to just hold off on GPU
| features. At some point native developers need to figure out
| _why_ the DOM matters or we 'll just keep on having this
| debate.
|
| People wanting to write code that runs on both native and the
| web is good, it's a reasonable instinct. Electron-style app
| development isn't a bad goal. It's just how those apps get
| developed and what parts of the web get thrown out because
| developers aren't considering them to be important.
| syntheweave wrote:
| When it comes down to it, I think most of our issue is that
| the technical details still matter enough that we can't
| afford to provide a universal human interface layer...and
| when that falls on the app developer, either they compromise
| the app or they compromise the user, because nobody is
| capable of filling in every rough edge and _also_ doing the
| thing they set out to do in that moment. If they actually set
| out to create a fix, that quickly turns into their career.
|
| A lot of the "web frontend churn" meme is derived from the
| quest for a slightly better compromise - which has produced
| some results if what you are building resembles a web page.
| But over and over, native devs will say, "no, I want the
| hardware access. This layer still doesn't address my use
| case." That's been true of anything deeply I/O related on the
| Web - graphics, audio, input. Things where you can't make a
| simplifying assumption if you actually start covering all use
| cases.
| croes wrote:
| You will always have the overhead otherwise you need to check
| with every browser update if something got broken.
|
| Same problem with WebView
| crazygringo wrote:
| The only possible application I can imagine for that would be
| videogames, though.
|
| Because HTML+CSS+JS provides a fantastic cross-platform UI
| toolkit that everybody knows how to use.
|
| Videogames create their own UI in order to have lots of shiny
| effects and a crazy immersive audio-filled controller-driven
| experience... but non-videogames don't need or want that.
|
| Heck, I'm actually expecting the opposite -- for the entire OS
| interface to become based on Chromium HTML+CSS+JS, and
| eventually Electron apps don't bundle a runtime, because
| they're just apps. My Synology DSM is an entire operating
| system whose user interface runs in the browser and it just...
| makes sense.
| uoaei wrote:
| What is holding back a UI framework for WebGPU? It won't have
| HTML but couldn't you just simulate a scaffold inside the
| WebGPU canvas?
| iainmerrick wrote:
| For most applications you'll want to do things like render
| text nicely, select text, copy and paste text, right-click
| to inspect, boost font sizes and change colors for
| accessibility, auto-translate to other languages.
|
| A lot of it is about text, I guess!
|
| Once you've re-implemented all that in a canvas, you've
| more or less built another web browser, so why not just use
| HTML?
| mtrower wrote:
| Alright guys, hear me out...
|
| Let's build a browser inside of virtual assembly code
| that runs in a browser that runs on an OS that runs on
| real assembly code (sort of). We could run that on a
| physical processor, or in a VM (hey, maybe we could run
| that VM inside a browser that runs on...)
| uoaei wrote:
| Presumably the argument in this thread is that lugging
| around an Electron app just for HTML is overkill if you
| could put the same functionality in a much smaller
| package.
| rezmason wrote:
| Also, we may be able to create those packages from parts
| of browsers, which wouldn't be a re-implementation, and
| would benefit from the rigor of the standards.
|
| I agree that it would be kind of silly to then put this
| in the browser. Instead, I think it could be used to
| build the native target.
|
| And just to clarify my earlier statement, I'm not a fan
| of phasing out the use of the DOM in the browser-- it has
| graceful degradation and accessibility features that are
| really important. It's more that there are people with
| existing Qt or JavaFX or Cocoa dependent projects, or
| whatever, who are now able to deploy to the web by
| implementing the UI layers in WASM/WebGPU.
| [deleted]
| crazygringo wrote:
| Why would you duplicate the massive amount of helpful
| functionality and styling HTML+CSS already provides? What's
| the point?
|
| It's one thing to build panels and buttons for a video
| game. It's a totally different beast to build a text layout
| and editing and selection engine, accessibility and screen
| reader compatibility, clipboard support, date pickers and
| file dialogs, and ten thousand other things.
| et1337 wrote:
| Even in the current HTML + CSS world, everyone writes
| their own date picker, file dialog, combo menu, etc. in
| React. It's no longer acceptable to use built-in browser
| controls.
| jacquesm wrote:
| CAD stuff could take advantage of this too.
| BlueTemplar wrote:
| At the end you pointed out the issue : the browser is good at
| displaying documents, but a program wants to run in the OS
| directly, and trying to make the browser an OS inside the OS
| only makes sense if you are Google and are trying to wrestle
| with Microsoft for the control of the OS that the average
| user is exposed to.
| jamesgeck0 wrote:
| > Videogames create their own UI in order to have lots of
| shiny effects and a crazy immersive audio-filled controller-
| driven experience... but non-videogames don't need or want
| that.
|
| Because UI is such a pain, it's actually not uncommon for
| browser-based games to use HTML/CSS to handle their menus and
| HUD elements.
| udbhavs wrote:
| I wonder if application frameworks like Flutter will move to
| WebGPU? I imagine it shouldn't be that hard to get Skia running
| on a wgpu backend. The current web target generates a lot of
| markup that isn't really semantic or representative of a web
| app's structure with lots of canvases anyway, so I imagine
| moving to a uniform render target will make things smoother.
| They're already experimenting with Dart in WASM instead of
| transpiling to JS as well.
| danShumway wrote:
| I love the level of detail in this post, really helpful for
| filling in a lot of the gaps in my knowledge about the history
| and motivations at play. This is exactly the kind of post I love
| to see on HN.
|
| I haven't played with WebGPU much ( _cough_ Linux support _cough_
| ) but I'm looking forward to it. And I generally agree that even
| more than the API itself, having GPU code that's easily portable
| between the web and native languages is a pretty big deal to me.
| Netcob wrote:
| This was great for catching up!
|
| I stopped doing graphics programming somewhere between OpenCL and
| Vulkan being released and always wondered what had happened -
| especially along with the sentiments in the industry since that's
| difficult to glean from an wikipedia article.
| karussell wrote:
| _> WebGPU goes live... today, actually. Chrome 113 shipped in the
| final minutes of me finishing this post_
|
| Note that WebGPU in Chrome is not yet available for Linux.
|
| Firefox Nightly has some partial support for Linux so that the
| first two of these examples work for me:
| https://webkit.org/demos/webgpu/
| dogben wrote:
| It works with --enable-unsafe-webgpu --enable-features=Vulkan
| command line arguments. Not very stable though.
| fafzv wrote:
| I'm on Chrome on Windows and some of those examples work but
| most do not.
| nwoli wrote:
| Sadly it will likely be years and years still until we get to
| broad adoption eg to where even old androids can use it
| kccqzy wrote:
| Chrome is updated separately from the Android OS itself,
| unlike iOS and Safari.
| [deleted]
| lern_too_spel wrote:
| Old Android phones will support WebGPU the day Chrome ships
| WebGPU support for Android. Dawn, Chrome's WebGPU
| implementation, works on Vulkan 1.1, which has been required
| since Android 9.
| AndrewKemendo wrote:
| > In the browser I can already mix Rust and TypeScript, there's
| copious example code for that.
|
| I'd love to see a production architecture and file structure for
| this setup if anyone has a pointer to a GH repo or something
| similar
| lukax wrote:
| You can check out Koofr Vault. The engine is written in Rust
| and the web frontend is written in TypeScript and React.
|
| https://github.com/koofr/vault
| azeemba wrote:
| https://github.com/GraphiteEditor/Graphite
|
| Web based graphics editor where the engine is written in rust.
| I think it uses tauri
| flohofwoe wrote:
| It's not Rust and TS, instead C and JS, but Emscripten has a
| very nice way of integrating C/C++ and JS (you can just embed
| snippets of Javascript inside C/C++ source files), e.g.
| starting at this line, there's a couple of embedded Javascript
| functions which can be called like C functions directly from
| the "C side":
|
| https://github.com/floooh/sokol/blob/4535a3b4be59eb912e77e04...
| winwhiz wrote:
| I like Cloudflare's docs as a good starting place.
| chrisco255 wrote:
| Not a production example, but good "academic" examples are
| found in the Rust & WebAssembly Gitbook:
| https://rustwasm.github.io/docs/book/introduction.html
| Keyframe wrote:
| Unfortunately, I couldn't get it to run on chrome 113 under
| linux. Even after some fiddling and proper VK_ICD_FILENAMES for
| nvidia (3090 RTX) and VK_LAYER_PATH set to explicit.d, it borked
| out on "vkAllocateMemory failed with
| VK_ERROR_OUT_OF_DEVICE_MEMORY" which makes no sense. I thought
| chrome, well google, internally used linux a lot. I guess not in
| this case. State of this seems to be at least few years out then
| on any sort of (wide) adoption rate. I'll come back to it then.
| ianpurton wrote:
| To get an idea where WebGPU is heading a couple of projects worth
| looking at.
|
| - The Bevy game engine, using WebGPU on the backend.
| https://bevyengine.org/
|
| - Wonnx, A WebGPU inference engine for running AI compute on the
| server or in the browser. https://github.com/webonnx/wonnx
| wackget wrote:
| Open this site with uMatrix - blocking cookies, third-party
| content, and XHR requests - and the page simply goes blank after
| about 10 seconds.
|
| Why it needs cookies/XHR to display a page of plain text, I don't
| know, but I left the site.
| Laaas wrote:
| > 12 If I were a cynical, paranoid conspiracy theorist, I would
| float the theory here that Apple at some point decided they
| wanted to leave open the capability to sue the other video card
| developers on the Khronos board, so they are aggressively
| refusing to let their code touch anything that has touched the
| Vulkan patent pool to insulate themselves from counter-suits. Or
| that is what I would say if I were a cynical, paranoid conspiracy
| theorist. Hypothetically.
|
| Such a shame that they lobbied against SPIR-V on the web. Textual
| formats are evil.
| flohofwoe wrote:
| The entire web has been built on textual formats though, and
| quite successfully so.
|
| Even without Apple in the way, SPIRV as it is wouldn't have
| been usable for WebGPU:
| http://kvark.github.io/spirv/2021/05/01/spirv-horrors.html
| jitl wrote:
| WASM is very much binary-first, and quite popular.
| ladberg wrote:
| Unfortunately WASM is not popular in the slightest outside
| of the HN community. Less than 1% of websites use it, and
| those that do often use it for malicious purposes.
| DonHopkins wrote:
| [flagged]
| ladberg wrote:
| Please source where on Wikipedia it says >1% of websites
| use WASM.
|
| I don't really know what the most trusted / canonical
| sources would be on this topic, but the first few results
| from Google all suggest <1% of websites use it:
|
| https://w3techs.com/technologies/details/cp-webassembly
|
| https://almanac.httparchive.org/en/2022/webassembly
|
| https://www.zdnet.com/article/half-of-the-websites-using-
| web...
| Jasper_ wrote:
| eh, I think the game is given away when kvark self-admits in
| that post that he's never written a compiler before, or done
| parsing before.
|
| Yes, SPIR-V is weird and confusing... if you've never worked
| on a compiler. A lot of it is relatively standard if you
| have. Some of the messy control flow stuff got pretty
| massively cleaned up by the POPL paper. [0]
|
| The issue is that Naga wants to support SPIR-V, but doesn't
| want to grow to become a full compiler. e.g.
|
| > When writing SPIR-V, you can't have two integer types of
| the same width.
|
| This makes compilers much easier as now you can guarantee
| that all types are uniquely comparable by index. Just shove
| the type in an array, done.
|
| > However, it can also declare an output "interface struct"
| with a bunch of special built-ins and an empty name...
| Perhaps, it's a mechanism that helps with tessellation
| shaders. But for us in Naga land that caused more trouble
| than good.
|
| No clue why you would care, unless you just blindly broadcast
| names when translating from SPIR-V. But also, don't do that?
| It's fine for things to have no names.
|
| > Later I was pointed to the fact that all the existing
| production tools for generating SPIR-V (namely, glslang and
| dxc) only do so for a concrete entry point. So the multiple
| entry points is there in spirit, but discriminated in
| practice by the driver bugs, as well as this little
| validation rule.
|
| Yeah, this is unfortunate. Multiple entry points are one of
| those things that make it seem easy to write a translator.
| Unfortunately, they're under-tested, not in the CTS, as
| glslang/DXC don't support them, and aren't how most shader
| pipelines tend to work.
|
| Anyway, I don't want to enumerate all of this. SPIR-V has
| issues, sure, but it can be simultaneously true that SPIR-V
| isn't flawless, while also being true that it's the _best_
| version of this that anyone 's seen yet.
|
| [0] https://www.doc.ic.ac.uk/~afd/homepages/papers/pdfs/2023/
| POP...
| Laaas wrote:
| I wonder whether you could have used a slightly modified
| WebAssembly instead.
| flohofwoe wrote:
| That wouldn't have been all that different from WGSL
| though, the most important thing is that whatever WebGPU
| uses for its shaders can be translated to and from SPRIV
| (e.g. via https://dawn.googlesource.com/tint and
| https://github.com/gfx-rs/naga).
| edflsafoiewq wrote:
| Textual formats are great. You can build shaders by pasting
| strings together and using #define and #ifdef.
| dist-epoch wrote:
| Are there any compute/memory resource quotas?
|
| It's quite easy to almost lock up a computer by doing high
| intensity GPU work.
| jsheard wrote:
| It's the usual story with web APIs, the implementation probably
| has resource quotas to keep applications from accidentally or
| deliberately doing denial of service, but you the developer
| targeting that implementation aren't allowed to know what the
| quotas are. You just have to make an educated guess at how much
| you can get away with and hope for the best. WebAssembly has a
| similar issue where consuming too much memory will get your app
| killed, but there's no reliable way to know how much is "too
| much" until it's too late to recover.
| codedokode wrote:
| Based on previous experience I assume there are no quotas and
| the webpage can hang your system. I had Google Street View
| hang a whole Linux system by using too much memory and
| Firefox did nothing to prevent this.
| BlueTemplar wrote:
| What if you are using it in a native app rather than a
| browser/Electron ?
| ben-schaaf wrote:
| There are _some_ limits you can query from the adapter:
| https://developer.mozilla.org/en-
| US/docs/Web/API/GPUSupporte...
| jsheard wrote:
| Those limits only tell you how big each individual GPU
| allocation can be, not how much you can allocate _total_
| before the browser puts a bullet in your context.
| hkwerf wrote:
| That's probably already possible with just a huge HTML page? At
| least on my system, if I create such a page and open it via a
| file:// URL, firefox will happily gobble up memory.
| hkwerf wrote:
| Uhhh... and at some point it segfaults if I try to load 5 GB
| of HTML?
|
| [ 7527.750745] HTML5 Parser[14186]: segfault at 0 ip
| 0000556be8b79cef sp 00007fbdb1570420 error 6 in
| firefox[556be8b77000+9c000]
| SpaghettiCthulu wrote:
| That's definitely a bug. Have you reported it?
| develatio wrote:
| This is the case with AWS's Go SDK for EC2:
| https://docs.aws.amazon.com/sdk-for-go/api/service/ec2/
|
| No matter what PC I use, I can't open that website...
| heinrich5991 wrote:
| Firefox seems to fare okay on that website. Chrome usually
| struggles more with huge websites IME.
| BlueTemplar wrote:
| It opened (after a while) on mobile Firefox on a Galaxy
| S7...
| satao wrote:
| holy crap this document is awful, crashed my browser
| pjmlp wrote:
| FF on Windows 11, no problem.
| jeroenhd wrote:
| I don't know who would make such a monstrous HTML page UT
| I'm pleasantly surprised that once it loaded my phone can
| interact with it just fine.
|
| Someone should probably tell Amazon that hyperlinks allow
| linking to other HTML documents, though, because that's a
| ridiculously long page.
| red_trumpet wrote:
| Works nicely on my Firefox (Kubuntu 22.04), but Chromium is
| troubled. Doesn't scroll smoothly...
| SpaghettiCthulu wrote:
| Works perfectly fine on Firefox for Android. I'm able to
| scroll and view everything even before the styling has
| finished loading.
| mrguyorama wrote:
| Firefox on a garbage macbook: Site loads in a few seconds
| and causes no problems. It's just a bunch of text and
| hyperlinks, why would that be a problem?
| 123pie123 wrote:
| My PC hangs for some time as well
|
| I thought FF should not allow that to happen?
| scsteps wrote:
| If the browser ever becomes a popular platform for mainstream
| games then I suspect the quality of web applications will also
| boom just because of all the talent pouring into the browser as a
| platform.
| kvark wrote:
| Related - this was published exactly 3 years ago on a similar
| topic:
|
| http://kvark.github.io/web/gpu/native/2020/05/03/point-of-we...
| Animats wrote:
| Yes. Kvark pushed WGPU as a cross-platform graphics base for
| Rust, and that worked out quite well.
|
| It's actually better in an application than in the browser. In
| an application, you get to use real threads and utilize the
| computer's full resources, both CPUs and GPUs. In browsers, the
| Main Thread is special, you usually can't have threads at
| different priorities, there's much resource limiting, and the
| Javascript callback mindset gets in the way.
|
| Here's video from my metaverse viewer, which uses WGPU.[1] This
| seems to be, much to my surprise, the most photo-realistic
| game-type 3D graphics application yet written in Rust.
|
| The stack for that is Egui (for 2D menus), Rend3 (for a
| lightweight scene graph and memory management), WGPU (as
| discussed above), Winit (cross-platform window event
| management), and Vulkan. Runs on both Linux and Windows. Should
| work on MacOS, but hasn't been debugged there. Android has a
| browser-like thread model, so, although WGPU supports those
| targets, this program won't work on Android or WASM. All this
| is in Rust.
|
| It's been a painful two year experience getting that stack to
| work. It suffers from the usual open source problem -
| everything is stuck at version 0.x, sort of working, and no
| longer exciting to work on. The APIs at each level are not
| stable, and so the versions of everything have to be carefully
| matched. When someone changes one level, the other levels have
| to adapt, which takes time. Here's a more detailed discussion
| of the problems.[2] The right stuff is there, but it does not
| Just Work yet. Which is why we're not seeing AAA game titles
| written in Rust. You can't bet a project with a deadline on
| this stack yet. As you can see from the video, it does do a
| nice job.
|
| It's encouraging that WGPU is seen as a long-term solution,
| because it improves the odds of that work getting completed.
|
| Still, I was chatting with one of the few people to ship a good
| 3D game (a yacht racing simulator) in Rust, and he admits that
| he simply used "good old DX11".
|
| [1] https://video.hardlimit.com/w/tp9mLAQoHaFR32YAVKVDrz
| (That's on PeerTube. I'm curious to see how it copes with an
| HN-sized load. PeerTube is supposed to scale automatically.)
|
| [2]
| https://www.reddit.com/r/rust_gamedev/comments/1302512/reall...
| photochemsyn wrote:
| So how does OpenVG fit into this picture?
|
| https://www.khronos.org/openvg/
| formerly_proven wrote:
| It doesn't
| npteljes wrote:
| >a lot of the Linux devices I've been checking out don't support
| Vulkan even now after it's been out seven years. So really the
| only platform where Vulkan runs natively is Android
|
| I got really curious about this. To my understanding, I have been
| using Vulkan on my Linux desktop computers for quite some time
| now. What Linux devices could the author mean?
| sp332 wrote:
| In context, I don't think "many" means "most". You need a GPU
| from Nvidia or AMD, or an Intel platform at least as new as
| Ivybridge. That covers a lot of devices, but there are also a
| lot that it leaves out.
| codedokode wrote:
| I believe main use of WebGPU, as well as WebGL will be
| fingerprinting therefore they should be put behing a permission.
| It is ridiculous that browser developers do nothing to reduce API
| surface usable for fingerprinting and instead just extend it.
| nwoli wrote:
| People keep saying "webgpu will just be used for
| fingerprinting" here on HN as a meme constantly but it's
| clearly not the case. There's obvious use cases not involving
| finger printing for webgl, and webgpu has tons of convenience
| functions that makes it superior to webgl to make things nearly
| impossible otherwise (eg atomics to name just one)
| overgard wrote:
| Kinda doubt it's that great for fingerprinting. Look at
| something like WebGL report and any semi-modern system will
| support everything. "Computer was made in the last 10 years"
| isn't that useful. Even knowing the exact GPU... we're talking
| maybe 5 major vendors? Seems like if you really care for
| anonymity you need a vpn and a special browser at this point
| anyway.
| chrisjc wrote:
| While I don't disagree with the essence of what you're
| concerned about, I imagine that every new step/functionality in
| the browser evolution introduces new minutiae that can be used
| in fingerprinting.
|
| Also, once/if the WebGPU interface expands into more direct GPU
| functionality, I imagine there will many that will try to use
| your GPU for crypto mining/etc.
|
| But surely a permission option/prompt will eventually be
| introduced, but probably not by google in chrome. Anyone know
| the roadmap/timeline for WebGPU on Firefox and other browsers?
| codedokode wrote:
| > I imagine that every new step/functionality in the browser
| evolution introduces new minutiae that can be used in
| fingerprinting.
|
| No problem; just put such APIs behind a permission and they
| become unusable for fingerprinting.
| PoignardAzur wrote:
| If you do that too much, you just train users to enable all
| permissions all the time without thinking.
___________________________________________________________________
(page generated 2023-05-03 23:00 UTC)