Opened 10 years ago

Closed 10 years ago

#43710 closed defect (wontfix)

Open GL & CL errors after flawless install of gr-fosphor

Reported by: xformdave@… Owned by: michaelld (Michael Dickens)
Priority: Normal Milestone:
Component: ports Version: 2.2.1
Keywords: mavericks Cc:
Port: gr-fosphor

Description (last modified by ryandesign (Ryan Carsten Schmidt))

After a successful instal and launch of the normal osmosdr_fft when attempting to launch with the gr-fosphor graphics acceleration I receive errors and the python app window is blank. Machine is a 13" macbook 8,1, 2.7 ghz dual core i7, 10.9.2.

Errors as they came (each appeared several times during launch):

1st is probably unrelated but seen this several times will toying with gr-osmosdr and gqrx:

2014-05-13 20:27:08.820 Python[4980:d07] CoreText performance note: Client called CTFontCreateWithName() using name ".Lucida Grande UI" and got font with PostScript name ".LucidaGrandeUI". For best performance, only use PostScript names when calling this API.

2nd chuck Open GL related:

[!] gl_cmap shader compile log :
ERROR: 0:27: '' :  version '150' is not supported
ERROR: 0:27: '' : syntax error #version

[!] gl_cmap shader compilation failed (cmap_simple.glsl)
[w] Color map shader 'simple' failed to load, will use fallback
[!] gl_cmap shader compile log :
ERROR: 0:27: '' :  version '150' is not supported
ERROR: 0:27: '' : syntax error #version

[!] gl_cmap shader compilation failed (cmap_bicubic.glsl)
[w] Color map shader 'bicubic' failed to load, will use fallback
[+] Selected device: Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz

Last the CL error:

[!] CL Error (-54, /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_gr-fosphor/gr-fosphor/work/gr-fosphor-20140112/lib/fosphor/cl.c:684): Unable to queue FFT kernel execution

followed after 20+ reoccurrences by an error 11 seg fault.

I am admittedly in slighlty over my head at this point but to have things mostly working only to fault at this last step of gr-fosphor is frustrating. Any input is appreciated.

Attachments (1)

clInfo.c (12.4 KB) - added by 246tnt@… 10 years ago.

Download all attachments as: .zip

Change History (6)

comment:1 in reply to:  description Changed 10 years ago by xformdave@…

Replying to xformdave@…: Figured it out. No CL support on the 3000HD graphics.

comment:2 Changed 10 years ago by ryandesign (Ryan Carsten Schmidt)

Description: modified (diff)
Owner: changed from macports-tickets@… to michaelld@…

comment:3 Changed 10 years ago by Veence (Vincent)

The OpenGL shader compilation error might be caused by selecting a wrong profile. You should make sure the code picks up the Core profile (OpenGL 3.3) and NOT the compatibility profile (OpenGL 1.x). Besides, I’m not positive (you should check in the doc), I think in Marvericks the HD3000 driver has been bumped to OpenGL 3.3, in which case the version of the shading language might not be 150 (OGL 3.2 if memory serves) but 330.

Changed 10 years ago by 246tnt@…

Attachment: clInfo.c added

comment:4 Changed 10 years ago by 246tnt@…

The OpenGL errors are normal on OSX and those are not fatal. As the message says, the compilation fails but it will use a fallback method. (which in what's currently used shouldn't make much of a difference visually).

This error happens because I rely on the GLSL 1.5 compatibility profile for those shaders and OSX doesn't have any of the compatibility profiles. I basically want to use some of the advanced GLSL features not available in previous versions, but I don't want to give up the legacy pipeline. To go to full 3.x core profile, I'd need to completely give up immediate mode, use my own vertex shaders, re-implement the matrix stuff myself, etc, etc ... which I'm really not willing to do so I can just draw a few lines and 2 textured quads with pixel shaders applied ...

The CL error is the real issue. It says it selected "Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz" which is a CPU implemention of OpenCL since your GPU doesn't do OpenCL. Now, that means it evaluated the device and thought that it was capable of running fosphor. But obviously it wasn't because even though the initialization went nicely, when it tried to actually queue the execution of some compuation, it failed with CL_INVALID_WORK_GROUP_SIZE. To know if this is justified, it would be useful to see the actual capabilities of the device. I attached a clInfo.c test program that should print all the required info. If you could compile and execute it and post the results, it would be nice.

PS: Also, btw, I now _hate_ trac ... the damn 'attach file' function doensn't warn you it will just drop the whole comment you already typed ...

Last edited 10 years ago by 246tnt@… (previous) (diff)

comment:5 Changed 10 years ago by michaelld (Michael Dickens)

Resolution: wontfix
Status: newclosed

I'm glad that gr-fosphor installed flawlessly for you! The "CoreText performance note" are normal for 10.9. As 246tnt writes: many of the errors/warnings displayed are normal on OSX. The issue here is not with MacPorts, but rather with gr-fosphor and OSX's OpenGL -- likely some combination. I encourage the OP to discuss this issue with the gr-fosphor programmer (I'm assuming "246tnt@…"; from git logs "tnt@…") to resolve this issue. I'm going to defer fixing this issue to TNT; I can't really fix it myself. I'm closing this ticket as "wontfix" to indicate this status. Again: Please be in touch with TNT directly to resolve this issue.

Note: See TracTickets for help on using tickets.