This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/osmocom-sdr@lists.osmocom.org/.
Sylvain Munaut 246tnt at gmail.comOh, wow, very interesting ! Thanks for taking the time to dig into this. I just got a RTX2070, I still need to actually install some linux version on it, but I'll be sure to confirm and merge a patch for that. Cheers, Sylvain On Sat, Sep 28, 2019 at 4:42 PM Aaron Giles <gilesam73 at gmail.com> wrote: > > >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/oclSimpleGL.tar.gz > > [2] > https://git.osmocom.org/gr-fosphor/tree/lib/fosphor/gl.c#n235 >