Can anybody point me in a direction to a great tutorial or how-to for using OpenGL Extensions using OS X. I'm learning OpenGL and somewhat of a newbie. I'm using a textbook to learn graphics but it doesn't give platform specific instructions on how to get the code to work.
I'm running OS X(10.6.7) on a MacBookPro with a NVidia GeForce 9400M. I have XCode installed, so I have the necessary headers and libraries to compile and run graphics code. I'm attempting to use the OpenGL extensions and now I'm stuck. Here's my problem:
An example in my textbook utilizes a function called glGenVertexArrays. I see in glext.h that there is a function called glGenVertexArrays, a APIENTRYP next to it, and a typedef slightly below it:
wdyn-n233-240-235:GL marklagatuz$ cat glext.h | grep glGenVertexArrays
GLAPI void APIENTRY glGenVertexArrays (GLsizei, GLuint *);
GLAPI void APIENTRY glGenVertexArraysAPPLE (GLsizei, GLuint *);
typedef void (APIENTRYP PFNGLGENVERTEXARRAYSPROC) (GLsizei n, GLuint *arrays);
My question is how to utilize this function in my .cpp source code? I've perused the net, and haven't found great documentation. Maybe cause I'm new to this. Could somebody point me into some great help and tutorials?
If you want to make your life simple, don't bother with glext.h but use a extension wrapper instead. I recommend GLEW, http://glew.sourceforge.net
Related
I found that _mm256_log_ps can't be used with GCC7. Most common suggestions on stackoverflow is to use ICC or leveraging OpenCL SDK.
After downloading SDK and extracting RPM file, there are three .so files: __ocl_svml_l9.so, __ocl_svml_e9.so, __ocl_svml_h8.so
Can someone teach me how to call _mm256_log_ps with these .so files?
Thank you.
You can use the log function from the Eigen library:
#include <Eigen/Core>
void foo(float* data, int size)
{
Eigen::Map<Eigen::ArrayXf> arr(data, size);
arr = arr.log();
}
Depending on the compile flags this generates optimized SSE or AVX code (as well as SIMD for other architectures). The implementation is based on http://gruntthepeon.free.fr/ssemath/ which is based on cephes.
I am writing a class that inherits from std::vector (*) and I want to be able to construct it in all the ways that are available for its base, so I use
#include <vector>
struct B : public std::vector<double>
{
using std::vector<double>::vector;
};
This compiles fine with the g++ and clang, but the Intel compiler gives me (with flag -std=c++11)
error: function template "B::B(_ForwardIterator, _ForwardIterator, const std::__1::allocator<double> &)" already inherited from "std::__1::vector<double, std::__1::allocator<double>>"
at the using directive.
Any ideas why this is happening and/or how to solve it?
Update: it would seem this is OS dependent, works fine on Linux and Windows platforms but fails on OS X. A discussion is ongoing on the Intel forums.
(*) I don't want to use polymorphism, please avoid "this is bad practice" answers if not directly relevant - there are in fact numerous posts that agree this is acceptable.
Is there any way to tell within the source code for a shader that the shader is being compiled for OpenGL ES? I want to be able to define the version using the #version preprocessor directive to be 100 for OpenGL ES (so that the shader compiles for OpenGL ES 2.0), but is version 110 for OpenGL 2.1).
Is the best way to do this to place the #version as a separate string which is fed in at the application level, or is there a way to to do this within the shader?
Another useful, related thing to be able to do would be to say something like
#if version == 100 compile this code, else compile this code. Is this possible within GLSL?
Thanks.
Prepending #version from the main program as PeterT suggested in the above comment is the only way that will work. Being able to do this (and being able to define constants without having something like a -D compiler switch available) is the main intent behind glShaderSource taking an array of pointers rather than a simple char*.
The GLSL specification (chapter 3.3) requires that #version be the first thing in a shader source, except for whitespace and comments.
Thus, no such thing as
#ifdef foo
#version 123
#endif
is valid, and no such thing will compile (unless the shader compiler is overly permissive, i.e. broken).
About your second question, conditional compilation certainly works and using it in the way you intend to do is a good thing.
This is also related information:
http://blog.beuc.net/posts/OpenGL_ES_2.0_using_Android_NDK/
You can, for example:
#ifdef GL_ES
precision mediump float;
#endif
OpenGL ES 2.0 implementations are required to have a GL_ES macro predefined in the shaders.
Hey guys,
This could be a noob question, but I really can't find any useful solution through Google.
I'm testing a hello world with boost.asio, the program is quite simple:
#include <iostream>
#include <boost/asio.hpp>
#include <boost/date_time/posix_time/posix_time.hpp>
int main()
{
boost::asio::io_service io;
boost::asio::deadline_timer t(io, boost::posix_time::seconds(5));
t.wait();
std::cout << "Hello, world!\n";
return 0;
}
I passed the compilation and run well on my Intel Pentium PC (Ubuntu 10.10, gcc 4.4.5, Boost 1.46.0). The command line I used was
g++ -o a a.cpp -I /Boost-Include-Path/ -L /Boost-lib-Path/ -lboost_system
But when I compile the same code on another machine(which is a big one, I'll explain it later), it can't pass the compilation and gives such errors:
/tmp/ccOZxZBX.o: In function boost::asio::detail::gcc_sync_fenced_block::gcc_sync_fenced_block()': a.cpp:(.text._ZN5boost4asio6detail21gcc_sync_fenced_blockC1Ev[boost::asio::detail::gcc_sync_fenced_block::gcc_sync_fenced_block()]+0x4c): undefined reference to__sync_lock_test_and_set_4' /tmp/ccOZxZBX.o: In function boost::detail::atomic_count::operator++()': a.cpp:(.text._ZN5boost6detail12atomic_countppEv[boost::detail::atomic_count::operator++()]+0x30): undefined reference to__sync_add_and_fetch_8' /tmp/ccOZxZBX.o: In function boost::detail::atomic_count::operator--()': a.cpp:(.text._ZN5boost6detail12atomic_countmmEv[boost::detail::atomic_count::operator--()]+0x30): undefined reference to__sync_add_and_fetch_8' /tmp/ccOZxZBX.o: In function boost::detail::atomic_count::operator long() const': a.cpp:(.text._ZNK5boost6detail12atomic_countcvlEv[boost::detail::atomic_count::operator long() const]+0x30): undefined reference to__sync_fetch_and_add_8'
The machine I used was a SiCortex SC5832,which use MIPS64 instruction set processors, OS is changed CentoOS. Gcc 4.2.3, Boost1.46.0. Is it possible that there are problems about the compatibility of the MIPS? I added -mips64 option, but it still give the same errors.
I know this environment could not be very usual, but I think some people who are using similar big machines may face the same problem.
Any help would be appreciated. By the way, I don't have sudo permission.
Thanks,
Tony
This function is a GCC built-in function, and it was introduced around GCC 4.2 (iirc) see documentation.
According to the documentation it's not available on all target processors.
If you look at boost/smart_ptr/detail/atomic_count.hpp it looks like it would fall into the #elif defined(BOOST_SP_HAS_SYNC) block. i.e. boost/smart_ptr/detail/atomic_count_sync.hpp.
Support for this is determined in boost/smart_ptr/detail/sp_has_sync.hpp. This header essentially assumes that GCC supports this on all platforms except for a few exceptions. You might want to insert MIPS as another exception here and submit a patch to boost.
You'll also see that one workaround is to define BOOST_AC_USE_PTHREADS. This will use a mutex around the atomic count, which probably is significantly less efficient, but at least it will work until you can figure out what atomic operations are supported on MIPS64.
What's the instruction to cause a hard-break in Xcode? For example under Visual Studio I could do '_asm int 3' or 'DebugBreak()'. Under some GCC implementations it's asm("break 0") or asm("trap").
I've tried various combos under Xcode without any luck. (inline assembler works fine so it's not a syntax issue).
For reference this is for an assert macro. I don't want to use the definitions in assert.h both for portability, and because they appear to do an abort() in the version XCode provides.
John - Super, cheers. For reference the int 3 syntax is the one required for Intel Macs and iPhone.
Chris - Thanks for your comment but there are many reasons to avoid the standard assert() function for codebases ported to different platforms. If you've gone to the trouble of rolling your own assert it's usually because you have additional functionality (logging, stack unwinding, user-interaction) that you wish to retain.
Your suggestion of attempting to replace the hander via an implementation of '__assert" or similar is not going to be portable. The standard 'assert' is usually a macro and while it may map to __assert on the Mac it doesn't on other platforms.
http://developer.apple.com/documentation/DeveloperTools/Conceptual/XcodeProjectManagement/090_Running_Programs/chapter_11_section_3.html
asm {trap} ; Halts a program running on PPC32 or PPC64.
__asm {int 3} ; Halts a program running on IA-32.
You can just insert a call to Debugger() — that will stop your app in the debugger (if it's being run under the debugger), or halt it with an exception if it's not.
Also, do not avoid assert() for "portability reasons" — portability is why it exists! It's part of Standard C, and you'll find it wherever you find a C compiler. What you really want to do is define a new assertion handler that does a debugger break instead of calling abort(); virtually all C compilers offer a mechanism by which you can do this.
Typically this is done by simply implementing a function or macro that follows this prototype:
void __assert(const char *expression, const char *file, int line);
It's called when an assertion expression fails. Usually it, not assert() itself, is what performs "the printf() followed by abort()" that is the default documented behavior. By customizing this function or macro, you can change its behavior.
__builtin_trap();
Since Debugger() is depreciated now this should work instead.
https://developer.apple.com/library/mac/technotes/tn2124/_index.html#//apple_ref/doc/uid/DTS10003391-CH1-SECCONTROLLEDCRASH
For posterity: I have some code for generating halts at the correct stack frame in the debugger and (optionally) pausing the app so you can attach the debugger just-in-time. Works for simulator and device (and possibly desktop, if you should ever need it). Exhaustively detailed post at http://iphone.m20.nl/wp/2010/10/xcode-iphone-debugger-halt-assertions/
I found the following in an Apple Forum:
Xcode doesn't come with any symbolic breaks built in - but they're
quick to add. Go to the breakpoints window and add:
-[NSException raise]
kill(getpid(), SIGINT);
Works in the simulator and the device.
There is also the following function that is available as cross platform straight Halt() alternative:
#include <stdlib.h>
void abort(void);
We use it in our cross platform engine for the iPhone implementation in case of fatal asserts. Cross platform across Nintendo DS/Wii/XBOX 360/iOS etc...