+- Cuberite Forum (https://forum.cuberite.org)
+-- Forum: Cuberite (https://forum.cuberite.org/forum-4.html)
+--- Forum: Development (https://forum.cuberite.org/forum-13.html)
+--- Thread: GPU code (/thread-1480.html)
RE: GPU code - worktycho - 06-20-2014
To the current CPU version.
RE: GPU code - xoft - 06-20-2014
Then you must have done something wrong, because the current CPU code should run much faster if refactored this way. You did keep the upscaling, didn't you?
RE: GPU code - worktycho - 06-20-2014
Its the memory bandwidth. Every loop has an overhead of ~40 cycles per item. So if you've got a loop for every add you end up with add operations being 40 cycles rather than one.
RE: GPU code - Schwertspize - 10-30-2015
Actually the best way to do it (nowadays) is using OpenGL ES with picture code.
because we are targetting the Raspberry PI as system, some of us may try forking Cuberite to rewrite the engine.
you use OpenGL to render Pictures where you save information. that means that one monster has one dot, each value r, g, b stands for a vector value where the monster should go. or express every position with one color dot. you dont have to display that dot, but if you want to, these would be great colorful pics
but imagine. A LAN party with 100 ppl playing on Cuberite on a Raspberry PI.... how cheap.
RE: GPU code - worktycho - 10-30-2015
You could try, but my experience of trying to get GPU code working last time was that you have two major problems: Code base size and latency.
Reimplementation is a real challenge, and basically equivalent to the initial implementation resulting in separate dedicated subsystems. Maintaining the subsystems would require someone to be willing to take up all the work xoft has done and replace it. The other problem is latency, sending a job to the GPU takes time, and if that time is longer than the amount of time saved by running the job on the GPU it isn't worth it. You would not be able to run the entire server on a GPU without significant performance costs.
If you want to look into it I suggest you ignore the main core and start with the lighting subsystem. Its a nice simple piece of code, that is heavily parallel, but also extremely control flow dependent in its current version. It is also independent enough that batching it would be relatively simple compared to other subsystems.
And regarding OpenGL ES, that made most sense for the pi at the time, but for a Proof of Concept branch covering multiplatform implementation, OpenCL offered numerous advantages, particularly a better pipeline model.
RE: GPU code - DiamondToaster - 10-30-2015
OpenCL acceleration would be awesome since I just got a Radeon R9 290. That thing is a compute beast.
