Problems in Safari iOS on mediump

[gregtatum]

It seems like snoise(vec3) and maybe others are only working using precision highp float; on Safari in iOS. I spent a bit of time debugging some older shaders of mine that aren't working anymore and this appeared to fix it.

[gregtatum]

This random codepen I found seems to exhibit the behavior: https://codepen.io/ykob/pen/qbwLaY

I'm not sure if it's the exact latest version of the shader in this repo.

Steps to reproduce:

• Open https://codepen.io/ykob/pen/qbwLaY in iOS Safari
• Codepen is blank
• Change shader from mediump to highp.
• Codepen now works.

[stegu]

Yes, high precision is required for the functions to work in WebGL. All functions require it, and it's not easy to fix, because the code that requires high precision is not the floating point computations, but the integers for the hashing. This is not a bug, it's simply a requirement for the algorithm to work. I will add it to the documentation to make this more clear.

[tgrajewski]

The wiki page still says

NOTE: You do not need a super fast GPU to use these functions. They are useful even on low end hardware, old hardware and embedded OpenGL ES hardware with low performance.

suggesting that mediump would be supported, which is not true.

[stegu]

I don't agree that this suggests mediump support, but I will clarify that passage. The functions worked on my then-current Samsung Note 1 smartphone which had a GPU inferior to anything you would find even in budget smartphones today, and it ran fine on my contemporary generation of the Raspberry Pi, also a stone age GPU with modern measures. That was the frame of reference I had when I wrote that passage some time in 2015 or so. Which platforms are you working on that still don't have highp support? My experience is almost exclusively with desktop/laptop hardware, various Samsung smartphones I have owned myself and my wife's iPhones of various older, company-issued models. (Her employer is not a cheapskate, but their security certification of new hardware takes longer than the generation changes, which is a major nuisance.) Den fre 25 mars 2022 22:10Tomasz Grajewski ***@***.***> skrev:

…

The wiki page <https://github.com/ashima/webgl-noise/wiki> still says NOTE: You do not need a super fast GPU to use these functions. They are useful even on low end hardware, old hardware and embedded OpenGL ES hardware with low performance. suggesting that mediump would be supported, which is not true. — Reply to this email directly, view it on GitHub <#25 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFGK2VCGOUTAOWWBKN63CTVBYTTPANCNFSM5DXIAJ2A> . You are receiving this because you commented.Message ID: ***@***.***>

[tgrajewski]

Thanks, would be great if mediump support would be stated plainly somewhere for this repository.
It's very hard to obtain noise/random functions that work with mediump well, if at all.

I'm working on games and targeting mostly mobile devices. From my experience even if a smartphone supports highp it is usually slower than mediump. Also there is still small percentage of devices not supporting highp in fragment shaders at all, but I don't collect details about this. Because of these issues, all my fragment shaders always use mediump.

[stegu]

Sounds like I have a task, then: create some noise functions that work with mediump ! :) Do these devices have integer support (WebGL 2)? I suppose integer precision is specified separately from float precision, and then the changes required are minimal, provided that integer operations have reasonable performance. (The first desktop GPUs with integer support were dead slow with integer math, so I am not taking this for granted.) I could probably restrict the code to work with only 16-bit half-floats and no integers, although it will probably require some workarounds that might be slow. I have no clear plan on how to do this, but I'm pretty sure it *can* be done. And, not least importantly, how would you suggest I test this? My current Samsung S21 seems to use "highp" no matter what I specify for the precision, but I might be doing my testing wrong. My experience with mobile devices is limited, and I have access only to two smartphones: my own Samsung S21 and my wife's somewhat dated iPhone. Could I perhaps persuade you to provide some assistance in testing? I would be happy to add you as a developer to a Github repo for this purpose.

[tgrajewski]

Hey, awesome! Yes, I'm in :)

Here is a list of some devices that do not support highp at all in fragment shaders:

• Huawei P8 Lite (ALE-L21)
• Samsung Galaxy S5 mini (SM-G800F)
• Samsung Galaxy S20+ Pro
• Samsung Galaxy J3 (SM-J320FN)
• Samsung Galaxy S3 (GT-I9305)
• Lenovo Tab 2 A7-10F

Unfortunately I don't own any of them, but I have some devices with mediump support, so I can test on those if needed. I'm using WebGL 1, but don't have data on int precision for now.

[stegu]

I got "mediump" working just now on my Samsung S21 (classic stupid mistake: I just needed to wait for the server refresh of the HTML test file I edited), so I will get back to you about testing once I get something working on this one device. So far, I have only broken the function by putting "precision mediump float" at the top, but now I can at least see for myself when (if) I fix it. Let me just repeat my question from before: is WebGL 2 with a mix of mostly floats and a few integers a reasonable target? That should be relatively quick and easy, while a WebGL 1 compatible version with half-floats only would require more thought. Also, reading the letter of the WebGL 2 spec it says that "mediump float" could actually be the 10-bit kind-of-floats that I can't see how they could handle anything beyond simple color blending, and "highp float" could be the one that maps to 16-bit "half float". Is that a thing, or can I assume that "mediump" means 16-bit floats? On my Samsung S21, "highp" seems to give me 32-bit "proper" floats in fragment shaders, and with very reasonable performance, and "mediump" seems to be 16-bit half-floats.

