7

I have some javascript/webgl code. I want to have some idea of whether it will work for someone with a different browser/machine/gpu.

This is difficult, because there's so much diversity in support for features. For example, on my machines, I can pass GL.FLOAT to readPixels, but I know that really I should only use GL.UNSIGNED_BYTE. Another example is that, when webgl compiles a fragment shader at runtime, one of my machines will accept vec4(1, 0, 0, 0) while the other will complain that implicit casts from int to float aren't allowed. I even have some code that works on my phone in chrome, but not on my phone in firefox, for no discernible reason.

How can I test if my webgl code conforms to the standard? How can I estimate how many users it will work for in practice?

Maybe there exist interpreters with minimal feature sets that run the code, and if it works in the interpreter you can be sure it will work for most users? Or maybe there are services that run your code on many machines? Maybe a particular old phone is a good 'minimal support' candidate for testing?

(I tried using SauceLabs to run it on a variety of machines, but they don't support webgl so that's a bust. Also there's always the fallback of just waiting for people to complain...)

Community
  • 1
Craig Gidney
  • 831
  • 7
  • 16
  • 1
    `when webgl compiles a fragment shader at runtime (... WHYYYYYYyyyyy)` What else do you expect it to do? A shader is code that is executed on the GPU; how's it going to run if it's not compiled? – Mason Wheeler Apr 26 '16 at 18:33
  • Why? You can get away with distributing binaries for the main game code because you know the instruction set and basic architecture will be the same for every system you're developing this build for, but that assumption is nowhere even close to being valid for GPU hardware, so what other choice is there but to distribute source and compile it on the target system? – Mason Wheeler Apr 26 '16 at 18:42
  • 3
    No, that's the whole point: the same thing is *not* true of CPUs. If you're developing a program for Windows, you can assume the existence of the standard x86 (or x64) architecture, if you're developing for Android, you can assume a JVM, and so on. But GPU hardware hasn't come anywhere near that level of homogeneity. – Mason Wheeler Apr 26 '16 at 18:52
  • Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/38931/discussion-between-craig-gidney-and-mason-wheeler). – Craig Gidney Apr 26 '16 at 19:34
  • Sorry to contradict you but you can assume the presence of a Dalvik Virtual Machine or Android Runtime under Android but DVM != JVM. – gouessej Oct 12 '17 at 10:52

1 Answers1

1

A combination of benchmarks for each class of device is necessary:

Create a set of benchmarking tools by selecting a benchmark in each domain to get to a comprehensive view of platform performance.

Data collection based on community effort is a necessity:

WebGL Stats

As well as defining criteria for determining benchmark quality:

Intel believes that good benchmarks should meet both of these two basic criteria:

  1. The benchmark uses real applications or benchmark applications executing real workloads, and be based on real-world scenarios and workflows

  2. The benchmark was designed with industry stakeholder input baked into the development process, guided by industry best practices and transparency

Some WebGL implementations support the failIfMajorPerformanceCaveat API:

var canvas = document.getElementById('renderCanvas');
var context = canvas.getContext('webgl', 
    { 
     failIfMajorPerformanceCaveat: true 
    }
);

When a context is requested on a computer with a block-listed driver, the failIfMajorPerformanceCaveat flag prevents IE from returning a software context, and instead returns no context.

To use it you just have to add it as an option to the getContext function:

Using this attribute, you can know that the current device isn't powerful or secure enough to run hardware accelerated 3D rendering. Then you can decide to use the software renderer, or if you prefer, let the user know their computer or graphics card aren't supported.

References

Paul Sweatte
  • 382
  • 2
  • 15