Do GLSL geometry shaders work on the GMA X3100 under OSX - macos

I am trying to use a trivial geometry shader but when run in Shader Builder on a laptop with a GMA X3100 it falls back and uses the software render. According this document the GMA X3100 does support EXT_geometry_shader4.
The input is POINTS and the output is LINE_STRIP.
What would be required to get it to run on the GPU (if possible)
uniform vec2 offset;
void main()
{
gl_Position = gl_PositionIn[0];
EmitVertex();
gl_Position = gl_PositionIn[0] + vec4(offset.x,offset.y,0,0);
EmitVertex();
EndPrimitive();
}

From the docs you link to it certainly appears it should be supported.
You could try
int hasGEOM = isExtensionSupported("EXT_geometry_shader4");
If it returns in the affirmative you may have another problem stopping it from working.
Also according to the GLSL Spec (1.20.8) "Any extended behavior must first be enabled.
Directives to control the behavior of the compiler with respect to extensions are declared with the #extension directive"
I didn't see you use this directive in your code so I can suggest
#extension GL_EXT_geometry_shader4 : enable
At the top of your shader code block.

I've found this OpenGL Extensions Viewer tool really helpful in tracking down these sorts of issues. It will certainly allow you to confirm Apple's claims. That said, wikipedia states that official GLSL support for geometry shaders is technically an OpenGL 3.2 feature.
Does anyone know if the EXT_geometry_shader4 implementation supports the GLSL syntax, or does it require some hardware or driver specific format?

Interestingly enough, I've heard that the compatibility claims of Intel regarding these integrated GPUs are sometimes overstated or just false. Apparently the X3100 only supports OpenGL 1.4 and below (or so I've heard, take this with a grain of salt, as I can't confirm this).

On my HP Laptop, with an Intel x3100 using Windows 7 x64 drivers (v8.15.10.1930 (9-23-2009)) directly from Intel's website, the extension "EXT_geometry_shader4" (or any variation of it) is NOT supported. I've confirmed this programmatically and using the tool "GPU Caps Viewer" (which lists detected supported extensions, amongst other useful things). Since Windows tends to be the primary subject of driver development from any vendor, it's unlikely the OSX driver is any better, and may in fact have even less supported extensions.

Related

How to use OpenGL ES with GLFW on windows?

Since NVIDIA DRIVE product supports the OpenGL ES 2 and 3 specifications, I want to run OpenGL ES code on Windows 10 with GTX 2070, which will elimated a
Also, GLFW support configuration like glfwWindowHint(GLFW_CLIENT_API, GLFW_OPENGL_ES_API). Is it possible to use GLFW to run OpenGL ES code on Windows 10?
First of all, make sure you have downloaded glad with GL ES.
https://glad.dav1d.de/
For the glfw part, you need to set the GLFW_CLIENT_API window hints.
glfwWindowHint(GLFW_CLIENT_API, GLFW_OPENGL_ES_API);
And also choose wich version you want, for example:
glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 3);
glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 2);
Then specify the kind of context. In the case of OpenGL ES, according to the documentation, it must be GLFW_OPENGL_ANY_PROFILE.
glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_ANY_PROFILE);
GLFW_OPENGL_PROFILE indicates the OpenGL profile used by the context.
This is GLFW_OPENGL_CORE_PROFILE or GLFW_OPENGL_COMPAT_PROFILE if the
context uses a known profile, or GLFW_OPENGL_ANY_PROFILE if the OpenGL
profile is unknown or the context is an OpenGL ES context. Note that
the returned profile may not match the profile bits of the context
flags, as GLFW will try other means of detecting the profile when no
bits are set.
However, GLFW_OPENGL_ANY_PROFILE is already the default value, so you don't really need to set it.

How to request use of integrated GPU when using Metal API?

According to Apple documentation, when adding the value "YES" (or true) for key "NSSupportsAutomaticGraphicsSwitching" to the Info.plist file for an OSX app, the integrated GPU will be invoked on dual-GPU systems (as opposed to the discrete GPU). This is useful as the integrated GPU -- while less performant -- is adequate for my app's needs and consumes less energy.
Unfortunately, building as per above and subsequently inspecting the Activity Monitor (Energy tab: "Requires High Perf GPU" column) reveals that my Metal API-enabled app still uses the discrete GPU, despite requesting the integrated GPU.
Is there any way I can give a hint to the Metal system itself to use the integrated GPU?
The problem was that Metal API defaults to using the discrete GPU. Using the following code, along with the correct Info.plist configuration detailed above, results in the integrated GPU being used:
NSArray<id<MTLDevice>> *devices = MTLCopyAllDevices();
gpu_ = nil;
// Low power device is sufficient - try to use it!
for (id<MTLDevice> device in devices) {
if (device.isLowPower) {
gpu_ = device;
break;
}
}
// below: probably not necessary since there is always
// integrated GPU, but doesn't hurt.
if (gpu_ == nil)
gpu_ = MTLCreateSystemDefaultDevice();
If you're using an MTKView remember to pass gpu_ to the its initWithFrame:device: method.

