As I'm making some minimum system recommendation for a 3D demo, what version of OpenGL should I blindly trust on Intel integrated graphics (within range of 10 years old)? Regardless of the capabilities I will utilize I will have to restrict it to the least version that can run on Intel graphics safely without bugs or weird effects.
Thanks.
In general, you shouldn't blindly trust any GL implementation. If you do so and release software without thorougly testing your renderer you can get into trouble depending on what features you use. Intel has a tradition of not being the pinnacle of GL conformance and reliability, so especially when it comes to Intel you should be suspicious. From what I've seen so far, the Sandy Bridge and probably Ivy Bridge chips seem to handle most of the supported GL subset well enough for basic usage. However, I cannot guarantee anything beyond simple demos.what version of OpenGL should I blindly trust on Intel integrated graphics (within range of 10 years old)?
I was thinking to restrict it to version 1.2 with no shaders. But since high performance is not an issue I could use Mesa3D as an option on Intel's. I think it has some basic acceleration which should be enough.
Sorry. I meant by "blindly trusting" an implementation is its reliability to some degree that matches lets say Direct3D drivers reliability on the same hardware. So I don't expect a 100% bug-free implementation.In general, you shouldn't blindly trust any GL implementation.
And that's why some CAD software requirements exclude Intel explicitly. Should I do the same? The main problem with this if someone has a decent new laptop with integrated Intel graphics, there's a high chance it may work with a minimal GL version...Intel has a tradition of not being the pinnacle of GL conformance and reliability, so especially when it comes to Intel you should be suspicious.
Now if I'm limiting the demo to NVIDIA and ATI only, where can I get a list of each hardware with its last supported GL version?
Thanks.
I think this isn't true for all major companies. With D3D drivers vendors need to pass what Microsoft set as a quality standard if the want WHQL certification. For OpenGL there is no such thing.I meant by "blindly trusting" an implementation is its reliability to some degree that matches lets say Direct3D drivers reliability on the same hardware.
I think you would have to go back beyond a decade to find hardware of the two which doesn't support GL 1.2.Now if I'm limiting the demo to NVIDIA and ATI only, where can I get a list of each hardware with its last supported GL version?
What features do you intend to use?
No eye-candy effects, just basic multi-texturing, and I prefer using shaders for multi-texturing and lighting.What features do you intend to use?
I'm also good without vertex buffer objects.
In that case a GLSl supporting version, i.e. minimally GL 2.0 is advisable. In any case I suggest you try the code on as many platforms as you can get your hands on. You can't trust a program to run fine on NVIDIA, just because it does so on an AMD system.and I prefer using shaders for multi-texturing and lighting.
I would not trust anything but the most basic OpenGL code for GL 2.1 and below. NVIDIA still supports the GeForce 6xxx line (note the number of x's). ATI doesn't support anything before the HD series. So all of ATI's supported hardware is 3.3-capable.Now if I'm limiting the demo to NVIDIA and ATI only, where can I get a list of each hardware with its last supported GL version?
The problem is that ATI left their 2.x hardware in a less-than-good state. While their drivers have become much better of late, their drivers in those days were terrible. And since that hardware isn't being supported anymore, then problems arise when you try to do something with it.
Actually it's more likely to work than the other way around. NVIDIA's drivers are far more permissive than AMD's.You can't trust a program to run fine on NVIDIA, just because it does so on an AMD system.
Yeah, definitely the wrong order.Actually it's more likely to work than the other way around. NVIDIA's drivers are far more permissive than AMD's.However, my point was to emphasize that testing on a single platform is never enough to reach a certain level of quality.
BTW: I wouldn't call it permissive as they somtimes reflect the spec incorrectly. So faulty might be a better term.
For within range of 10 years you're likely talking about OpenGL 1.1 or 1.2 maximum, and with the D3D option not looking much better either. I personally think you're being over-conservative with this, so if you're willing to narrow it to 6 or so years things get a LOT better - by the 9xx series Intel capabilities were actually getting pretty decent and much of them are even exposed via their GL driver.
So, looking at the 9xx series as a baseline, you'll have OpenGL 1.4 plus a bunch of interesting extensions - GL_ARB_vertex_buffer_object (emulated in software on the earlier models), GL_ARB_vertex_program (likewise) and GL_ARB_fragment_program - broadly equivalent to D3D9 with shader model 2 (which also works quite well on them) - but note - we're talking assembly shaders rather than GLSL here. These are all available and will even work well and fast - despite the software emulation on the per-vertex side you should easily hit or exceed 60 fps with Quake or Quake II level graphics.
In other capabilities you'll have 8 texture units, support for up to 1024x1024 texture sizes at a minimum, 128mb of video memory (shared, of course), and full, general multitexture capability. I'm not certain if point sprites are exposed via their GL driver (they are on their D3D driver though).
More recent models are better still, with the ever-present caveat that it's Intel graphics.
So you still have to tread a little carefully with them - a good general rule of thumb is that if functionality isn't exposed in the D3D driver for a given model, then don't even attempt to use it in OpenGL - even if the GL spec says that you should be able to.
Posting Permissions
