Intel and multisampling

Quote:

---

GL_ARB_texture_swizzle and GL_ARB_texture_buffer_object are supported in the 8.15.10.2696 drivers, though they aren't listed in the extension string. I became a little suspicious after the latest driver for my AMD FirePro card also didn't list GL_ARB_texture_swizzle but claimed GL4.2 support and properly supported it, so I decided to recheck the HD4000. The shader with samplerBuffer compiled without incident, and the glTexBuffer API entry point was found. Swizzling also works properly ( glTexParameter(GL_TEXTURE_2D, GL_TEXTURE_SWIZZLE_RGBA) ).

---

Don't forget: OpenGL versions are not defined by extensions. It is perfectly legitimate for an implementation to say "3.3" and not support ARB_texture_swizzle or any other 3.3 core extension. It advertises support for 3.3, therefore it supports all of 3.3, and texture swizzling is a part of it.

So I would say that using extensions to somehow "verify" core support for an advertized version is not a reliable mechanism.

Sure, but there's no good reason not to list these core features as extensions, so I'm guessing that their omission is just an oversight. Personally I'd much rather check against GL version X.Y than check for the support of dozens of extensions, but that doesn't mean that one shouldn't be able to.

Quote:

---

that doesn't mean that one shouldn't be able to

---

That doesn't mean one should be able to either. I think Apple has it right here; their 3.2 implementation only exposes extensions that matter. IE: things that aren't already in core.

The point is that you should check the version, and only check the extension if it's below the version where it was incorporated. Otherwise, actually having OpenGL versions is irrelevant; you'd just check for a bunch of extensions you use.

Thank you, randall!!!
9.17.10.2792 drivers can be installed on Win7 and they fully support GL 4.0. Great!

Quote:

---

Originally Posted by Alfonse

The point is that you should check the version, and only check the extension if it's below the version where it was incorporated. Otherwise, actually having OpenGL versions is irrelevant; you'd just check for a bunch of extensions you use.

---

I strongly disagree. All functionality should be reported through extension strings, and currently it is a default behavior of all drivers on Windows.
Take a look at an Intel's case. Multisampling is a part of GL 1.3 specification, and Intel does not support it even if it advertises GL 2.1. But, there is no trace of GL_ARB_multisample extension string, so it is a regular behavior. Imagine what will happen if Intel would say it supports GL 1.2 only and at the same time there is a full support for the shaders.

Quote:

---

I strongly disagree. All functionality should be reported through extension strings, and currently it is a default behavior of all drivers on Windows. Take a look at an Intel's case. Multisampling is a part of GL 1.3 specification, and Intel does not support it even if it advertises GL 2.1. But, there is no trace of GL_ARB_multisample extension string, so it is a regular behavior. Imagine what will happen if Intel would say it supports GL 1.2 only and at the same time there is a full support for the shaders.

---

Hmm, I'm with Alfonse here since core conforming drivers have to expose what's specified for the particular version they're implementing. If the extension is not reported then Intel is to blame and should fix their driver.

Quote:

---

Take a look at an Intel's case. Multisampling is a part of GL 1.3 specification, and Intel does not support it even if it advertises GL 2.1. But, there is no trace of GL_ARB_multisample extension string, so it is a regular behavior.

---

It's "regular behavior" because it's conformant with 2.1. It supports what the 2.1 core requires: it has the machinery for multisampling. But it doesn't actually provide any multisample pixel formats. You can enable it all you like; but without the multisample pixel formats, that won't actually do anything.

Even ARB_framebuffer_object does not require an implementation to support multisampling; just the machinery for it. It allows GL_MAX_SAMPLES to be 0.

This only becomes a lie in 3.0, where GL_MAX_SAMPLES is required to be at least 4. At which point, if Intel's driver advertises 3.0+ and doesn't provide multisampling behavior, they are lying. Just as ATi was lying in all of their pre-HD graphics cards when they advertised 2.0 and 2.1 when they didn't provide full NPOT support. But rather than forcing the IHVs to actually do what the spec says, people take your advice and work around it by looking at extension lists to figure out what elements of the spec the implementation is blatantly ignoring.

Things like that are probably why we can't get a conformance test for OpenGL. Because it would actually test the specification, and some drivers refuse to actually implement what they say they do.

Lying is only "regular behavior" when you accept it as regular behavior, when you start believing that lies are the truth.

Quote:

---

Imagine what will happen if Intel would say it supports GL 1.2 only and at the same time there is a full support for the shaders.

---

How could there possibly be "full support for the shaders?" ARB_shader_objects is very different from core GL 2.0 shaders. And since it advertises only GL 1.2, you should not expect the GLSL functions to be there. Even if you advertise ARB_shader_objects, there's absolutely no reason to expect `glUseProgram` (for example) to be available; the ARB_shader_objects version is called `glUseProgramObjectARB`.

I don't see how that constitutes "full support" for anything.

Quote:

---

I think Apple has it right here; their 3.2 implementation only exposes extensions that matter. IE: things that aren't already in core.

---

I'm okay with that approach, as well as the 'list them all' approach. But pick one; don't expose some core features in the extension string, and leave others out. That's just plain inconsistent.

GL_ARB_texture_buffer_object as an extension provides more functionality (more formats to be precise) than version of this feature that is mandatory for OpenGL core. This is the reason why some implementations do not expose this extension string.

Ah, I never noticed that before, thanks! The GL spec appendix on Version 3.1 only briefly mentions that TBOs are included.

Makes sense that the old ALPHA, LUMINANCE and LUMINANCE_ALPHA formats mentioned in the extension aren't available for TBOs in core (only R, RG, and RGBA formats are supported).

Quote:

---

Ah, I never noticed that before, thanks! The GL spec appendix on Version 3.1 only briefly mentions that TBOs are included.

---

It's not a core extension (hence the "ARB" slapped onto the end of everything). So it's presence shouldn't mean that the core TBO feature is available. Also, if you want to use those other formats, you can't use `glTexBuffer` with them; you must use `glTexBufferARB`.