Slashdot Mirror


Software Rendering Engine GPU-Accelerated By WebCL

Phopojijo writes "OpenGL and DirectX have been the dominant real-time graphics APIs for decades. Both are catalogs of functions which convert geometry into images using predetermined mathematical algorithms (scanline rendering, triangles, etc.). Software rendering engines calculate colour values directly from the fundamental math. Reliance on OpenGL and DirectX could diminish when GPUs are utilized as general 'large batches of math' solvers which software rendering engines offload to. Developers would then be able to choose their algorithms for best suits their project, even native to web browsers with the upcoming WebCL."

14 of 84 comments (clear)

  1. Software-rendered API wrappers through OpenCL by Hsien-Ko · · Score: 2

    ...is something i'd really like to see -especially one that does Glide and the dither+undither characteristic of the first three Voodoo cards.

    I know there's MAME/MESS but I don't think they do the infamous filtering.

  2. STAAAAAHP! by girlintraining · · Score: 5, Insightful

    Developers would then be able to choose their algorithms for best suits their project, even native to web browsers with the upcoming WebCL."

    If web browsers were people, that statement would have caused a mass suicide of them. Guys, stop trying to turn the browser into a platform. It introduces so many layers of complexity and security issues that it's a miracle anyone has any trust or faith in the internet at all. It's getting to the point where the only way to safely browse the net is to shove the entire browser into a virtual machine... and even that only manages to protect your own computer, say nothing of your online activities, credentials, life, etc.

    We need to be making browsers simpler, not more complex. Feature bloat is making these things a leper's colony inside your computer... a cesspool of malware and vulnerability. Don't add to it by coming up with some new way for developers to directly access the hardware of your computer because you're too fucking lazy to write an app to do whatever it is, and want to cram it into the browser instead. You're just encouraging them.

    Seriously, we need a 12 step program for these "web 2.0" people.

    --
    #fuckbeta #iamslashdot #dicemustdie
    1. Re:STAAAAAHP! by fragfoo · · Score: 2

      Developers would then be able to choose their algorithms for best suits their project, even native to web browsers with the upcoming WebCL."

      If web browsers were people, that statement would have caused a mass suicide of them. Guys, stop trying to turn the browser into a platform. It introduces so many layers of complexity and security issues that it's a miracle anyone has any trust or faith in the internet at all. It's getting to the point where the only way to safely browse the net is to shove the entire browser into a virtual machine... and even that only manages to protect your own computer, say nothing of your online activities, credentials, life, etc.

      We need to be making browsers simpler, not more complex. Feature bloat is making these things a leper's colony inside your computer... a cesspool of malware and vulnerability. Don't add to it by coming up with some new way for developers to directly access the hardware of your computer because you're too fucking lazy to write an app to do whatever it is, and want to cram it into the browser instead. You're just encouraging them.

      Seriously, we need a 12 step program for these "web 2.0" people.

      Browser based apps are not done because developers are "too fucking lazy to write an app to do whatever" but because they are lazy/costs more money to do it for multiple platforms, including mobile ones, and they just-work without the need of installing anything (the app itself, JRE, whatever) and the need for some kind of user privileges.

      --
      Sig? Heil
    2. Re:STAAAAAHP! by Phopojijo · · Score: 4, Interesting

      Actually, I look at web browsers as an art platform. It is programmed by a set of open standards which gives any person or organization the tools to build support for the content which is relevant to society. A video game, designed in web standards, could be preserved for centuries by whoever deems it culturally relevant.

      For once, we have a gaming platform (besides Linux and BSD) which allows genuine, timeless art. If the W3C, or an industry body like them, creates an equivalent pseudo-native app platform... then great. For now, the web is the best we have.

    3. Re:STAAAAAHP! by Anonymous Coward · · Score: 2, Insightful

      Yeah, they really missed the boat not freezing computing in the 70s. These kids and wanting features and interesting applications and useful computing are a bunch of assholes. They should be forced to do things MY preferred way because my opinion is the only one that matters.

      Fucking slashtards.

    4. Re:STAAAAAHP! by Anonymous Coward · · Score: 2, Insightful

      Guys, stop trying to turn the browser into a platform.

      No. Or "too late", rather.

      these "web 2.0" people

      These "web 2.0" people are going to continue to ignore you until what you espouse is as obviously stupid to everyone as it is to them. I'm not sure it isn't already.

    5. Re:STAAAAAHP! by Phopojijo · · Score: 2

      It's getting much closer. Most ASM.js demos show C++-compiled-into-Javascript is only half performance of native C++ (and getting faster). That's a difference between 30fps and 60fps if all code was Javascript. WebCL, on the other hand, is almost exactly OpenCL speeds... so for GPU-accelerated apps (depending on whether Javascript or WebCL is your primary bottleneck) you could get almost native performance.

      SmallPtGPU, from the testing I did a while ago, seems to be almost the same speed whether run in WebCL via Javascript or OpenCL via C++

    6. Re:STAAAAAHP! by blahplusplus · · Score: 3, Insightful

      " stop trying to turn the browser into a platform."

      The reason why they are doing this, is the big push by major industries for more DRM. Although current DRM is ineffective against more technically inclined people. They want to eventually be able to encrypt and split up programs and data tying them to the server. Just like how diablo 3 took part of the program hostage across the internet and you had to constantly 'get permission' to continue playing the game.

      If you think big companies are not looking at what the game industry and others are doing locking down apps, then you haven't been paying attention.

    7. Re:STAAAAAHP! by TomGreenhaw · · Score: 2

      I respectfully disagree. Whether anybody likes it or not, when JavaScript support was added to browsers (a really long time ago) the browser became a platform. Great web based apps are harder to do than native apps. Well designed web based apps work on all platforms and do not require client side installation or support. The cost of distribution and maintenance of web based apps is dramatically lower and that reduces cost. Centralized code management makes change management much more effective and that can increase quality. As for security and safety, I think having no data stored on a client and all data stored on centralized servers managed by professionals is a tremendous advantage in every respect.

      --
      Greed is the root of all evil.
  3. Security by damaki · · Score: 2

    Great. I'd sure like my GPU, with its mad low level optimizations and surely ugly code to be used by unsigned code from random sources.
    Java applets are far too secure, let's get to the lowest level!

    --
    Stupidity is the root of all evil.
  4. Re:Missing the point? by Phopojijo · · Score: 2

    Some want to use the same algorithms OpenGL and DirectX does... and those APIs are still for them.

    Some do not. A good example is Epic Games who, in 2008, predicted "100% of the rendering code" for Unreal Engine 4 would be programmed directly for the GPUs. The next year they found the cost prohibitive so they kept with DirectX and OpenGL at least for a while longer. Especially for big production houses, if there is a bug or a quirk in the rendering code, it would be nice to be able to fix the problem directly rather than hack in a workaround.

  5. summary has weird language by Musc · · Score: 2

    The terminology in the summary is confusing and wrong.

    First of all, software rendering vs. hardware rendering isn't the same as scanline rendering vs. "rendering from the underlying math", which I assume is a bad attempt at a layman's description of raytracing. You can have a scanline triangle renderer in software, and you can have a raytracer in hardware. It is true that most GPUs are built for scanline rendering and not raytracing, but plenty of raytracers have been written that run on GPUs.

    Second, if your renderer runs on the GPU using OpenCL, then it is not a software renderer, it is a hardware renderer, perhaps with a little more of the work done in programmable shaders and a little less done on the fixed function hardware.
    What they meant to say was that you can program your own hardware renderer using CL kernels, rather than rely on the ever-decreasing fixed-function hardware that the triangle pipeline normally uses.

    The only fixed-function capabilities in a modern GPU are texture filtering and rasterization. The vertex processing, lighting, and shading are all programmable.

    There is something interesting and new here, which is that maybe sometime in the future the programmable hardware will be good enough that the fixed-function stuff can be done away with completely.

    --
    Hamsters are at least as feathery as penguins. HamLix
  6. I/O Bandwidth by Mr.+Sketch · · Score: 3, Interesting

    Many 3D engines are carefully tuned to the limited bandwidth to the GPU cards that provides them just enough bandwidth per frame to transfer the necessary geometry/textures/etc for that frame. The results, of course, stay on the GPU card and are just outputted to the frame buffer. Now, in addition to that existing overhead, the engine writer would now have to transfer back the results/frame buffer back to the CPU to process, generate an image, that is then passed back to the GPU to be displayed as an image? Or am I missing something?

    While I'm sure it would allow customized algorithms, they would have to be rather unique to not be handled by the current state of geometry/vertex/fragment shaders. Are they thinking some of non-triangular geometry?

    Maybe there is a way to send the result of the maths directly to the frame buffer while it's on the GPU?

    1. Re:I/O Bandwidth by Phopojijo · · Score: 2

      Only if you want it to! You can share resources between OpenCL and OpenGL without passing through the CPU.

      Now, of course, you may wish to (example: copy to APU memory, run physics, copy to GPU memory, render)... but the programmer needs to explicitly queue a memory move command to do so. If the programmer doesn't move the content... it stays on wherever it is.