**** BEGIN LOGGING AT Sat Dec 31 02:59:56 2022 Dec 31 05:01:53 TI says they don't support OpenCL for the GPU on the TDA4VM Dec 31 05:39:49 Yeah, I can't speak to whether they officially support it — the error message definitely seems to suggest they don't. But in this case a stock build of OpenCV (either pre-installed or installed via pip, I don't recall) and other libraries. So if there's a normal API where a user unwittingly can invoke the unsupported codepath it's a bug in one of Dec 31 05:39:50 the libraries in the stack. Dec 31 05:40:40 This one is caused by a call to "cv2.rectangle" (i.e., draw a rectangle). Nothing special, no custom builds or options, etc. Dec 31 05:41:03 The only requirement as far as I can tell is that at least one of the pixel coordinates is a float Dec 31 05:57:54 kaelin: ah, I see in the traceback that they're trying to probe whether openCL is available, and this triggers an abort in the powervr library... yeah that's pretty rude Dec 31 06:01:23 kaelin: wb Dec 31 06:02:36 kaelin: where does this libOpenCL.so come from? (dpkg-query --search libOpenCL.so) Dec 31 06:03:13 Haha I was just writing to ponder where it came from Dec 31 06:03:32 you could try temporarily renaming/moving it to see if that fixes the problem but my guess would be that other libs have a dep on it Dec 31 06:03:46 I'm going to assume it's from a bb.org-vendored package, I'll need to check when I get back home in a couple hours. Dec 31 06:04:54 kaelin: ah, I found something useful\ Dec 31 06:04:56 https://github.com/opencv/opencv/blob/master/modules/core/src/ocl.cpp#L1167 Dec 31 06:05:14 it seems you can set the environment variable OPENCV_OPENCL_RUNTIME=disabled Dec 31 06:05:25 to forcibly disable opencv support Dec 31 06:05:35 opencl support in opencv I mean Dec 31 06:06:38 Ooh nice, I'll definitely try that Dec 31 06:09:27 the alternative would have been to just create a trivial clGetPlatformIDs() function in your program, overriding the one in libOpenCL.so Dec 31 06:11:23 Haha yeah I didn't do too much digging after what I posted above (I've been out of the house) so I hadn't looked into the logic thay invokes OpenCL. In this particular case, I'm working in Python so don't have an easy way to override linker symbols, but the idea is reasonable. Dec 31 06:27:58 kaelin: it's surprisingly easy to override shared library symbols in any program, you don't even need the source code, you can use LD_PRELOAD: https://pastebin.com/34tjhKt5 Dec 31 06:43:41 kaelin: btw, in case it's of interest, TI does support OpenVX for hw-acceleration for vision stuff, but I don't know if that's useful for opencv or your particular application Dec 31 07:45:04 zmatt: https://pastebin.com/rdm2Ei0U Dec 31 07:45:53 OpenCV gives the _wrong_ error message (I think), but at least it's an appropriate parameter error, when disabling the OpenCL acceleration. Dec 31 07:47:49 It's not a blocker for me since giving fractional pixel coords to OpenCV drawing functions is "incorrect" (and warrants an error), it's just an inscrutable error condition to arrive at which doesn't point you to the root cause. If OpenCL is going to crash on the BB then IMO it shouldn't be included/all backends should be disabled. Dec 31 07:57:41 Yeah it looks like OpenCV has a codepath in its Python binding logic which, when it detects invalid parameters, ends up attempting to copy a matrix which in turn probes for OpenCL. So any time you pass an invalid parameter type to a Python OpenCV function on the BB it'll give this silly OpenCL abort assertion error and crash. Dec 31 09:07:45 kaelin: I'm a bit worried about that other OpenCL.so.1, I wonder if there's shared library confusion happening Dec 31 09:09:19 kaelin: anyway, OPENCV_OPENCL_RUNTIME=disabled looks like a good enough workaround. you can probably even set that environment variable in your python code (before importing any opencv library) Dec 31 09:10:38 (os.environ['OPENCV_OPENCL_RUNTIME'] = 'disabled') Dec 31 09:49:50 zmatt: Yeah, I'm not really worried about my own use-case anymore -- I can work around it -- I'm more worried about impact on other users. It's a pretty big flaw if a user encounters this without doing anything particularly strange on a stock BB image and board. I'll take another look tomorrow. But I've now run into this in a few different cases today while working with OpenCV which means it'd be really easy for an Dec 31 09:49:50 up blocked by it. Dec 31 09:58:47 kaelin: removing ti-sgx-j721e-ddx-um entirely might also be an option assuming you don't actually intend to use the gpu Jan 01 00:03:12 rcn-ee: on the current bullseye image, disabling cape-universal in /boot/uEnv.txt doesn't work. downgrading the kernel to 4.19-ti fixes the problem Jan 01 00:07:19 also, happy new year! Jan 01 00:21:54 Festivities! **** ENDING LOGGING AT Sun Jan 01 02:59:56 2023