Add Ocean OpenCL-OpenGL interop demo - #124
starcatter wants to merge 7 commits into
Conversation
|
|
| } | ||
|
|
||
|
|
||
| static const char* IGetErrorString(int clErrorCode) |
There was a problem hiding this comment.
This seems generally useful. Could we move this to a shared location? Or, could we use the cl_util_print_error function already in the SDK utils lib?
|
|
||
| int main(int argc, char* argv[]) | ||
| { | ||
| OceanApplication app; |
There was a problem hiding this comment.
Because app is instantiated before parsing command line options, it is ignoring any passed-in command line options to select the platform or device index. Could we instead parse the command line options first and pass the chosen platform index, device index, and device type when we construct app? See the nbody sample as an example.
There was a problem hiding this comment.
This still didn't work for me, at least for the platform and device arguments (specified with "-p"), and it looks like the sample is exclusively running on platform zero. With my current config, this just so happens to be a CPU platform, so the sample isn't working. I'd really like to be able to select the platform to run with. Alternatively, we could try to find the right platform based on the OpenGL context with CL-GL sharing is enabled, but this isn't a viable solution when CL-GL sharing is disabled.
There was a problem hiding this comment.
I see similar behavior at my end - the failure was a CL/GL context mismatch on a hybrid-GPU laptop, the OpenGL context was landing on the integrated GPU while OpenCL picked the discrete one. Forcing GL onto the same physical device via PRIME render offload, both -p and -d select the platform/device as expected. In other words, -p/-d select correctly; the platform and device you get were never the problem, only the fact that OpenGL was rendering on a different physical GPU than the one OpenCL was told to use.
|
Hi @starcatter, thanks again for your contribution. Do you think you will have a chance to address the review comments above? Thanks! |
|
@bashbaug Hello, sorry if I was a bit unresponsive! Those are good suggestions, I'll try to get them implemented this week. |
Yes, the intent was to use the same kernels in both samples. Only the shaders have subtle differences. |
bashbaug
left a comment
bashbaug
left a comment
There was a problem hiding this comment.
Couple other things will need to be fixed before we can merge:
- Can you please check that the CLA is all squared away? It's possible some of the latest commits were made with the wrong GitHub ID.
- Can you please take a look at the CI build errors? I didn't see them on my system, but we'll need to fix them one way or the other before merging.
| VERSION 300 | ||
| SOURCES main.cpp ocean.cpp ocean.hpp ocean_util.hpp | ||
| KERNELS twiddle.cl time_spectrum.cl inversion.cl normals.cl fft_kernel.cl init_spectrum.cl | ||
| SHADERS ocean.vert.glsl ocean.frag.glsl) |
There was a problem hiding this comment.
I wasn't able to build on my system without adding a glm dependency also:
| SHADERS ocean.vert.glsl ocean.frag.glsl) | |
| SHADERS ocean.vert.glsl ocean.frag.glsl | |
| LIBS glm::glm) |
9bb24b4 to
7b5ec3e
Compare
7b5ec3e to
44e005a
Compare
Fixed, CI is green across Linux, macOS, and Windows now. |
5 participants
For comparison purposes with #110
The sample follows 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 OpenCL and OpenGL to simulate an ocean surface.