Slick Forums

We know that Slick is built upon LWJGL, which is built upon OpenGL.
After reading the OpenGL FAQ, I saw that there are things in OpenGL that are not rendered with GPU. Right now, I don't know what aspects of OpenGL, hence Slick 2D, use software rendering and what are GPU accelerated.

I'm wondering about these things because I'd like to know how to calculate stuff on the GPU side, as I need to do many vector related calculations every frame. I've read that GPUs are extremely fast for vector calculations.

OpenGL knows a software emulated mode and a hardware mode. LWJGL and slick will try to use the hardware accelerated mode (so GPU rendering) to perform all drawing operations as far as possible. In case the host system does not have the required driver support to perform hardware accelerated rendering on the GPU, it will fallback to the software mode and perform the drawing operations on the CPU. But the software mode is really badly slow.

Other operations, such as vector and matrix operations that can be done by the GPU extremly fast, are currently not supported by slick as far as I know. But LWJGL has support for OpenCL (computing language) that should be able to perform such operations on the GPU.

Nitram

_________________
http://illarion.org

So, I did a bit of googling, and I found that if I want to code on a PC with AMD card, I have to download their special SDK at http://developer.amd.com/zones/OpenCLZone/pages/GettingStarted.aspx
Same for NVIDIA - They have a special SDK as well. http://developer.nvidia.com/object/opencl.html

When I create a program using my AMD card, will it still work on NVIDIA cards, or do I have to download their special SDK as well and reference it in my Eclipse project somehow? This whole OpenCL setup is quite confusing.

Also, I couldn't find any downloadable library from OpenCL's official website - http://www.khronos.org/opencl/

Slick's images, polygons, lines, circles, etc. are all rendered using the GPU unless the user has old/broken drivers or they have somehow disabled hardware acceleration (in which case they probably shouldn't expect any OpenGL games to work).

There are a variety of things in Slick, like polygon triangulation, transform/scaling/rotation, etc that are done on the CPU.

What kind of vector calculations are you doing that need to take advantage of the GPU? Even AAA titles generally don't need to take advantage of the GPU for math/physics -- PhysX has supported GPU physics for a while, yet the list of games using it is very short.

Generally speaking the CPU will be more than fast enough to handle all of the physics and math in your game -- if you are finding it a bottleneck, I'd wonder whether your algorithm is slow, rather than the processor. For a 2D game, especially, the CPU should be suitable.

Calculating physics on the GPU is not a small task -- OpenCL is pretty new and finding documentation/tutorials on using it may be challenging. It's also not very widely supported yet, and many of your users will be unable to play your game.

If you really need hardware accelerated calculations, you can use GLSL (shaders) to achieve this. Here's a brief intro on shaders in Slick:
http://slick.cokeandcode.com/wiki/doku.php?id=shaders

Chances are, whatever you're trying to do should be possible with plain old CPU calculations -- or GLSL if you have more specific performance needs.

I'm doing an outline(border) for a polygon shape, and I'm doing it by extruding the existing polygon edges.


I have to normalize the normal vectors in order to make uniform thickness for the outline.
Normalizing vector means calculating the unit vector, which requires the use of the square root, which is computationally very heavy. I have to use the square root dozens of times every frame so that I can update the polygon's outline. That's why I'd like to have an option to move those vector calculations to the GPU somehow.

Have you benchmarked this, or are you just assuming the CPU won't be fast enough? You could probably get away with thousands of square root operations per frame without noticing a change in FPS.

Why don't you calculate it once, and then store the "extruded" polygon so that you aren't re-calculating it every frame?

If you really want to do it on the GPU, you could achieve that by passing glNormal with a value that you can later use for extrusion. Then, in the vertex shader, you would extrude the point by a given amount (e.g. set via a uniform). You then render the geometry twice -- once with the extrude vertex shader (i.e. the outline), and once without (i.e. the shape). Ideally this would be done in a single pass instead of two -- you'd need to figure out a way to tell your fragment shader that you are "outside" of the original shape.

Even if you manage to do that, it wouldn't necessarily be any more efficient, because (a) it may require two passes, and (b) the number crunching needs to be done every frame. Whereas on the CPU, you can do the calculations once, and then save them until the shape/points change, thus reducing redundant calculations.

All in all... definitely sounds like a case of premature optimization.

Thanks for the reply. I'll try the easiest way then - calculating the square roots on CPU.


Because the shape is constantly changing:
http://www.youtube.com/watch?v=YcsTi4u-nL0