>Yeah, the nVidia driver is annoying ... it used to work and they broke
>it a few years ago and they don't care enough to fix it.
>And since I got a new laptop a few years back, I don't have a nvidia
>card to debug or work around it.
I compared fosphor to the nVidia OpenCL Simple OpenGL Interop example [1]
and noticed that fosphor calls glMapBuffer/glUnmapBuffer to clear the
spectrum vbo between the calls to glBufferData and clCreateFromGLBuffer.
If I eliminate the map/memset/unmap here by removing the call to
gl_vbo_clear in gl_deferred_init [2], then clCreateFromGLBuffer returns
CL_SUCCESS and fosphor appears to work with CL/GL sharing. It is not clear
to me if clearing the vbo_spectrum is necessary here, since
cl_queue_clear_buffers later initializes the mem_spectrum buffer to the
noise floor.
I'm using an nvidia GTX 1650 with version 430.50 of the nvidia drivers
under Linux Mint 18. A friend of mine tested the GTX 1060 and also had
success with this workaround.
Aaron
[1]
http://developer.download.nvidia.com/compute/DevZone/OpenCL/Projects/oclSim…
[2]
https://git.osmocom.org/gr-fosphor/tree/lib/fosphor/gl.c#n235
Dear Osmocom SDR community,
Dear Dimitri,
the situation around gr-osmosdr has been deteriorating for years.
Among other things, I notice:
* there has not been a tagged release since 2014
* patches (e.g. fixing clang support) are not merged
* there is no support for gnuradio 3.8
I raised at least some of this both on-list (in June 2018 at
http://lists.osmocom.org/pipermail/osmocom-sdr/2018-June/001766.html)
and off-list in personal discussions, e.g. at CCCamp2019
It is clear that technically there are alternatives these days
(mainly SoapySDR, which didn't exist when gr-osmosdr started in 2012).
However, at the same time I'm seeing plenty of users asking about gr3.8
support, as there are [probably] lots of existing applications which
are not ported to other input blocks. As the overall Osmocom project
leader, this puts me in a difficult position: I've never been involved
with gr-osmosdr myself, but I get various related e-mail which show that
there are users, and that they are struggling by a lack of maintenance.
It appears that original author and maintainer Dimitri has lost time
and/or interest in maintaining gr-osmosdr. That's very sad, but it is a
fact that people have a limited amount of time, and priorities change.
I'd like to thank Dimitri and all other gr-osmosdr
developers/contributors for what they have done so far.
But what has unfortunately been missed here during the last 1-2 years is
passing the project over to a new maintainer or group of maintainers.
Just because the original author is not around anymore, it doesn't mean
the project has to die. So with this message, I'm publicly calling for
some other community member[s] to step up and become maintainer[s] of
gr-osmosdr.
Who is interested in gr-osmosdr and willing to maintain it, possibly in
a team with other interested folks?
I would be more than happy to provide the respective accounts/access on
the osmocom.org redmine as well as the official osmocom.org upstream
repository.
There's a list of open issues at http://osmocom.org/projects/gr-osmosdr/issues
I know there are also many forks on github, including
* https://github.com/igorauad/gr-osmosdr/tree/gr3.8 gr3.8 support
* https://github.com/xtrx-sdr/gr-osmosdr/ with xtrx support
* https://github.com/zhovner/gr-osmosdr and https://github.com/Sevyls/gr-osmosdr
with clang/MacOS related fix
* https://github.com/wirstrom/gr-osmosdr with soapy end-of-burst fix
* https://github.com/thegildedturtle/gr-osmosdr hackrf raspi signedness fix?
* https://github.com/ScanOC/gr-osmosdr print AirSpy serial number on connect
* https://github.com/romeojulietthotel/gr-osmosdr cosmetics
* https://github.com/racerxdl/gr-osmosdr spyserver support?
* https://github.com/rascustoms/gr-osmosdr airspy related patches
* https://github.com/newdreamlj/gr-osmosdr bladerf multi stream fix
* https://github.com/Lukeekul/gr-osmosdr bladerf pass source/sink args
* https://github.com/IW0HDV/gr-osmosdr perseus HF support
* https://github.com/dl1ksv/gr-osmosdr rs-hfiq support
* https://github.com/carpikes/gr-osmosdr/ hackRF AVX/SSE performance
* https://github.com/aports-ugly/gr-osmosdr gr3.8 + xtrx support
* https://github.com/amungo/gr-osmosdr ADSDR support
* https://github.com/0pq76r/gr-osmosdr/commits/master expose rtl-sdr gain stages
So there's no shortage of interesting fixes and features to investigate
and/or merge, even beyond the 'make a release and port to gr3.8'.
Thanks in advance!
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hi everyone,
I've created a branch of fosphor with the goal of making it compatible with
GNU Radio 3.8 (specifically the maint-3.8 branch). I've branched fosphor
from
https://github.com/osmocom/gr-fosphor/tree/gr38-qt5.
My branch is located at
https://github.com/the-aerospace-corporation/gr-fosphor/tree/gr38-qt5-aero
The changes are updates to the cmake scripts and modules, most of which are
derived directly from the 3.8 module porting guide located at
https://wiki.gnuradio.org/index.php/GNU_Radio_3.8_OOT_Module_Porting_Guide
Development was performed in Ubuntu 18.04 with GNU Radio installed using
pybombs and Python 3 support as described at
https://github.com/gnuradio/gnuradio
and using a prefix-based GNU Radio install. The updated fosphor branch has
been tested with NVidia and Intel OpenCL. At this point GLFW works but QT
does not.
To build and install the updated fosphor branch, install GNU Radio 3.8 from
the maint-3.8 branch, install all dependencies as described at the fosphor
wiki, then execute
git clone https://github.com/the-aerospace-corporation/gr-fosphor
cd gr-fosphor
git checkout gr38-qt5-aero
mkdir build
cd build
cmake ..
make
make install
I'm interested in the process for merging my updates back to the official
repository. For instance, additional testing using different platforms
might be a good idea.
Best,
Terry Ferrett, Signal Processing and Estimation Engineer
The Aerospace Corporation <https://aerospace.org/>, El Segundo, CA
Hello,
I'm creating a GNU Radio OOT module in C++ language, in which I instantiate
an osmosdr source. The syntax is : osmosdr::source ::sptr m_source =
osmosdr::source::make();
I also implement other blocks in my design.
In CMakeLists.txt file, I specify all these components:
set(GR_REQUIRED_COMPONENTS RUNTIME BLOCKS FFT OSMOSDR)
find_package(Gnuradio-osdmosdr REQUIRED)
include_directories(
...
${GNURADIO_OSMOSDR_INCLUDE_DIRS}
)
link_directories(
...
${GNURADIO_OSMOSDR_LIBRARY_DIRS}
)
In cmake/Modules folder, I copied the FindGnuradio-osmosdr.cmake file from
gqrx project.
The logs of cmake command show that the osmosdr library is found:
-- checking for module 'gnuradio-osmosdr'
-- Found gnuradio-osmosdr, version v0.1.4-127-g4d83c606
-- Found GNURADIO_OSMOSDR: /usr/local/lib/libgnuradio-osmosdr.so
After compiling the module (cmake .. -> make -> make install -> ldconfig),
I got the error 'AttributeError: 'module' object has no attribute 'test'. I
analysed the undefined symbol, and it was due to osmosdr module.
Any suggestion to solve this problem?
PS:
- I'm working on Ubuntu 16.04 (VM), gnuradio 3.7.9, cmake 3.5.1
- In GRC, the osmosdr source and sink work fine
Thanks.