Thanks, that worked. It complied without GLFW but it errs at run time
with:
ImportError: libgnuradio-fosphor-3.7.0git.so.0.0.0: cannot open shared
object file: No such file or directory
I passed the GLFW directories to cmake, and edited line 26
of glfw_sink_c_impl.cc to remove the directory name preceding the header
file, the but then it errs at complile with:
/usr/local/src/gr-fosphor/lib/glfw_sink_c_impl.cc:51:48: error:
‘glfwGetFramebufferSize’ was not declared in this scope
glfwGetFramebufferSize(this->d_window, &w, &h);
Just strange that cmake is not picking up the libraries. My editing
probably messed something up.
I’ve added basic sample rate awareness to gr-fosphor via constructor
parameters and a set_rate() call. The GRC blocks now take a sample rate
parameter as well. The sink also creates an appropriate legend (kHz,
MHz,
etc.) and applies it to the plot. I’ve tested it with WX, Qt, and GLFW
versions of the sink.
Sylvain, if you’d like to pull it back, it’s in a Github repo
at [email protected]:bistromath/gr-fosphor.git. I’ve also added a CMake
check
for the Python OpenGL bindings, as I somehow managed to not have them
installed on my new machine.
ImportError: libgnuradio-fosphor-3.7.0git.so.0.0.0: cannot open shared
object file: No such file or directory
Did you install it in the same prefix as gnuradio was installed in ?
Not sure where your GR install comes from …
I passed the GLFW directories to cmake, and edited line 26
of glfw_sink_c_impl.cc to remove the directory name preceding the header
file, the but then it errs at complile with:
/usr/local/src/gr-fosphor/lib/glfw_sink_c_impl.cc:51:48: error:
‘glfwGetFramebufferSize’ was not declared in this scope
glfwGetFramebufferSize(this->d_window, &w, &h);
Just strange that cmake is not picking up the libraries. My editing
probably messed something up.
Are you sure you compiled GLFW3 (and not the 2.x series) ?
And compiled it as a shared library ?
And for opencl, is /usr/lib64/nvidia in the LD_LIBRARY_PATH or in
/etc/ld.so.conf (or similar for your distro).
Maybe it’s not meant to be used directly and you should call it
through the ICD ? Fedora seems to have an opencl-icd package, is that
installed ?
I’ve added basic sample rate awareness to gr-fosphor via constructor
parameters and a set_rate() call. The GRC blocks now take a sample rate
parameter as well. The sink also creates an appropriate legend (kHz, MHz,
etc.) and applies it to the plot. I’ve tested it with WX, Qt, and GLFW
versions of the sink.
Nice, but unfortunately I’m working on my own version of this.
I wasn’t really happy with the current set_range. So I’m doing a bit
of refactoring. Basically the cl_state and gl_state struct will be
kept around for strictly CL/GL stuff but most method will get the full
fosphor struct as argument and I will put shared stuff and things not
strictly CL/GL there. For example the sample rate is useful in CL to
dynamically adapt the batch size and the time constants of fading to
ensure low latency in low bitrate case and performance in high bitrate
cases. And there is some similar stuff happenning with other types of
set/get I wanted to put in so I decided to do the refactor first.
Sylvain, if you’d like to pull it back, it’s in a Github repo at [email protected]:bistromath/gr-fosphor.git. I’ve also added a CMake check for
the Python OpenGL bindings, as I somehow managed to not have them installed
on my new machine.
Interesting. Did that actually prevent build ? What was the symptom ?
A choice I’ve made (albeit a possibly questionable one) was to only
check for things required at build time.
For example, I don’t check you have WX Python installed either … if
you don’t the import will fail in python but be caught and the sink
will just not work but shouldn’t prevent using the others and if you
want the WX one, just install the dependencies afterwards and no need
to rebuild gr-fosphor.
I’ve just pushed all the things that were pending in my tree, which
include the sample rate awareness, configurable FFT windows and
various fixes / refactor for more things to come.
Great! Glad to hear it. You might still take a look at the changes to gl.c,
as they’re orthogonal to your reorganization and it adds a nice autoranging
sample rate text and legend.
I looked at it and improved on it to support displaying the center
frequency as well and switch automatically between several display
modes depending on what’s available (span/center) and their relative
relation to one another.
That’s fine. Really it was just a matter of a poor user experience – when
the Python OpenGL bindings aren’t there, the WX import fails in init.py,
and all the user sees is “no block named wx_core_c”. Perhaps a better
failure message in init.py is all that’s needed.
I improved the error reporting. If the import failed, it keeps the
stack trace and exception but doesn’t display them at first. But if
you try to actually instanciate the WX version, then, it will display
the error and matching stack trace so that you know what went wrong.
I am lucky to have a new Laptop with i7 Haswell CPU, however you have
written on gr-fosphor homepage that intel does not offer OpenCL for
Haswell
on Linux. (Appearantly due to some self cannibalization issue of their
products if done so, as suggested somewhere else on the internet). I
have
two questions:
Can it be compiled without OpenCL?
Do you know beignet? Appearantly they try to implement OpenCL support
for
Haswell.
Do you know beignet? Appearantly they try to implement OpenCL support for
Haswell.
Yes and this should in time allow to run fosphor.
But I don’t think they’re sufficiently advanced yet to do it. Last
time I checked they were missing some features required for fosphor
like :
Single channel float textures (sharing with OpenCL into a cl_mem)
Sharing of Vertex Buffer Objects (used for the ‘live’ spectrum line
and the ‘max hold’ line)
Possibly missing more, I was just taking a quick look at the code. I
don’t have any hardware supporting it …
Might be worth asking the Beignet dev if those are on their roadmap or
just implement them yourself, or hack fophor to disable some features
temporarely.
great - thanks for your answer. I got it run now on OS X via simple
macports install. However I will follow the issue from time to time, as
I think it would be great to have beignet available for this (and other)
purposes.
Also I am keen on looking into how the colored spectrum view is
implemented by you ( I have no glue and have not yet looked into it).
HOWEVER: I did some offline studies on this kind of plots a while ago in
python. what I found to look nice was the following idea:
Plot like a monochrome FFT with persistence on and where each of the
line has some alpha (even the first one). So naturally the more often a
peak occurs with the same level, the stronger (or more opaque) the point
will be. Then apply a simple jet colormap (or any other suitable
colormap) to the monochrome plot. As said, I have not looked into your
code yet, chances are you are doing exactly that.
This, by the way would not only make sense for the spectrum view, but
also for the scope as it gives some nice colored eye-diagrams.
Also I read earlier, that someone was asking about the benefit of this
kind of plot with respect to a simple FFT (with persistence). The
benefit of course is that you can see the probability distribution at
frequency points of interest (f = const-line) and that you still see
single occurring events, as they will not be very weak as in a FFT with
persistence, but have some dedicated good visible color for a while.
On Wed, Oct 30, 2013 at 1:28 AM, Sylvain M. [email protected]
wrote:
I wasn’t really happy with the current set_range. So I’m doing a bit
of refactoring. Basically the cl_state and gl_state struct will be
kept around for strictly CL/GL stuff but most method will get the full
fosphor struct as argument and I will put shared stuff and things not
strictly CL/GL there. For example the sample rate is useful in CL to
dynamically adapt the batch size and the time constants of fading to
ensure low latency in low bitrate case and performance in high bitrate
cases. And there is some similar stuff happenning with other types of
set/get I wanted to put in so I decided to do the refactor first.
Great! Glad to hear it. You might still take a look at the changes to
gl.c,
as they’re orthogonal to your reorganization and it adds a nice
autoranging
sample rate text and legend. I agree putting everything in a large
struct
is the C-ish way to do things.
Sylvain, if you’d like to pull it back, it’s in a Github repo at [email protected]:bistromath/gr-fosphor.git. I’ve also added a CMake check
for
the Python OpenGL bindings, as I somehow managed to not have them
installed
on my new machine.
Interesting. Did that actually prevent build ? What was the symptom ?
A choice I’ve made (albeit a possibly questionable one) was to only
check for things required at build time.
For example, I don’t check you have WX Python installed either … if
you don’t the import will fail in python but be caught and the sink
will just not work but shouldn’t prevent using the others and if you
want the WX one, just install the dependencies afterwards and no need
to rebuild gr-fosphor.
That’s fine. Really it was just a matter of a poor user experience –
when
the Python OpenGL bindings aren’t there, the WX import fails in init.py, and all the user sees is “no block named wx_core_c”.
Perhaps a
better failure message in init.py is all that’s needed.
However I will follow the issue from time to time, as I think it would be great
to have beignet available for this (and other) purposes.
Yes, it’d be great and I would love if a beignet dev was also
interested and SDR and tried to make it work and implement the missing
stuff.
Or a SDR guy experience in GPU programming that could hack both in
beignet and fosphor.
Also I am keen on looking into how the colored spectrum view is implemented by
you ( I have no glue and have not yet looked into it). HOWEVER: I did some offline
studies on this kind of plots a while ago in python. what I found to look nice was
the following idea:
Plot like a monochrome FFT with persistence on and where each of the line has
some alpha (even the first one). So naturally the more often a peak occurs with
the same level, the stronger (or more opaque) the point will be. Then apply a
simple jet colormap (or any other suitable colormap) to the monochrome plot. As
said, I have not looked into your code yet, chances are you are doing exactly
that.
Actually that’s not at all implemented like this at all. You might
want to look at my grcon slides for more info. The code is pretty well
optimized (from a math point of view) which makes it a bit hard to
understand wtf is going on …
What you describe is closer to what’s implemented in the ‘persistence’
mode of the WX sink. However it doesn’t look as good but that might be
because the WX sink has much less spectra/second processed.
This, by the way would not only make sense for the spectrum view, but also for
the scope as it gives some nice colored eye-diagrams.
Yes, that’d probably be nice to try as well.
Cheers,
Sylvain
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.