UE4 / OpenC / STD::algorithm

As a side project (non UE4), I’ve been reading material and going over some video tutoirlas of OpenCL. I’m using AMD’s APP SDK. I’m not really interested in GPU programming, but I am interested in putting the APUs on modern Intel and AMD CPUs to use. I’m not exactly sure what that’s going to be yet, but as some trivial projects just to learn OpenCL I was thinking re-writing some of the Standard Template Libraries algorithms would be a good exercise. Does UE4 ever make use of any of these? I could probably just search the project for <algorithm> but it’s not a bad topic for discussion.

I haven’t looked yet, I just figured someone on here might know. If UE4 isn’t using STD::algorithm, does it have any algorithm types that I could take a look at? The idea would be to emulate their functionality but modifying them to run on the APU of modern CPUs. The main benefit of modern APUs over GPUs is that they share global memory and even constant memory (OpenCL memory spaces) with the CPU, the system ram and the L3 cache respectively, so large amounts of time wouldn’t be wasted moving things over the PCI bus. By using the APU we also don’t take up any resources on a discrete card that would otherwise be used for rending.

If there are any performance gains to be found here I intend to find them.

UE4 does not make use of <algorithm>, and if you’re looking at using OpenCL then there is some good news here for you: UE4 does have support for compute shaders, however it does not support OpenCL just DirectCompute and OpenGL 4.3’s concept of a compute shader. That being said, it’d probably be handy to have an OpenCL fallback or an alternative on drivers that don’t fully support OpenGL 4.3 (cough OS X cough), but I imagine that may be more trouble than it’s worth depending on variances in platform support for OpenCL. I suppose it’d also be good for drivers that claim to support OpenGL 4.3, but have poor support for OpenGL’s compute shaders yet have better support for OpenCL (as was the case with AMD for a while there) in situations where OpenGL would be the preferred API.

Oh I have no worries about OpenCL working with UE4. OpenCL like any other C library and can be implemented as much or as little as you please (within the law).

There was an interesting post by Epic today on the subject of UE4 libraries which answered my question.

Cliffs: We would write our own iterators/predicates…

Your predicate could include w/e library you wanted, OpenCL or otherwise whether UE4 “supports” it or not, we’re writing full blown C++ these days not a scripting language. Having full source I assume we could write our own iterators too. I was mainly just wondering the proper way to implement OpenCL algorithms, but today’s post from Epic answers that. They aren’t exactly STL, but the only difference is in the implementation, the theory is much the same.

Compute Shaders would probably also work, but I for one don’t look fondly on using them for non gfx related computing (general computing instead of graphics), although they would definitely be preferable for anything you were rendering to the screen. Another problem would be writing in support for UE4 to take advantage of multiple graphics cards, one for rendering and another for computing (a discreet GPU and APU), this isn’t easy to do in OpenGL. With OpenCL this can be done with just a few lines of code. Last but not least, I don’t want my code to be GPU only. If someone is running my algorithms on a computer without an APU/iGPU (A10/Intel), say, an FX series chip, I would much rather these algorithms be ran on the CPU and NOT the GPU as these algorithms are intended to to operate on system cache/ram (huge time waster on a GPU). Also, because of the similarities in the memory spaces between the apu/cpu (virtually no difference in global/constant memory, they even share the memory controller) optimizing for one is in many ways almost the same as optimizing for the other.