What to Recommend for Intel Graphics???

[Janika]

Let me give an example I experienced on some hardware. Running a standard code that uses a very basic functionality to render textured quads, resulted in wrong colors and shades, even textures were not showing. Sometimes black screen background, when cube mapping is used. Then how would a conformance test be able to detect such bugs? What you saying is a conformance test that checks the interface, not the implementation details that can be as low as setting or feeding the wrong values to hardware registers, which is not detectable by just being compliance with the specification.
Maybe two-stage test will do it, where the first is the conformance or API verification. The second stage is to check the result of a test-case program with a pre-rendered image. This is not a per-fragment check. With approximation algorithms a good test package can verify that both images are close so that the driver is not producing weird colors from Mars

[thokra]

on some hardware

In what year and on which GPU did you test this?

[..]very basic functionality to render textured quads, resulted in wrong colors and shades, even textures were not showing.

Depending on your answer to the above I think I'm gonna have a hard time believing that this wasn't your fault. No but seriously, per vertex colors and interpolation wasn't working? I believe that's very unlikely even with Intel hardware.

What you saying is a conformance test that checks the interface, not the implementation details that can be as low as setting or feeding the wrong values to hardware registers, which is not detectable by just being compliance with the specification.

You don't need to check the internals of functions. White-box tests are usually done by people who develop functions and know the internals of functions, i.e. GL implementors. Like Alfonse already established a conformance test suite needs to,

At the very least, (test) each function command [..] to see if it produces errors when it should.

This is classic black-box testing. Put something in and check the output, in this no errors or errors which are either correct or false according to the spec. Alfonse goes on to state that

Shader functions should be tested to show if they produce appropriate values[..]

Also black-box testing. A texture lookup falls right into this category. You look up some value in a texture who's value you know exactly and see if the texture look-up produces the correct result.

Of course, you can't check GPU registers, but ultimately what we as developers care about is correct output values when correct input values are supplied. Regarding correctness, to us it doesn't matter how the implementation handles stuff internally. Performance is written on another sheet but here we as powerless as with API conformance.

[Alfonse Reinheart]

Running a standard code that uses a very basic functionality to render textured quads, resulted in wrong colors and shades, even textures were not showing. Sometimes black screen background, when cube mapping is used. Then how would a conformance test be able to detect such bugs?

It would depend on what the bug was that caused the "black screen background".

A conformance test cannot be absolutely comprehensive. But it would certainly be better than what we have now (ie: nothing).

[Janika]

Depending on your answer to the above I think I'm gonna have a hard time believing that this wasn't your fault. No but seriously, per vertex colors and interpolation wasn't working? I believe that's very unlikely even with Intel hardware.

It happened with some Intel ancient laptop which claims supporting version GL 2.0. the problem was with using cube maps, the textures turn into black color. Another bug when the hardware somehow decides to modulate a texture with pink color However same code worked fine with NVIDIA and ATI that supported GL 2.1. This is why I'm not sure if I was doing something wrong, which is possible. But then how come it worked with other hardware?

Another problem with performance. For instance on ATI Radeon x1600 with OpenGL 2.0 drivers, I got a significant performance gain when executing the fixed-functionality rendering path, even using glBegin/glEnd. While when using shaders it becomes noticeably slower, and with VBOs, it's almost dead as if it was running in software mode, until I did a tweak suggested on these forums. This suggestion was not mentioned in any reference or the hardware OpenGL optimization tips. It was by experience. I had to use glBufferSubData instead of glMap/unmap buffer.

Unfortunately this hardware is not anymore supported by AMD so I canot verify if the problem would have been resolved with a new driver update.

My conclusion is to use "removed" functionality and fixed pipeline for anything that supports up to 2.1.
But with the new hardware that has GL >= 3.x I expect the 2.1 support is something legacy and undeveloped so I better have to rely on GL > 3.x core. This implies writing two rendering paths for the same application. With good abstraction design the application can check for the highest GL version supported and dynamically link to the appropriate GL engine module.

[thokra]

But with the new hardware that has GL >= 3.x I expect the 2.1 support is something legacy and undeveloped so I better have to rely on GL > 3.x core.

It depends. Both AMD and NVIDIA made a pledge to fully support the compatibility profile. This means that GL2.1- features are supposedly fully supported even with current drivers. You should be able to yank some heavy legacy code even through a Keppler GPU. However, if you can, I guess most people here will suggest you go for GL 3.3 (or GL3.x for that matter).