WebGL Performance on Safari and Apple Vision Pro

Safari–especially on iOS–has always been considered the pinnacle of performance challenge for developers building on the 3D web. The Metal-based implementation of WebGL, together with the unique performance characteristics of WebKit make it particularly interesting to deal with.

In this article, we give you some insights into how you could improve the performance of your WebGL apps on Safari.

Apple Vision Pro 

In recent days with the launch of the Apple Vision Pro, WebGL performance on Safari has gained even more importance as Apple Vision’s version of Safari has inherited all the performance characteristics of Safari on MacOS and iOS.

We will be posting a full article on WebXR with Apple Vision Pro soon, subscribe to our newsletter to get notified.

Wonderland Engine on Apple Vision Pro 

If you are already using Wonderland Engine, we have good news: all the optimizations we did for our 0.9.0 release translate over to Apple Vision Pro.

Developers with access to the Apple Vision Pro are reporting great performance on their Wonderland Engine based apps:

  • James C. Kane about The Escape Artist and
  • Ayushman Johri - Vintage Study Room .

Optimizing for Safari 

If you are on another framework, make sure to have a look at our WebGL Performance Profiling blog post . That blog post contains tips on how to find the bottlenecks of your application to find out what to optimize.

Additionally, below are some notes on what you might find in Safari while profiling. These are not one-size fits all, profile your application to find out which of these are cause you trouble.

Bottlenecks 

Here are a few more characteristic issues you might encounter when working with WebGL on Safari:

Uniform Buffers 

Because of how Apple’s graphics API Metal differs from WebGL, Safari needs to emulate a WebGL-style uniform buffer under the hood. This emulation incurs some difficulty in predicting the performance of UBOs: some uses will be fine, while others could incur a 150ms hitch when trying to upload data at the wrong moment in time.

This snippet of code from the Metal implementation of Angle (which is used by WebKit to implement the WebGL2 API) points to the implementation of the GLES equivalent to WebGL’s bufferSubData . It helps us appreciate to which lengths browser developers go to provide us with a consistent graphics API. It also shows to which lengths the Wonderland Engine team goes for you to understand browser performance and optimize for you.

There was a lot of dismay around Safari taking a long time to release support for WebGL2. Contrary to speculations that they might never support it, they did release WebGL2 support in September 2021 with Safari 15 . Reading the WebKit and Angle code raises some empathy around why it might not have been an easy task to get done.

WebGL State Access 

WebGL’s getParameter function has some performance surprises in store for you. What seems like a harmless function can cost a lot of performance budget.

WebGL Error 

While checking errors with getError is generally a good idea, avoid it outside of your frame callback, since it can be more expensive than it should be.

Memory and Limits 

WebGL Safari will report limits for texture sizes, layers, uniform buffer sizes and more. A good tool to check these limits is webglreport.com .

While Safari will allow you to allocate up to these limits in theory, you might find that this can cause your page to crash.

To use memory resources on iOS more efficiently, Wonderland Engine provides a feature we call Texture Streaming , to dynamically swap pieces of textures in and out of memory based on what is currently needed in the frame. It is enabled by default.

Closing Words 

We will be following up with a detailed blog post about WebXR on Apple Vision Pro in short. Subscribe to our newsletter to get notified when we release it.

Until then, we hope you give Wonderland Engine a try ! Especially when coming from Unity, Wonderland Engine is easy to learn .

Make sure to join our Discord server as we are happy to point you to the right resources to get started.

Stay up to date.

You will receive an email verification link, in case you were not signed up already.

High-performance graphics and data-parallel programming for iOS and macOS

WebGPU for Metal Developers, Part One

Doing high-performance 3D rendering on the Web has always been a tricky proposition.

WebGL, in its quest for programmer familiarity and cross-platform ubiquity, adopted the API of OpenGL ES. As such it has never been capable of exploiting the full power of the underlying GPU, even as desktop APIs like DirectX 12, Metal, and Vulkan debuted and became popular. Furthermore, Apple has been slow to build out full support for WebGL 2: as of this writing, it remains an Experimental Feature in Safari).

Fortunately, the situation seems to be changing. After over four years in development by a working group in the W3C Consortium, the WebGPU API is hopefully on the cusp of stability and broad availability.

There are already several implementations of WebGPU across various browsers and operating systems, just as there are for WebGL. These implementations are written atop other APIs like Vulkan and Metal, which I will refer to as “backend APIs” below.

The purpose of this article series is to introduce Metal programmers to modern GPU programming on the Web. There are enough similarities between Metal and WebGPU that we can directly compare their respective APIs and shading languages. Even readers who are not familiar with Metal can hopefully benefit from this overview and the accompanying samples.

In Part One (this article), we will learn the fundamentals of the WebGPU API in Javascript, from scratch, culminating in a single, colored triangle in 2D. In Part Two , we look at a slightly more practical example of 3D terrain rendering.

If you want to view the samples embedded in this page, I recommend using a bleeding-edge browser like Chrome Canary , as existing implementations vary significantly in their support for the WebGPU draft standard (at the time of this writing).

Preparing to Draw

In contrast to native development, where we use view and layer classes to display drawable content, on the Web we use the <canvas> HTML element.

The core structure of the sample HTML looks like this:

To draw into the canvas with WebGPU, we first need to know when the page has loaded. We do this by registering an event listener that calls a function called main() . The main function in turn calls init() , which does all necessary one-time object initialization:

The main function is marked async because it uses the await keyword to suspend its execution while calling into asynchronous WebGPU APIs.

Adapters and Devices

The first API we use is window.navigator.gpu . A GPU is an object that allows us to request adapters . An adapter is an implementation of WebGPU made available by a system. There may be multiple adapters, but in this case, we call requestAdapter() with no parameters to get the default adapter.

The adapter, in turn, allows us to query the available features and limits of the implementation, as well as request devices . In this sample, we ask the adapter for the default device, which will be suitable for most purposes. As you might expect, a device in WebGPU is very similar to a MTLDevice in Metal: with a device, you can create resources and submit work to the GPU.

Getting the Canvas Context

To draw, we need to retrieve a context from the canvas. First, we use the querySelector function to get a reference to the canvas element we created above, then we ask for its gpupresent context, which gives us access to WebGPU resources associated with the canvas.

Configuring the Swap Chain

To display what we draw on the screen, we need to configure the context’s swap chain . Abstractly, the swap chain is the pool of textures that we will render to and which will be shown on-screen. This is similar to how we configure the device and pixel format of an MTKView or CAMetalLayer .

By passing the device to the configure() function, we create a linkage between the GPU and the canvas.

Establishing the Draw Loop

If you haven’t used WebGL or done animation with Web technologies before, the way we set up the draw loop may seem a little odd.

JavaScript has a function called requestAnimationFrame that schedules a function to be called the next time the browser decides it’s ready to repaint. However, the passed function is only called once: we are responsible for requesting the next frame at the end of the current frame if we want to render repeatedly. This leads to the following pattern:

Of course, unconditionally requesting drawing can be inefficient if the content being rendered hasn’t changed. We do so here only for demonstration purposes.

The Command Submission Model

Just like Metal, WebGPU requires us to record GPU commands into a command buffer to submit them to the GPU for execution.

In contrast to Metal, WebGPU does not require you to explicitly create a command buffer prior to encoding commands. Instead, you create a command encoder directly from the device, and when you’re ready to submit a batch of commands for execution, you call the finish() function on the encoder. This function returns a command buffer that can be submitted to the device’s command queue .

To understand exactly how to submit rendering work to the GPU, we first need to understand the anatomy of render passes.

Render Passes

Each frame is subdivided into one or more render passes. A render pass is a sequence of commands that consists of a load phase, one or more draw calls, and a store phase.

The outputs of a render pass are written to one or more attachments . In the simplest case, there is just one color attachment, and it stores the rendered image that will be displayed on the screen. Other scenarios may use several color attachments, a depth attachment, etc.

Each attachment has its own load operation , which determines its contents at the beginning of the pass, and store operation , which determines whether the results of the pass are stored or discarded. By providing a load value of 'load' , we tell WebGPU to retain the existing contents of the target; by providing a value (such as a color) instead, we indicate that the target should be “cleared” to that value.

To tell WebGPU which textures to draw into, we create a render pass descriptor , which is little more than a collection of attachments:

Here, we have specified that there is one color attachment, that we want to clear it to a particular color during the load phase, and that we want to store the results at the end of the pass. To indicate the texture to draw into, we get the current swap chain texture from the context, then create a view from it. This is analogous to asking a CAMetalLayer for its next drawable .

(A view is a thin abstraction over a texture that allows us to refer to a subset of its mip levels and array elements (its so-called subresources ). In Metal, a texture view is literally just another texture , but in WebGPU they are distinct types.)

Encoding a Pass

The load and store operations of a render pass occur independently of whether the pass actually includes any draw calls. We can use this to clear the canvas to a solid color by beginning a render pass and immediately ending it:

If we were doing real work, we would use the render pass encoder to encode drawing commands. We’ll see an example of that shortly.

Ending a Frame

As mentioned above, finishing a command encoder produces a command buffer that can be submitted to the GPU. We do this by asking the device for its command queue and passing an array of command buffers to be enqueued for execution. Once the work is complete, the image will be displayed by the canvas.

The result of the above code is embedded below. Depending on when you’re reading this and which browser you’re using, you might see an error message. If everything is working correctly, you should see a solid blue box.

Now that we know the basics of setting up a canvas and encoding rendering work, let’s begin drawing in earnest. We’ll start with an overview of WebGPU’s all new shading language.

A Brief Orientation to WGSL

Shaders in WebGPU are written in a language called WebGPU Shading Language , abbreviated WGSL 1 .

Modern shading languages have more similarities among them than differences. After all, their purpose is to provide a high-level syntax for the I/O and arithmetic operations available on the typical GPU.

Syntactically, WGSL borrows much from Rust. Functions definitions begin with fn ; return types appear after the parameter list, preceded by an arrow ( -> ); generics use angle brackets (e.g., vec4<f32> ). Scalar numeric types have terse names like f32 and u32 .

