JoeJ said:
Tried it but still the same error.

I hate to press you on this but are you sure you set the platform to the one you're using when you made the change? It's a very common issue. Like x86 vs x64 or debug vs release?

fleabay said:
are you sure you set the platform to the one you're using when you made the change?

No, not sure. I did:

Linker / System / subsystem → console

But where to set ‘Platform’?

Edit: You mean x64 / Win32? Same error stays for both.

oh, wait, progress… now new errors come in. But it's late. Will continue tomorrow…

Finally those errors, although i've added glew32.lib to linker

Yo! It runs. But could not find font.bmp… will be easy to fix, but tomorrow… : )

@JoeJ Sorry man, yes, font.bmp and the shaders are in the Release subdirectory of the repository! Good job!

P.S. What kind of graphics processor do you have? I have tested the latest version of the software on AMD and Intel, but not nVidia.

P.P.S. The compute shader source file is written to every time you Generate a mesh, so don't worry about it not being there the first time you run the app – it'll take care of itself. ?

Things you should know about the software:

I started out by using a multi-threaded approach, with the interface handled by the main thread, and the computation handled by the second thread. It worked smashingly on Intel, but got pseudorandom freeglut errors about lacking a display function on AMD and nVidia. So, I backtracked and went with the single-threaded approach, where both the interface and the computation are handled by the same thread. In order to do this, I took the approach that the computation occurs in bursts of ⅓ rd of a second at a time. So basically, the interface is given control only 3 times per second, which makes it feel a little choppy while the generation process is occurring.

Now I'm going with GLFW for window and context creation, and I'll be breaking out the “old” multi-threaded code. From what I understand, GLFW handles multiple threads just fine, unlike freeglut.

It's running fine now, on AMD Vega 56.

Only issue i've noticed framebuffer ‘too small’ vertically if i make the window very large on 1440p screen, see screenshot.

So, how do i change workgroup size to test if 1 GPU thread indeed is faster than using all 64? And how do i measure the performance difference?

And i wonder about usage of compute shader at all. Impression is that you generate fractal and mesh on CPU after clicking “Generate Mesh”, and then just render the result every frame.

JoeJ said:

…

Thanks for testing the software out JoeJ. There is a glViewport call in display_func() – try commenting that out to see if that helps with the framebuffer size problem.

In js_state_machine.cpp there is a statement: string code = eqparser.emit_compute_shader_code(1, 1, fsp.max_iterations); – try altering the function parameters to whatever you like. The only real test measure that I have is to measure the duration of the calculations, which is spit out to the log.

Yeah, I took out the “Use GPU” checkbox because it's now always using a OpenGL compute shader. No option to disable it. I should have made that clear, sorry. ?

I added in depth of field on the CPU. What do you think? Yay or nay? I won't be moving the calculations over to the GPU unless it's a yay.