Subject: General Tech | February 9, 2017 - 03:46 AM | Scott Michaud
Tagged: webkit, webgpu, metal, vulkan, webgl
Apple’s WebKit team has just announced their proposal for WebGPU, which competes with WebGL to provide graphics and GPU compute to websites. Being from Apple, it is based on the Metal API, so it has a lot of potential, especially as a Web graphics API.
Okay, so I have mixed feelings about this announcement.
First, and most concerning, is that Apple has attempted to legally block open standards in the past. For instance, when The Khronos Group created WebCL based on OpenCL, which Apple owns the trademark and several patents to, Apple shut the door on extending their licensing agreement to the new standard. If the W3C considers Apple’s proposal, they should be really careful about what legal control they allow Apple to retain.
From a functionality standpoint, this is very interesting, though. With the aforementioned death of WebCL, as well as the sluggish progress of WebGL Compute Shaders, there’s a lot of room to use one (or more) GPUs in a system for high-end compute tasks. Even if you are not interested in gaming on a web browser, although many people are, especially if you count the market that Adobe Flash dominated for the last ten years, you might want to GPU-accelerate photo and video tasks. Having an API that allows for this would be very helpful going forward, although, as stated, others are working on it, like The Khronos Group with WebGL compute shaders. On the other-other hand, an API that allows explicit multi-GPU would be even more interesting.
Further, it sounds like they’re even intending to ingest byte-code, like what DirectX 12 and Vulkan are doing with DXIL and SPIR-V, respectively, but it currently accepts shader code as a string and compiles it in the driver. This is interesting from a security standpoint, because it obfuscates what GPU-executed code consists of, but that’s up to the graphics and browser vendors to figure out... for now.
So when will we see it? No idea! There’s an experimental WebKit patch, which requires the Metal API, and an API proposal... a couple blog posts... a tweet or two... and that’s about it.
So what do you think? Does the API sound interesting? Does Apple’s involvement scare you? Or does getting scared about Apple’s involvement annoy you? Comment away! : D
Subject: General Tech | January 27, 2017 - 08:55 PM | Scott Michaud
Tagged: webgl, webgl2, firefox, chrome, google, mozilla, Opera
After quite a bit of anticipation, both Mozilla and Google have just shipped compatible implementations of WebGL 2. This feature was unlocked to the public in Firefox 51 and Chrome 56 for the desktop, both released this week, while Opera will push it out to desktop and mobile on their next version, Opera 43. Microsoft currently has the API “under consideration” for Edge.
As we’ve highlighted in the past, this new version of the graphics API pushes the platform up to OpenGL ES 3.0, with a few exceptions that are typically made for security reasons. This update allows quite a few new features like off-screen render targets, which is useful for deferred rendering. The shading language is also significantly larger, and can now operate natively on integer types and 3D textures.
WebGL 2.0 does not include compute shaders, however, which is a bit unfortunate. That said, it is (at least last I checked) a highly-requested feature and the browser vendors are interested in providing it.
Subject: General Tech | June 10, 2016 - 05:50 AM | Scott Michaud
Tagged: Basemark, webgl, webgl2
Basemark has just released Basemark Web 3.0, which includes WebGL 2.0 tests for supporting browsers. No browsers support the standard by default yet, although it can be enabled on Firefox and Chrome with a command-line flag.
WebGL 1.0 has become ubiquitous, but it is based on quite an old version of OpenGL. OpenGL ES 2.0 was specified all the way back in March 2007. While it simplified development by forcing everyone down a programmable shader pipeline, it has quite a few limitations. OpenGL ES 3.0 remedied many of these, such as allowing multiple render targets and texture compression. OpenGL ES 3.1 added compute shaders, which brings us pretty much to today. In fact, Vulkan targets OpenGL ES 3.1 hardware (should the hardware vendor provide a driver).
WebGL targeted OpenGL ES 2.0. WebGL 2 targets OpenGL ES 3.0.
Of course, this means that the WebGL 2.0 base standard does not support compute shaders, which is a bit of a drag. It's something that they really want to incorporate, though, but they still can't seem to decide whether it will align with a new version of WebGL (such as WebGL 2.1) or be incorporated in a multi-vendor extension.
So where are we today?
Well, WebGL 2.0 is still a little ways off from being everywhere. As we mentioned, only Firefox and Chrome support the standard, although WebKit is working on it, too. Microsoft has WebGL 2.0 listed as “Under Consideration” with a “Roadmap Priority” of Medium, “Development is likely for a future release.” One major hold up was its shader support. Again, OpenGL ES 3.0 shaders are much more complex than OpenGL ES 2.0 ones, and many WebGL browsers convert OpenGL ES 2.0 shaders to HLSL for DirectX on Windows. This circumvents lackluster graphics drivers, and it adds an extra, huge layer of complexity for someone who wants to write malware. It's not sufficient to know of a driver bug with a specific shader string -- you need to trick the transpiler into outputting it, too.
But, again, we're slowly inching our way there.
Subject: General Tech | June 9, 2016 - 05:42 AM | Scott Michaud
Tagged: webgl, microsoft
This is not an open-source build of Microsoft Edge, though. It doesn't have the project files to actually be built into something useful. Microsoft intends for it to be reference, at least for now they say. If you are interested in using or contributing to this project for some reason, their GitHub readme file asks you to contact them. As for me? I just think it's neat.
Subject: General Tech | April 4, 2016 - 05:30 PM | Scott Michaud
Tagged: zelda, webgl, Nintendo
Before it invariably gets taken offline, you might want to check out a remake of the original Legend of Zelda. It's not just a straight port of the original, though. Its pixel art assets were remade in voxels, which are rendered in WebGL at an angle that's similar to what the original pixel art implies. Original NES controls are overlaid on the screen, which is useful for multi-touch, but keyboard also works.
Most of the game is plugin-free and running in the browser. The only thing that requires plug-in support is audio, and it doesn't play nice with click-to-activate. It would have been nice for them to implement it in WebAudio API, and implement Gamepad API while they're at it, but who am I to criticize a passion project that will likely be challenged by Nintendo in a handful of days?
I'm not sure how complete the game is. They seem to imply that all eight dungeons are available, but I haven't had a chance to check.
Subject: General Tech | January 1, 2016 - 03:25 AM | Scott Michaud
Tagged: webgl2, webgl, mozilla, firefox
The next step is WebGL2. OpenGL ES 3.0 adds a bunch of new features that are sorely needed for modern games and applications. For instance, it allows drawing to multiple render targets, which is very useful for virtual cameras in video games (although the original WebGL software could access this as an optional extension when supported). The addition of “Uniform Buffer Objects” is a better example. This allows you to store a bunch of data, like view transformation matrices, as a single buffer that can be bound to multiple applications, rather than binding them one at a time to every draw that needs them.
It's hard to describe, but demos speak a thousand words.
The news today is that Mozilla Nightly now ships with WebGL2 enabled by default. It was previously hidden, disabled by default, behind an option in the browser. This doesn't seem like a big deal, but one of the largest hurdles to WebGL2 is how the browsers actually implement it. The shading language in WebGL was simple enough that most browsers convert it to DirectX HLSL on Windows. This is said to have the added advantage of obfuscating the ability to write malicious code, since developers never directly writes what's executed. GLSL in OpenGL ES 3.0 is much more difficult. I'm not sure whether the browsers will begin to trust OpenGL ES 3.0 drivers directly, or if they finally updated the GLSL translator, but supported implementations means that something was fixed.
Unfortunately, OpenGL compute shaders are not supported in WebGL2. That said, the biggest hurdle is, again, to get WebGL2 working at all. From my talks with browser vendors over the last year or so, it sounds like features (including compute shaders) should start flying in easily once this hurdle is cleared. From there, GPGPU in a website should be much more straightforward.
Subject: General Tech | December 8, 2015 - 12:30 PM | Scott Michaud
Tagged: webgl, Unity
WebGL is a Web standard that allows issuing OpenGL ES 2.0-based instructions to compatible graphics cards, which is just about everything today. It has programmable vertex and fragment (pixel) shaders with a decent amount of flexibility. Engines like Unity have been looking toward using this technology as a compile target, because Web browsers are ubiquitous, relatively user friendly, and based on standards that anyone could implement should a work of art benefit from preservation.
Image Credit: Mozilla
Until Unity 5.3, this feature was in “preview” levels of support. This upcoming release, scheduled for today according to their roadmap, drops this moniker. It is now a build target with official support.
To run WebGL applications that are built in Unity, the vast majority of features target recent versions of Firefox, Chrome, and Edge for Windows 10 Version 1511. (The November Update for Windows 10 added the ability to lock the mouse cursor, which is obviously useful for mouse and keyboard titles.)
We're still a long way from web browsers being equivalent to game consoles. That said, they are catching up fast. You could easily have an experience that shames the last generation, especially when WebGL 2 lands, and you don't have to worry about what happens in 10, 40, or even hundreds of years as long as society deems your art worthy for preservation. I do hope that some artists and serious developers take real advantage of it, though. Shovelware could obscure its power and confuse users, and we know they will be pretty much first out of the gate.
Subject: General Tech | October 22, 2015 - 01:48 AM | Scott Michaud
Tagged: webgl, tencent, atlas, artillery games
The Chinese investment and Web company, Tencent, has taken interest in many American video game companies. In a couple installments, Tencent purchased chunks of Riot Games, developer of League of Legends, which now total up to over 90% of the game studio. They later grabbed a “minority” (~48%) stake in Epic Games, which creates Unreal Engine, Unreal Tournament, Fortnite, Infinity Blade, the original three Gears of War games, and a few other franchises.
This time, they purchased an undisclosed share of Artillery Games. Artillery has not released a title yet, but they are working on a WebGL-powered engine. In other words, titles created with this technology will run directly in web browsers without plug-ins or extensions. At some point, Artillery Games decided to make a native client alongside their web engine, which was announced in September. This was apparently due to latency introduced in the Pointer Lock API and networking issues until WebRTC matures. (WebRTC brings P2P network sockets to web browsers. While people mentally equate it to video conferencing, it is also used for client-to-client multiplayer. There is even a BitTorrent client that runs in a web browser using it.)
Unfortunately, the real story would be how much of Artillery they have purchased, and we don't know that yet (if ever). They are buying up quite a lot of formerly-independent studios though, considering how many are left.
Subject: General Tech, Graphics Cards | January 17, 2015 - 03:37 AM | Scott Michaud
Tagged: Khronos, opengl, OpenGL ES, webgl, OpenGL Next
The Khornos Group probably wants some advice from graphics developers because they ultimately want to market to them, as the future platform's success depends on their applications. If you develop games or other software (web browsers?) then you can give your feedback. If not, then it's probably best to leave responses to its target demographic.
As for the questions themselves, first and foremost they ask if you are (or were) an active software developer. From there, they ask you to score your opinion on OpenGL, OpenGL ES, and WebGL. They then ask whether you value “Open” or “GL” in the title. They then ask you whether you feel like OpenGL, OpenGL ES, and WebGL are related APIs. They ask how you learn about the Khronos APIs. Finally, they directly ask you for name suggestions and any final commentary.
Now it is time to (metaphorically) read tea leaves. The survey seems written primarily to establish whether developers consider OpenGL, OpenGL ES, and WebGL as related libraries, and to gauge their overall interest in each. If you look at the way OpenGL ES has been developing, it has slowly brought mobile graphics into a subset of desktop GPU features. It is basically an on-ramp to full OpenGL.
We expect that, like Mantle and DirectX 12, the next OpenGL initiative will be designed around efficiently loading massively parallel processors, with a little bit of fixed-function hardware for common tasks, like rasterizing triangles into fragments. The name survey might be implying that the Next Generation OpenGL Initiative is intended to be a unified platform, for high-end, mobile, and even web. Again, modern graphics APIs are based on loading massively parallel processors as directly as possible.
If you are a graphics developer, the Khronos Group is asking for your feedback via their survey.
Subject: General Tech | January 16, 2015 - 07:36 PM | Scott Michaud
Tagged: webgl, pc gaming
gorescript is a first person shooter that runs in a browser through WebGL (via Three.JS). Its developer, Time Invariant Games, has not mentioned a business model, if there is one, but the first three levels, three guns, and two monsters can be instantly played at their GitHub site for free. The source code, including a map editor for levels and a map editor for monsters, weapons, and powerups, is also on their GitHub under an MIT (permissive) license.
From a technical standpoint, it is not the most impressive game that I have played in a browser -- that would be a toss-up between Unreal Tournament 3 (they had a demo at Mozilla Summit 2013) or Dead Trigger 2. In gorescript on Firefox 35, I was getting about 80-110 FPS, although that begun to crawl down to around 20-30 FPS with some dips down to ~10 FPS; it was probably averaging ~45 FPS when all is said and done.
(Note: Especially if you have a high-refresh panel, the maximum frame rate of Firefox can be adjusted in about:config with the layout.frame_rate variable. Mine is set to 120.)
Again, it is free and it should amuse you for a little while. Maybe we can get it to blow up with third-party content? Even as it is, I think it is worth a mention for anyone who wants a Doom/Quake throwback.