WGSL also has some similarities to Metal Shading Language (MSL). Attributes (e.g., [[location(0)]] ) use C++-style double square brackets. Varyings are returned from the vertex shader as a struct, and the interpolated fragment values are taken as a struct-valued parameter to the fragment shader (which may or not be of the same as the output type of the vertex shader, but must be “compatible” ).

As an introduction to the language, we will look at the vertex and fragment shaders that will produce our first triangle.

A Basic Vertex Shader

As in Metal Shading Language, we can define a struct that contains the outputs of our vertex shader. We are obligated to provide a vec4<f32> (a four-element floating-point vector) containing the clip-space vertex position, attributed with [[builtin(position)]] . In this sample, we also return a vertex color, which will be used by the fragment shader:

The vertex shader itself is a function attributed with [[stage(vertex)]] , similar to MSL’s vertex keyword. Vertex function parameters indicate where their values should be fetched from with location attributes. We will see shortly how to create a mapping from these location indices to the vertex buffers we bind when drawing.

In this sample, the vertex function simply constructs an instance of the output struct, populates it with the fetched vertex data, and returns it:

A Basic Fragment Shader

The fragment shader’s job is to return a color for its pixel based on its inputs. In this example, the output color is just the interpolated color from the rasterizer:

The location attribute on the return type indicates the index of the color attachment to which the color should be written. In Metal, a single vector return value is inferred to correspond to the first color attachment. In WGSL, we are obligated to provide this index explicitly.

This completes the shader code for the sample. We’ll see in the next section how to incorporate this shader code into a complete render pipeline.

Creating and Uploading Vertex Data

To have something to draw, we need to generate or load a mesh, perhaps from a 3D model file. In this sample, we’ll just be drawing one triangle, so we’ll specify its data by hardcoding it as a list of floats. Each vertex has a position and a color packed in memory in X Y Z W R G B A order:

To use this data on the GPU, we need to copy it into a buffer . As in Metal, we create buffers with the device. The createBuffer function takes a buffer descriptor , containing the size of the buffer, some usage flags, and whether the buffer should be “mapped” for writing at creation.

If we map the buffer at creation, it is ready to have data copied into it immediately. Since we will use the buffer as a vertex buffer when drawing, we pass the GPUBufferUsage.VERTEX flag. Since we want to use it as the destination of a copy operation, we also include the GPUBufferUsage.COPY_DST flag.

The buffer’s getMappedRange() function returns an ArrayBuffer which can be wrapped in a typed array of our choosing to copy data into it, via the set() function:

We then unmap the vertex buffer, which indicates we’re done changing its contents. The new contents are implicitly copied to the GPU.

Render Pipelines

Now that we have some shaders and some vertex data, we’re ready to assemble our render pipeline. This consists of several steps involving many different descriptor types, so we’ll go one step at a time.

Creating Shader Modules

First, we need the shaders as a string. In this sample, the shaders are contained in an HTML <script> element, but they could be sourced from an external file, typed in by the end user, or included as a JavaScript string literal.

We use the device’s createShaderModule() function to turn the shader string into a shader module , from which we can get shader functions. Different implementations will do different things behind the scenes, but a Metal implementation might create a MTLLibrary at this point, since there is a natural parallel between a WebGPU shader module and a Metal shader library.

There is nothing exactly like an MTLFunction in WebGPU. Instead, functions are uniquely identified by their module and their name.

Describing Vertex Data

As in Metal, we need to describe the layout of our vertex data up-front so it can be incorporated into the render pipeline. This description, called a vertex state , consists of an array of layouts, with each layout containing one or more attributes . This directly corresponds to Metal concept of a vertex descriptor , with the difference that the attributes are contained by the layouts rather than living in a separate container.

Each layout has a stride , which indicates the number of bytes between vertices, and a step mode , which indicates whether data should be fetched per-vertex or per-instance 2 .

Each member of the attributes array describes a single vertex attribute, including its offset from the start of vertex data, a format , and a shader location . This shader location is what is used to map from vertex buffers to the vertex shader parameters attributed with location(n) .

Mirroring the layout of our vertex data, we define two vertex attributes (position and color), both with format 'float32x4' , which maps to the WGSL vec4<f32> type.

Putting all of this together, here is the complete list of vertex layouts for this sample:

Render Pipeline Descriptors

Render pipelines contain most of the data necessary to configure the programmable and fixed-function portions of the GPU to execute rendering commands. So it’s no surprise that the render pipeline descriptor is the most complex descriptor we’ve seen so far.

Each pipeline stage (vertex and fragment) has an associated entry point and state. In the case of the vertex stage, the state is the previously-defined list of vertex buffer layouts. In the case of the fragment stage, the state is an array of color target state s, which describe the format of the render pass attachments that will be targeted by the pipeline. Each color target state also has an optional blend state , which controls fixed-function alpha blending. We don’t use alpha blending in this sample, so we omit this portion of the state.

The final piece of state that is incorporated into the render pipeline is the primitive state. At its most basic, this is just an indication of which type of primitive we will be drawing. In Metal, we specify this at the time we encode draw calls, but since some APIs require it up-front, we provide it as part of the pipeline configuration.

Bringing all of this together, here is the complete definition of our sample render pipeline descriptor:

Notice that the names of the entry points match the names of the functions we wrote in our shader source. We use a primitive topology of 'triangle-list' , since we will be drawing a list of triangles (really just one triangle).

Creating a Render Pipeline

Now that we’ve slogged through all of the above concepts, actually creating a pipeline is simple:

To encode rendering work, we create a command encoder and begin a render pass as before:

Equipped with a pipeline and a vertex buffer, we bind each of them and issue our first draw call:

The draw() function has a number of parameters, most of them optional, but the first one—the vertex count—is the most important. In this case, because we’re drawing a single triangle, it is 3.

We then end the pass, finish encoding, and enqueue the work as before.

The result of this is embedded below. In browsers with an up-to-date WebGPU implementation, it should display a single colored triangle.

Conclusion and a Look Ahead

In spite of the humble result, we’ve covered a lot of conceptual ground:

  • Canvases and contexts
  • Adapters and devices
  • Command encoders, render passes, and attachments
  • Uploading and describing vertex data
  • Basics of WGSL, vertex and fragment shaders
  • Configuring and creating render pipelines
  • Encoding draw calls

In Part 2 , we look at intermediate topics including texture loading, displacement mapping, and instancing.

  • For better and for worse, WebGPU is an open standard predominantly designed by a consortium of several large companies. Without delving into corporate politics, it is obvious that WGSL is the product of compromise among these entities. Despite the inconveniences associated with introducing Yet Another Shading Language, having a textual shading language designed for safety and ease of conversion to backend shading languages seems like the best outcome we could hope for.  ↩
  • This is a natural extension point for tessellation. If WebGPU’s tessellation model looks like Metal’s, vertex fetch could be used to fetch per-patch data in addition to per-vertex data.  ↩

Share this:

  • Click to print (Opens in new window)
  • Click to email a link to a friend (Opens in new window)
  • Click to share on Facebook (Opens in new window)
  • Click to share on Twitter (Opens in new window)

3 thoughts on “WebGPU for Metal Developers, Part One”

For those wondering how to create a commandEncoder it’s just one line of code missing above

const commandEncoder = device.createCommandEncoder();

Great article, this really helped me get started/understand some WebGPU fundamentals (I’m not even a Metal developer).

Just noticed the iframed examples were not working on Chrome Canary (as of Sep 14, 2021 version 96.0.4642.2), because of recent change in how to get the canvas context…

Before: context = canvas.getContext(“gpupresent”); After: context = canvas.getContext(“webgpu”);

Reference: – https://github.com/gpuweb/gpuweb/pull/1930 – https://chromium-review.googlesource.com/c/chromium/src/+/3027671

Thanks, Peter! I’ve updated the code so that it works in Chrome Canary Version 96.0.4652.0.

Leave a Comment Cancel Reply

Your email address will not be published. Required fields are marked *

Notify me of follow-up comments by email.

Notify me of new posts by email.

This site uses Akismet to reduce spam. Learn how your comment data is processed .

Newsletters

  • Our sponsors
  • Watch Store
  • Hot topics:
  • MacBook Air
  •  Apple deals 
  • Editor’s picks
  • Buying guides

Google Chrome 94 adds new WebGPU API with Apple Metal support

By Killian Bell • 4:51 am, August 31, 2021

Google Chrome updated for Apple Silicon

Google has rolled out its newest Chrome beta with a new WebGPU API that finally adds support for Apple Metal. The version 94 release should lead to improved rendering performance for websites and web apps.

Google’s new WebGPU API promises big improvements over existing WebGL interfaces, which were originally designed for drawing images and not much else. It packs modern features, such as “GPU compute,” and promises more efficient, more predictable performance.

The WebGPU API supports not only Apple Metal, but also other modern graphics platforms — including Microsoft’s Direct3D and Vulkan — which allow for rendering and computation operations on a GPU. But Google believes it will take a little while to experience the full benefits.

Chrome 94 adds Apple Metal support

With the Chrome 94 beta for Mac, Windows, Linux, and Android, Google is rolling out its new WebGPU API in trial form. It hopes to ship the API out to everyone in a public release of Chrome in version 99. It will then rely on website developers to take advantage of the WebGPU improvements.

The WebGPU trial is expected to end in Chrome 97 , scheduled for release in January 2022. And Google hopes that websites will have started making the most of the improvements by then. The company notes WebGPU support is also “in progress” in both Safari and Firefox.

Apple allows access to the WebGPU and its Metal API in the latest Safari Technology Preview, but it’s yet to make its way to public Safari releases. It is not yet available in Safari 15, which ships with macOS Monterey. It’s though Apple, like Google, plans to officially roll out support in early 2022.

Apple first introduced its Metal API back in 2014 , giving developers low-level access to its graphics hardware inside Mac, iPhone, iPad, and Apple TV. It allows for greater graphics performance while reducing the impact apps and games have on the central processing unit (CPU).

Daily round-ups or a weekly refresher, straight from Cult of Mac to your inbox.

