Added new sample to demonstrate OpenCL-Vulkan interop with ocean surface simulation #110
Conversation
main subject of this sample is ocean surface simulation
|
|
There was a problem hiding this comment.
This is awesome! I love this! Nice work!
I'll do a more thorough review a little later, but here are a few minor issues I found running this on our implementation, and a few high-level questions:
-
This sample uses glfw for its windowing library. I'm OK with this personally, and it's used for other Vulkan samples, but the OpenGL samples in this SDK currently use SFML instead. If we're going to use glfw for the Vulkan samples, should we consider adding some CMake smarts for it? Getting glfw working on Windows especially can be challenging.
-
Would it be possible to add a framerate counter or similar, to quantify the benefit of using external memory vs. copying via the host?
Thanks!
samples/vulkan/ocean/fft_kernel.cl
Outdated
| float4 data = read_imagef(twiddle, sampler, data_coords); | ||
|
|
||
|
|
||
| work_group_barrier(CLK_IMAGE_MEM_FENCE); |
There was a problem hiding this comment.
Do we need this work_group_barrier here, or can it be removed?
If we need it for some reason, then we'll need to compile this kernel for -cl-std=CL2.0 or newer, since neither work_group_barrier nor CLK_IMAGE_MEM_FENCE are in OpenCL C 1.2.
samples/vulkan/ocean/fft_kernel.cl
Outdated
| int2 pp_coords0 = (int2)(data.z, uv.y) * (1-mode.x) + (int2)(uv.x, data.z) * mode.x; | ||
| float2 p = read_imagef(src, sampler, pp_coords0).rg; | ||
|
|
||
| int2 pp_coords1 = (int2)(data.w, uv.y) * (1-mode.x) + (int2)(uv.x, data.w) * mode.x; | ||
| float2 q = read_imagef(src, sampler, pp_coords1).rg; |
There was a problem hiding this comment.
Likewise, to use these .rg swizzles we'll need to compile this kernel for -cl-std=CL3.0. It might be easiest to just use the .xy swizzles, instead.
| int2 pp_coords0 = (int2)(data.z, uv.y) * (1-mode.x) + (int2)(uv.x, data.z) * mode.x; | |
| float2 p = read_imagef(src, sampler, pp_coords0).rg; | |
| int2 pp_coords1 = (int2)(data.w, uv.y) * (1-mode.x) + (int2)(uv.x, data.w) * mode.x; | |
| float2 q = read_imagef(src, sampler, pp_coords1).rg; | |
| int2 pp_coords0 = (int2)(data.z, uv.y) * (1-mode.x) + (int2)(uv.x, data.z) * mode.x; | |
| float2 p = read_imagef(src, sampler, pp_coords0).xy; | |
| int2 pp_coords1 = (int2)(data.w, uv.y) * (1-mode.x) + (int2)(uv.x, data.w) * mode.x; | |
| float2 q = read_imagef(src, sampler, pp_coords1).xy; |
samples/vulkan/ocean/ocean.hpp
Outdated
| clEnqueueAcquireExternalMemObjectsKHR_fn | ||
| clEnqueueAcquireExternalMemObjectsKHR = NULL; | ||
| clEnqueueReleaseExternalMemObjectsKHR_fn | ||
| clEnqueueReleaseExternalMemObjectsKHR = NULL; |
There was a problem hiding this comment.
Having these function pointers won't hurt, but this sample is currently calling into the C++ bindings (OpenCL-CLHPP) to acquire and release the external memory objects. The C++ bindings query their own function pointers, so I'm pretty sure these function pointers are never used and can be removed.
Thanks :)
I could use SFML but in order to support vulkan window that would require newer version than requested 2.5.1. Update: I just added GLFW related corrections to cmake files but I am not sure if that satisfies all project requirement, it builds at my machine, I will ask mobica fellows for verification as well.
Indeed that would be useful, I will check it Update: added tracking of FPS in a title bar of main window which could be toggled with 'e' key |
-added support of FPS in title bar of main window -corrected reading shaders/kernels with cl::util::read_exe_relative_text_file -complemented readme
The sample follow general steps (with multiple optimizations) described in the publication: Realtime GPGPU FFT ocean water simulation
Main focus of the sample is to demonstrate how to share compute/render resources between
OpenCLandVulkanto simulate an ocean surface.