Apparently needed for mingw build and doesn't affect the MSVC ones.
Thanks to Martin Hauke <mardnh@gmx.de> for reporting
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
This happens commonly on optimus laptop when CL is Nvidia and the GL
is the Intel card. They can't share data ...
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
If no data was processed, finished would return 0 and then the gl_refresh
would not be called which would lead to the GL deferred init to not be
executed which can crash the OpenGL driver.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
The basic idea is that we just create normal CL buffers, then whenever
we need to draw, we wait for CL completion, read the buffers into the
main memory and upload them as textures using plain GL.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
When calling the process method several time without drawing, we don't
need to release the GL objects or even calling clFinish. So here we
internally keep track and only do the 'finishing up' of the CL process
when doing a drawing call.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
The OpenCL 1.2 is nicer but we can't always use it and on linux,
even if the CL_VERSION_1_2 exists, we can't trust it because distrib
sometimes have CL 1.2 headers with a CL 1.1 dispatcher.
So instead, we only assume we have 1.1 header and lib at compile time.
Then at run-time we do a dynamic lookup of the 1.2 symbols from the lib.
We also check if the actual selected platform does support 1.2 (you
could have a 1.2 dispatcher with a 1.1 platform implementation).
If both conditions are satisfied, then we dispatch the call to the 1.2
implementation and if not, then we dispatch them to a local fallback
implementation of the functions (but limited to the functions we need)
It's not pretty but it should work and it isolates all the hack magic
inside cl_compat.{c,h} and you just use the CL1.2 API normally outside
of it.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
cl_platform.h will convert any sign of windows to this symbol and this
is also the one use for the include at the top, so use it everywhere.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
On system with an integrated gpu + external gpu, the integrated one looks
great "on paper". Plenty of local ram, plenty of compute units, ...
But in practice, it sucks against the external one. So here, we prefer
NVidia / AMD.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
- It's not longer hardcoded / computed in the kernel, but computed
once and read from constant memory
- By default it uses a periodic Hamming window
- But you can load any window as a simple array of float
- Different types of window is deemed out-of-scope here. The default
is provided just for convenience to have something valid.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Originally I wanted the CL/GL part to be as separate as possible and
have no shared data. But it's too inconvenient since a beside the
CL / GL objects there is also configuration data that should be shared
and distributed between the two.
So instead we still have separate gl/cl state that are restricted but
the function act on a shared 'struct fosphor' object that contains
everything that's shared and exposed to both cl.c and gl.c
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Basically need to :
- Set the kernel parameter at each kernel invocation
- Modify the kernel to deal with wrap-around when writing the
waterfall texture
The batch size still must meet some constraint :
- Be a multiple of FOSPHOR_FFT_MULT_BATCH
- Be less than FOSPHOR_FFT_MAX_BATCH
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Apparently there are some cards that are neither Nvidia SM1.1, nor
OpenCL 1.1 but that do have cl_khr_local_int32_base_atomics extension.
This is enough for fosphor to implement the histogram so add the
required code to test for it and enable its use in the kernel if
required.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
OSX doesn't allow query of NV attributes even on NVidia cards so we just
assume any non-opencl 1.1 nvidia card that does OpenCL is a SM1.1 one.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Sylvain Munaut