4 ms·

Found no live-examples to run. WebCL's not supported by my browser. WebCL's not integrating with the WebGL rendering pipeline (no buffer sharing, no atomic sync

by pyalot2 13y ago

Found no live-examples to run. WebCL's not supported by my browser. WebCL's not integrating with the WebGL rendering pipeline (no buffer sharing, no atomic synchroniczation primitives etc.) I'd suggest solving a few fundamental problems with the technology first, sorry to rain on the parade.

iso8859-1 13y ago
Other compilation targets are available, see lmeyerov's posts.
lmeyerov 13y ago
Yeah, WebCL->WebGL buffer sharing is a big deal: having to copy the data from GPU->CPU->GPU for the layout->rendering hand-off is a ~5-10ms hit on the animation loop. Luckily, the Safari version of WebCL we use has integrated buffer sharing (https://github.com/SRA-SiliconValley/webkit-webcl https://github.com/SRA-SiliconValley/webkit-webcl). I'd expect that to be in the Chrome port being developed. The Nokia port for Firefox a couple years back didn't have it, though I don't know what's going on with the new one @ https://www.khronos.org/bugzilla/show_bug.cgi?id=792 https://www.khronos.org/bugzilla/show_bug.cgi?id=792 . My benchmarks show that asm.js + workers + webgl will have that 5-10ms hit, but otherwise performs at similar scales. If we figure out streaming data transfers to overlap communication with computation, it would be even less.
- pyalot2 13y ago
  Compute shaders solve essentially all these issues, and more. The graphics pipeline consists of programmable and semi-fixed components and it is quite often useful to interact with it. For that purpose compute shaders introduce compute kernels, atomic counters, atomic locks, sharable buffers and some hookups to the pipeline stages. This is functionality gleaned from Cuda, but repackaged in a more or less portable way. Of course compute shader kernels aren't as flexible as either Cuda or OpenCL programs. However OpenCL is by now quite far behind "the state of the art".
  - lmeyerov 13y ago
    Ah, interesting. OpenCL/WebCL solve this problem, so I think the question is portability. Will compute shaders be landing in most WebGL implementations? WebGL seems generally limited to OpenGL ES, so I had only explored BrookGPU-style alternatives. Targeting CUDA/OpenCL/WebCL was so that we can rely upon intermediate GPGPU compilers. Our DSL compiler outputs a bunch of for-loops, which traditional compilers love to optimize (the JIT for JS, LLVM for OpenCL, etc.). If we targeted a low-level language such as nvidia's PTX, I suspect we'd still want something like LLVM inbetween. Is there a good preprocessor for compute shaders?
    - pyalot2 13y ago
      At least in the OpenGL world, compute shaders use more or less the same syntax as other kinds of shaders (GLSL). It's true that WebGL does not have compute shaders (and neither does OpenGL ES), yet. However OpenGL ES roughly tracks OpenGL's development with OpenGL ES 2.0 == OGL 2.0, OpenGL ES 3.0 == OGL 3.0, in each case with a bunch of features stripped but with the essential advances in place. OpenGL ES 4.0 which should come about in the next 2-3 years is very likely to include compute shaders.

by pyalot2 13y ago

iso8859-1 13y ago

Other compilation targets are available, see lmeyerov's posts.

lmeyerov 13y ago

Yeah, WebCL->WebGL buffer sharing is a big deal: having to copy the data from GPU->CPU->GPU for the layout->rendering hand-off is a ~5-10ms hit on the animation loop. Luckily, the Safari version of WebCL we use has integrated buffer sharing (https://github.com/SRA-SiliconValley/webkit-webcl https://github.com/SRA-SiliconValley/webkit-webcl). I'd expect that to be in the Chrome port being developed. The Nokia port for Firefox a couple years back didn't have it, though I don't know what's going on with the new one @ https://www.khronos.org/bugzilla/show_bug.cgi?id=792 https://www.khronos.org/bugzilla/show_bug.cgi?id=792 . My benchmarks show that asm.js + workers + webgl will have that 5-10ms hit, but otherwise performs at similar scales. If we figure out streaming data transfers to overlap communication with computation, it would be even less.

pyalot2 13y ago
Compute shaders solve essentially all these issues, and more. The graphics pipeline consists of programmable and semi-fixed components and it is quite often useful to interact with it. For that purpose compute shaders introduce compute kernels, atomic counters, atomic locks, sharable buffers and some hookups to the pipeline stages. This is functionality gleaned from Cuda, but repackaged in a more or less portable way. Of course compute shader kernels aren't as flexible as either Cuda or OpenCL programs. However OpenCL is by now quite far behind "the state of the art".
- lmeyerov 13y ago
  Ah, interesting. OpenCL/WebCL solve this problem, so I think the question is portability. Will compute shaders be landing in most WebGL implementations? WebGL seems generally limited to OpenGL ES, so I had only explored BrookGPU-style alternatives. Targeting CUDA/OpenCL/WebCL was so that we can rely upon intermediate GPGPU compilers. Our DSL compiler outputs a bunch of for-loops, which traditional compilers love to optimize (the JIT for JS, LLVM for OpenCL, etc.). If we targeted a low-level language such as nvidia's PTX, I suspect we'd still want something like LLVM inbetween. Is there a good preprocessor for compute shaders?
  - pyalot2 13y ago
    At least in the OpenGL world, compute shaders use more or less the same syntax as other kinds of shaders (GLSL). It's true that WebGL does not have compute shaders (and neither does OpenGL ES), yet. However OpenGL ES roughly tracks OpenGL's development with OpenGL ES 2.0 == OGL 2.0, OpenGL ES 3.0 == OGL 3.0, in each case with a bunch of features stripped but with the essential advances in place. OpenGL ES 4.0 which should come about in the next 2-3 years is very likely to include compute shaders.