Intel Media Controllers - The Specs + Extension List

[Baker]

OpenGL 1.2 is the only thing that can be counted on to be on any Intel Integrated Media graphics controller.

You know, the default low performance 3D "video card" chip Intel has that comes by default on ALL Intel desktops and laptops. They are by far the most commonly used "video card" as they are virtually the default one on a huge % of PCs sold in the last 6-7 years.

[A laptop's video can't be changed. They come with what they come with. They can't "go buy a video card".]

Since these Intel display adapters represent the floor -- the worst OpenGL support available, it can be helpful to know where that floor is.

Unforunately, these things are everywhere and run Direct3D just fine. Eventually Intel will ship OpenGL 2.0 with them (plus or minus some of OpenGL 2.0 if I recall).

But when/if the day that happens comes, that isn't going to retroactively cause the old ones to have updated drivers nor will all the old ones get new drivers.

So if broad compatibility is a goal with OpenGL in the year 2008, here is a dump of the extensions list.

Dell Desktop Circa Late 2002:

Now it says OpenGL 1.3, but I don't think it shipped with that. I think it shipped with 1.2 and I updated it. Upgrading OpenGL drivers is NOT something easy to do like updating DirectX drivers. It is hardware vendor specific, there is no single place to go. In short, OpenGL is not Direct3D/DirectX.

-------------

GL_VENDOR: Intel
GL_RENDERER: Intel Brookdale-G
GL_VERSION: 1.3.0 - Build 4.13.10.3510
GL_EXTENSIONS:

GL_3DFX_texture_compression_FXT1
GL_ARB_multitexture
GL_ARB_texture_border_clamp
GL_ARB_texture_compression
GL_ARB_texture_cube_map
GL_ARB_texture_env_add
GL_ARB_texture_env_combine
GL_ARB_texture_env_crossbar
GL_ARB_texture_env_dot3
GL_ARB_transpose_matrix
GL_EXT_abgr
GL_EXT_bgra
GL_EXT_blend_color
GL_EXT_blend_func_separate
GL_EXT_blend_minmax
GL_EXT_blend_subtract
GL_EXT_clip_volume_hint
GL_EXT_compiled_vertex_array
GL_EXT_cull_vertex
GL_EXT_fog_coord
GL_EXT_packed_pixels
GL_EXT_packed_pixels_12
GL_EXT_rescale_normal
GL_EXT_secondary_color
GL_EXT_separate_specular_color
GL_EXT_stencil_wrap
GL_EXT_texture_compression_s3tc
GL_EXT_texture_env_add
GL_EXT_texture_env_combine
GL_EXT_texture_filter_anisotropic
GL_IBM_texture_mirrored_repeat
GL_NV_texgen_reflection
GL_WIN_swap_hint

And here is the one off my Mac Mini (yes, Intel Media controllers there and even Linux too ...)

Mac Mini (late 2008)


GL_VENDOR: Intel Inc.
GL_RENDERER: Intel GMA 950 OpenGL Engine
GL_VERSION: 1.2 APPLE-1.5.30
GL_EXTENSIONS:

GL_APPLE_aux_depth_stencil
GL_APPLE_client_storage
GL_APPLE_element_array
GL_APPLE_fence
GL_APPLE_flush_buffer_range
GL_APPLE_flush_render
GL_APPLE_object_purgeable
GL_APPLE_packed_pixels
GL_APPLE_pixel_buffer
GL_APPLE_specular_vector
GL_APPLE_texture_range
GL_APPLE_transform_hint
GL_APPLE_vertex_array_object
GL_APPLE_vertex_array_range
GL_APPLE_vertex_program_evaluators
GL_APPLE_ycbcr_422
GL_ARB_depth_texture
GL_ARB_fragment_program
GL_ARB_fragment_program_shadow
GL_ARB_fragment_shader
GL_ARB_multitexture
GL_ARB_pixel_buffer_object
GL_ARB_point_sprite
GL_ARB_shader_objects
GL_ARB_shading_language_100
GL_ARB_shadow
GL_ARB_texture_border_clamp
GL_ARB_texture_compression
GL_ARB_texture_cube_map
GL_ARB_texture_env_add
GL_ARB_texture_env_combine
GL_ARB_texture_env_dot3
GL_ARB_texture_mirrored_repeat
GL_ARB_texture_non_power_of_two
GL_ARB_texture_rectangle
GL_ARB_transpose_matrix
GL_ARB_vertex_blend
GL_ARB_vertex_buffer_object
GL_ARB_vertex_program
GL_ARB_vertex_shader
GL_ARB_window_pos
GL_ATI_texture_env_combine3
GL_EXT_abgr
GL_EXT_bgra
GL_EXT_blend_color
GL_EXT_blend_equation_separate
GL_EXT_blend_func_separate
GL_EXT_blend_minmax
GL_EXT_blend_subtract
GL_EXT_clip_volume_hint
GL_EXT_draw_range_elements
GL_EXT_fog_coord
GL_EXT_framebuffer_object
GL_EXT_geometry_shader4
GL_EXT_gpu_program_parameters
GL_EXT_multi_draw_arrays
GL_EXT_packed_depth_stencil
GL_EXT_rescale_normal
GL_EXT_secondary_color
GL_EXT_separate_specular_color
GL_EXT_shadow_funcs
GL_EXT_stencil_two_side
GL_EXT_stencil_wrap
GL_EXT_texture_compression_dxt1
GL_EXT_texture_compression_s3tc
GL_EXT_texture_env_add
GL_EXT_texture_filter_anisotropic
GL_EXT_texture_lod_bias
GL_EXT_texture_rectangle
GL_EXT_transform_feedback
GL_IBM_rasterpos_clip
GL_NV_blend_square
GL_NV_light_max_exponent
GL_NV_texgen_reflection
GL_SGIS_generate_mipmap
GL_SGIS_texture_edge_clamp
GL_SGIS_texture_lod

Found MacOS X v10.2 or later. Using luminance lightmaps...
Found GL_ARB_multitexture...
(8 texture units)
Found GL_EXT_texture_filter_anisotropic

[Spike]

opengl 1.2 with fragment program extensions???

I admit that some of the features required for 1.4/1.5 are a bit bloated... but hey.
I'll bet those extra bits are emulated.

Tbh, the only way to get companies to support the specs properly is to let the user know exactly what's going on, and make the user click that they want to ignore what the drivers say their card can do (eg: messagebox("your graphics card claims to support extension XYZ but may be buggy, would you like to disable it? saying no will disable feature YZX") ), so they petition their vendors to release non-buggy drivers that can actually do it.

You could just disable anything past gl 1.2 for certain vendors, but then that's a major hinderance when it comes to people enjoying your game/engine.

The main issue with opengl, at least with Intel cards, is that there's no way to detect if something will be emulated or not.

[mh]

You could just try something and see if it works, but that's more a solution for a developer than for an end-user, who often has to contend with the fact that the developer didn't consider them as a potential audience.

Anyway, here's what the ghastly Intel on my laptop gives me:

GL_VENDOR: Intel

GL_RENDERER: Intel 915GM

GL_VERSION: 1.4.0 - Build 7.14.10.4764

GL_EXTENSIONS:
GL_ARB_depth_texture
GL_ARB_fragment_program
GL_ARB_multitexture
GL_ARB_point_parameters
GL_ARB_shadow
GL_ARB_texture_border_clamp
GL_ARB_texture_compression
GL_ARB_texture_cube_map
GL_ARB_texture_env_add
GL_ARB_texture_env_combine
GL_ARB_texture_env_dot3
GL_ARB_texture_env_crossbar
GL_ARB_transpose_matrix
GL_ARB_vertex_buffer_object
GL_ARB_vertex_program
GL_ARB_window_pos
GL_EXT_abgr
GL_EXT_bgra
GL_EXT_blend_color
GL_EXT_blend_func_separate
GL_EXT_blend_minmax
GL_EXT_blend_subtract
GL_EXT_clip_volume_hint
GL_EXT_compiled_vertex_array
GL_EXT_cull_vertex
GL_EXT_draw_range_elements
GL_EXT_fog_coord
GL_EXT_multi_draw_arrays
GL_EXT_packed_pixels
GL_EXT_rescale_normal
GL_EXT_secondary_color
GL_EXT_separate_specular_color
GL_EXT_shadow_funcs
GL_EXT_stencil_two_side
GL_EXT_stencil_wrap
GL_EXT_texture_compression_s3tc
GL_EXT_texture_env_add
GL_EXT_texture_env_combine
GL_EXT_texture_filter_anisotropic
GL_EXT_texture3D
GL_3DFX_texture_compression_FXT1
GL_IBM_texture_mirrored_repeat
GL_NV_blend_square
GL_NV_texgen_reflection
GL_SGIS_generate_mipmap
GL_WIN_swap_hint

[Baker]

Tbh, the only way to get companies to support the specs properly is to let the user know exactly what's going on, and make the user click that they want to ignore what the drivers say their card can do (eg: messagebox("your graphics card claims to support extension XYZ but may be buggy, would you like to disable it? saying no will disable feature YZX") ), so they petition their vendors to release non-buggy drivers that can actually do it.

Yeah. Although with these Intels and their lack of performance, I wonder about this.

My Windows one, which is older, doesn't even support vertical sync.

You could just disable anything past gl 1.2 for certain vendors, but then that's a major hinderance when it comes to people enjoying your game/engine.

And uglier code and a lot of extra time to write/debug stuff.

Like MH said, I guess part of it comes down to defining the audience.

To get a better world, I guess you have to start with the one you have.

My main goal in listing the information is just trying to define where the widespread baseline floor resides. My various GeForce cards are the ones I use the most by far and I know I want to avoid ... at least for now ... writing code that won't work on the other ones.

The main issue with opengl, at least with Intel cards, is that there's no way to detect if something will be emulated or not.

Now Direct3D emulates virtually everything, doesn't it?

[revelator]

ouch

im glad i dont own a laptop

[mh]

Time to dig this one up again.

I've been doing some work with Direct3D HLSL on my 910-equipped laptop, and the end results have been fairly surprising.

Surprise 1 was that Direct3D 9 has software emulation of vertex shaders 3.0 (I guess that 10 would have 4.0 in software) and if anything it's actually faster than fixed func. I guess that MS have some pretty good optimisations in there, but overall software vertex shaders doesn't seem like a particularly difficult thing to do (you can do it in your app without ever having to touch a shader).

Big surprise 2 is the fragment/pixel shaders. These are a full-blown hardware implementation, and they are fast. Like I mean really really fast, faster than some GeForce 5 series cards I could mention. Basic RenderMonkey samples easily top 250 FPS, with even the heaviest sample (9 passes - ouch!) managing 10.

Here's the HLSL I've written for Quake's water warp (combining water alpha):

Code: Select all

sampler2D baseMap;
float warptime;
float Alpha;

struct PS_INPUT
{
   float2 Texcoord : TEXCOORD0;
};

float4 main (PS_INPUT Input) : COLOR0
{
   float2 stwarp;
   float4 color;
   
   stwarp.x = Input.Texcoord.x + sin ((Input.Texcoord.y + warptime) / 4);
   stwarp.y = Input.Texcoord.y + sin ((Input.Texcoord.x + warptime) / 4);
   
   stwarp.xy = mul (stwarp.xy, 0.0625);
   color.rgb = tex2D (baseMap, stwarp);
   color.a = Alpha;
   
   return color;
}

Two sin functions per fragment used in a way that can't be pre-optimised, bearing in mind that this was the "hello world" of HLSL for me, and the card doesn't even break a sweat. Same speed as just rendering the textures without any shader. I can fill a 1280x768 screen with nothing but water rendered by this shader and still get playable framerates (over 40).

Conclusion? If anything, these cards are more constrained by bandwidth and command-buffer size than anything else. Lots of state changes or lots of data going down the pipe will choke them, but keep it in manageable chunks and use shaders to help reduce state changes and they fly.

[mh]

Another Intel update.

I've actually been experimenting some with GL_ARB_vertex_program and GL_ARB_fragment_program on an Intel (a 945 this time). I've done a complete port of everything in GLQuake's renderer to vertex/fragment programs and yes, they work. And they rock - some 20% faster than the fixed pipeline, full precision floating point, solid and stable performance and everything Just Works. Quite surprising as the vertex programs are emulated in software on this part.

Only shame is shader code that looks like this:

Code: Select all

!!ARBvp1.0
TEMP tc0;
DP4 result.position.x, state.matrix.mvp.row[0], vertex.attrib[0];
DP4 result.position.y, state.matrix.mvp.row[1], vertex.attrib[0];
DP4 result.position.z, state.matrix.mvp.row[2], vertex.attrib[0];
DP4 result.position.w, state.matrix.mvp.row[3], vertex.attrib[0];
SUB tc0, vertex.attrib[0], program.local[0];
MUL tc0.z, tc0.z, 3.0;
MOV result.texcoord[0], tc0;
END

!!ARBfp1.0
TEMP tc0, tc1, col1, col2;
DP3 tc0, fragment.texcoord[0], fragment.texcoord[0];
RSQ tc1.x, tc0.x;
MUL tc1.x, 378.0, tc1.x;
MUL tc0, fragment.texcoord[0], tc1.x;
ADD tc1, tc0, program.local[0].x;
MUL tc1, tc1, 0.0078125;
TEX col1, tc1, texture[0], 2D;
ADD tc1, tc0, program.local[0].y;
MUL tc1, tc1, 0.0078125;
TEX col2, tc1, texture[1], 2D;
LRP result.color, col2.w, col2, col1;
END;