three.js: GPGPU examples do not work on iPadOS Safari

Description of the problem

These Three.js examples do not run on Safari iPadOS 13.5.1. This could possibly be the case on other iOS environments like iPhones, but I don’t have one to test it out on. It looks like the GPGPU examples don’t run the compute shader and the only warning are these:

THREE.WebGLRenderer: EXT_frag_depth extension not supported.
THREE.WebGLRenderer: WEBGL_draw_buffers extension not supported.

The examples run fine on desktop Safari. At one point, this was due to OES_texture_float as described in this issue. But, it looks like GPUComputeRenderer.js handles this check and doesn’t trigger an error message.

Three.js version
  • Dev
  • r118
Browser
  • All of them
  • Chrome
  • Firefox
  • Internet Explorer
  • Mobile Safari
OS
  • All of them
  • Windows
  • macOS
  • Linux
  • Android
  • iOS
Hardware Requirements (graphics card, VR Device, …)

This was found on iPad Pro Gen 2 (~2018 model). Running iPad OS 13.5.1

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Comments: 35 (31 by maintainers)

Most upvoted comments

this would be mostly @greggman code. Gregg, do you have any plan regarding detection, or do you mind if we package most o those functions in a single lib?

Further reference, this WebGL Fluid Simulation (not based on Three.js) works: https://paveldogreat.github.io/WebGL-Fluid-Simulation/

I’m going to dig into what might be different on how he’s doing GPGPU style computation to work on iPads.

I have a iPhone XR for testing and they do work there… I should be able to try them on an iPad Pro next weekend.

That check should not be needed in iOS 14? Also though what that code is doing is pretty simple. You could just three.js instead in probably far fewer lines of code.

I’ve been thinking of building a third party lib, like Modernizr, that tries to give a clear idea of what the device running your WebGL code can handle. WDYT?

Sounds good. I’ll be sure to update the examples in this way. Thanks for all your input!

It would be easy to adopt this into GPUComputationRenderer.js

IMHO, adding a feature detection utility to the examples is a good idea, but I’d call it from the app, not from GPUComputationRenderer.

Maybe follow the .setDataType() API of EXRLoader and RGBELoader, etc.

gpuCompute = new GPUComputationRenderer( WIDTH, WIDTH, renderer )
		.setDataType( THREE.FloatType );

Perhaps leave the default as FloatType and check for the capability in the app itself.

Sounds good to me! 👌