12 ms·
WebGL2 Fundamentals
- madez 9y agoSeriously, we are having immense trouble with securing CPU virtualization and now we are talking about GPU virtualization for unreviewed, unaccounted, automatically downloaded and executed code? Stop this madness. Use native code and native APIs like OpenGL or Vulkan.
- dtf 9y agoHow do I run that in my web page?
- madez 9y agoYou don't.
- dtf 9y agoHow do I run it on my computer?
- madez 9y agoBest case is you get the source or binary package from your trusted package manager and run/compile that. If that is not available, and you still really need the result of that piece of code, fetch the code, compile it and run it. Code distribution has inherent dangers and cannot be safely made extremely effortless and comfortable. Accounting can be bothersome, but is necessary for code.
- teraflop 9y agoWhy don't we just put a trusted package manager into the web browser?
- madez 9y agoWe already have one in the system, why duplicate the effort? Also, It is important to keep the number of authorized sources of code to a system small. If you insist on using that horrible language, you can deliver a webapp that runs in a JavaScript runtime through the OS package manager. That ensures proper accounting for the users.
- Klathmon 9y agoSo how will I do all that in seconds on any platform with only a URL that is end-to-end encrypted and gives me multiple runtime options? What happens when the "authorized code source" doesn't agree with my program?
- madez 9y agoIn most distros you don't even need the URL but just the name and get the program in seconds, including signed code that is vetted for by maintainers. Usually you also have many runtime options in the config file, if not in the program itself, but that are details. When your authorized source of code doesn't agree with a program then there is a problem, either with your source or with the program. There are too many parameters to describe all scenarios. For example, if distros refuse to provide a certain program, then you most likely are better off without it, if Apple doesn't let you install a program on your iphone, then you picked the wrong gatekeeper. Apple is a tyrant and puts its interests above yours. If you enter their garden you are on your own and I care very little for the problems there. I'm not saying that code delivery is optimal like it is in the most popular distributions. But the Web is not the solution. Speed is not the only metric.
- Klathmon 9y agoMaybe for you, but I don't want any gatekeeper. I want to decide what is "good for me", I want things fast and on any platform from my phone to laptop to car to TV. Luckily we have choices, and I choose to use the web. You can use a browser that disabled all of this, as long as your gatekeeper allows you to.
- roblabla 9y agoCare to explain how GPU virtualization is somehow worse/harder than CPU virtualization ?
- madez 9y agoI didn't say that. It's more oil to the fire.
- albertgoeswoof 9y agoBrb, turning off all my cpus and gpus, can’t be adding more fuel!
- madez 9y agoYou seem to misunderstand. It's not about not using CPUs or GPUs, but about what code runs on them, and how that code is accounted for. Who vetted for it and who is responsible for it?
- saltcured 9y agoConsidering that GPU architecture and low-level programming is still treated largely as trade secrets and the domain of proprietary blobs, it's hard to argue how virtualization should be trustworthy. When the OS designers get a good spec about the GPU instruction sets, memory architecture, MMU, and IO-MMU, and the OS designers can be the ones in charge of programming these to be consistent with existing OS protections, then we might start to approach an equivalence with CPUs. Then and only then, we can start worrying about subtle, modern risks like errata where the GPU hardware deviates from the idealized spec or where side-channel attacks take the wind out of our sails. Right now, we have something much closer to the GPU being another computer with an opaque and proprietary OS and a higher-level "managed code" runtime that accepts jobs defined in a mystery ISA by a proprietary compiler suite embedded inside the "graphics driver" in our own computer. We have to have blind faith that there is any data protection as well as that there aren't any code-injection flaws that would allow malicious data and "shader" code to hijack the GPU and its bus interface to compromise the host computer.
- verletx64 9y agoLet's not go too far - Meltdown and Spectre is not an excuse to shut everything down. They existed for years before and I'm sure issues will exist for years after.
- madez 9y ago> They existed for years before and I'm sure issues will exist for years after. How is that an argument for more lenient rather than more extreme measures?
- verletx64 9y agoI wasn't arguing for making anything for lenient, I just meant that WebGL is not necessarily suddenly a bad thing just because of Meltdown/Spectre.
- madez 9y agoWe need everything but more attack surface. Do you really think the WebGL runtimes are safe and don't leak data through a side channel, possibly combined with the running JavaScript code? To make matters worse, the hardware is opague, running unknown firmware.
- pcwalton 9y agoGPUs are not vulnerable to Meltdown or Spectre, because they don't do speculation, to my knowledge.
- madez 9y agoFirst, at least the driver of Nvidia is affected in an unspecified manner. [0] Second, the hardware is opague and runs unknown firmware. What lies sill in there? What will in future lie in there? Third, how do these hardware components interact? Do they create vulnerabilities in connection with each other? Maybe side leaks that wouldn't be there otherwise? Fourth, there are arguments for rejecting these Web technologies that are orthogonal to their security. These Web technologies lead to an ecosystem of unreviewed code that is outside of the direct and indirect control of the user, shifting power to the developers, ultimately leading to centralization. [0] http://nvidia.custhelp.com/app/answers/detail/a_id/4611 http://nvidia.custhelp.com/app/answers/detail/a_id/4611
- DiThi 9y agoA side channel attack in WebGL similar to Spectre/Meltdown is probably not possible, simply because you don't know when stuff is going to be rendered and how long it takes. You tell the GPU "do this computation" and if it took too long vsync will take 32 ms instead of 16. Maybe you can get a bit more precision with gl.readPixels but I seriously doubt it. I tried to micro benchmark features and changes and I always get too much noise.
- dang 9y agoPlease don't take HN threads on generic tangents. Unexpected tangents can be excellent, but generic ones are predictable, and the predictable is the enemy of the curious. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- madez 9y agoI get your point.
- Exuma 9y agoThis is really awesome, I will be going through this for sure.
- franciscop 9y agoThe text on the main page is difficult to read with random 3D text on its background.
- kennethkl 9y agoi agree -- couldn't bare trying to read, closed tab immediately.
- transcranial 9y agoSee https://webgl2fundamentals.org/webgl/lessons/webgl2-whats-new.html https://webgl2fundamentals.org/webgl/lessons/webgl2-whats-ne... for an overview of new (well, to WebGL at least) features. Direct texel lookups and the expanded texture formats has been amazing for using WebGL 2 for GPGPU purposes.
- tw1010 9y agoWebGL has been around for quite a while now, but I never see any websites using it. Surely they exist somewhere? What have I been missing? Anyone have a good source of links to things using WebGL?
- mertens 9y agoAlmost all browser games coming out these days. Here's a link with a list if you want to see what they're like: https://www.crazygames.com/t/webgl https://www.crazygames.com/t/webgl It's quite impressive. Try any of Madalin Stunt Cars, Bullet Force, or Truck Driver Crazy Road 2 in fullscreen considering each of them is built by a single developer and be amazed (I am, at least).
- King-Aaron 9y agoI really like the prominent yet still fairly subtle use here: https://panic.com/transmit/ https://panic.com/transmit/
- diimdeep 9y agohttps://threejs.org https://threejs.org
- based2 9y agohttps://github.com/WhitestormJS/whs.js https://github.com/WhitestormJS/whs.js
- bearforcenine 9y agoLucidchart uses WebGL for the canvas in our editor. The menus around the canvas are Angular, but the actual editor is all WebGL. Full disclosure: I work at Lucid.
- jsheard 9y agoGoogle Maps uses WebGL to render the map, even in the 2D view.
- heavenlyblue 9y agoUsing latest Firefox: why is Google Maps so comparably bad (scaling is only in steps when using scrolling, much slower time to load the map) compared to a MapBox mentioned in a neighbouring comment?
- Jyaif 9y agoDoes anybody know what are the penetration numbers for WebGL and WebGL2?
- jsheard 9y agoAccording to webglstats.com, WebGL is at 97% and WebGL2 is at 39%. Unfortunately neither Safari or Edge support WebGL2 by default yet.
- pjmlp 9y agoAnd their support it pretty lame in most mobile devices. It might be supported, but fast is it not. My Asus, LG, Nokia and Samsung devices don't have any hiccups with OpenGL ES 3.x games, however most WebGL demos are janky on them.
- jsheard 9y agoI wonder how much of that performance difference is due to "Three.js vs Unity/Unreal" rather than "WebGL vs Native GLES". AFAIK Three.js is still missing standard optimizations that are taken for granted in a "real" engine, like batching and occlusion culling, and some optimizations it does support are scarcely used due to poor tooling. Pre-baked lighting and compressed textures are technically supported but there's no easy workflow to pre-generate the necessary data.
- debacle 9y agoAre there any other libraries that aren't Unity/Unreal that are better than Three.js?
- jsheard 9y agoI think PlayCanvas is the most robust engine that's built specifically for the web. Only the core runtime is open-source though, to get the full benefit you need to use their proprietary editor and asset pipeline.
- mrspeaker 9y agoThis is really a fantastic resource - it doesn't hide too much away behind "helper" libraries so you understand where everything is coming from. It's the only beginner resource I've found that covers drawing multiple things: that was always my stumbling block with WebGL! When you've exhausted this and are looking for next steps to try, I recommend this youtube series by Sketchpunk Labs: https://www.youtube.com/watch?v=LtFujAtKM5I&list=PLMinhigDWz6emRKVkVIEAaePW7vtIkaIF https://www.youtube.com/watch?v=LtFujAtKM5I&list=PLMinhigDWz...
- davidwparker 9y agoShameless self plug: You should check out my Youtube channel. I have a playlist that I cover Webgl (not 2) https://www.youtube.com/watch?v=oDiSqQT_szo&list=PLPqKsyEGhUnaOdIFLKvdkXAQWD4DoXnFl https://www.youtube.com/watch?v=oDiSqQT_szo&list=PLPqKsyEGhU.... I've done 108 WebGL screencasts, everything is built up slowly over time from scratch (so nothing is hidden away), and covers a lot for beginners to include covering drawing multiple things. Cheers!
- tamriel 9y agoI would actually just recommend diving into THREE.js. It's truly one of the best documented and most "obvious" codebases out there. If all you've got is a solid understanding of JS, you can just start hacking up something nontrivial on THREE.js and you'll come out of it knowing most of WebGL. And in doing so you'll eventually realize that even WebGL itself is quite "high level" -- there is a _huge_ amount of abstraction that you take for granted in the browser.
- wwwtyro 9y ago> you can just start hacking up something nontrivial on THREE.js and you'll come out of it knowing most of WebGL. Sorry, but this is wildly untrue. I don't really know where to begin, but you wouldn't even need to touch shaders to accomplish that, so no, you wouldn't know most of WebGL. THREE.js is very much a thick abstraction over WebGL. > And in doing so you'll eventually realize that even WebGL itself is quite "high level" -- there is a _huge_ amount of abstraction that you take for granted in the browser. Also not accurate. WebGL is a -very- thin wrapper over OpenGL ES, which is itself as low level as you can go without stepping into something like Vulkan. There's almost no abstraction.
- tamriel 9y agoIf you don't need to touch shaders, then you're doing something trivial, like drawing models with a camera. Once you dip your toes into even something like alpha transparency, or z fighting, depth buffer precision, or texture upload hitches, you start to unpack the shader pipeline under the hood. Which THREE.js makes it super easy to do, because it's much more of a broad library than it is a thick one. > Also not accurate. WebGL is a -very- thin wrapper over OpenGL ES Conceptually it seems thin, but it's all a lie. WebGL's most awesome feature is that for simple cases you don't realize how much of a lie this is. In practice, there is shader recompilation, sentinel rewrites and caching, sync fences, format decodes, a full-blown message queue protocol to a render thread, automatic frame flipping and composition, CPU rendering, and the end of the pipe isn't even necessarily OpenGL at all! But I agree it appears very thin until you actually look at what's happening (or are forced to due to leaky abstractions). One of the best resources I've read on this is WebGL Insights: https://github.com/WebGLInsights/WebGLInsights.github.io/releases/download/v1.0/WebGL.Insights.-.Patrick.Cozzi.pdf https://github.com/WebGLInsights/WebGLInsights.github.io/rel...
- typon 9y agoCan someone explain why the API design is such that it takes roughly ~100 lines of code and understanding of many different concepts (buffers, vertex/fragment shaders, uniforms, attributes, etc.) to draw a monochrome triangle on a canvas? I'm not trying to be snarky or say WebGL sucks (I have very little experience with it), I'm just wondering why the design choices have culminated into such an API?
- dahart 9y agoFlexibility and performance are the two driving forces behind the amount of template you need to get something on-screen. All the GPU API designs have gone the same direction. WebGL actually takes less template code than, say, Vulkan or Direct3d. Back when less template code was needed, we had fixed function pipelines that couldn't run shader code, and we were bound by all kinds of assumptions & limits. The APIs basically assumed you were doing perspective projection of textured triangles with Phong shading using point lights, for example. The APIs these days assume far less about what you want to do, and allow far more customization, at the expense of more setup function calls. That said, getting started really is a total nightmare, and there's lots of room for acknowledging that most people only have one of several basic pipelines. There's no reason we couldn't have some easy default setups in addition to all the flexibility. API designers would probably argue that templates are not in their purview, but it sure would be nice if GPU interfaces took a step or two in the ease of use direction.
- pjmlp 9y agoGL is the worst of graphics APIs regarding newbie support. While every other 3D API has support for math, textures, models, shaders, fonts, basic scene graph, GL leaves to the developers to hunt for 3rd party libraries. Khronos tried to change that by creating an SDK page, listing endorsed libraries, but it has not been updated in ages.
- Jasper_ 9y agoBecause this is what a modern programmable pipeline looks like. You can go from that same ~100 lines of code to 80,000 triangles and have it still run well. You need: 1. A way to send opaque data to the GPU (this is a buffer) 2. A way to programmatically transform that data (this is a shader) 3. A way to specify input parameters to those transforms not found in the data (a uniform) 4. A way to decompose that opaque data into tangible (an attribute) With not much more code, you can go from that to something like e.g. http://magcius.github.io/pbrtview/ http://magcius.github.io/pbrtview/ using the same exact primitives. This is an example of a custom WebGL2 engine (not using three.js) in action. Leaf through https://github.com/magcius/pbrtview/blob/gh-pages/src/models.ts https://github.com/magcius/pbrtview/blob/gh-pages/src/models... and you'll still see the same createBuffer, bufferData, drawArrays. There's not much more that I added on top.