> With a working OpenCL platform -- that can be an OpenCL-cabable GPU driver, > or something like the intel OpenCL > implementation. Depending on what devices or how you pass through the CPU to > the VM, that might even work -- however, > gr-fosphor is just "one" awesome visualization making most of OpenCL to > reduce CPU load necessary to display an FFT for > every single input vector. If you can live with lesser update rates (and > hence, a reduced probability of interception), > simply go for the QT frequency or waterfall sinks.
Marcus, Good points. I switched to the Freq Sink, and it think that will be very useful. While I debug this further, is there any issues with running my transmit and receive from within the same X310? I am starting to wonder if this is part of my issue. > It's probably even worth it thinking about moving your signal processing out > of your VM; high rate visualizations > aren't exactly what virtual display adapters were made for... Totally agree. There are some new machines on order that I am hoping to snag one of. Time will tell... _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