safari webgl metal

Cult of Mac Today

Our daily roundup of Apple news, reviews and how-tos. Plus the best Apple tweets, fun polls and inspiring Steve Jobs bons mots. Our readers say: "Love what you do" -- Christi Cardenas. "Absolutely love the content!" -- Harshita Arora. "Genuinely one of the highlights of my inbox" -- Lee Barnett.

safari webgl metal

The Weekender

The week's best Apple news, reviews and how-tos from Cult of Mac, every Saturday morning. Our readers say: "Thank you guys for always posting cool stuff" -- Vaughn Nevins. "Very informative" -- Kenly Xavier.

Popular This Week

These are the best and coolest apple watch faces, get ready for ‘the biggest airpods launch to date’, why you shouldn’t use m3 macbook air in clamshell mode, ai designed this insane $326,700 iphone case, apple watch series 10 could finally offer blood pressure monitoring, m1 macbook air drops to all-time low price of $649 [deals], apple acquires fundamental ai smarts by buying darwinai, homepod mini scores a big 20% discount [deals], ios 18’s generative ai features might use google gemini, today in apple history: power mac 7100 lands apple in hot water with carl sagan.

safari webgl metal

Search code, repositories, users, issues, pull requests...

Provide feedback.

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly.

To see all available qualifiers, see our documentation .

  • Notifications

MetalANGLE: OpenGL ES to Metal API translation layer

kakashidinho/metalangle

Folders and files, repository files navigation, metalangle - opengl es to apple metal api translation layer.

Build Status

This is a fork of Google's ANGLE project . It adds Metal API backend support. Apple announced OpenGL (ES) deprecation in 2018. So the purpose of MetalANGLE is to allow OpenGL ES applications to continue operate on Apple platforms by translating OpenGL ES draw calls to Metal draw calls under the hood. It also supports OpenGL ES & Metal's interop.

30 Jun 2021 Update: Most of this repo's OpenGL ES 3.0 implementing code in Metal has been merged into official ANGLE repo. Initially, this was the only place where Metal backend's developments took place. It is not true anymore as Apple are also making modifications and are in a progress of merging their changes into official ANGLE . See current Differences between MetalANGLE and official ANGLE .

2023 Update: This repo is currently not in active development. Because I officially joined Google last year. As such, all the ANGLE related developments should be redirected to official ANGLE repo instead. In future I am planning to create a separate repo containing only the high level wrapper layer MGLKit + iOS Xcode project. See #79 .

Preliminary Metal based WebGL benchmarks (based on gles3-dev branch code):

safari webgl metal

  • This benchmark runs https://webglsamples.org/aquarium/aquarium.html on Chromium browser using AMD Radeon Pro 560 GPU.

