Driver Extension or Extinction?

Any one can tell me please why some features in the new GL versions such as Separate Shader Objects that don’t require support by hardware are not made available to updated drivers for older hardware which already supports GL version 2.1?

Some may argue that it still requires specific hardware “features” But if a GL 2.1 capable hardware already supports D3D9 shaders which are separable then I see it as a matter of implementation at the API level. Cannot this be provided as an extension?

Even DSA can be provided as an extension to GL 2.1 drivers.

Is it the problem that they don’t want to support antique hardware, for instance Mobility Radeon X1600?

Any one can tell me please why some features in the new GL versions such as Separate Shader Objects that don’t require support by hardware are not made available to updated drivers for older hardware which already supports GL version 2.1?

They are. The extension is supported where the IHV supports the hardware.

NVIDIA still supports the GeForce 6xxx line and expose this extension to them. The difference is that AMD cut off support for pre-HD-class hardware (ie: GL 2.1 or below), and therefore don’t provide new drivers for them.

Unsupported hardware is unsupported. Even NVIDIA is not going to support the GeForce 6xxx and 7xxx lines forever.

Cannot this be provided as an extension?

It is provided as an extension.

It was a design decision back then with GL 2.0 to have a monolithic shader model.
Bad design decision.

Same as the gl_ModelViewMatrix and other built-in crap.
Bad design decision.

Bad design decision.

I agree. But why are not they replaced by a new cleaner shader API instead of patching existing badly designed path, since it’s already a new version specification…???

Should an extension be forced as a patch solution over cleaning the API in a new specification? Maybe backward compatibility is the reason but is not there compatibility profile solution already in place?

What I see now is OpenGL is not fully being streamlined, it’s actually being bloated with extensions and hack-and-patch solutions to solve bad design decisions.

And… what else is new? Did you honestly expect them to be constantly deprecating and removing functionality with each GL version release? That was just a one-time thing.

But since that one-time thing, it has been changing very rapidly as a “stable” API, which is not good. This indicates bad design decisions that are “corrected” in a bad way (patching).

But since that one-time thing, it has been changing very rapidly as a “stable” API, which is not good.

Considering that the alternatives are “not changing at all” (they tried the “change everything at once”. Twice. It didn’t take), I’ll take slow, measured changes.

Nobody’s claiming that this is the best possible scenario. But it is what it is, and it’s not going to suddenly become something else just because you want it to. If you don’t like it, you can use something else. Otherwise, best learn to live with it and use what you can get.

But it is what it is, and it’s not going to suddenly become something else just because you want it to

So if the people involved in writing the specification are mainly driver implementers, game/graphics programmers, then yeah thumbs up! But bear in mind the API is implemented by different people/IHVs, not the same ones who wrote it (AFAIK), so why should they implement badly-designed-stuff + its patches and fixes? This is no wonder why drivers are not that perfect.

I mean when I design my own API that I will use it withing my team/company then it’s alrite. However when others have to implement it and other will use it then no no no

Actually, people involved in writing the specification and deciding what gets into it are:

1. representants of IHVs (most probably driver developers, architects, etc.)
2. representants of ISVs (most probably their graphics developers)

I don’t think that they don’t care, just changing a standard is not something that easy.

1. representants of IHVs (most probably driver developers, architects, etc.)

So these are people who implement what they specify?

2. representants of ISVs (most probably their graphics developers)

How many and which ISVs?

The CAD developers? Not many, and they don’t seem really care much for the new specifications since they wanted the legacy-stuff be there.

The Gamed Developers! Too many! How many using OpenGL?

Ok what’s wrong with this?

char *shaderString = ...;
GLvoid *shader;
char *result;
glCompileShader(GL_VERTEX_SHADER, shaderString, &shader, &result);
                GL_FRAGMENT_SHADER, 
                GL_GEOMETRY_SHADER, 

glUseShader(GL_VERTEX_SHADER, shader);
            GL_FRAGMENT_SHADER, 
            GL_GEOMETRY_SHADER, 

Get it simple from the beginning.

I don’t understand what the purpose of this conversation is. You’re complaining that the shader creation system for GLSL wasn’t very good.

Guess what? We agree! But unless you have a time machine and are going back to 2003/2004 to knock some sense into the ARB before they accept 3D Labs’s ridiculous compilation model, complaining about it now is useless.

Because we have that API now. Observe:

GLuint program = CreateShaderProgramv(GL_VERTEX_SHADER, 1, &shaderString);

Does it matter that it uses a GLuint rather than a void*? No. Does it matter that you could pass multiple strings? No. Those don’t materially affect the functioning of the concept. One function call, and you get a program.

Does it matter that you have to query for the log? Yes, but that’s actually better, because the log querying is explicitly a copy operation. As opposed to your idea that returns a pointer to internal driver memory which will be deleted at some nebulous time in the future.

There’s no point in complaining about a problem that has been resolved.

The absolute most you can complain about is that the old API is still there. Well boo hoo. If you don’t like it, ignore it. I guarantee that the OpenGL police will not bash in your door and force you to build shader objects and so forth.

This discussion started off as a complaint about ARB_separate_shader_objects not being exported to 2.1 hardware, which was false. It’s available on all hardware still supported by NVIDIA and ATI (Intel just doesn’t care, so nothing you suggest will suddenly start making them care). ATI doesn’t support their 2.1 hardware anymore, so it’s not surprising that it hasn’t filtered back to it. Neither have anything else that came out since ATI dropped support for them.

Since then, it has devolved into complaining about something that was fixed. Or at best, complaining about not removing the old way.

If you want to complain about deficiencies in the OpenGL API, then complain about the ones that haven’t been fixed. And complain about it in the suggestions forum; this forum is for driver issues.

What I proposed is a shader API consisting of only 2 calls, excluding those ones to set uniform and attribute values. Regardless of the function parameter types and whether they are good or bad, the functions themselves are DSA, which is something GL is offering through extensions, and again as a hack.

Yes I posted in the wrong forum.

What I proposed is a shader API consisting of only 2 calls, excluding those ones to set uniform and attribute values.

… And? Considering the lifetime issues inherent in dealing with shader logs, I’d much rather have a couple extra functions to see if the compile completed correctly.

Regardless of the function parameter types and whether they are good or bad, the functions themselves are DSA, which is something GL is offering through extensions, and again as a hack.

The two functions you’ve shown are no more DSA than the currently existing ones. Indeed, the only GLSL shader and program-based functions that aren’t DSA style are the uniform setting functions. glBindAttribLocation, glGetUniformLocation, and every program function that doesn’t set uniform values is already DSA-style.

Oh, and ARB_separate_shader_object introduces DSA versions of the uniform setting functions. Again, a problem that has been resolved.

Your proposed API adds nothing that does not already exist.

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.