GPGPU(OpenCL/CUDA)+Multithreading Support

  • The-Fall
    5th Dec 2012 Member 0 Permalink

    Well, Perhaps with an empty screen. 

    I have frame stutters with an 8-Core AMD...

  • jacob1
    5th Dec 2012 Developer 0 Permalink
    @The-Fall (View Post)
    probably because it only uses 1 of those cores... which is why multithreading is really needed. It's just complicated to add.
  • Rawrkanos
    5th Dec 2012 Member 0 Permalink

    @jacob1 (View Post)

     My feeling isn't that I can play with a "good enough" fps, but that I play with acceptable FPS and that it lags with too much going on, and that bothers me. I don't have the technical knowledge to say for certain that OpenCL would make many improvements, but multithreading at least stands a fair chance to give a good boost for most, myself included.

    It's a shame that it's so hard to add, though. Which is why I've heartily recommended a re-write. At this stage in developement, the developers know all the elements they need to have and what they need to do, right? So, hopefully, a re-write would actually be easier then added in multithreading with the as-is code.

  • The-Fall
    5th Dec 2012 Member 0 Permalink

    Well, atleast a rewrite of the Simulation.cpp File.

     

    After Looking through it... Oy...

     

    Why on earth is all... That... in one file only? C++ Classes could clean that mess up.

  • Simon
    5th Dec 2012 Administrator 0 Permalink
    PowderToy++ was just a reorganisation of code, only the UI/Front-end was rewritten. As for OpenCL, so far there has been no successful multithreaded version. The only portion of the game that is suitable to be run with any form of multithreading is the renderer, which isn't too much of a bottleneck anyway. The main issue with multithreading the simulation is memory access
  • Bekas
    5th Dec 2012 Member 0 Permalink

    OpenCL code can also run on cpu's.

    But dont tink that opencl is just speed ups. Lets say that you write a kernel for heat simulation.
    Even if you keep some data on the gpu, you have to update particle positions and types.

    You still have to get some data for showing the temperature value of a certain particle and see if its state changed based on the new temprature. Also PCIe bandwitd is limited, you risk running into a bottleneck.

     

    Also you have to sincronize the kernel execution with the game, which will slow down your program.

  • plypencil
    5th Dec 2012 Member 0 Permalink

    OpenCL works directly with hardware where as SDL is a middle man to the hardware, there would be an increase in performance switching to it, the more powerful cards would see a huge reduction in draw time.

     

    Logic time is however the issue with this program, multithreading is the answer. Using the same principles as double buffering for the logic allows for easy synchronision between the threads.

  • Bekas
    6th Dec 2012 Member 0 Permalink

    Yes you can use OpenCL to draw directly data in the buffers of the gpu to the screen.

    But for that to work you have to have all the relevant information on the device memory (GPU), mainly particle position and color. If you have to transfer the data from the host memory to the GPU memory every frame you are better off using just openGL.

     

     

  • The-Fall
    6th Dec 2012 Member 0 Permalink

    So then what can be done to improve code efficiency? A practical soution?

  • Bekas
    6th Dec 2012 Member 0 Permalink

    I have little knowledge about the TPT architecture, i just pointed out the drawbacks of the openCL.

    However if there is a pratical solution probably multithreading.
    But like Simon said

     

     The main issue with multithreading the simulation is memory access