gr-fosphor CL_INVALID_VALUE in clEnqueueFillBuffer call

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.com
Fri Feb 3 19:06:19 UTC 2017


Hi Raj,

> I'm using the latest fosphor from git
> (7b6b9961bc2d9b84daeb42a5c8f8aeba293d207c) and am seeing two weird (and I
> believe related) issues. Firstly, I see the following error:
>
> [+] Selected device: TITAN X (Pascal)
> [!] CL Error (-30, /home/user/gr-fosphor/lib/fosphor/cl.c:409): Unable to
> queue clear of spectrum buffer

That's really weird indeed. Although I've seen it before. Can't
remember exactly what it was though ...


> This is CL_INVALID_VALUE returning from clEnqueueFillBuffer, so I added some
> debug fprints to cl.c to see what parameters were being passed into
> clEnqueueFillBuffer:

Watchout that CL 1.2 might not be supported by NVidia's driver and so
it might use the fallback path defined in cl_compat.c


> But there is this one condition that might be met, which is that somehow
> size (16384) is larger than the underlying buffer (cl->mem_spectrum). The
> underlying OpenGL buffer being too small brings me to my next (I believe
> related) issue. The spectrum plot in fosphor is weirdly pixelated, please
> see the attachment, which shows a screencap from "osmocom_fft -F -f 100e6 -g
> 20 -s 10e6".
>
> Where is the cl->mem_spectrum buffer ultimately declared / initialized? My
> OpenCL / OpenGL sharing knowledge is nonexistent, any pointers for how I can
> help debug this issue?

So, there is two way that mem_spectrum can be initialized depending on
wether CL/GL sharing is active or not.
Look into cl_init_buffers_gl and cl_init_buffers_nogl basically.

But I've seen drivers do things that are not spec compliant
unfortunately ... and other than trying random stuff to see exactly
what they don't like, I'm not sure what to do.


Cheers,

    Sylvain



More information about the osmocom-sdr mailing list