What's the current status of OpenGL 3.o drivers and how users accepting it in terms of performance and an alternative to D3D 10 - 11?
When is OpenGL 3.1 spec expected?
Any promising future?
What's the current status of OpenGL 3.o drivers and how users accepting it in terms of performance and an alternative to D3D 10 - 11?
When is OpenGL 3.1 spec expected?
Any promising future?
To my knowledge GL 3.0 drivers are available from both NVidia and ATI. I haven't used/tested the ATI drivers yet, but it seems as if they have support for PC/Mac/Linux.
Who knows when Intel will be on board?
Timothy Farrar :: http://farrarfocus.blogspot.com
lol
Intel doesn't even support vertex shader ... They reach GLSL fragment shader few months ago.
Intel? I sooooooo don't care!!!
Intel on OpenGL 3.0
- Intel is excited about OpenGL 3.0
- We look forward to a strong OpenGL future
- Look for Intel support of OpenGL 3.0 on future platforms
This according to the vendor announcements at the Siggraph BOF.
Yes existed ... well nothing is existing when I'm thinking of Intel graphics chips.
Until you find yourself stuck with supporting an OpenGL app on intel hardware. You can imagine how fun that is not.
And the sad thing is that intel has about 1/3rd of the GPU market.
I'm tired of people spreading misinformation about Intel's graphics chips. They may not be the fastest, but that's no reason to claim they don't support features, which they clearly support. However it seems to me that the hardware could support even more than what's exposend in the drivers (geometry shaders, RGBA16 buffer objects, etc).
Here's part of the glxinfo output on the system on which I'm writing this. As you can see, GL_ARB_vertex_shader is in the extension list even though I have an old Intel 965 graphics chip.
OpenGL vendor string: Tungsten Graphics, Inc
OpenGL renderer string: Mesa DRI Intel(R) 965GM GEM 20090114
OpenGL version string: 2.1 Mesa 7.3
OpenGL shading language version string: 1.10
OpenGL extensions:
GL_ARB_depth_texture, GL_ARB_draw_buffers, GL_ARB_fragment_program,
GL_ARB_fragment_program_shadow, GL_ARB_fragment_shader,
GL_ARB_multisample, GL_ARB_multitexture, GL_ARB_occlusion_query,
GL_ARB_pixel_buffer_object, GL_ARB_point_parameters, 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_crossbar,
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_buffer_object,
GL_ARB_vertex_program, GL_ARB_vertex_shader, GL_ARB_window_pos,
This is direct information from Keith Packard at Fosdem 2009 conference, 1 week ago.
+
The extension string of GL_ARB_vertex_buffer_object is present since years ago but last time I tried to use it (1 year and half) I had a null pointer for glGenBuffer ...
I unfortunalty had to support this chip for the project I was working on at the time, after a lot of issue I choose to use an OpenGL 1.1 code pass for any Intel chips.
So yes I claim it: They are close to stone edge in term of drivers. The hardware is fine (expect some terrible design issues (have a look on Fosdem X.org presentations for more information)) and yes is support even Geometry Shader with Direct3D. It's a Direct3D 10 chip!
The issue is the software! Keith Packard have a really good understanding of this issue but at Intel, it seams that a policy is "if we could do it in software, it's not a big deal". Other graphics chip companies choose to do it in hardware.
I more or less trust ATI with their OpenGL drivers. They might be slow to implement feature but it's going to happen. With Intel ... well, it's so not going to happen and to conference I had was such a demonstration.
By the way, they just complete there support of Framebuffer object!
...................................
Intel => I don't care! => OpenGL 1.1
The best way to support Intel is through D3D. Personally, I beleive that you should use the tool that works best.
As for Pkk post, on Linux things are different. The Intel drivers are corrected and updated by the open source community... in other words, things get done.
------------------------------
Sig: http://glhlib.sourceforge.net
an open source GLU replacement library. Much more modern than GLU.
float matrix[16], inverse_matrix[16];
glhLoadIdentityf2(matrix);
glhTranslatef2(matrix, 0.0, 0.0, 5.0);
glhRotateAboutXf2(matrix, angleInRadians);
glhScalef2(matrix, 1.0, 1.0, -1.0);
glhQuickInvertMatrixf2(matrix, inverse_matrix);
glUniformMatrix4fv(uniformLocation1, 1, FALSE, matrix);
glUniformMatrix4fv(uniformLocation2, 1, FALSE, inverse_matrix);
My experience has been that intel drivers fail to compile bog-standard GLSL programs (typical vertex shader & per pixel lighting) that run perfectly fine on 7 year old Ati and Nvidia hardware. GL2.1 support - yeah right.
Then you have artifacts when using 8bit alpha textures on their lovely 865 and 915 IGPs (workaround: use a RGBA texture or use another card.)
Intel's D3D drivers is passable. Their OpenGL support is atrocious. Just take a look at the workaround list in Google Earth, it's quite enlightening!
Groovounet's got this just about right: Intel => GL1.1 codepath => pray it works.
@VMan: sometimes you have to support an existing or a cross-platform codebase, where writing a D3D renderer is not an option...
Posting Permissions