Current Metal backend implementation status

  • MetalANGLE has been migrated into official ANGLE repo. See current Differences between MetalANGLE and official ANGLE .
  • OpenGL ES 2.0 functionalities are 100% completed.
  • Occlusion queries.
  • Multiple render targets ( Not all GL formats are supported on old iOS GPUs due to pixel storage's limits . See #issue 64 ).
  • 3D, array, shadow textures.
  • Texture swizzles ( supported on iOS 13.0+, macOS 10.15+ only ).
  • Uniform buffers.
  • Fence sync ( supported on iOS 12.0+, macOS 10.14+ only ).
  • Pixel buffer objects.
  • Primitive Restart. Metal's primitive restart doesn't work reliably.
  • Flat shading with last provoking vertex. Metal's default is first provoking vertex.
  • Transform feedbacks.
  • OpenGL ES 1.0 is not recommended to be used. Its implementation is not actively maintained by original ANGLE project and currently buggy/not fully compliant.
  • All basic samples are working.
  • Almost all of ANGLE end2end tests have been passed . See List of failed tests .
  • 98% of OpenGL ES 2.0 conformance tests passed . 90%+ of OpenGL ES 3.0 conformance tests passed . See Khronos VK-GL-CTS .
  • EXT_instanced_arrays / ANGLE_instanced_arrays : Instanced draw calls for GLES 2.0.
  • OES_depth_texture .
  • EXT_draw_buffers : Multiple render targets for GLES 2.0.
  • ANGLE_framebuffer_blit .
  • APPLE_clip_distance : Custom clip planes.
  • MGLKit utilities classes have been added. Providing kind of similar functionalies to Apples's GLKit.
  • Urho3D engine's demos have been tested using MetalANGLE without issues. See Urho3D's MetalANGLE integration testing branch .
  • Irrlicht Engine's integration with MetalANGLE sample: https://github.com/kakashidinho/irrlicht .
  • Interop with Metal is supported, see Qt example: https://github.com/kakashidinho/qml-metalangle .
  • No GL_TRIANGLE_FAN & GL_LINE_LOOP support in draw calls yet.
  • Metal doesn't allow buffer offset not being multiple of 4 bytes or multiple of attribute's size. Hence, draw calls that use unsupported offsets, strides, and vertex formats will force MetalANGLE to do conversions on the fly.
  • MSAA is not supported yet.
  • Old OpenGL ES 2.0 only implementation can be found on gles2 branch
  • MetalANGLE only supports MacOS 10.13+ for Mac.
  • For iOS, the min supported version is iOS 9.0 . However, Metal acceleration is only available for iOS 11.0+ , any version prior to that will fall back to use native Apple OpenGL ES implementation instead of Metal. Furthermore, most of the sample apps are compiled for iOS 11.0+ . So if you want to test the sample apps on 10.0 devices and below, it won't run, except a few ones (e.g. MGLKitSampleApp_ios9.0).
  • iPhone 5 and below are not supported.
  • MacCatalyst 13.0+ is supported.
  • Make sure it passes all ANGLE's tests.
  • Support GL_TRIANGLE_FAN & GL_LINE_LOOP by generating index buffer on the fly using Metal compute shader.
  • Use compute shader to convert unsupported offsets, strides & vertex formats.
  • Support MSAA.
  • Fully support OpenGL ES 3.0.

How to build Metal ANGLE for MacOS & iOS

View the Metal backend's Dev setup instructions .

Currently, for convenience, MetalANGLE can also be built using an Xcode project provided in ios/xcode & mac/xcode folder. The Xcode project also builds MGLKit utilities wrapper library which provides MGLContext , MGLLayer , MGLKView , MGLKViewController , similar to Apple's provided GLKit classes such as CAEAGLContext , CAEAGLLayer , GLKView , GLKViewController . Please open MGLKitSamples.xcodeproj for example iOS app using this MGLKit library. This documents contains some guides to port GLKit apps to use MGLKit .

Nevertheless, you still need to setup the required environment and dependencies properly as mentioned in Metal backend's Dev setup instructions first.

Differences between MetalANGLE and Google's ANGLE

  • Before June 2021, most of the Metal back-end code are shared between MetalANGLE and ANGLE .
  • Rewriting the index buffer on the fly to support last provoking vertex of flat shading. While this helps conforming to OpenGL ES's flat shading's specifications, it makes draw calls using flat shading become slower. In majority of use cases, user wouldn't care whether flat shading uses last or first provoking vertex.
  • MetalANGLE includes iOS supports and high level API such as MGLKit that mimics Apple's deprecated EAGL & GLKit API. These features are unlikely to be merged into ANGLE since ANGLE project doesn't have any plan to support iOS in near future.

Google's ANGLE - Almost Native Graphics Layer Engine

The goal of ANGLE is to allow users of multiple operating systems to seamlessly run WebGL and other OpenGL ES content by translating OpenGL ES API calls to one of the hardware-supported APIs available for that platform. ANGLE currently provides translation from OpenGL ES 2.0 and 3.0 to desktop OpenGL, OpenGL ES, Direct3D 9, and Direct3D 11. Support for translation from OpenGL ES to Vulkan is underway, and future plans include compute shader support (ES 3.1) and MacOS support.

Level of OpenGL ES support via backing renderers

Platform support via backing renderers.

ANGLE v1.0.772 was certified compliant by passing the ES 2.0.3 conformance tests in October 2011. ANGLE also provides an implementation of the EGL 1.4 specification.

ANGLE is used as the default WebGL backend for both Google Chrome and Mozilla Firefox on Windows platforms. Chrome uses ANGLE for all graphics rendering on Windows, including the accelerated Canvas2D implementation and the Native Client sandbox environment.

Portions of the ANGLE shader compiler are used as a shader validator and translator by WebGL implementations across multiple platforms. It is used on Mac OS X, Linux, and in mobile variants of the browsers. Having one shader validator helps to ensure that a consistent set of GLSL ES shaders are accepted across browsers and platforms. The shader translator can be used to translate shaders to other shading languages, and to optionally apply shader modifications to work around bugs or quirks in the native graphics drivers. The translator targets Desktop GLSL, Direct3D HLSL, and even ESSL for native GLES2 platforms.

ANGLE repository is hosted by Chromium project and can be browsed online or cloned with

View the Dev setup instructions .

Contributing

Join our Google group to keep up to date.

Join us on IRC in the #ANGLEproject channel on FreeNode.

Join us on Slack in the #angle channel.

File bugs in the issue tracker (preferably with an isolated test-case).

Choose an ANGLE branch to track in your own project.

Read ANGLE development documentation .

Look at pending and merged changes.

Become a code contributor .

Use ANGLE's coding standard .

Learn how to build ANGLE for Chromium development .

Get help on debugging ANGLE .

Go through ANGLE's orientation and sift through starter projects .

Read about WebGL on the Khronos WebGL Wiki .

Learn about implementation details in the OpenGL Insights chapter on ANGLE and this ANGLE presentation .

Learn about the past, present, and future of the ANGLE implementation in this presentation .

Watch a short presentation on the Vulkan back-end.

Track the dEQP test conformance

Read design docs on the Vulkan back-end

If you use ANGLE in your own project, we'd love to hear about it!

Sponsor this project

  • https://www.paypal.com/paypalme/HQgame

Contributors 151

  • Objective-C++ 3.5%
  • Python 1.5%
  • Objective-C 1.1%

How To Enable Webgl On Safari

Copy to Clipboard

  • Software & Applications
  • Browsers & Extensions

how-to-enable-webgl-on-safari

Introduction

Welcome to the world of web browsing, where the seamless integration of technology and creativity opens up a universe of possibilities. As you navigate the digital landscape, you encounter captivating visuals, interactive experiences, and immersive 3D graphics that breathe life into websites and applications. At the heart of this visual extravaganza lies WebGL, a powerful JavaScript API that brings stunning graphics to your browser, transforming the way you interact with online content.

WebGL, short for Web Graphics Library, serves as the cornerstone of modern web-based 3D graphics, enabling developers to craft visually rich and dynamic experiences that push the boundaries of traditional web design. From interactive product showcases and engaging games to architectural visualizations and virtual reality experiences, WebGL empowers developers to unleash their creativity and deliver captivating content to users across the globe.

While major web browsers embrace WebGL as a fundamental component of the web experience, Safari, Apple's renowned browser , requires a specific configuration to unleash the full potential of WebGL. In this guide, we'll delve into the intricacies of enabling WebGL on Safari, empowering you to harness the full spectrum of 3D graphics and interactive content that the web has to offer.

So, fasten your seatbelt as we embark on a journey to unlock the captivating world of WebGL on Safari. Whether you're a developer seeking to optimize your creations or an enthusiast eager to immerse yourself in visually stunning web content, this guide will equip you with the knowledge and tools to enable WebGL on Safari and elevate your browsing experience to new heights. Let's dive in and unravel the magic of WebGL within the Safari browser!

Checking WebGL Support on Safari

Before delving into the process of enabling WebGL on Safari, it's crucial to ascertain whether your browser supports this cutting-edge technology. Checking WebGL support on Safari is a straightforward yet essential step to ensure that your browser is equipped to render immersive 3D graphics and interactive content seamlessly.

To verify WebGL support on Safari, you can follow these simple steps:

Accessing Safari Preferences : Launch the Safari browser on your Mac and navigate to the "Safari" menu located in the top-left corner of the screen. From the dropdown menu, select "Preferences" to access the browser's settings and configuration options.

Opening the Advanced Tab : Within the Preferences window, click on the "Advanced" tab, which houses advanced settings and features that cater to the technical aspects of the browser.

Enabling the Develop Menu : To reveal the Develop menu in Safari, ensure that the "Show Develop menu in menu bar" option is checked. This step is crucial as it grants access to developer-centric tools and features, including WebGL-related functionalities.

Accessing the Develop Menu : After enabling the Develop menu, you'll notice a new option labeled "Develop" in the top menu bar, adjacent to the "Bookmarks" and "Window" menus. Click on the "Develop" menu to unveil a dropdown list of developer-oriented tools and settings.

Selecting the Experimental Features : Within the "Develop" menu, navigate to the "Experimental Features" section and ensure that the "WebGL 2.0" option is checked. This step is pivotal in confirming that WebGL support is enabled on Safari, allowing the browser to harness the full potential of WebGL-powered content.

By following these steps, you can effectively check WebGL support on Safari, ensuring that your browser is primed to deliver captivating 3D graphics and interactive experiences seamlessly. This preliminary assessment sets the stage for the subsequent process of enabling WebGL on Safari, paving the way for a visually rich and immersive browsing experience.

With WebGL support verified, you're now ready to embark on the next phase of our journey – enabling WebGL on Safari to unlock a world of visually stunning web content and interactive experiences. Let's dive into the intricacies of enabling WebGL on Safari and harness the full potential of this groundbreaking technology.

Enabling WebGL on Safari

Enabling WebGL on Safari is a pivotal step that unlocks the browser's capability to render immersive 3D graphics, interactive content, and visually rich web experiences. By configuring Safari to harness the full potential of WebGL, users can indulge in a seamless and captivating browsing journey, encountering stunning visuals and dynamic content that elevate the web experience to new heights.

To enable WebGL on Safari, follow these steps:

Accessing the Develop Menu : As mentioned in the previous section, ensure that the Develop menu is visible in Safari. This can be achieved by navigating to the Safari Preferences, clicking on the Advanced tab, and checking the "Show Develop menu in menu bar" option. The Develop menu is a gateway to a plethora of developer-centric tools and features, including essential settings related to WebGL.

Enabling WebGL : Once the Develop menu is accessible, click on it to reveal a dropdown list of developer-oriented tools and settings. Within the Develop menu, locate the "Experimental Features" section and ensure that the "WebGL 2.0" option is checked. This pivotal action effectively enables WebGL on Safari, empowering the browser to seamlessly render 3D graphics and interactive content with precision and fluidity.

By following these steps, you can successfully enable WebGL on Safari, transforming the browser into a powerhouse capable of delivering visually stunning web content and immersive experiences. With WebGL now activated, Safari stands ready to embrace the creative prowess of developers and the captivating allure of WebGL-powered content, ensuring that users are immersed in a visually rich and dynamic online environment.

Enabling WebGL on Safari marks a significant milestone in enhancing the browser's capabilities, allowing users to explore a myriad of visually captivating websites, interactive applications, and 3D experiences that push the boundaries of traditional web design. This pivotal configuration empowers Safari to seamlessly render WebGL-powered content, ensuring that users are greeted with a visually rich and engaging browsing experience that transcends conventional web interactions.

With WebGL now enabled on Safari, users can embark on a captivating journey through the immersive realm of 3D graphics, interactive visualizations, and dynamic web content, all seamlessly rendered within the confines of the Safari browser. This transformation elevates the web experience, inviting users to explore a digital landscape teeming with creativity, innovation, and visually stunning content that captivates the senses and sparks the imagination.

Verifying WebGL is Enabled

After enabling WebGL on Safari, it's essential to verify that the configuration has been successfully implemented, ensuring that the browser is primed to render immersive 3D graphics and interactive content seamlessly. This crucial step allows users to confirm that Safari is equipped to harness the full potential of WebGL, setting the stage for a visually rich and dynamic browsing experience.

To verify that WebGL is enabled on Safari, follow these steps:

Accessing the Develop Menu : Launch the Safari browser and ensure that the Develop menu is visible in the top menu bar. If the Develop menu is not visible, navigate to Safari Preferences, click on the Advanced tab, and check the "Show Develop menu in menu bar" option. The Develop menu serves as a gateway to essential developer-centric tools and settings, including those related to WebGL.

Inspecting the WebGL Status : Once the Develop menu is accessible, click on it to reveal a dropdown list of developer-oriented tools and settings. Within the Develop menu, locate the "Experimental Features" section and ensure that the "WebGL 2.0" option is checked. This pivotal action confirms that WebGL is enabled on Safari, empowering the browser to seamlessly render 3D graphics and interactive content with precision and fluidity.

Testing WebGL Functionality : With WebGL enabled, it's beneficial to test its functionality to ensure that the browser can effectively render WebGL-powered content. Visit websites or applications that utilize WebGL for 3D graphics or interactive experiences. Engage with the content and observe the fluidity and visual richness of the WebGL-powered elements, confirming that Safari is successfully leveraging WebGL to enhance the browsing experience.

By following these steps, users can effectively verify that WebGL is enabled on Safari, ensuring that the browser is equipped to deliver visually stunning web content and immersive experiences seamlessly. This validation process serves as a pivotal checkpoint, confirming that Safari has embraced the creative prowess of developers and the captivating allure of WebGL-powered content, ensuring that users are immersed in a visually rich and dynamic online environment.

With WebGL successfully enabled and verified on Safari, users can embark on a captivating journey through the immersive realm of 3D graphics, interactive visualizations, and dynamic web content, all seamlessly rendered within the confines of the Safari browser. This transformation elevates the web experience, inviting users to explore a digital landscape teeming with creativity, innovation, and visually stunning content that captivates the senses and sparks the imagination.

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Save my name, email, and website in this browser for the next time I comment.

  • Crowdfunding
  • Cryptocurrency
  • Digital Banking
  • Digital Payments
  • Investments
  • Console Gaming
  • Mobile Gaming
  • VR/AR Gaming
  • Gadget Usage
  • Gaming Tips
  • Online Safety
  • Software Tutorials
  • Tech Setup & Troubleshooting
  • Buyer’s Guides
  • Comparative Analysis
  • Gadget Reviews
  • Service Reviews
  • Software Reviews
  • Mobile Devices
  • PCs & Laptops
  • Smart Home Gadgets
  • Content Creation Tools
  • Digital Photography
  • Video & Music Streaming
  • Online Security
  • Online Services
  • Web Hosting
  • WiFi & Ethernet
  • Browsers & Extensions
  • Communication Platforms
  • Operating Systems
  • Productivity Tools
  • AI & Machine Learning
  • Cybersecurity
  • Emerging Tech
  • IoT & Smart Devices
  • Virtual & Augmented Reality
  • Latest News
  • AI Developments
  • Fintech Updates
  • Gaming News
  • New Product Launches

Close Icon

10 Best AI Math Solvers for Instant Homework Solutions

10 best ai homework helper tools to get instant homework help, related post, 10 best ai humanizers to humanize ai text with ease, sla network: benefits, advantages, satisfaction of both parties to the contract, the future of autonomous vehicles: promises and pitfalls for road safety, unlocking creativity: how essay and content creator resources empower writers, privacy in the age of always watching, related posts.

Why Does Unity Not Work On Chrome

Why Does Unity Not Work On Chrome

How Do I Enable Webgl In Firefox?

How Do I Enable Webgl In Firefox?

How To Enable Webgl In Chrome

How To Enable Webgl In Chrome

How To Enable Webgl On Chrome

How To Enable Webgl On Chrome

What Experimental Features Should I Turn On In Safari

What Experimental Features Should I Turn On In Safari

How To Use Unity In Chrome

How To Use Unity In Chrome

Why Doesn’t Chrome Support Unity Anymore?

Why Doesn’t Chrome Support Unity Anymore?

What Coding Language Is Used For Games

What Coding Language Is Used For Games

Recent stories.

10 Best AI Math Solvers for Instant Homework Solutions

Esports World Cup Games Announcement: What’s on the Horizon

SLA Network: Benefits, Advantages, Satisfaction of Both Parties to the Contract

Designing for Flexibility: Materials and Manufacturing Techniques in Flexible Hybrid Electronics

Icse Chemistry Exams 2024: How Did The Paper Go? Here’s What Students Mentioned

Icse Chemistry Exams 2024: How Did The Paper Go? Here’s What Students Mentioned

How Sustainable Is Bitcoin’s Current Price Rally?

How Sustainable Is Bitcoin’s Current Price Rally?

Robots.net

  • Privacy Overview
  • Strictly Necessary Cookies

This website uses cookies so that we can provide you with the best user experience possible. Cookie information is stored in your browser and performs functions such as recognising you when you return to our website and helping our team to understand which sections of the website you find most interesting and useful.

Strictly Necessary Cookie should be enabled at all times so that we can save your preferences for cookie settings.

If you disable this cookie, we will not be able to save your preferences. This means that every time you visit this website you will need to enable or disable cookies again.

Google Chrome

Chrome 94 beta adds webgpu api with support for apple’s metal.

Avatar for Filipe Espósito

Google this week announced the beta release of Chrome 94 , the next update to Google’s desktop web browser. In addition to general improvements, the update also adds support for the new WebGPU API, which comes to replace WebGL and can even access Apple’s Metal API.

As described by Google in a blog post , WebGPU is a new, more advanced graphics API for the web that is able to access GPU hardware, resulting in better performance for rendering interfaces in websites and web apps.

The main difference of WebGPU to other graphics acceleration APIs for the web is that the new API is based on the device’s native technologies, such as Apple’s Metal, Microsoft’s Direct3D, or the open Vulkan standard. This should make it easier for web developers to create web apps and games with more intense graphics.

The WebGPU API is the successor to the WebGL and WebGL2 graphics APIs for the Web. It provides modern features such as “GPU compute” as well as lower overhead access to GPU hardware and better, more predictable performance. This is an improvement over the existing WebGL interfaces, which were designed for drawing images but could only be repurposed for other kinds of computations with great effort.

For those unfamiliar, Metal is an API introduced by Apple in 2014 that provides low-level access to GPU hardware for iOS, macOS, and tvOS apps. In other words, apps can access the GPU without overloading the CPU, which is one of the limitations of old APIs like OpenGL.

However, as noted by The Verge , it will probably take some time before developers adopt the new WebGPU API into their web projects as it’s still considered an experimental feature. Google says WebGPU is not expected to come enabled by default for all Chrome users until early 2022.

The final release of Chrome 94 should enable WebCodecs for everyone, which is another API designed to improve the encoding and decoding of streaming videos.

Apple currently provides access to the WebGPU API in its Safari web browser through the latest version of the Safari Technology Preview , which can be downloaded by developers. Since the API is not yet included in Safari 15 that comes with macOS Monterey, it will probably come in early 2022 with a future Safari update.

FTC: We use income earning auto affiliate links. More.

safari webgl metal

Check out 9to5Mac on YouTube for more Apple news:

Google Chrome

Filipe Espósito is a Brazilian tech Journalist who started covering Apple news on iHelp BR with some exclusive scoops — including the reveal of the new Apple Watch Series 5 models in titanium and ceramic. He joined 9to5Mac to share even more tech news around the world.

SAFARI 15.2 WEBGL performance disaster

recent switcher, I bought a Mac Pro M1 on November 11 and try one of my webgl prog that run fast in Safari. Some days later, Safari goes slow and I go back to others nav. I decided to wait next Mac OS release which happens for me yesterday December 12 : version 12.1 Monterey. Now safari is 15.2 and new tests show a disaster : A simple move on screen with P5.js of an obj model takes : 7,381s on Chrome, 7,447 s on Edge, 7,330 s on Brave and ... 32,598 s on Safari ! I supposed one day that can comes from external monitors ( I work on a high canvas ), but last tests were done with a reduced 800x800 canvas on computer screen . So wrong path.

is this a known problem ?

It has been like this for ages ... Deplorable

WebGl on Safari Monterey is a disaster. It's a disaster too on iPads last gen......

Seeing the same issue here. Our test scene used to render at 60fps back in April 2021, now without changing any code it's at 2FPS and my whole Macbook Air freezes.

Test scene: https://test.looc.io/forest/index.html

Thanks for the test scene! It also almost freezes my entire machine (M1 Pro). But if I disable WebGL 2.0 under experimental features, it's back to 60 FPS again. So, there seems to be a bug with WebGL 2.0.

Thanks for the test scene. I can confirm this bug still exist on Safari 16.1 on Ventura 13.1.1 on M1 MBA

Any progress on that issue? Or workarounds? 🤔

safari webgl metal

Following your question, i redo a test on my p5.js application. I have a watcher in the main loop of my app to detect slow-down. I set its threeshold at 50 Fps. On my splash screen webgl displaying a (rather big) plane with a texture:

  • Chrome stays at 50 and give very rarely some 48, 49 fps.
  • Safari stays permanently under 11 fps

workaround : download chrome, brave or firefox ....

In case anyone else lands here via Google.

The slowdown I've seen is most severe when WebGL 2.0 is enabled.

So if you are in developer mode in Safari you can go to "Develop" -> "Experimental Features" -> untick "WebGL 2.0".

This will significantly improve performance if the page you're trying to view also supports webgl 1.0 (as the demo page posted by Bersaelor does).

Still nowhere near Firefox or Chome performance, but still a 20x improvement in frametime for me in Safari comparing with and and without WebGL 2.0 enabled.

This bug is still reproducible on Ventura 13.1.1 and Safari 16.1.1 5 months later. I was wondering if this bug is relating to Apple's implementation of WebGL via Metal. I did an experiment that I run Bersaelor's test scene:  https://test.looc.io/forest/index.html on Chrome 107 with metal as ANGELS backend. At last it's still with a freezing screen and 1-2 FPS on my M1 laptop. It seems that it's a Metal bug, and less relevant to WebKit.

The problem still persists. Maybe got worse in 13.1. Safari Tech Preview is even worse! Do any of you have a good webgl 1 and 2 performance test we can try. I wonder if I adapt my tools to use webgl 2 I will get better performance.

I did an experiment to turn off the 'WebGL via Metal' and webGL works like magic. If you turn on develop mode in Safari you can go to safari's menu and follow "Develop" -> "Experimental Features" -> untick "WebGL via Metal".

iOS/iPadOS 16.3 WebGL via Metal Feature issue

I can’t load playcanvas projects on my iPhone and iPad. After the project is loaded I just see a black square and everything becomes laggy.

I made some tests with public projects with different level of complexity

A) Dab Motors Configurator ( https://dabmotors.com/configurator/ ) B) Basecamp Airstream Configurator ( Airstream Basecamp 3D Experience - Airstream ) C) Anim State Graph Blending (can’t post another link, but it’s in the tutorial section)

I tested the projects with these devices and browsers

  • iPhone XR iOS 16.3.1 - Safari - A: black square, B: black square, C: black square
  • iPad Air 3 iPadOS 16.3.1 - Safari - A: black square, B: black square, C: ok
  • iPhone 12 iOS 16.0 - Safari - A: ok, B: ok, C: ok

I found that the issue could be the Safari experimental feature “WebGL via Metal” (Settings App → Safari → detail → Experimental Features → “WebGL via Metal”)

Disabling “WebGL via Metal” feature the test results are

  • iPhone XR iOS 16.3.1 - Safari - A: page crashes, B: ok, C: ok
  • iPad Air 3 iPadOS 16.3.1 - Safari - A: page crashes, B: sometimes page crashes, C: ok

I’d like to know if there’s a possible workaround and if it is something that Playcanvas could fix or I have to wait future Apple OS releases.

@mvaligursky May have some feedback but as it’s an experimental feature from Apple, it’s more likely to be an issue from Apple side while they work through issues.

Thank you for the answer, but the problem is that this feature is enabled by default, so PlayCanvas projects don’t run anymore on some Apple devices.

I’ve not heard of any reports of issues with Apple devices. If it was enabled by default, I would have expected to be flooded with emails and messages.

I’m looking this up now to see what’s up and I will also check with browser stack

Hmm, seems like it’s enabled by default as you said for WebGL 2.0 support

16.0 seems fine on browser stack, I see if I can find one that has 16.3.1

image

16.3 seems fine too

image

I wonder if some of these have issues as well? https://playcanvas.github.io/

Often they only use smaller subset of features, so we could easier isolate the problem areas.

I tested almost all the examples on iPhone XR (iOS 16.3.1) and iPad Air 3 (iPadOS 16.3.1) with the “WebGL via Metal” feature enabled and they all works fine. But I keep on seeing a black square with the projects on the tutorial page ( Tutorials | Learn PlayCanvas ). What’s the difference between the two?

Can you post a screenshot of the ‘black square’ just so that we are sure what we are looking for.

Also, are there any error logs in the devtools console?

The tutorials are iframe embeds if that makes a difference and published on a range of older engines.

IMG_5211.PNG

I can’t reproduce the issue on my XR 16.3.1 device

Try this published build that has vConsole (see bottom right green button) so you can see logs on device: test 16.3.1 vConsole - PLAYCANVAS

img_v2_6def7a55-bc17-4cd1-804b-19f34e65700g

This is really odd as well can’t reproduce the issue here locally on our devices.

Do you get any errors in the devtools console? If so, what are they?

Can you try the iframeless link of the same build please? https://playcanv.as/e/p/S2r8lFwv/

Can you try closing all other tabs and closing all background apps on the device?

img_v2_99ac1804-7802-49ce-8152-6fd103438d7g

There is another situation:when I test on other projects, there is a chance of a black screen appearing when I refresh multiple times.

As we can’t reproduce it, we can’t really investigate. Ideally having the console logs on Safari remote devtools would help us a lot

:disappointed:

I’ve check with some other users on Discord and they can’t reproduce your issue either.

Unless we get some logs, I can’t even think on what could be causing the issue that would also stop you from pressing the vConsole tab. It’s like it’s locked up the page.

Try this version (new build) https://playcanv.as/p/S2r8lFwv/ where I set the vConsole to show after 250, 500 and 1000 ms from start.

When I first opened it, it would display normally, but after multiple refreshes, it would appear as a black screen, and VConsole would not be able to click either.

  • Español – América Latina
  • Português – Brasil
  • Tiếng Việt
  • Chrome for Developers

WebGPU: Unlocking modern GPU access in the browser

Learn how WebGPU unlocks the power of the GPU for faster machine learning performance and better graphics rendering.

Corentin Wallez

The new WebGPU API unlocks massive performance gains in graphics and machine learning workloads. This article explores how WebGPU is an improvement over the current solution of WebGL, with a sneak peek at future developments. But first, let’s provide some context for why WebGPU was developed.

Context on WebGPU

WebGL landed in Chrome in 2011 . By allowing web applications to take advantage of GPUs, WebGL enables amazing experiences on the web—from Google Earth, to interactive music videos, to 3D real-estate walkthroughs and more. WebGL was based on the OpenGL family of APIs first developed in 1992. That's a long time ago! And you can imagine that GPU hardware has evolved significantly since that time.

To keep up with this evolution, a new breed of APIs were developed to more efficiently interact with modern GPU hardware. APIs like Direct3D 12 , Metal , and Vulkan . These new APIs have supported new and demanding use cases for GPU programming such as the explosion in machine learning and advances in rendering algorithms. WebGPU is the successor to WebGL bringing the advancements of this new class of modern APIs to the Web.

WebGPU unlocks a lot of new GPU programming possibilities in the browser. It better reflects how modern GPU hardware works, while also laying a foundation for more advanced GPU capabilities in the future. The API has been baking in the W3C’s "GPU for the Web" group since 2017, and is a collaboration between many companies such as Apple, Google, Mozilla, Microsoft, and Intel. And now after 6 years of work, we’re excited to announce that one of the biggest additions to the Web platform is finally available!

WebGPU is available today in Chrome 113 on ChromeOS, macOS, and Windows, with other platforms coming soon. A huge thank you to other Chromium contributors and Intel in particular who helped make this happen.

Now let’s take a look at some of the exciting use cases WebGPU enables.

Unlocking new GPU workloads for rendering

WebGPU features such as compute shaders enable new classes of algorithms to be ported on the GPU. For example, algorithms that can add more dynamic details to scenes, simulate physical phenomenons, and more! There are even workloads that previously could only be done in JavaScript that can now be moved to the GPU.

The following video shows the marching cubes algorithm being used to triangulate the surface of these metaballs. In the first 20 seconds of the video, the algorithm, when it's running in JavaScript, struggles to keep up with the page only running at 8 FPS resulting in janky animation. To keep it performant in JavaScript we would need to lower the level of details a lot.

It's a night and day difference when we move the same algorithm to a compute shader, which is seen in the video after 20 seconds. The performance improves dramatically with the page now running at a smooth 60 FPS and there's still a lot of performance headroom for other effects. In addition the page’s main JavaScript loop is completely freed up for other tasks, ensuring that interactions with the page stay responsive.

WebGPU also enables complex visual effects that were not practical before. In the following example, created in the popular Babylon.js library, the ocean surface is being simulated entirely on the GPU. The realistic dynamics are created from many independent waves being added to each other. But simulating each wave directly would be too expensive.

That's why the demo uses an advanced algorithm called Fast Fourier Transform . Instead of representing all the waves as complex positional data, this uses the spectral data which is much more efficient to perform computations. Then each frame uses the Fourier Transform to convert from spectral data to the positional data that represents the height of the waves.

Faster ML inference

WebGPU is also useful to accelerate machine learning, which has become a major use of GPUs in recent years.

For a long time, creative developers have been repurposing WebGL's rendering API to perform non-rendering operations such as machine learning computations. However, this requires drawing the pixels of triangles as a way to initiate the computations, and carefully packing and unpacking tensor data in texture instead of more general purpose memory accesses.

An illustration of the inefficiencies in a single ML operator execution with WebGL, including redundant memory loads, redundant computations, and few values written per thread.

Using WebGL in this way requires developers to awkwardly conform their code to the expectations of an API designed only for drawing. Combined with the lack of basic features like shared memory access between computations, this leads to duplicate work and suboptimal performance.

Compute shaders are WebGPU's primary new feature and remove these pain points. Compute shaders offer a more flexible programming model that takes advantage of the GPU's massively parallel nature while not being constrained by the strict structure of rendering operations.

The various efficiency gains in WebGPU compute shaders, including shared memory loads, shared computations, and flexible writes to memory.

Compute shaders give more opportunity for sharing data and computation results within groups of shader work for better efficiency. This can lead to significant gains over previous attempts to use WebGL for the same purpose.

As an example of the efficiency gains this can bring, an initial port of an image diffusion model in TensorFlow.js shows a 3x performance gain on a variety of hardware when moved from WebGL to WebGPU. On some of the hardware tested the image was rendered in under 10 seconds. And because this was an early port, we believe there are even more improvements possible in both WebGPU and TensorFlow.js! Check out What’s new with Web ML in 2023? Google I/O session.

But WebGPU is not only about bringing GPU features to the web.

Designed for JavaScript first

The features that enable these use cases have been available to platform-specific desktop and mobile developers for a while, and it’s been our challenge to expose them in a way that feels like a natural part of the web platform.

WebGPU was developed with the benefit of hindsight from over a decade of developers doing amazing work with WebGL. We were able to take the problems they encountered, the bottlenecks they hit, and the issues they raised and funneled all of that feedback into this new API.

We saw that WebGL’s global state model made creating robust, composable libraries and applications difficult and fragile. So WebGPU dramatically reduces the amount of state that developers need to keep track of while sending the GPU commands.

We heard that debugging WebGL applications was a pain, so WebGPU includes more flexible error handling mechanisms that don’t tank your performance. And we’ve gone out of our way to ensure that every message you get back from the API is easy to understand and actionable .

We also saw that frequently the overhead of making too many JavaScript calls was a bottleneck for complex WebGL applications. As a result, the WebGPU API is less chatty, so you can accomplish more with fewer function calls. We focus on performing heavyweight validation up front, keeping the critical draw loop as lean as possible. And we offer new APIs like Render Bundles , which allow you to record large numbers of drawing commands in advance and replay them with a single call.

To demonstrate what a dramatic difference a feature like render bundles can make, here’s another demo from Babylon.js. Their WebGL 2 renderer can execute all the JavaScript calls to render this art gallery scene about 500 times a second. Which is pretty good!

Their WebGPU renderer, however, enables a feature they call Snapshot Rendering. Built on top of WebGPUs render bundles, this feature allows the same scene to be submitted more than 10x faster. This significantly reduced overhead allows WebGPU to render more complex scenes, while also allowing applications to do more with JavaScript in parallel.

Modern graphics APIs have a reputation for complexity, trading simplicity for extreme optimization opportunities. WebGPU, on the other hand, is focused on cross-platform compatibility, handling traditionally difficult topics like resource synchronization automatically in most cases.

This has the happy side effect that WebGPU is easy to learn and use. It relies on existing features of the web platform for things like image and video loading, and leans into well-known JavaScript patterns like Promises for asynchronous operations. This helps keep the amount of boilerplate code needed to a minimum. You can get your first triangle on-screen in under 50 lines of code.

It's exciting to see all the new possibilities that WebGPU brings to the web platform and we're looking forward to seeing all the cool new use cases that you will find for WebGPU!

A vibrant ecosystem of libraries and frameworks has been built around WebGL, and that same ecosystem is eager to embrace WebGPU. Support for WebGPU is in-progress or already complete in many popular Javascript WebGL libraries, and in some cases taking advantage of the benefits of WebGPU might be as simple as changing a single flag!

Babylon.js, Construct 3, Google Earth, Google Meet, PlayCanvas, Sketchfab, Three.JS, TensorFlow.js, and Unity.

And this first release in Chrome 113 is just a start. While our initial release is for Windows, ChromeOS, and MacOS, we plan to bring WebGPU to the remaining platforms like Android and Linux in the near future.

And it’s not just the Chrome team that’s been working on launching WebGPU. Implementations are also in-progress in Firefox and WebKit as well.

Additionally, new features are already being designed at the W3C that can be exposed when available in hardware. For example: In Chrome we plan to enable support for 16 bit floating point numbers in shaders and the DP4a class of instructions soon for even more machine learning performance improvements.

WebGPU is an extensive API that unlocks amazing performance if you invest in it. Today we could only cover its benefits at a high level, but if you'd like to get a hands-on start with WebGPU, please check out our introductory Codelab, Your first WebGPU app , where you’ll build a GPU version of the classic Conway’s Game of Life. This codelab will walk you through the process step-by-step, so you can try it out even if it’s your first time doing GPU development.

The WebGPU samples are also a good place to get a feel for the API. They range from the traditional "hello triangle" to more complete rendering and compute pipelines, demonstrating a variety of techniques. Finally, check out our other resources .

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License , and code samples are licensed under the Apache 2.0 License . For details, see the Google Developers Site Policies . Java is a registered trademark of Oracle and/or its affiliates.

Last updated 2023-05-10 UTC.

WebGPU now available for testing in Safari Technology Preview

Dec 21, 2023

by Mike Wyrzykowski

WebGPU is a new standards-compliant API that enables high-performance 3D graphics and general-purpose computations on the Web. WebGPU programs are written in JavaScript but expose GPU functionality, allowing GPU computing to be used in Web content for the first time. Starting in Safari Technology Preview 185, WebGPU can be enabled for early testing and development.

To enable WebGPU, turn on the “WebGPU”, “GPU Process: DOM Rendering” and “GPU Process: Canvas Rendering” feature flags in the Feature Flags tab in Safari Preferences. If you don’t see the Feature Flags tab, you need to first check “ Show features for web developers ” in the Advanced tab.

Once you have WebGPU enabled in Safari Technology Preview 185, try out this example of WebGPU . It utilizes many of the best features of WebGPU.

WebGPU JavaScript API

The WebGPU API is accessed through JavaScript, similar to WebGL.

Creating a GPUDevice

In order to use WebGPU, a device must be created. Resources and pipeline state are created from a GPUDevice instance. To create a device with default limits and features which are supported on all devices supporting WebGPU, we can pass zero parameters to the invocations of requestAdapter and requestDevice .

Configuring a GPUCanvasContext

The GPUCanvasContext is an interface that allows you to configure how your content will be displayed in the corresponding HTMLCanvas element on the page.

Creating a GPURenderPipeline

A GPURenderPipeline or a corresponding GPUComputePipeline are used to configure the pipeline state of the graphics driver. This pipeline state is then used in a GPURenderPassEncoder or GPUComputePassEncoder as later illustrated.

Issuing draw calls

A GPURenderPassEncoder is created to send draw calls to the graphics driver. In the below example, we draw a simple triangle which contains three vertices. A GPURenderPassEncoder can also draw multiple instances of the same geometry or draw from an offset of a vertex buffer.

WebGPU Shading Language

WebGPU introduces WGSL, a platform independent shading language for the web. Here is an example of a WGSL shader source that would be passed in place of wgslSource in the above API call:

Try WebGPU and file bugs!

We’re very excited to have an early version of WebGPU and WGSL in the latest version of Safari Technology Preview. Please do try it out. Check out the public repository of WebGPU samples . And file bugs or issues you discover at bugs.webkit.org .

Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

Webkid115

Safari 16.0

Google Maps not working. Page initially loads ok. Then the page goes black with lines across the centre. I've tried it on other machines and browsers and it's working ok on them. Any one else experiencing this issue?

Mac mini, macOS 12.6

Posted on Sep 16, 2022 1:18 PM

Posted on Sep 19, 2022 12:34 PM

Hi. I found this solution and it worked for me:

https://www.youtube.com/watch?v=F1PKPhUj1w8

Basically from the “Develop” menu in Safari select “Experimental Features" and uncheck “WebGL via Metal” (to enable the “Develop” menu go to “Preferences”, select “Advanced” and check “Show Develop menu in menu bar”). After that Google Maps should start working again.

Similar questions

  • Safari maps broken after Version 16.0 (17614.1.25.9.10, 17614) I installed Safari Version 16.0 (17614.1.25.9.10, 17614) today, and try to enter google maps and get a black screen. Open it in Firefox and its working correctly, anyone with this problem? Cheers! 414 2
  • Safari 16.0--maps are squished on websites (MacBook Pro) This is particularly true of Google Maps, which are used by many websites. Location is enabled everywhere. The map displays correctly for a second, and then squishes to a thick line. All the colors of the map are there; areas are still active. Started right after upgrade to Safari 16.0. 314 1
  • safari_google map view_blackscreen Recently I checked goole map web on safari browser , after few seconds it turned into a black screen. Did anyone have same problems? And how can I solve this issue? Please see attached files. Hardware & Safari Spec:Mac mini (Late 2014) macOS Monterey 12.6, Safari version 16.0. 213 2

Loading page content

Page content loaded

Sep 19, 2022 12:34 PM in response to Webkid115

steveald

Sep 18, 2022 1:12 PM in response to Webkid115

Interactive maps do not render properly with Safari 16.0 (macOS 12.6) on my Mid-2015 15" MacBook Pro,

A Google Maps page (ex. https://www.google.com/maps/place/Washington,+DC) looks fine for 2 seconds. Then the map goes all black with shifting color lines of static across about 1/2" in the middle. Zooming, Layers, etc. all work as expected. The map stays black; the colored lines just shift around.

This also happens with Weather Underground's Hurricane Tracker map ( https://www.wunderground.com/hurricane/atlantic/2022/hurricane-f) - except it's a 3/8" wide solid bar with shifting colors.

Same thing with local new weather maps.

No Safari extensions are loaded. Restrictive Settings for the webpage are turned off. Opening a new window and loading a map looks fine - for about 2 seconds. Changing Display preferences doesn’t help.

Loading the same page in Chrome works fine.

safari webgl metal

Sep 20, 2022 3:52 PM in response to xengen

Might have spoken too soon.

WebGL via Metal is still unchecked. But, when playing with Layers, it keeps redrawing the map and this appears:

safari webgl metal

Worse, selecting Layers > Satellite results in:

safari webgl metal

Unchecking "Automatic graphics switching" in the Battery System Preferences did not help.

The YouTube video's Written Guide ( https://www.droidwin.com/google-maps-not-working-in-safari-16-macos-12-6-fixed/ ) says the issue is mostly happening with older Macs - like my 2015 MacBook Pro. So, their final option of switching to Chrome may be my best option.

DD445

Sep 17, 2022 9:29 AM in response to Webkid115

Yes, most sites I've visited with Safari 16 that contain "movable graphics" show up as a single thin horizontal line running the width of the page. Games, some Facebook, most any site with a movable graphic has stopped working. Needless to say, this is a real problem. Everything appears to be working okay in Firefox though!

Sep 18, 2022 1:23 PM in response to steveald

That's what I see, Bing and OS maps also do the same. As stated chrome and Firefox work just fine. I'm currently using google earth and fire Fox until a fix comes along. Interestingly if you have google map embedded into a webpage it works fine.

Sep 19, 2022 1:20 PM in response to steveald

Oddly enough, about 9 - 10 months ago, a similar issue was fixed by checking WebGL via Metal - not unchecking it ( https://discussions.apple.com/search?q=WebGL+via+Metal ).

lkrupp

Sep 17, 2022 1:37 PM in response to Webkid115

Safari 16, Monterey 12.6 and maps.google.com working flawlessly here. No issues whatsoever.

Try clearing history and caches.

Sep 18, 2022 3:44 AM in response to lkrupp

Cleared History and cache out. No improvement. I'm seeing the same as DD445's response moving graphics are and issue in version 16. Firefox and Safari Ver 15 both work fine with moving graphics.

Sep 18, 2022 1:20 PM in response to steveald

That 2nd link should be: https://www.wunderground.com/hurricane/atlantic/2022/hurricane-fiona

Sep 19, 2022 1:02 PM in response to guido151

guido151, you are a true genius! Thank you for this easy fix. I'll be sure to pass this on to @AppleSupport (and give you full credit) because they didn't have a solution for me.

Sep 19, 2022 1:12 PM in response to guido151

Worked for me too. Didn't even have to quit and restart Safari - much less reboot. Thanks!

I wonder if this is a useful option to reselect when I upgrade to a newer (M1/M2) MacBook?

Sep 19, 2022 1:15 PM in response to guido151

This worked for me too. Thanks for the fix.

xengen

Sep 20, 2022 2:50 PM in response to guido151

This did the trick! Thank you so much!

S. Madigan

Sep 24, 2022 11:52 AM in response to guido151

What DDD445 said! It fixed the problem, let alone I didn't even know there was a 'Develop' list. Thank you again!!!

Sep 28, 2022 6:16 PM in response to guido151

Thanks. This cleared up the problem I had with Google Maps and also with windy.com.

Horrible 3D/Three.js performance in latest Safari on macOS

I’m currently running Safari Version 14.1 (16611.1.21.161.6) on macOS 11.3.1 (20E241) and since about last week, our app ( https://app.shadowmap.org ) seems to run ridiculously slow on this config. I am pretty convinced it is caused by the latest update for Safari.

Other browsers including Brave and Firefox on the same machine/OS run still fine. Safari on iOS behaves as well as ever too.

Does anyone have infos about what happened to Safari? Maybe has an idea how to compensate/fix the performance drop?

Do you see this performance degradation with other WebGL apps, too? What about the official three.js examples? three.js examples

Like @Mugen87 said you should try track down the cause of the performance drop, the easiest way is starting with the official examples and possibly specific features you use that are also showcased in them, if everything works fine you can start isolating the issue by disabling features, reducing what you render or process.

Did you measured the performance yet?

Very good point! I just tried some of the examples in Safari and – yes – they work significantly worse than some weeks ago. This even leads to the whole browser UI freezing, the machine becoming unresponsive. Again, same examples on the same machine in Firefox/Brave run perfectly smooth. Seems to be a bigger Safari issue.

A thought: renderer = new THREE.WebGLRenderer({ powerPreference: "high-performance" }); – maybe this isn’t activated or something?

It’s best if you report the issue right here: https://bugs.webkit.org/

Whether this problem is related to powerPreference or not is hard to tell. I mean you can try different renderer settings out and see if things improve. But it’s probably best if the devs from WebKit investigate the issue.

@molzer Did you ever find the culprit in safari? I’m seeing the same slowdowns on my machine for examples and other stuff too, but only in safari, both chrome and firefox are fine.

No, unfortunately no update. Also Safari Technology Preview is even worse. I wonder whether it’s WebGL apps in general or only Three.js?

What machine do you have? On my side it’s a 2016 MBP with Radeon Pro 455 and integrated Intel HD 530 (doesn’t matter which one is active, the performance is a catastrophy). The other one is a 16" MBP.

I have a 2019 16" MBP, AMD Radeon Pro 5600M 8 GB, I think it’s a software issue with safari 14, I’m running macOS 11.4, on older laptops in our company running safari 13, same demo runs fine. I found a few issues that may be related: https://bugs.webkit.org/show_bug.cgi?id=218949 https://bugs.webkit.org/show_bug.cgi?id=220846

Thanks for the links, @Lasse – it’s weird and fragmented. E.g., regarding powerPreference , on my MBP, the performance with the integrated GPU is now also far worse than before.

:pray:

I just tested the latest Safari Technology preview (15.0, R128) on macOS 11.5 and Shadowmap runs perfectly fine, maybe even faster! If that’s where this all is going, I’m happy and hope for fall …

Bildschirmfoto 2021-07-28 um 17.08.54

On the other hand, some three.js demos are still super slow (e.g., three.js examples ).

Any other updates from other people affected by this?

The latest 129 preview release fixes the bug. The bug came from not respecting the request to use the discrete GPU it seems: Release Notes for Safari Technology Preview 129 | WebKit https://twitter.com/Supermoos/status/1423196071711363076

:raised_hands:

Seems like the bug has re-appeared: 227408 – [macOS] WebGL content is unable to use the discrete GPU

:upside_down_face:

Just upgraded to Safari 15 on macOS 11.6 and the performance is still bad. Just confirming the Technology Preview’s trajectory. Unfortunately.

reporting from march 2022, still terrible performance. it is very annoying to say the least. tried shadowmap and my own project along with the examples in the docs. chrome just has more than double the framerate. very weird

Oh really? The problem disappeared after upgrading to macOS 12, Monterey. Make sure to have the “Experimental Features”:

  • WebGL via Metal

Runs super smooth since then.

With latest iOS and macOS enabling WebGL 2.0 in Safari should not be necessary anymore since it is enabled by default.

that’s actually the first thing I checked before posting here and both were enabled (as @Mugen87 pointed out). Including GPU process: canvas rendering and WebGL. All on macOS kinda sad but I lowkey have given up trying, working pretty well on chrome, almost triple the frame rate and loading speed. I will test it out later on a retired iPhone X sometime later.

Not sure if this is the same issue coming back to haunt us, vs. a new one, but I’ve run into a situation where Safari is using the integrated GPU instead of the dedicated GPU: Horrible Safari Performance - #2 by Mike_D

Related Topics

IMAGES

  1. How do I enable WebGl support in Apple's Safari?

    safari webgl metal

  2. Create an interactive liquid metal ball with WebGL

    safari webgl metal

  3. iOS 15.4 Webgl via Metal issue · Issue #13486 · openlayers/openlayers

    safari webgl metal

  4. New WebKit Features in Safari 15

    safari webgl metal

  5. Google Maps not working in Safari 16 macOS 12.6 [Fixed]

    safari webgl metal

  6. Experimented Metal based WebGL vs OpenGL based WebGL benchmarks on macOS

    safari webgl metal

VIDEO

  1. EFT Questing solo for peacekeeper

  2. Google 率先實現 WebGPU 顯示卡優勢,Firefox 與 Safari 緊隨腳步

COMMENTS

  1. Safari feature WebGL via Metal have issue on iOS 15.4 #10659

    Fix Apple enables "WebGL via Metal" by default on iOS 15.4. Tencent/libpag#320. pandamicro closed this as completed on Jun 15, 2022. pandamicro mentioned this issue on Nov 9, 2022. Empty project build web-mobile or web-desktop lags on safari browser (frame rate only 30+) #12790.

  2. New WebKit Features in Safari 15

    In addition, the WebGL implementation now runs on top of Metal for better performance. ... Safari 15 includes several media improvements for users and developers. For example, built-in media controls now have Playback Speed and Chapters menus. Plus, the language/subtitle tracks menu is now available on iOS and iPadOS.

  3. iOS 15.4 Webgl via Metal issue #13486

    @ahocevar I can confirm that, since iOS 15.4, some WebGL TileLayers are broken. The official WebGL Sea Level example is one example of this: As noted by @jeroenvheel, disabling "Webgl via Metal" in the Safari advanced settings fixes this (I think it has become the default since iOS 15.4). Also reproducible with macOS Safari since updating to 12.3.

  4. Rendering Bug with Metal (iOs, macOS)

    But I came up with a basic example to showcase our problem: three.js webgl - Webkit METAL Z-fighting. We can reproduce the bug by using "Safari Technology Preview" on MacOS. Using a "simple" ShaderPass like below makes the z-fighting problem really visible: vertexShader: varying vec2 vUv; void main() {. vUv = uv;

  5. WebGL Performance on Safari and Apple Vision Pro

    Here are a few more characteristic issues you might encounter when working with WebGL on Safari: Uniform Buffers Because of how Apple's graphics API Metal differs from WebGL, Safari needs to emulate a WebGL-style uniform buffer under the hood. This emulation incurs some difficulty in predicting the performance of UBOs: some uses will be fine ...

  6. Develop advanced web content

    Develop advanced web content. Develop in JavaScript, WebGL, or WebAssembly? Learn how the latest updates to Safari and WebKit — including language changes to class syntax — can help simplify your development process, enhance performance, and improve security. We'll explore several web APIs that can help provide better interoperability and ...

  7. WebGPU for Metal Developers, Part One

    As such it has never been capable of exploiting the full power of the underlying GPU, even as desktop APIs like DirectX 12, Metal, and Vulkan debuted and became popular. Furthermore, Apple has been slow to build out full support for WebGL 2: as of this writing, it remains an Experimental Feature in Safari).

  8. Khronos Blog

    Safari now runs WebGL on top of Metal on recent iOS and macOS devices. Collaborative work continues among the Apple and Google engineering teams, including adopting top-of-tree ANGLE into WebKit, creating a common codebase for development going forward, and switching Chrome to use ANGLE's Metal backend as well. ...

  9. WebGL and WebGPU Updates

    Safari 15 runs WebGL on top of Metal on recent iOS and macOS devices Apple and Google engineering teams are collaborating on: Upstreaming Apple's work to the ANGLE repository Passing the underlying OpenGL ES 2.0 and 3.0 conformance tests which affect WebGL Addressing key functionality issues

  10. Google Chrome 94 adds new WebGPU API with Apple Metal support

    Chrome 94 adds Apple Metal support. With the Chrome 94 beta for Mac, Windows, Linux, and Android, Google is rolling out its new WebGPU API in trial form. It hopes to ship the API out to everyone ...

  11. WebGPU and WSL in Safari

    WebGPU is a new API being developed by Apple and others in the W3C which enables high-performance 3D graphics and data-parallel computation on the Web. This API represents a significant improvement over the existing WebGL API in both performance and ease of use. Starting in Safari Technology Preview release 91, beta support is available for WebGPU API and WSL, our proposal for the WebGPU ...

  12. MetalANGLE

    This is a fork of Google's ANGLE project. It adds Metal API backend support. Apple announced OpenGL (ES) deprecation in 2018. So the purpose of MetalANGLE is to allow OpenGL ES applications to continue operate on Apple platforms by translating OpenGL ES draw calls to Metal draw calls under the hood. It also supports OpenGL ES & Metal's interop.

  13. What to do if you are experiencing slow performance in Safari 14 and 15

    On Macs using Intel processor, Safari versions 14, 15 and Safari Technology Preview use the WebGL content through an experimental feature called "WebGL via Metal".In our testing, this implementation can decrease performance significantly. In addition, depending on the exact version of your Safari browser it may be affected by an underlying bug in the rendering WebKit engine which prevents ...

  14. How To Enable Webgl On Safari

    Enabling WebGL on Safari is a pivotal step that unlocks the browser's capability to render immersive 3D graphics, interactive content, and visually rich web experiences. By configuring Safari to harness the full potential of WebGL, users can indulge in a seamless and captivating browsing journey, encountering stunning visuals and dynamic ...

  15. WebGL Working Group Updates

    WebGL 2.0 In Safari Updates WebGL 2.0 is enabled by default in Safari 15! Uses ANGLE's Metal backend Huge thanks to Lê Hoàng Quy ền for the original contribution Credit to Kyle Piddington and team from Apple for the direct -to-Metal translator The latest code can be tested on both macOS and iOS macOS: install macOS 12 (Monterey) Betas

  16. Chrome 94 beta adds WebGPU API with support for Metal

    Google this week announced the beta release of Chrome 94, the next update to Google's desktop web browser. In addition to general improvements, the update also adds support for the new WebGPU ...

  17. SAFARI 15.2 WEBGL performance disaster

    Posted 1 year ago by. pirla. In case anyone else lands here via Google. The slowdown I've seen is most severe when WebGL 2.0 is enabled. So if you are in developer mode in Safari you can go to "Develop" -> "Experimental Features" -> untick "WebGL 2.0". This will significantly improve performance if the page you're trying to view also supports ...

  18. Migrating OpenGL Code to Metal

    OpenGL. Mixing Metal and OpenGL Rendering in a View. Draw with Metal and OpenGL in the same view using an interoperable texture. Replace your app's deprecated OpenGL code with Metal.

  19. iOS/iPadOS 16.3 WebGL via Metal Feature issue

    I found that the issue could be the Safari experimental feature "WebGL via Metal" (Settings App → Safari → detail → Experimental Features → "WebGL via Metal") Disabling "WebGL via Metal" feature the test results are. iPhone XR iOS 16.3.1 - Safari - A: page crashes, B: ok, C: ok. iPad Air 3 iPadOS 16.3.1 - Safari - A: page ...

  20. WebGPU: Unlocking modern GPU access in the browser

    WebGPU is the successor to WebGL bringing the advancements of this new class of modern APIs to the Web. WebGPU unlocks a lot of new GPU programming possibilities in the browser. It better reflects how modern GPU hardware works, while also laying a foundation for more advanced GPU capabilities in the future. The API has been baking in the W3C ...

  21. WebGPU now available for testing in Safari Technology Preview

    Once you have WebGPU enabled in Safari Technology Preview 185, try out this example of WebGPU. It utilizes many of the best features of WebGPU. WebGPU JavaScript API. The WebGPU API is accessed through JavaScript, similar to WebGL. Creating a GPUDevice. In order to use WebGPU, a device must be created.

  22. Safari 16.0

    Hi. I found this solution and it worked for me: Basically from the "Develop" menu in Safari select "Experimental Features" and uncheck "WebGL via Metal" (to enable the "Develop" menu go to "Preferences", select "Advanced" and check "Show Develop menu in menu bar"). After that Google Maps should start working again.

  23. Horrible 3D/Three.js performance in latest Safari on macOS

    WebGL 2.0; WebGL via Metal; enabled. Runs super smooth since then. Mugen87 March 5, 2022, 8:35am 18. With latest iOS and macOS enabling WebGL 2.0 in Safari should not be necessary anymore since it is enabled by default. geet March 6, 2022, 4:42pm 19. that's actually the first ...

  24. webgl

    I precisely require this for the WebGL 2.0 as well as WebGL via Metal experimental features. Is it possible to check whether they're active via some API call?