Q3Map3 - Discussion and Development

[Delirium]

what new features do you plan on implementing? or do you just plan on rewriting the code so its smoother?

Im actually confused, what are you intentions with q3map3? :>

[Silicone_Milk]

I'm building on the existing q3map2 code to add the ability to compile using an OpenCL Device (this can be a GPU, CPU, PhysX chip, etc.. or any combination of).

This will allow compile times to be decreased (hopefully) by quite a bit.

[Delirium]

Sweet

I'll be following progress for sure

[monaster]

Yeah, keep on working on that, I believe that could turn out really sweet (even if most of what the screenshots above show went way over my head )!

[Silicone_Milk]

Working on getting a test function working. Should have it done before my next class.

In a nutshell, the above screenshots are a -light compile with q3map2 with verbose information giving me status reports on the following:
- Does an OpenCL-enabled device exist?
- Can we use the device if it does exist?
- Can we get some memory to load the opencl functions in to?
- Are the functions we're reading to memory being read correctly?

Everything's checking out ok. Now it's getting the functions working with some of the data and creating the right results that I need to work on

Then the task of porting q3map2 code over to the gpu begins. Things'll start gettin' nasty at that point for sure.

My main issue right now is that a lot of the algorithms ("method for solving a problem" for the non-mathematically inclined) are recursive (meaning they use themselves in calculating results (ie. a factorial equation such as function(number) = number * function(number - 1) ))

The problem with this is OpenCL doesn't allow recursion. At all. So I need to rewrite the algorithms to be non-recursive which is going to take some thinking.

Disclaimer: The "factorial" recursive equation example isn't a true factorial equation and will give you gas if you try to run it.

[roughrider]

Gl. I hope to be able to use this before I turn 50

[Silicone_Milk]

Added in error reporting. Bad OpenCL kernels will cause q3map3 to fall back to using the old cpu-based code and print the build errors out to a log file.

[lvlshot]http://www.siliconemilk.com/music/error_report.jpg[/lvlshot]

[Eraser]

The problem with this is OpenCL doesn't allow recursion. At all. So I need to rewrite the algorithms to be non-recursive which is going to take some thinking.

Sounds like you're about to embark on a journey into the lands of Hurt

[^misantropia^]

What if f() calls g() and g() calls f()? Does the compiler see that as recursion?

[Silicone_Milk]

That's an excellent question, misantropia.

I will have to see. But first, I must find out why the OpenCL build log is suddenly spewing nonsense as if I'm outputting random locations in memory and not from the buffer I've *been* outputting from.

The thing that's making me scratch my head is that rolling back a revision to when the code produced the above screenshot doesn't fix the problem.

We'll see what Valgrind has to say about these shenanigans.

EDIT: Rather embarassing, but I figured it out without valgrind (too lazy to add the new ocl libraries to scons to build a linux version of the program....). It turns out the error was a rather stupid one - double-dereferencing

Fixed that minor issue and the error logs work once more. I just wonder when I added that in to the program

Anyways, I have a new goal for tonight/tomorrow morning - .cl file parser to automatically allocate memory for kernel arguments.

When you write a kernel for OpenCL you also need to allocate a buffer of memory for EACH argument you want to pass in to the function. It's a tedious task to have to do it every time you write a new function so I'm going to make the program do it for me.... after I upload an image of a test kernel running in q3map3 using hard-coded arguments

Progress is good at least!

[Eraser]

What if f() calls g() and g() calls f()? Does the compiler see that as recursion?

If recursion isn't allowed, I'm sure the compiler or runtime environment will throw an exception when one function appears twice in the call stack.

[^misantropia^]

Depends, probably.

Compilers have a hard time optimizing tail recursion and that's the easiest, most obvious special case of recursion. I suppose the only way to reliably detect it, is to inline all function calls and wait until you hit a limit. I wouldn't put it past the OpenCL compiler to actually do that.

[Silicone_Milk]

Small hiccup in kernel loading code fixed. The OCL compiler should be happy with the changes now and stop ignoring the other .cl files.

[Silicone_Milk]

Results of the first test kernel are in!

At first I was worried because the GPU seemed slower than the CPU in this simple calculation but it turns out I totally spaced out and forgot to increase the workload for the CPU when I increased the work for the GPU :P

Here's a shot of the results of adding 4096 pairs of floating point numbers.

[lvlshot]http://www.siliconemilk.com/music/success.jpg[/lvlshot]

Notice how the GPU is around 2x faster on such a simple operation. This is reading and writing to global memory which is an extremely slow process for the videocard to do.

For more complicated functions, I'll be able to make use of local memory to cache data to limit the number of global memory accesses so performance should increase quite a bit!

EDIT:

Doubling the amount of floats being added from 4096 to 8192 results in the GPU being 3.8x faster as opposed to only 2x faster with half the data.

[lvlshot]http://www.siliconemilk.com/music/success2.jpg[/lvlshot]

For giggles, I doubled the data once again to 16384 pairs of floats and saw the GPU end up being ~7x faster. It's good because that behavior was expected

Didn't come anywhere close to my "1000x performance increase!" claim (which was totally pulled out of my ass) but then again, can you argue with 7x faster compilation times?

Edited the numbers for Eraser. He's right, those rounding issues are just too severe to ignore I'll continue thinking it's a 14x increase in my head though

[Eraser]

Nice, but your statistics are off.
The set of 4096 numbers is only 2.04 times faster and the set of 8192 numbers is 3.86 faster. You're comparing 0.01 to 0.07 which is a rather large rounding error

[Silicone_Milk]

*waves Eraser off*

Let me dream, Eraser, let me dream.

Funny side story, I failed Chemistry due to my habit of rounding.

[Eraser]

Okay, okay, 7 times it is
Good job nonetheless. Every bit of speed increase is welcome.

[obsidian]

I hate significant figures in Chemistry as well.

[Anthem]

Sig figs make me happy. Chem ftw.

[Silicone_Milk]

Refactoring some code so the gpu demonstration isn't hard-coded.

Also made my server upset and raped the permission settings on it resulting in being locked out on all accounts. This meant I couldn't fix the mistake from the account I made it in

(Never ever ever EVER execute 'sudo chmod o-rwx /')

It was an easy fix though. Just had to be creative.

[^misantropia^]

What in the world made you do that?

[Silicone_Milk]

Was locking down some permissions on the "public" account for my server and wasn't thinking clearly about what I was doing.

By the way, ^misantropia^ are you able to establish an ssh connection to my server or does it time you out?

[^misantropia^]

It times out (and has for a couple of days now). nmap says the port is filtered.

[Silicone_Milk]

That's odd. A couple people have reported time-outs and others have gotten in with no problems.

I need to look in to that more. Thanks

[Silicone_Milk]

Switching web hosts at the moment.

Working on fixing broken image links.