View Full Version : Perpetual Motion Engine
Phopojijo
October 3rd, 2013, 02:21 AM
http://www.pcper.com/reviews/Editorial/Perpetual-Motion-Engine-Early-Demo-Me
So I've been working on this for a little while (most of the work was rushed though).
It is basically a software rendering engine which can target OpenCL devices (mostly GPUs) to offload the big batches of strict mathematics. I programmed it in Javascript and WebCL.
Bodzilla
October 3rd, 2013, 08:44 AM
whats the end goal with this? what are you trying to achieve?
Zeph
October 3rd, 2013, 11:30 AM
But more importantly, is that you in the video?
Phopojijo
October 3rd, 2013, 11:54 AM
Yep, it is me in the video. End goal? Not sure yet... there's a few ways I can take this.
Patrickssj6
October 3rd, 2013, 06:27 PM
You might have done everything perfect except for one thing: I don't even...
Tnnaas
October 3rd, 2013, 07:37 PM
I read the title and was ready to point and shame you. I did not expect what I saw.
Neat-o.
Dwood
October 3rd, 2013, 10:33 PM
Wow. Color me impressed. But, as bodzilla asked. What does this open up to the developers besides simply being a math engine? Or did I not understand the vid at all?
Brb reading the editorial.
Bodzilla
October 4th, 2013, 07:35 AM
You might have done everything perfect except for one thing: I don't even...
from what i understand is it's a way for the computer to designate mathematical tasks the computer needs to perform to selective individual components.
Similiar to how you can have 2 nvidia cards, from different generations and one acts as a physics processor and the other a GPU. It's a share the load type thing. but on a grander scale
Am i right Flibjphobojohobo?
Phopojijo
October 5th, 2013, 12:15 AM
from what i understand is it's a way for the computer to designate mathematical tasks the computer needs to perform to selective individual components.
Similiar to how you can have 2 nvidia cards, from different generations and one acts as a physics processor and the other a GPU. It's a share the load type thing. but on a grander scale
Am i right Flibjphobojohobo?It's not really a grander scale.
I just reimplement graphics algorithms (any of them) as software and send it to whatever OpenCL-compatible processor (or processors) I want to target. Sacrificing some hardware efficiency... gaining a tonne of control.
Dwood
October 29th, 2013, 01:55 AM
I know this isn't on perfect topic of Phops work recently, but this is the best place I've found to post about it.
Webgl gaming engines coming to a browser near you?
https://artillery.com
Edit: is this a part of what you are trying to do with your graphics Phops?
Phopojijo
November 1st, 2013, 06:10 PM
Yeah, Artillery Games is pretty cool but they're not the only ones doing this stuff (they're an early adopter, for sure, though).
At Mozilla Summit, I played a level of Unreal Tournament 3 on a newer build of Unreal Engine native to Firefox (Google Chrome and others should be coming soon). It uses tools, namely Emscripten, to cross-compile C++ code into Javascript (including ASM.js). Here is the official video of the same demo that I played (http://youtu.be/BV32Cs_CMqo?t=1m48s). Epic Games has announced that they are designing HTML5/CSS/JS/WebGL as a platform (I believe an officially supported one) for Unreal Engine 4.
((As an aside: ASM.js code runs like Javascript. In browsers which understand what ASM.js really is, however, the code can be heavily optimized and even compiled at-load (versus during-execution like typical Javascript). First benchmarks show average ASM.js performance is ~50% of C++. More recent, but still old, benchmarks show more like 66% of native performance for C++ code cross-compiled into Javascript versus running in the native OS.))
-----
That is not *quite* what I am doing though. These engines use WebGL as a replacement for OpenGL, and they use Javascript as a replacement for compiled C++ (or hand-written JS) code.
What I am doing is much more abstract than that. I draw just two triangles with WebGL... and they perfectly cover the whole viewport. I apply one (or more) texture(s) to it. If just one texture then it gets applied to the rectangle unlit. Multiple textures get blended (in some way I defined) and then applied to the rectangle unlit. ((Lighting a flat canvas would be very very dumb lol)).
Texture resolution is whatever resolution the user selects (almost definitely Non Power-of-Two (NPOT)).
What texture(s)? Those are drawn by software renderer(s) which output render-to-texture(s). That software renderer is programmed in Javascript and WebCL. If I need to run a single function many many times (example: "Calculate rigid body collisions for every applicable object in the scene" or "Find which pixels are inside each triangle for every triangle in the scene" or even "Cast a ray in the 3D scene for every pixel") then I can write it as an OpenCL kernel and choose any CPU or GPU (using WebCL) to actually perform the bundle of computations. If I can figure out "the math" corresponding to what I want to achieve: I can do it. Could be voxels. Could be triangles. Could be rasterized. Whatever. (Could even mix-and-match if I want to SLOWLY DIE INSIDE).
This means that I can load any combination of independent tasks to any combination of CPUs, GPUs, or any other viable OpenCL 1.1-compliant device (if I don't just program it in Javascript). If you have two very similar GPUs (Like a GTX 770 and a GTX 680) I can render frames in advance like SLi or Crossfire. Or I could use your weaker one for Physics, AI (pathfinding and visibility tend to be parallelizable). Maybe I could try breaking the screen into "tiles" and queuing them to first-available device (kernel queue time is pretty low but probably not THAT low -- but it might be worth fooling around with)? The point is: I am the one making the tradeoffs... not NVIDIA, not AMD, not Microsoft, not Khronos Group.
Actually one application I've been musing is implementing an audio processing engine in OpenCL. Think about rain. Instead of recording rainfall for a bunch of different locations... record a handful (2 to 3 maybe?) of sound interactions of "a raindrop" against "metal/dirt/wood". Load up all the sound assets in GPU memory and let the rain particles drive the input to an actual sound simulation. As long as you have the performance, it should just work. And, as a result, you have less to pre-record (you could even make a library of sound cues for generic sound cues and use that across multiple projects). Etc.
Again, if you haven't figured it out yet, this is all very skunkworksy and could turn out that it's completely unviable for any situation. Fun to think about though.
Dwood
November 1st, 2013, 07:26 PM
so is yours still java script?
Phopojijo
November 1st, 2013, 09:47 PM
Yep. It is almost entirely Javascript. Think of it this way... imagine a software rendering engine programmed in Javascript.
However, in Javascript, you will come across places like this:
for (var i = 0; i < screen.width; i++) {
for (var j = 0; j < screen.height; j++) {
cast_a_frickin_ray(i, j, more_data);
};
};
... and you would think something like, "God no!" or maybe, "EVIL!"
You would then go back and rewrite "cast_a_frickin_ray()" in OpenCL "kernel language" (a weird version of C). You load that C-ish source code into Javascript as a string. You pass that source code string to WebCL (while the web page is running) saying, "Compile this for (selected device... GPU... CPU... whatever)".
Then, instead of having a double-nested for loop... you have a function that WebCL sends to as many cores as your device has (WebCL gives you one or more numbers for each instance of the kernel called a Global ID which acts like an "i" or a "j").
Other than that, yes: pure Javascript.
Dwood
November 1st, 2013, 11:25 PM
Sounds like your solution still suffers from the speed problem because of the abstraction as you already mentioned.... Do you have any comparisons of your engine speed vs native non js speeds?
Phopojijo
November 2nd, 2013, 01:22 AM
This is really not the stage to be concerned about performance. The advantage is flexibility. If I gain any performance (chances are) it will be through skipping irrelevant steps, choosing a more efficient algorithm, or being able to perform a weird tradeoff to better approximate any given goal. In fact I am bypassing a lot of dedicated hardware that is probably like two orders of magnitude more efficient than the compute cores.
That said even if I am losing 99% of my performance... on what could be just 5% of the overall workload... could the control I gain (access to normally idle hardware, availability in any compatible web browser, etc.) be worth it?
Frankly most of the goal is seeing what I can gain by cutting OpenGL and DirectX loose (except as an efficient link between my buffers and the monitor).
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions Inc. All rights reserved.