OpenCL half precision extension support on Apple OS X

Does anybody know the state of half precision floating point support in OpenCL as implemented by Apple.
According to OpenCL 1.1 spec The following statement should enable half2:
#pragma OPENCL EXTENSION cl_khr_fp16 : enable
but when I come to build the kernel the compiler throws a message such as
error: variable has incomplete type 'half4' (aka 'struct __Reserved_Name__Do_
The following thread ask a similar question : OpenCL half4 type Apple OS X
But this thread is old. Can anyone please tell me if the half precision is supported by apple recently?
When you want to know if a extension is supported by a specific implementation (regardless if it's Apple's or another), just use the function
cl_int clGetPlatformInfo(cl_platform_id platform,
cl_platform_info param_name,
size_t param_value_size,
void *param_value,
size_t *param_value_size_ret)
passing the value CL_PLATFORM_EXTENSIONS for the param_name argument. it'll return a space-separated list of extension names.
Note that this list must returns the extensions "supported by all devices associated with this platform".
So it means that even if the platform supports the cl_khr_fp16 extension but not your device, it won't appear in the list.
To know the extension available on your device use
clGetDeviceInfo(...)
with the value CL_DEVICE_EXTENSIONS for the param_name argument.
For a generic answer to OpenCL extension querying see CaptainObvious' answer above (https://stackoverflow.com/a/17425167/5394228).
I asked Apple Developer Support about this and they say that half support is available in Metal and there are no plans to add new functionality to OpenCL now. (they answered Nov 2017)

OpenCL half4 type Apple OS X

Does anybody know the state of half precision floating point support in OpenCL as implemented by Apple.
According to http://www.khronos.org/registry/cl/sdk/1.2/docs/man/xhtml/cl_khr_fp16.html
#pragma OPENCL EXTENSION cl_khr_fp16 : enable
should enable support for types such as half4 but when I come to build the kernel the compiler throws a message such as
error: variable has incomplete type 'half4' (aka 'struct __Reserved_Name__Do_not_use_half4')
is there anyway I can have half4 support in Apple's OpenCL?
Thanks.
The latest shipping Apple implementation is on Lion, and it supports OpenCL 1.1. You are looking at the recently released OpenCL 1.2 specification. That simply documents what will be in a given 1.2 implementation of OpenCL, whoever the vendor might be.
The cl_khr_fp16 extension (floating point operations on the 16bit scalar type (half) and vectors of half (half2,half3,half4,half8,half16) is an optional extension to OpenCL 1.0, 1.1 and 1.2.
An OpenCL extension defines a macro of the same name as the extension if it is supported in the OpenCL implementation.
e.g.
#ifdef cl_khr_fp16
#pragma OPENCL EXTENSION cl_khr_fp16 : enable
... // Code using half
#else
#error No FP16 support
#endif
I do not believe Apple are shipping an OpenCL with half support.

Is there a Snow Leopard compatible "sudden motion sensor" API available?

I have been using Unimotion in my application to read motion sensor values for Apple laptops, but have been unable to port the code to 10.6 64-bit. (I have also tried SMSLib and had the no luck either.)
Is there any simple 10.6 compatible
SMS API?
If there is no alternative, I am also considering patching one of the libraries. Both Unimotion and SMSLib use the following call, which has been deprecated in 10.5 and removed from 10.6 64-bit:
result = IOConnectMethodStructureIStructureO(
dataPort, kernFunc, structureInputSize,
&structureOutputSize, &inputStructure,
outputStructure);
Is there any simple way to replace
this with new IOKit calls?
(This post did not really get me much further)
If there is no alternative, I am also considering patching one of the libraries. Both Unimotion and SMSLib use the following call, which has been deprecated in 10.5 and removed from 10.6 64-bit:
result = IOConnectMethodStructureIStructureO(
dataPort, kernFunc, structureInputSize,
&structureOutputSize, &inputStructure,
outputStructure);
Is there any simple way to replace this with new IOKit calls?
That very document suggests replacements. What about this one?
kern_return_t
IOConnectCallStructMethod(
mach_port_t connection, // In
uint32_t selector, // In
const void *inputStruct, // In
size_t inputStructCnt, // In
void *outputStruct, // Out
size_t *outputStructCnt) // In/Out
As far as I can tell, there should be no difference except for the order of the arguments. That said, I've never used I/O Kit, so I could be missing some critical conceptual difference that will make this call not work as the old one did.
I haven't used this in 10.6, but does this work?
http://code.google.com/p/google-mac-qtz-patches/

Resources