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 reverts commit 585bac0316983286830f3bc50fce8247bad142f9.
This is causing issue with Ubuntu and its lack of libpng 1.6 ... so
removed for now.
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>
Turns out some fucked up compilers (MSVC I'm looking at you) don't
support strings that are very long.
So in the resource compiler:
- Change binary encoding to use a separate declaration and use array
rather than string encoding
- If a text file is > 64k, use the binary encoding method rather than
string
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Theses are not in header, and we don't really care about inlining, and
the compiler will most likely do it if it thinks its appropriate anyway.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Since this is not actually executable, don't need it and it apparently
creates some warning when making RPM packages ...
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Since we always call swap buffer between a call to draw and
the next call to process(), we don't need it. In the future,
make this an option in case there is some usecase that require
it.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
This app is CL 1.1 compatible and so we're forced to use some API
that were deprecated in 2.0, no need to be constantly reminded of
it
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
I originally used 1.5 compatibility because it still allows immediate
mode / fixed pipeline without warning. But Intel Cards on linux and
OSX in general don't implement it.
Using 1.3 works fine since I don't need anything more recent, but
if you display the compilation results, it will for a deprecation
warning.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
GL_MODULATE is required and since it might be used in other mode for
other function, we need to set it explicitely.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Much faster than glTexImage2D since it only updates the data
and doesn't delete/create a new storage space for the 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>
- Update the GrXXX modules from the GNURadio counter parts
- Remove the included FindGnuradio and rely on the installed one
(force 3.7.3 since previous ones are broken)
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Although in theory there is nothing wrong with this and fosphor itself
should support it. However it seems some OpenCL implementation don't
really like having multiple context created in parallell, so we prevent
this manually here.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
This has been removed of Gnuradio iteself in 2012 and this seems to
be causing issues for some OOT on some platforms ...
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>
Sylvain Munaut