These are purely display things that allow to highligh chunks of spectrum
of interest. (like currently selected channel)
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
There is a lot of parameters that have no influence on the internal
computations but solely affect the rendering call. The height / width
are the only two that were supported previously.
This commit re-structures the drawing code and introduces a lot more
of those parameters. Instead of just passing them all as arguments, a
'struct fosphor_render' is introduced to hold them.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
The texture coordinates didn't match what the normal OpenGL bilinear
mapper does. It was off by half a texel.
This is needed because the color in the texture is considered to be a
sample at the center of the texel. (hence 0.5f, 0.5f offset removed)
For more details on bilinear from OpenGL :
http://hacksoflife.blogspot.be/2009/12/texture-coordinate-system-for-opengl.html
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
This is required for OSX where you need to tell the GL context when resize
has occured and stuff like that.
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>
The setters can be called from any thrad and will just set the
member variables and a flag asking the main processing thread to apply
the new settings on the next iteration.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Although this is not actually used anywhere yet, but will be used in the
drawing routines to draw a proper scale.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
The CL code keeps its own copy since those values are tweaked to be
applied in the kernel. We may also need the callback in the future if
instead of storing them we reconfigure the kernel at that point.
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>
It seems that some linux distro ship OpenCL 1.2 headers but a OpenCL 1.1
ICD ...
So we just use OpenCL 1.1 API everywhere and disable 1.1 deprecated
warnings.
OSX OTOH doesn't allow to disable the deprecated but at least ships
consistent headers/ICD so we use 1.2 is available.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
You'd don't have to have glfw, qt and wx all at once, you can select
which variant you want built.
Python support is also make fully optional
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
It's split into:
- A generic "base" sink that handles pretty much everything except
managing a GL context and getting the UI interaction for it
- The GLFW specific part
This is preparation for for WX and QT widget implementations of a
fosphor sink.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
I originally thought that even with multiple fosphor instance, the shaders
could just be shared. But if those instances are binded to different
GL Contexts, shaders aren't shared and so need to be recreated.
So all the gl_cmap shader stuff is now stored inside a fosphor_gl_cmap_ctx
struct and the latter is stored in fosphor_gl_state
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Since all the cmap stuff is fosphor-specific and can't be really
reused, use the fosphor_ prefix for stuff exposed outside gl_cmap.c
itself.
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
Konstanty Bialkowski