Forum: GNU Radio Re: gr-fosphor : New RTSA-like visualization block for GNURadio using GPU acceleration

D2595f4322a69535ddb92617d17f0eef?d=identicon&s=25 Louis Brown (madengr)
on 2013-10-30 04:19
(Received via mailing list)
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.
0f670021207b3329243056244633dcad?d=identicon&s=25 Nick Foster (Guest)
on 2013-10-30 07:08
(Received via mailing list)
All,

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 git@github.com: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.

Best,
Nick
0817fa933c74eec9b3fcf3a04e16f418?d=identicon&s=25 Sylvain Munaut (Guest)
on 2013-10-30 09:20
(Received via mailing list)
Hi,

> 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 ?

Cheers,

   Sylvain
0817fa933c74eec9b3fcf3a04e16f418?d=identicon&s=25 Sylvain Munaut (Guest)
on 2013-10-30 09:29
(Received via mailing list)
Hi Nick,

> 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
> git@github.com: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.


Cheers,

    Sylvain
0f670021207b3329243056244633dcad?d=identicon&s=25 Nick Foster (Guest)
on 2013-10-30 16:17
(Received via mailing list)
On Wed, Oct 30, 2013 at 1:28 AM, Sylvain Munaut <246tnt@gmail.com>
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
> > git@github.com: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.

--n
0817fa933c74eec9b3fcf3a04e16f418?d=identicon&s=25 Sylvain Munaut (Guest)
on 2013-11-10 23:15
(Received via mailing list)
Hi Nick,

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.


Cheers,

    Sylvain
7017d47554ed41cf59f9cc8cd661b0b4?d=identicon&s=25 M. G. (rffreak)
on 2014-02-02 21:19
(Received via mailing list)
Hi Sylvain,

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:

1) Can it be compiled without OpenCL?
2) Do you know beignet? Appearantly they try to implement OpenCL support
for
Haswell.

Cheers,

Markus




--
View this message in context:
http://gnuradio.4.n7.nabble.com/gr-fosphor-New-RTS...
Sent from the GnuRadio mailing list archive at Nabble.com.
0817fa933c74eec9b3fcf3a04e16f418?d=identicon&s=25 Sylvain Munaut (Guest)
on 2014-02-03 09:23
(Received via mailing list)
Hi Markus,


> 1) Can it be compiled without OpenCL?

No. All the data processing is done with OpenCL.


> 2) 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.


Cheers,

    Sylvain
7017d47554ed41cf59f9cc8cd661b0b4?d=identicon&s=25 M. G. (rffreak)
on 2014-02-03 22:31
(Received via mailing list)
Hi Silvain,

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.

Markus

Am 03.02.2014 um 09:21 schrieb Sylvain Munaut <246tnt@gmail.com>:
0817fa933c74eec9b3fcf3a04e16f418?d=identicon&s=25 Sylvain Munaut (Guest)
on 2014-02-03 23:04
(Received via mailing list)
Hi,

> 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
Please log in before posting. Registration is free and takes only a minute.
Existing account

NEW: Do you have a Google/GoogleMail, Yahoo or Facebook account? No registration required!
Log in with Google account | Log in with Yahoo account | Log in with Facebook account
No account? Register here.