Your browser doesn't appear to support the HTML5 canvas element.

Tuesday, 14 March 2023


If you are paying attention close enough, you might have noticed that in the background of this blog is a very simple and strightforward wave simulation using GLSL or WebGL. It has specifically been written in accordance with the OpenGL Shading Language, Second Edition [1,2] text in mind so it is compatible with every single WebGL implementation ever conceived, and is almost completely decoupled from the browser. It has some intentional 'glitch' in it, which is a reference to the analog days of Sutherland's work.

Specifically, the simulation uses a textbook implementation of GLSL, as follows:

  • GLSL 1.2
  • OpenGL ES 2.0
  • WebGL 1.0

The only coupling to the browser is the opening of a GL context, and if one clicks on the animation in the right place, an "un-project" operation that unwinds the Z-division takes place so that the fragment that underlies the mouse cursor can be calculated and the scene can be rotated using a very primitive rotation scheme which includes gimble lock (no quarternions here!). Both are extrordinarilly simple 3D graphics operations that should not affect rendering at all and is the absolute minimum level of coupling one might expect. In short, it is the perfect test of the most basic of WebGL capability.

The un-project operation is written with the minimal amount of code required and uses a little linear algebra trick to do it very efficiently. Feel free to inspect the code to see how it's done.

Current State

Update 26-Jun-23: After much trial and error, and testing on many many devices, I now have successfully isolated three separate WebGL bugs. Now that I have the three bugs properly isolated, I'm starting the writeup and hope to submit the following bug reports in the next week or two, as follows:
  1. Incorrect rendering of WebGL 1.0 scene in Google Chrome
  2. WebGL rendering heisenbug causes GL context to crash in Chrome after handling some N fragments
  3. WebGL rendering heisenbug causes GL context to incorrectly render scene after handling some N fragments

The current state as at 14-March-2023 is that Chrome and other browsers are not able to run this animation for more than 24 hours without crashing, and on the latest versions of Chrome released early March, the animation has now slowed down to ridiculous FPS levels. Previously the animation ran at well over 30 FPS on most devices, but would crash after 24 hours.

This animation will quite happily run on an old iPad running Safari, however Chrome currently seems to be struggling. The number of vertices and the the number of sin() operations that it needs to calculate is well within the capabilities of all modern processors, including those found in i-devices such as phones and tablets on which one can play a typical game.

Example of correct rendering on all modern browsers including Safari on iPad

Example of incorrect rendering on Chrome 111.0.5563.111 (64-bit) as at 23-Mar-23

Brave Browser (based on Chromium) renders correctly, but is horrendously slow in the GA branch (Beta currently works fine). I'm not sure if this is a Linux vs. Windows issue or discrete vs. embedded GPU at this stage, will investigate further when I have time.

NB. As at 14-March-2023, on Brave Browser 1.49.120 on Windows with a Discrete GPU the simulation struggles to render 5 FPS, and on Brave Browser 1.50.85 (beta) on Linux with an embedded GPU it works OK, but I can point to other vizualisation artefacts elsewhere that 1.50.85 cannot handle (but which previous versions of Brave/Chrome could), for example, on the homepage of, the Humanized Data Robot should gently move around the screen with a slight parallax effect if one moves the mouse over it. Why is the rendering engine in Chrome suddenly regressing, and why is it not using the GPU? This wave simulation should be able to run in it's entirety on SIMD architecture and the Humanized Data Robot used to be rendering flawlessly. What is going on?

At 30 FPS, the wave simulation requires around 75 MFLOPS of processing power. To put that into perspective, the first Sun Microsystems SPARC Station released in 1989 was able to calculate 16.2 MIPS (similar to MFLOPS), and the SPARC Station 2 (released 1991) could calculate nearly 30 MIPS. That was over 30 years ago, and a SPARC Station 2 machine had enough compute power that it could happily calculate the same wave simulation at around 10-15 FPS without vizualising it, but actually at 2-5 FPS once one implements a GPU pipeline (thank god SGI bought out IRIS GL).

