6 ms·

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

by grenoire 7y ago

Jasper_ 7y ago
GPU's rarely have double precision arithmetic.
- grenoire 7y ago
  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.
- rrss 7y ago
  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.
  - Jasper_ 7y ago
    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=shaderFloat64&platform=android http://vulkan.gpuinfo.org/listdevicescoverage.php?feature=sh...
    - pcwalton 7y ago
      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 https://www.khronos.org/opengl/wiki/Data_Type_(GLSL)#Scalars [2]: https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_gpu_shader_fp64.txt https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_g...
    - yoden 7y ago
      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.
    - klodolph 7y ago
      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].
    - atq2119 7y ago
      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.
  - fulafel 7y ago
    Most GPUs are in mobile devices. Edit: and most of the rest are Intel.
    - jcelerier 7y ago
      Most animals on earth are ants. Do you propose we optimize for them ?
      - fulafel 7y ago
        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.
        jcelerier 7y ago
        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.
        fulafel 7y ago
        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.
szatkus 7y ago
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/Reference/Global_Objects/BigInt https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- hajile 7y ago
  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.
pcwalton 7y ago
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.
mschuetz 7y ago
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.

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

Jasper_ 7y ago

GPU's rarely have double precision arithmetic.

grenoire 7y ago
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.
rrss 7y ago
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.
- Jasper_ 7y ago
  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=shaderFloat64&platform=android http://vulkan.gpuinfo.org/listdevicescoverage.php?feature=sh...
  - pcwalton 7y ago
    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 https://www.khronos.org/opengl/wiki/Data_Type_(GLSL)#Scalars [2]: https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_gpu_shader_fp64.txt https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_g...
  - yoden 7y ago
    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.
  - klodolph 7y ago
    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].
  - atq2119 7y ago
    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.
- fulafel 7y ago
  Most GPUs are in mobile devices. Edit: and most of the rest are Intel.
  - jcelerier 7y ago
    Most animals on earth are ants. Do you propose we optimize for them ?
    - fulafel 7y ago
      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.
      - jcelerier 7y ago
        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.
        fulafel 7y ago
        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.

szatkus 7y ago

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/Reference/Global_Objects/BigInt https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

hajile 7y ago
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.

pcwalton 7y ago

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.

mschuetz 7y ago

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.