EXEC_BAD_ACCESS in 2-line OpenGL program - macos

The following simple program produces an EXEC_BAD_ACCESS (segmentation fault) when run, and I don't understand why:
#include <OpenGL/gl.h>
int main(void) {
const GLubyte * strVersion;
// The next line gives an 'EXEC_BAD_ACCESS'
strVersion = glGetString (GL_VERSION);
}
I'm running in Xcode in OS X 10.6.5, and I'm linking against the OpenGL framework. Any ideas would be appreciated.


You have to create an OpenGL context before you can call gl* functions. There are several ways to do that, for example using GLUT or SDL.


For C Specification to create the variable GLubyte you call it by
const GLubyte* glGetString(GL_VERSION );
then you should be able to get the version. by the following
const char *GLVersionString = glGetString(GL_VERSION);
//Or better yet, use the GL3 way to get the version number
int OpenGLVersion[2];
glGetIntegerv(GL_MAJOR_VERSION, &OpenGLVersion[0])
glGetIntegerv(GL_MINOR_VERSION, &OpenGLVersion[1])
here is more basic information on glGetString:
glGetString returns a pointer to a static string describing some aspect of the current GL connection. name can be one of the following:
GL_VENDOR
Returns the company responsible for this GL implementation.
This name does not change from release to release.
GL_RENDERER
Returns the name of the renderer.
This name is typically specific to a particular configuration of a hardware platform.
It does not change from release to release.
GL_VERSION
Returns a version or release number.
GL_SHADING_LANGUAGE_VERSION
Returns a version or release number for the shading language.
GL_EXTENSIONS
Returns a space-separated list of supported extensions to GL.

Related

How to get gcc to compile 16-bit unicode strings

So I'm trying to compile this project : https://github.com/dmitrystu/libusb_stm32 with Segger Embedded studio which uses gcc. The process is choking on this error :
pasting formed 'u"Open source USB stack for STM32"', an invalid preprocessing token
which is caused by this line :
static const struct usb_string_descriptor manuf_desc_en = USB_STRING_DESC("Open source USB stack for STM32");
So USB_STRING_DESC is a macro :
#define USB_STRING_DESC(s) {.bLength = sizeof(CAT(u,s)),.bDescriptorType = USB_DTYPE_STRING,.wString = {CAT(u,s)}}
And CAT is a macro CAT(x,y) x##y. The intent must be to convert a string of type 8-bit char into a 16-bit Unicode type but the compiler doesn't like it. Is there some #include or compiler setting that may be missing that I have to add here? Clearly the author of this code expects it to work so there must be some fault in my setup.
Also I'm not clear on how the sizeof() operation is supposed to work here. As I understand it there is no way to get the length of a string at compile time so that operation will always return the size of a pointer.

In response to Keith's question, the gcc version is 4.2.1. Poking around the compiler settings the default option is the C99 standard, when I changed it to C11 everything compiled just fine. Thanks!

Unknown type name array

I have a metal 2 shader on macOS 10.12 that I am trying to pass an array of int into, but XCode is giving me a compile-time error Unknown type name 'array'. Here is the code I am using:
kernel void computeMandelbrot(texture2d<float, access::write> output [[texture(0)]], constant int &maxIterations [[buffer(1)]], const array<int, 10> &hist [[buffer(2)]], uint2 gid [[thread_position_in_grid]]) {
// Compute Mandelbrot
}
I have also tried using the keyword constant instead of const but then I also get an error of Parameter may not be qualified with an address space. I had read that arrays of textures were not supported in metal on macOS, but I was not sure if this appled to arrays of other types. Any help would be greatly appriciated, thank you!

A few things:
Metal 2 is not available in macOS 10.12. It is new with 10.13.
array is only usable with textures and samplers.
array is not available on macOS <=10.12. It's available on macOS 10.13+ with Metal 2.
You can declare your parameter as constant int *hist [[buffer(2)]]. It won't have an explicit length, but just limit what elements you reference.
Edit: I was wrong about array only being usable with textures and samplers. The spec suggests that to be the case by introducing it in a section titled "Arrays of Textures and Samplers" and only illustrating its use that way, but the template class itself seems generically useful.
However, until Metal 2, it's not available on macOS. In other words, it's only available on macOS 10.13+.

