14
\$\begingroup\$

My current understanding is that anything done in a shader file is done on the GPU, and anything done in my (Java, in my case) code is done on the CPU.

Is this an accurate description?

\$\endgroup\$
  • 2
    \$\begingroup\$ Also you can do computing on the GPU using something like OpenCL which is essentially allows you to run code on the GPU. \$\endgroup\$ – Soapy Jan 20 '15 at 13:44
20
\$\begingroup\$

That's the gist of it.

In principle, the platform could, conceivably, do whatever it wants. One could imagine an advanced operating system doing just-in-time translation of compiled code from, say, x86 to GPU code. Similarly, OpenGL drivers could run whatever it wants on the host CPU.

But really, what you just described, is what happens.

\$\endgroup\$
  • 5
    \$\begingroup\$ IIRC, the shaders are compiled on the CPU before being sent to the GPU. And that's done by the GPU driver without the OS. \$\endgroup\$ – MSalters Jan 19 '15 at 20:22
  • \$\begingroup\$ True. I've dealt with many a compile error during program run in the shaders, even when the java code has already been compiled. \$\endgroup\$ – Bassinator Jan 19 '15 at 23:20
  • 1
    \$\begingroup\$ Theoretical: Let's say I had a program that is very CPU intensive but was just a command line interface (no graphical work). Could I offload some of the work to the GPU? I'm not actually planning on doing this, It's just a conceptual thing that interests me. \$\endgroup\$ – Bassinator Jan 19 '15 at 23:22
  • 2
    \$\begingroup\$ Yes! The link that @return true posted is for a Java library that does that. More generally, you can write a "compute shader" in OpenGL, or use OpenCL. In all cases, you need to isolate part of your code which is parallelizable, and pass information into and out of it. (GPUs are mostly great for "embarrassingly parallel" tasks.) \$\endgroup\$ – david van brink Jan 19 '15 at 23:41
  • 1
    \$\begingroup\$ One asterisk to add to this answer is that some implementations support the idea of a "preshader" - that is, code that is part of the shader, but whose result will be constant across all invocations in a given draw call (like multiplying uniform view & projection matrices). A shader compiler so inclined can identify bits of code like this and hoist them out to be executed once CPU-side, including the resulting constant output in the work submitted to the GPU. That's one common case where the "shader = GPU" assumption might be bent, though only in detail. \$\endgroup\$ – DMGregory Jan 20 '15 at 17:04
7
\$\begingroup\$

Generally, Yes. Java is used to write programs that run on the cpu. Shader languages (cg,hlsl, et al) are used to write programs that run on the gpu.

An exception to the rule would be using third party apis which can bridge the gap.

\$\endgroup\$
  • 1
    \$\begingroup\$ Very interesting tip, your link to "aparapi". Run some JVM code on the GPU... intriguing! \$\endgroup\$ – david van brink Jan 19 '15 at 20:43
3
\$\begingroup\$

david van brink answered your question in general.

But like he says, OpenGL driver could run stuff on the CPU, and it actually happens a lot. Especially with compatibility contexts, where some weird legacy functions cannot be implemented on the graphic cards. They require software emulation. For example, I've heard before that stippling is executed on the CPU. You can expect also surprises with picking.
These surprises can happen even more on MacOS using 2.1 contexts, because Apple has unified the view of OpenGL quite well accross their hardware range, and some smaller hardware lacks some stuff that has to be emulated. It goes so far as to actually be possible to execute the ENTIRE OpenGL 2.1 spec fully on CPU, if the context creation code specifies a software device explicitely.

Conversely, code that is executed through computing libraries like vexcl or boost compute, or microsoft's AMP, or nVidia thrust, CAN be executed on the GPU or the CPU depending on API setup flags.

And for the finish touch, inside the CPU you also have a DSP architecture with the part of it we call SIMD. Intel's ispc compiler provides help in generating code that is "ensured" to run on SIMD lanes with lots of performance diagnostics at compile time to help you make the most of it. Add OpenMP to that and you can get multithreaded SIMD, which approaches the concepts of GPUs. If you have a high end CPU and low end GPU, this can actually be more performant.
http://ispc.github.io/

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.