I still have my copy of the original OpenGL Programming Guide (1st edition, 6th printing) that came with my Silicon Graphics Indy workstation. It was a curious book, and I implemented my first OpenGL version of these wave simulations in 1996 according to it, so I'm quite familiar with what to expect. An Indy could handle this - with a bit of careful tuning - quite well. The hardness of this vizualisation is the tremendous number of sin() operations, and the cosine()s used to take their derivative, so it really does test the compute power of a graphics pipeline quite well - if the machine or the implementation isn't up to it, these calculations will bring it to it's knees quite quickly.

Fast-forward to 2023, and a basic i7 cannot run the simulation at 30FPS! To put things into perspective, a 2010 era Intel i7 980 XE is capable of over 100 GFLOPS (about 1000x more processing power than whats required to do 75 MFLOPS), and that's without engaging any discrete or integrated SIMD GPU cores. Simply put, the animation in the background of this blog should be trivial for any computing device available today, and should run without interruption.

Lets see how well things progress through March and if things improve.


[1] Rost, Randi J., and John M. Kessenich. OpenGL Shading Language. 2nd ed. Addison-Wesley, 2006. OpenGL 2.0 + GLSL 1.10

[2] Shreiner, Dave. OpenGL Programming Guide the Official Guide to Learning OpenGL, Version 2. 5th ed. Upper Saddle River, NJ u.a: Addison-Wesley, 2006.


Joe Pea (trusktr) said...


Andrew (AP) Prendergast said...

Hey mate,

Great to hear from you!

1. thank Elon for sticking up for me when NSA tried to kibosh my Twitter. They tried Reddit and a few others as well, I can't believe NSA thinks they can character assassinate me in Silicon Valley.

2. Can we setup a regular Zoom or WebEx call - much to discuss? Like moving useless .coms to salt lake city, and sorting out the Mormons so they start doing their job again and managing the place properly.

3. I know how to do truth GPT.

4. I also know how to do forensic IR, I'm part of the Melbourne InforRec team, possibly one of the most senior. Forensic IR works on Bing, it also works on LLMs. They are just information retrieval systems.

5. Also, CIA put me on a list in 2012 which has caused me problems, something to do with AI. Can Elon please get me off it? They killed my dad in 2013 because if it while he was in the USA.

6. I can do stochastic sensor merging that's resilient, eg, it can handle sensor uncertainty/failure, and when everything is running fine I don't get those 0.5M artefacts that come out of nowhere.

There are few people in the world still practicing CompSci that can do that stuff. DOD chassifies it as top secret, just like Benfords law (HAHA). So in america we say Centralised Discrete Regularization Filter (not sensor merging), just like we call Benfords Law Zipfs Law in the US.

7. What do you think of ProbabilisticLogic.AI ? Don't worry about the division by zero problem, it goes away when you do the proof in a probabilistic space but its outside of elementary level. We just assume what's there as an axiom, either its infinity or undefined doesnt change the meaning anyways for the purposes of elementary probability.

FYI, Australian Bayesian is Probabilistic, and it's logic based.

So we have east coast, west cost and soon Australian. Now Korb has retired, I think I might be it down here :)

8. I worked out where that stupid IRS digital font is stored. Are they still using it? Its somewhere rin the same building as Mae West, I think I know which room.

9. NSA Has two rooms in that building. One on the Floor Mae-West is on, the other is on the same floor as SJC.

10. All the established crytosystems are falling: Public Key, S-Box (DES, 3DES, AES), SHA, all dying. We need a new approach, one that doesn't run the same key material through an XOR operation. I have something I'm calling Prendergast-Reiman, but it's so strong it scares the NSA. It should protect your satellite comms. though. I have the 30 years of cryptography research and the Stanford creds to sign-off on cryptography.

11. Oh and I still owe you $1000.

Pls email or Signal me: contact details on LinkedIn.