Hacker News Reader

Comment by grenoire | Hacker News Reader

Are we missing f64 and other 64-bit integer types because of... JavaScript? Again!?

I'm not involved with the spec discussions, but I suspect it's just because 32-bit floats are heavily preferred on GPUs for performance reasons. If there were a lot of popular demand, I imagine 64-bit doubles could be added, but games overwhelmingly prefer 32-bit; it's mostly the scientific community that wants 64-bit.

Besides, if JS interop were the driving concern, 64-bit doubles would be the default, since that's what JS numbers are.

Number type in JS is fp64 since forever (at least the interface, usually it's optimized to int32 by an engine, but if you use decimals you can be sure you have fp64 under the hood) and BigInt[0] is supported in almost all modern browsers.

[0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Small correction, but it's optimized to int31 by all the current engines with the last bit used for tagging.

BigInt is now available on Firefox and Chrome (with JSC/Safari support in the works). That gives arbitrarily-large integers (with the JIT deciding the best size.

JS uses doubles by default, so no. There were times when js rendering engines used Float32Arrays for matrix and vector math because they should be faster since that's what the GPU uses, right? Turned out they were SIGNIFICANTLY slower because any math on CPU side now required casting floats to doubles back and forth.

GPU's rarely have double precision arithmetic.

I'm not sure if you're left over from 2007, but practically all Nvidia GPUs since 2008 have had double precision arithmetic. Integers are still compiled to 32-bit, sometimes, but doubles have been standard for quite a while.

Which GPUs do not have double precision arithmetic? As far as I'm aware, all of AMD's and Nvidia's from the last decade have double precision support. It may not be fast, but it's there.

Right, the desktop GPUs have support for float64, but it's not exposed in HLSL/GLSL to the best of my knowledge. "precision highp float" in GLSL will get you 32-bit on all vendors AFAIK, you have to use OpenCL/CUDA for 64-bit floats, but it's way slower and actually sometimes emulated.

None of the mobile GPU vendors (Apple, ARM Mali, Qualcomm, PVR, BroadCom) support it. You can see that here, where the only vendors supporting shaderFloat64 in Vulkan are desktop GPUs. http://vulkan.gpuinfo.org/listdevicescoverage.php?feature=sh...

GLSL has 64-bit values with "double" and "dvecN" since 4.0 [1] or with ARB_gpu_shader_fp64 [2]. I don't know if anyone actually uses them, though :)

[1]: https://www.khronos.org/opengl/wiki/Data_Type_(GLSL)#Scalars

[2]: https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_g...

64 bit support has been around on the desktop for a decade at this point (Through OpenGL4 / GL_ARB_gpu_shader_fp64 / cl_khr_fp64).

Unfortunately it is not exposed in Firefox or Chrome, even if the underlying hardware supports it. I think this is creating a chicken and egg problem - if WebGL were to actually support the capabilities of the underlying hardware, maybe there would be more interest in deploying 64-bit extensions on other platforms like mobile. Even emulated support would be a win, compared to having every developer emulate fp64/i64 themselves in GLSL.

So I am also disappointed in this proposal's failure to mention 64-bit support, even as an extension. At least they're reserving the keywords, I guess.

Desktop GPUs commonly have support for float64, and it's accessible in GLSL (how else would you use it?) and presumably HLSL.

The data types are prefixed with "d", so you have vec4 for float[4], and dvec4 for double[4].

fp64 is exposed in GLSL at least, but on desktop GPUs it's typically 16x (AMD) or 32x (Nvidia) slower than fp32.

Add that fact that mobile GPUs and some Intel GPUs don't support it in hardware at all, it makes a lot of sense to leave fp64 out of WebGPU.

Most GPUs are in mobile devices.

Edit: and most of the rest are Intel.

Most animals on earth are ants. Do you propose we optimize for them ?

Not sure what you were aiming for with the analogy, but I'm glad this made me look up the size difference between ants and humans. Humans are O(100 kg) and ants are O(1 mg), 5 orders of magnitude.

It would be interesting to see a graphics API designed to cover a range of 100 000x in performance.

Looks like Nvidia TNT had 2 GB/s of memory bandwidth in 1998 and the high end current ones have ~300-600 GB/s. That's just two orders of magnitude difference. Current fast mobile GPUs seem to get 40 GB/s so that plops to about the middle of the historical PC dGPU range, and is just 1 order of magnitude less than dGPUs.

I'm saying that just because mobile device is the majority of devices does not mean that we have to care about them. Rule of the majority is never a good rule.

Depends on who "we" are, from POV of browser vendors and makers of web graphics apps, there's certainly a compromise needed in adding features for niche users that contribute to the combinatorial explosion of tested configurations. Consider that even WebGL 2 currently is struggling to have a viable level of browser support.

WebGL mostly serves people with Intel/mobile GPUs, so will probably WebGPU if it is to survive, even though it aims to do better on the high end GPUs as well.

Reply on news.ycombinator.com