[tgrajewski]

WebGL 2 is not good, too low adoption, it needs few more years.

Regarding float precision for mediump, then I think it's the 16-bit half/fixed size most common, yes.

[stegu]

OK. The feature gap between WebGL 1 and 2 (GLSL ES 1.00 vs. GLSL ES 3.00) is a rather wide one, while the differences between GLSL ES 3.00 and the upcoming WGSL are mostly syntactic in nature. For the next few years I guess there will be a need to support two versions of GLSL as well as WGSL. Oh, well. It's not as if "the Web" has ever been a well defined and easy platform to target. To get a more clear picture of where we stand, I made a test page. When/if you have the time and opportunity, you could check this out: https://stegu.github.io/psrdnoise/test/showprecision.html There's no hurry with this, absolutely no obligations, and in any case I don't expect you to give me more than a general hunch, but thanks in advance for any help! To me, the important information would be whether you see any important devices/platforms that report *less* than 16 bits for "mediump float", and whether the "int" type has support even where WebGL 2 is reported as "not supported", which would imply that the *device* is WebGL2 ready even though the browser is not. It would be interesting to know also if any device supports 32-bit integers but not 32-bit floats. I suppose that's not the case, but I'm just guessing. Actual field testing on real devices is infinitely more useful than guesswork and reading formal specs.

[stegu]

A first attempt at mediump-tolerant 2D noise, in the recently published "psrdnoise" style: https://stegu.github.io/psrdnoise/test/psrdnoise2-mediump.html It seems to work, but using "mediump" precision has some nasty side effects: mediump texture coordinates makes the pattern blocky if you try to evaluate noise too far from the origin, and when you leave the page running for a few minutes the "time" uniform parameter for animation starts to stair-step and make the animation of "alpha" visibly jumpy. There might be more errors and flaws in there, this is a first attempt. To avoid overflow in the half-float hash, the repeat tile is smaller, 49x98 units, and the pattern might not be as good looking, because the restrictions for what I could use for the hash function was tight. This is not the final word on the hash, but there are now a lot fewer options to try to improve the "random look" of the pattern. On top of that, the hash function needs a ton of intermediate mod() operations to prevent overflow and truncation in the "half-float-integer" math. Therefore, this is not obviously faster than a highp version, but it might be, and it does work in mediump. Unless you find a way to break it, in which case I will gladly try to fix it. That's what "help with testing" means, after all. For reference, this is the 32-bit highp version with the "psrdnoise" that is oficially published on that github repo: https://stegu.github.io/psrdnoise/test/psrdnoise2-highp.html

[tgrajewski]

This is what I get for:

• Samsung Galaxy A9 (2018) (SM-A920F)
• Samsung Galaxy M51 (SM-M515F/DSN)
• Samsung Galaxy A11
• Samsung Galaxy S22
• Vivo Y50
• Xiaomi Redmi Note 7
• Xiaomi Redmi Note 8
• OnePlus 7
• OnePlus 7T
• Samsung Galaxy Tab 4
• Samsung Galaxy Tab S4
• Samsung Galaxy Tab S5e

• Huawei P30 Lite
• Samsung Galaxy S6 (SM-920F)
• Samsung Galaxy A10
• Samsung Galaxy A8
• Samsung Galaxy A51
• Samsung Galaxy S5
• Samsung Galaxy J7 Prime
• Samsung Galaxy Note 4
• Oppo Reno 6
• Vivo V21
• Xiaomi Redmi Note 9
• Moto G7 Play
• Moto G9 Play
• Google Pixel 6

• iPhone X (Safari v11)

• iPhone 12 Pro (Safari v14.4)

• Oppo Reno 3 Pro
• Vivo Y21

• Motorola Moto G 2nd Gen

[stegu]

Interesting that compared to that older A9, my reasonably fresh Samsung A21 has added lower precisions (16-bit for both lowp and mediump int *and* float) to the vertex stage. I have bothered friends and family with checking the test page as well, and they all report that WebGL2 *is* supported for both IOS and Android, and that mediump 16-bit floats and highp 32-bit floats are both available for fragment shaders. It's only a sample of a half dozen devices, but I will try putting together a WebGL2-only noise with an integer hash as well. Because it won't need all the mod() operations, it might be considerably faster. I noticed that the hash in 2D mpsrdnoise needs tweaking for the rotation --- there are too many instances of adjacent gradients pointing in more or less the same direction, and that creates ugly streaks in the pattern. Other than that, do you see any problems with the function?

[stegu]

I mean, of course, S21. All these numbers...