POST A COMMENT

7 Comments

Back to Article

  • JDG1980 - Wednesday, March 19, 2014 - link

    WebCL? Really? I wonder how long it will be before people start writing pages designed so that whenever your browser visits the page, it will use your GPU to do scrypt mining in the background (for their benefit). Reply
  • inighthawki - Wednesday, March 19, 2014 - link

    WebCL just sounds like a giant security hole in the making. I can't think of a SINGLE reason why I would need GPU compute on the web. Not a single one.

    Let me know when browsers start supporting this so I can disable it first thing :)
    Reply
  • ddriver - Wednesday, March 19, 2014 - link

    I think the whole "web" moniker is getting ridiculous. There can be found a use for GPU compute in applications running in browsers, but hey - that's as simple as linking the browser executable to OpenCL - really no need for yet-another-standard.

    God forbid the implementations suck as much as WebGL does...
    Reply
  • matt321 - Thursday, March 20, 2014 - link

    The use-cases I can think of would be something like Photoshop or a Near-Line Editor in a Chrome Browser, something used on a Chromebook, to expedite exports, renders, etc. Reply
  • Haravikk - Monday, March 24, 2014 - link

    As Matt says, this is useful for continuing with the ability to port programs from traditional native apps to fully web-based versions. Currently any kind of complex number crunching is extremely difficult to do efficiently in Javascript alone, meanwhile OpenCL presents a very powerful abstraction allowing an app (web or otherwise) to easily take fuller advantage of both CPU and GPUs in a system. The security concerns are of course understandable, but this could potentially allow web-based games to implement very sophisticated physics engines.

    For example, the web-based version of the Unreal engine uses asm.js to more efficiently compile code ported from C/C++, but it's still stuck within Javascript's comparatively limited environment. If you read articles about it then the main stumbling block is when too many physics operations are needed, as they start to interrupt rendering since everything is forced to work in a single main thread. By offloading physics to WebCL the web version of Unreal could actually truly start to approach native levels of performance, even more so whenever WebGL gets updated to match the upcoming OpenGL version (which should reduce reliance on the CPU)
    Reply
  • extide - Wednesday, March 19, 2014 - link

    There is already an implementation of a bitcoin miner like this... Reply
  • Haravikk - Monday, March 24, 2014 - link

    Interesting stuff, especially this SYCL update for OpenCL; as much as I like C, if you're working in C++ already then diving between the two languages gets to be a huge pain for developing with any consistency, so it'll be nice to see C++ support at last.

    One thing I'd really like to see the Khronos group look toward is allowing OpenCL to actually issue OpenGL commands; rather than trying to follow what AMD are doing with Mantle. This would allow a program to effectively offload some or all of its rendering engine entirely onto the GPU, leaving the CPU to only process what commands need to be issued to change view point, add/remove objects in the scene and so-on. With a suitably re-structured version of OpenGL with that in mind, we could end up with a truly significant modern rendering system. Especially since a game could dispatch different rendering engines to different GPUs. For example, in a system with integrated GPU and a discrete GPU the main rendering engine would go to the discrete GPU, while a "helper" engine would go to the integrated one to handle things like off-screen rendering jobs.

    I think SYCL probably is needed first to make such a system easier to develop with, but it could be extremely powerful, and potentially give us a truly modern OpenGL that's ahead of other APIs for a change.
    Reply

Log in

Don't have an account? Sign up now