GPU code

[worktycho]

Possibly. The main problem I see is that one of the main goals of my library design is to chain functions so that they can be compiled to a single kernel or executed in a single loop. If your library doesn't follow the monadic template pattern then it will cause problems. Also your 2D and 3D array classes sound like they might lead to duplication as I've come round to the idea that my library needs them as well. Maybe I should post my code (though Ive only got some of the C++ and SSE backends done.) as well as my plans.

So with the monadic patten the pesudocode would look like:

Code:

auto PerlinNoise = GeneratePerlin<4, 4, 17, 17>(...);
auto Multiplier = GeneratePerlin<4, 4, 17, 17>(...);
auto Multiplied = Multiply(Values, Multiplier);
auto Values = AddConstant(MultiplyByConstant(Clamp(Multiplied,0,1),80),40).Calculate();
// Values are calculated in a 4x smaller version first (5*5 numbers),
// and the final results are then linearly upscaled to the full dimension (17*17 numbers)

An Important thing to note is the computation is encoded in the type so partial values are effectively immutable.

[xoft]

One advantage to my design over your design - it could be exported to Lua and used by plugins. Marginal.

[worktycho]

Whereas my design has serious performance advantages. Also my design can be trivially adapted to your design using wrappers at the cost of performance but if your writing in lua performance is not the most important thing. If you refactor the code for your design now as a stopgap it should make moving to my design easier when we move to c++11.

[worktycho]

I had another look at your design and realised its very similar to the design I came up with 3 months ago and had to give up due to performance reasons. The problem is if you do the computation lazily the compilier loses a lot of opportunities to optimise and it takes twenty instructions fighure out which one instruction commmand your doing, and if you do the calculations eagerly then you end up with lots of loops with one instruction, horrible for memory bandwidth

[NiLSPACE]

I was wondering if it's going to be configureable to use the GPU. Some people might want MCServer to not use the GPU because they want to use it for something else.

[xoft]

Another somewhat similar concern is that there can actually be multiple generator threads (one per world), will GPU code work in such cases? Will it still perform well?

[worktycho]

My plan is that GPU use will have a global switch. I haven't decided whether there will be a run time switch but it will definitely be able to compile without GPU support. For thread safety, my code will be thread safe and the openCL and openGL specs both claim thread-safety by default (buggy drivers not withstanding).

[worktycho]

I've hit another problem which has made me reconsider the options. I'm only halfway through the lighting code and its crashing clang. This code is going to take forever to compile (think >10 minutes per file for a high spec machine) when it doesn't crash. I going to take another look at code generators in MSBuild.

[bearbin]

That sounds nasty. How's the performance of the actual app?

[worktycho]

Haven't managed to compile it so I don't know.