OpenACCArray swap function

while trying to create an object oriented OpenACC implementation I stumbled upon this question.
From there I took the code provided by #mat-colgrove at the GTC15 (code available at http://www.pgroup.com/lit/samples/gtc15_S5233.tar).
Since I am interested how to use objects to manage data on with OpenACC I posted another question.
I was quite impressed by the ease of the OpenACCArray::swap function, so I created a small example to test it (see gist).
First I tried to just swap and hope that it is sufficient to swap the pointers on the host, but this ends in a fatal memory error. (presumably because the size and capacity members are not updated on the device)
A safer approach, that I assumed to work is to update the host, swap arrays and update device. This runs but creates wrong results.
I am compiling for nvidia accelerators.

Looks like this is my fault since I didn't test the swap routine.
The problem here is while the code is swapping the data on the host, the device copy of the objects still point to the old array. The fix is to re-attach (i.e. set the object's device pointers to the correct arrays) the lists.
void swap(OpenACCArray<type>& x)
{
type* tmp_list = list;
int tmp_size = _size;
int tmp_capacity = _capacity;
list = x.list;
_size = x._size;
_capacity = x._capacity;
x.list = tmp_list;
x._size = tmp_size;
x._capacity = tmp_capacity;
#ifdef _OPENACC
#pragma acc update device(_size,_capacity,x._size,x._capacity)
acc_attach((void**)&list);
acc_attach((void**)&x.list);
#endif
}
"acc_attach" is a PGI extension that hopefully will be adopted in the OpenACC 3.0 standard.
Thanks for trying things out and let me know if you encounter other issues.
- Mat

freeimage 3.17 library build failing on Mac OS X: fails with C++11 narrowing error... any ideas?

With not having any understanding of C++ (I'm teaching myself Swift), I'm struggling a bit to get around this one - but ideally would love to be able to expose some of the functionality in the FreeImage library in my project.
It appears that only one module is generating any errors: dcraw_common.cpp - and the lines in error are those from the following entry list where there is a value of 0x80 or above. From the investigations I've done, it would appear that these values are too large for a signed char (max 128?), yet the list also includes negative numbers, and so it can't use an unsigned char.
Any help would be most gratefully received.
Here's an example of the error message generated by the make process:
Source/LibRawLite/./internal/dcraw_common.cpp:4543:19: error: constant expression evaluates to 136 which cannot be narrowed to type 'signed char'
[-Wc++11-narrowing]
+1,-1,+1,+1,0,0x88, +1,+0,+1,+2,0,0x08, +1,+0,+2,-1,0,0x40,
^~~~
And here's the code:
void CLASS vng_interpolate()
{
static const signed char *cp, terms[] = {
-2,-2,+0,-1,0,0x01, -2,-2,+0,+0,1,0x01, -2,-1,-1,+0,0,0x01,
-2,-1,+0,-1,0,0x02, -2,-1,+0,+0,0,0x03, -2,-1,+0,+1,1,0x01,
-2,+0,+0,-1,0,0x06, -2,+0,+0,+0,1,0x02, -2,+0,+0,+1,0,0x03,
-2,+1,-1,+0,0,0x04, -2,+1,+0,-1,1,0x04, -2,+1,+0,+0,0,0x06,
-2,+1,+0,+1,0,0x02, -2,+2,+0,+0,1,0x04, -2,+2,+0,+1,0,0x04,
-1,-2,-1,+0,0,0x80, -1,-2,+0,-1,0,0x01, -1,-2,+1,-1,0,0x01,
-1,-2,+1,+0,1,0x01, -1,-1,-1,+1,0,0x88, -1,-1,+1,-2,0,0x40,
-1,-1,+1,-1,0,0x22, -1,-1,+1,+0,0,0x33, -1,-1,+1,+1,1,0x11,
-1,+0,-1,+2,0,0x08, -1,+0,+0,-1,0,0x44, -1,+0,+0,+1,0,0x11,
-1,+0,+1,-2,1,0x40, -1,+0,+1,-1,0,0x66, -1,+0,+1,+0,1,0x22,
-1,+0,+1,+1,0,0x33, -1,+0,+1,+2,1,0x10, -1,+1,+1,-1,1,0x44,
-1,+1,+1,+0,0,0x66, -1,+1,+1,+1,0,0x22, -1,+1,+1,+2,0,0x10,
-1,+2,+0,+1,0,0x04, -1,+2,+1,+0,1,0x04, -1,+2,+1,+1,0,0x04,
+0,-2,+0,+0,1,0x80, +0,-1,+0,+1,1,0x88, +0,-1,+1,-2,0,0x40,
+0,-1,+1,+0,0,0x11, +0,-1,+2,-2,0,0x40, +0,-1,+2,-1,0,0x20,
+0,-1,+2,+0,0,0x30, +0,-1,+2,+1,1,0x10, +0,+0,+0,+2,1,0x08,
+0,+0,+2,-2,1,0x40, +0,+0,+2,-1,0,0x60, +0,+0,+2,+0,1,0x20,
+0,+0,+2,+1,0,0x30, +0,+0,+2,+2,1,0x10, +0,+1,+1,+0,0,0x44,
+0,+1,+1,+2,0,0x10, +0,+1,+2,-1,1,0x40, +0,+1,+2,+0,0,0x60,
+0,+1,+2,+1,0,0x20, +0,+1,+2,+2,0,0x10, +1,-2,+1,+0,0,0x80,
+1,-1,+1,+1,0,0x88, +1,+0,+1,+2,0,0x08, +1,+0,+2,-1,0,0x40,
+1,+0,+2,+1,0,0x10
}, chood[] = { -1,-1, -1,0, -1,+1, 0,+1, +1,+1, +1,0, +1,-1, 0,-1 };
...

C++11 prevents 'narrowing conversions' like that. Early versions of C++ would accept them. I think this patch to the source of dcraw_common.cpp should fix it.
https://gist.github.com/conchurnavid/ac19c8e882f1835f0310
There's a duplicate question here. Building FreeImage 3.16.0 for Android

The most usable solution I found to this issue was the following GitHub posting: https://github.com/danoli3/FreeImage. Here some kind soul appears to have successfully built the 3.17.0 library and uploaded it. I've found that works just fine.
Please bear in mind however that it's been built with a hard-coded path of /opt/local/lib - which may be an issue when you come to implementation, since your app will be looking for it there, not bundled with the app. I did find this LiveCode post aided my understanding in that regard a lot.
Hope this helps.

boost object_pool construct method

I'm keen on using boost's object_pool class for memory re-use for a set of video frames.
boost::object_pool< VideoFrame > FramePool;
Now, the VideoFrame class has two constructors. The first version of the constructor takes 4 arguments while the second version takes 6 arguments/parameters.
For every "new" video frame that is allocated, I would like to call the constructor on the object either using the 4 or 6 parameter version. For example:
//VideoFrame *F = new VideoFrame(IdeckLinkOutput, &R, PixelFormat, FrameFlags);
VideoFrame *F = FramePool.construct(IdeckLinkOutput, &R, PixelFormat, FrameFlags);
Building this on MSVS 2005, I receive the error:
error C2660: 'boost::object_pool<T>::construct' : function does not take 4 arguments
According to the documentation on the 'construct' method of object_pool, "ElementType must have a constructor matching ???; the number of parameters given must not exceed what is supported through pool_construct"
I've seen boost's page for the pool_construct, but I'm not too sure the direction I need to take. The build of boost that I have on my machine has both a pool_construct.m4, pool_construct.sh, pool_construct.bat, pool_construct.inc. It's a question of what do I do with these example files within my own project? Would I create my own variation of pool_construct.inc and include that in my own project? How would I add the file?
Any tips/recommendations would be much appreciated. Please note that I have installed gnu's m4.
zerodefect.

If I look at /usr/include/boost/pool/detail/pool_construct.inc on my Debian machine (sorry don't have access to MSVC currently), I see it only supports up to 3 constructor arguments.
Messing with m4 as per the documentation to support more than the supported 3 sounds like a pain compared with simply creating a new constructor which bundles enough of the arguments in a single struct or boost::tuple to bring the total passed down to the number supported.

Resources