Finally get through OpenCL's Hello World in Kotlin. Computing 3 million times sin and cos using GPU, total time is 456ms, 105ms is used to compute and read result back to CPU. On the other hand, CPU takes whole 891ms to compute cos and sin. Which I guess it's more convinced for me to just say "GPU is good for parallel computing". The result is more vivid than sentences.
After doing this, I though LWJGL's document on OpenCL is really bad. What all I referenced are Java test codes and C++ codes. And I rely on my experience a lot to debug it. It looks like JOCL's binding is more object oriented and more user friendly. But LWJGL is offering a integrated package of OpenGL, GLFW and OpenCL binding, which I guess I have to stick with it for now.
Besides auto converting Java bytecode to OpenCL kernel, Aparapi seems much easier to get start with. Without dealing a lot of data copying and buffer creating things, life is much simpler.
I might write a blog(in Chinese of course, since I'm a Chinese, maybe I'll commit this program to LWJGL as a OpenCL HelloWorld) to describe where you should take a good care with LWJGL's OpenCL binding, where I actually crash the JVM by doing it wrong. (BTW, using println to locate the crash point is way faster than step through XD)
Encountered a mind-blowing problem with OpenGL.
When I finally drew a circle using LWJGL with OpenGL, I tried moving my code from glBegin/glEnd calls to VBOs, and today I tried to make my code using shaders. And problem is here.
I draw a circle by slicing it into some segments and calculate the coordinates of points on the edge, then I can use GL_TRIANGLE_FAN or GL_LINE_LOOP to draw a circle. I randomly choose a color by assigning red equals cos(theta), where the i th theta is 2 * pi * i divided by total segments.
If I draw the circle using GL_LINE_LOOP, the color on the edge is correct, where only theta in mines pi to pi is positive number, thus given the red color, which should be the right hand side of the circle. Picture 1 is a compare that on the left I used GL_COLOR_ARRAY client state to draw color, on the right side I use shader but calculated cos before fragment shader(both in CPU part and vertex shader, they are same in result). In picture 2, I calculate cos value in the fragment shader by the theta passed by vertex shader. And it shows on the right of the picture, which is pretty odd.
I knew there other stages between vertex shader and fragment shader, but how they effect those color or theta value? Also on the left side of picture, color gradient given by fixed pipeline also seems a little bit weird.
BTW I have no ideas about where to find those documents. LWJGL doesn't have a detailed document on OpenGL(which I guess they of course not have one), and on the OpenGL side, the documents are just overwhelmed me...
This is why we can't have nice things
This video is about stuff: light bulbs, printers, phones and why they aren't better. Go to https://NordVPN.com/veritasium and use code VERITASIUM to get a 2-...
**I have a job now!**
I'm a Chinese shitizen, but I generally don't post in Chinese to avoid being suffering from other Chinese.
I'm physically a male, but I don't care how people think about my gender. I can be male, or female, or cat. But if you ask, I'd prefer to be referred to as male. Also, I support LGBT+ people, and I'm a copyleft. I don't think I'm too aggressive in arguing things, but sometimes I do. You should handle it with care.
I post about programming (most time is Java and Kotlin, unless I have a new love), and some random things I find interesting. I also post about my mental health, which is in a stable state of instability, thanks to my parents and Chinese society.
Anyway, if you want to follow me, I'm glad to see you. And, have a nice day.
Alt: @skyblond