PDA

View Full Version : Toward Version 4.3



glfreak
04-23-2012, 01:54 PM
Rewrite the specification so that the extensions that are used to patch deficiencies in the current API become needless. How? Rewrite some parts of the spec. Which parts? The shader API in particular, get rid of the program pipeline hack, and borrow some good ideas from D3D shader attribute and uniform specification...

Thanks ARB.

Alfonse Reinheart
04-23-2012, 02:59 PM
And thank you for trotting out the same tired old ideas that always get trotted out on this forum. Your contribution to the noise in this forum is appreciated.

glfreak
04-23-2012, 03:53 PM
I may be repeating the same ideas...but let me guess something, this forum is for...feature suggestions right? And suggesting something once does not really help much. We need a way to keep the idea active. But it seems that regardless of whatever feature is suggested here, we always get the same noise and panic from someone, negative criticism!

randall
04-24-2012, 02:33 AM
What do you mean by Program Pipeline hack?

glfreak
04-24-2012, 09:00 AM
http://www.opengl.org/registry/specs/ARB/separate_shader_objects.txt

A problem that could have been easily corrected by rewriting a little part of the specification instead.

You see the problem is that extensions are being abused, so they are now for patching a problem with the core specification instead of only adding features. Some add more complexities to the API pipeline instead of enriching it.

randall
04-24-2012, 01:38 PM
Yes, I am perfectly aware of this extension. What do you mean by "rewriting a little part of the specification"? What about backward compatibility? It is not so simple as you may think.

glfreak
04-24-2012, 03:05 PM
What about backward compatibility?

So sacrifice the proper development of OpenGL for the sake of backward compatibility? I thought backward compatibility is already solved by the compatibility profiles?


It is not so simple as you may think.

I don't think it's simple, but it's pretty possible. :)

aqnuep
04-24-2012, 03:08 PM
So sacrifice the proper development of OpenGL for the sake of backward compatibility? I thought backward compatibility is already solved by the compatibility profiles?

No, it's not. What you've suggested would have broken compatibility between OpenGL 4.0 core profile and OpenGL 4.1 core profile which is undesired.


I don't think it's simple, but it's pretty possible. :)

No, at least not how you imagine.

I don't say program pipeline objects are the best invention ever but seriously, what makes you think that they are evil?

glfreak
04-24-2012, 04:01 PM
No, it's not. What you've suggested would have broken compatibility between OpenGL 4.0 core profile and OpenGL 4.1 core profile which is undesired.

How undesired? There may be some optimization/performance benefit and therefore there's a need to keep the option available, but if it's not really the case, then correcting a bad design decision should be more desirable over minor compatibility issues.


I don't say program pipeline objects are the best invention ever but seriously, what makes you think that they are evil?

Evil? Who said that? They are awesome! :D But they are a hack :)

Alfonse Reinheart
04-24-2012, 04:49 PM
And suggesting something once does not really help much.

Suggesting it 30 times is also not going to help. It's negatively helpful because it drowns out other, legitimate suggestions.

Don't you get it? The ARB doesn't listen to anything that happens in this forum. Why? Because of people who constantly suggest the same thing 30 times. Because of people who like to keep their pet ideas "active". This means that the only thing that happens here is people dropping random pie-in-the-sky drivel that has zero chance of ever being implemented.

Continuing to make these unrealistic demands will only make the ARB continue to ignore anything that gets said here.


http://www.opengl.org/registry/specs/ARB/separate_shader_objects.txt

A problem that could have been easily corrected by rewriting a little part of the specification instead.

I have no particular love for the ARB_separate_shader_objects specification. But here's a reality check for you.

ARB_shader_objects, version 1.00 of GLSL, was finalized June 11, 2003. Almost 10 years ago. This is what defined the compilation model that GLSL has.

When did we get ARB_separate_shader_objects? June 9, 2010: almost 7 years to the day that GLSL 1.00 came out.

Do you think the GL community was silent about the compilation model? Do you think that ARB_shader_objects came out and everyone was like, "Hurray, we have to link our vertex and fragment shaders together, thus massively increasing compile times as well as the number of programs we need! Yay!"?

No, the community was against it from day 1. Users were against it from day 1. But ATI had no real power and NVIDIA was to busy trying to shove CG down the ARB's throat, which left 3D Labs to basically get whatever they wanted. It took us SEVEN YEARS to get that undone.

That was 7 years of complaints. Of OpenGL falling by the wayside. Of various other bad things. Etc. It took that long just to get a minimally functional version of what we should have had from the beginning.

Here's another reality check for you:

10 years ago, 3D Labs attempted to get the OpenGL API rewritten, with non-backwards compatible changes. That attempt failed. 5 years ago, NVIDIA and ATI tried to do the same thing. That attempt failed, and it failed at a critical time that OpenGL needed to be succeeding (ie: Windows Vista hurting DX10 adoption).

Now given these facts, do you honestly believe that your personal request is going to make the ARB say, "You know what? We tried to rewrite this API twice and both failed. But that glfreak fellow makes a good point. So let's stop all work on the API to try to make another rewrite." Or will they simply continue ignoring everything that gets posted in this forum?

Your suggestion is not going to be acted upon. Ever. No matter how many threads you make, no matter how many times you suggest it.

OpenGL is what it will always be. It will be a functional but crufty API; the sooner you get over that, the better for everyone.


You see the problem is that extensions are being abused

How are extensions "being abused"? It's a core extension; you support it the way you would any core feature, except that you can also use it on hardware that can't support GL 4.x.

Under what logic is this considered "abuse"?


I thought backward compatibility is already solved by the compatibility profiles?

Um, no. Compatibility profiles are for functionality that was removed from OpenGL. You can't just rip stuff out or replace it with new stuff. The point of backwards compatibility is that people can invest time and effort into code and know that it will work with later GL versions. That they can use new features with their older code. If I want to use shader_image_load_store, I shouldn't have to also upgrade all of my texture creation to use glTexStorage, for example.

Even D3D doesn't haphazardly ransack its API the way you're talking. They only make major API changes at a major version number. And even those are not nearly as radical as they used to be.


if it's not really the case, then correcting a bad design decision should be more desirable over minor compatibility issues.

Minor? You're talking about radically altering the GLSL language. That's not a "minor compatibility issue." That's "my shaders don't work with GL X.Y."

l_belev
04-25-2012, 06:06 PM
It's negatively helpful because it drowns out other, legitimate suggestions.


The ARB doesn't listen to anything that happens in this forum. Why? Because of people who constantly suggest the same thing 30 times.


Continuing to make these unrealistic demands will only make the ARB continue to ignore anything that gets said here.



Your suggestion is not going to be acted upon. Ever. No matter how many threads you make, no matter how many times you suggest it.



OpenGL is what it will always be. It will be a functional but crufty API; the sooner you get over that, the better for everyone.

Why do you keep talking on the behalf of the ARB? Are you their representative or something?
If not, please restrain yourself from pretending you are some OpenGL authority.

It is not you who defines what a "legitimate suggestion" or "unrealistic demand" is.

The OP sees problems (very valid IMO) with the current OpenGL state and does what he can - post suggestions. That's is exactly what this forum is for.
And you? You keep telling people to stop posting suggestions because it is useless as OpenGL will never get improved. I don't know what are you doing but it most certainly is not for the good of OpenGL.

If you say that I am getting personal, check this quote of yours first:


And thank you for trotting out the same tired old ideas that always get trotted out on this forum. Your contribution to the noise in this forum is appreciated.
It is not glfreak but you from where comes most of the noise in this forum.

Alfonse Reinheart
04-25-2012, 06:27 PM
Why do you keep talking on the behalf of the ARB? Are you their representative or something?
If not, please restrain yourself from pretending you are some OpenGL authority.

It is not you who defines what a "legitimate suggestion" or "unrealistic demand" is.

It's unrealistic to ask for something that there is documented evidence that the ARB will not do. If someone tries to do something twice and fails twice, it's obvious that they're not going to do it.

And no, it is not me who decides what is legitimate or not. But look around: do you see any members of the ARB posting here? Commenting on suggestions? Interacting with this community in any way? Look over the history of this part of the forum. The ARB used to talk. We used to discuss suggestions.

That doesn't happen anymore.

Maybe it's because so many of the suggestions made are so unrealistic that they're not worth discussing.

And maybe it's not. But of the last 25 threads on this forum, I was only able to find 5 that I believe the ARB would even consider implementing. Most of them are things like this: obvious personal wishlist and trash.


The OP sees problems (very valid IMO) with the current OpenGL state and does what he can - post suggestions. That's is exactly what this forum is for.

But he's already done' that. And the ARB has already attempted what he has suggested and rejected it. Twice.

What good is it to constantly spam the forum with the same suggestions over and over again, when the ARB has already said about as well as it can be said that it's not happening?


And you? You keep telling people to stop posting suggestions because it is useless as OpenGL will never get improved.

No, I tell people to stop posting suggestions that will not be implemented. What expectation is it that anything he has suggested would even be considered, given that the ARB tried twice and failed twice?

What I want is for people to stop asking for what they want. I want people to ask for something that the ARB would actually do. To stop thinking about what they would do if they were the ARB and start thinking about what the actual ARB would reasonably debate and consider.

I want people to filter their own ideas first before presenting them for public consumption. Is that so much to ask?

For example, we would all like to have a programmable blend stage. But that's not going to happen, not with current hardware. Asking for what is not going to happen serves no purpose.

If glfreak truly wants to improve OpenGL, then he will limit suggestions to things which the ARB hasn't clearly decided not to do. Simply saying "rip out half of separate_shader_objects and rewrite the GLSL interface to be more like D3D" is simply not going to happen.

If glfreak believes that the only way to fix the problems of OpenGL is by rewriting parts of it, then OpenGL will never be fixed for him. The sooner he accepts that, the better for everyone.

aqnuep
04-25-2012, 09:10 PM
While I agree that sometimes Alfonse is a bit negative, he is right here.
Suggestions like "remove Opengl32.dll" or "rewrite <insert random feature here> in the spec even if it breaks backward compatibility between two versions of the core profile" are useless. There is definitely a need for reorganizing the spec document to better reflect modern OpenGL, but that does not necessarily mean a rewrite and especially not something that redefines the behavior of certain features, it should be rather a refactoring, i.e. language rewrite that doesn't change behavior.
My personal opinion is that OpenGL requires the following (in priority/chronological order):

All new OpenGL software should use core profile only
Legacy OpenGL software should (even if slowly) move to use core profile only
Trully remove deprecated features once the critical mass of core-only software has been reached
Do another deprecation phase (things like mutable textures, standalone uniforms and by-mistake left-overs of the previous deprecation phase like texture environment LOD bias should go away)

Foobarbazqux
04-25-2012, 09:47 PM
For example, we would all like to have a programmable blend stage. But that's not going to happen, not with current hardware. Asking for what is not going to happen serves no purpose.



Some current mobile hardware has programmable blending exposed via NV_shader_framebuffer_fetch. Is it unreasonable to think that current or near future OpenGL hardware might have similar functionality to existing OpenGL ES hardware?

l_belev
04-26-2012, 03:51 AM
No, I tell people to stop posting suggestions that will not be implemented. What expectation is it that anything he has suggested would even be considered, given that the ARB tried twice and failed twice?

I would say that if they already tried TWICE then certainly there is a chance they will try it a third time, and hopefully now they even might succeed.

Repeated suggestion shows that people are STILL interested in this API and believe that it may be improved (unlike you -
OpenGL is what it will always be. It will be a functional but crufty API; the sooner you get over that, the better for everyone.).
And when the ARB see the repeated suggestion I doubt they will say "ah, we see some spammer here. Now we WONT do what he wants, even if we would do it otherwise!"
I think they rather would say something more like "we already tried that twice and failed, but since still there is a popular demand, we shall keep trying!"

Things don't always work from the first time. If you remember the history of the very wanted feature "render in texture". The first attempt ended up with the lousy pbuffers. Then people kept complaining and wanted improvement. Then ARB tried again and the second time they did it right (we got the framebuffer objects).


What I want is for people to stop asking for what they want. I want people to ask for something that the ARB would actually do.

The "suggestions" this forum is for are exactly things that people want. They are not what "the ARB would actually do".
It is not our job to guess what ARB would actually do. Our job is to decide what WE need and formulate it well.

Of course you are free to censor and apply your criteria for what is good and what is bad to your OWN suggestions (if you ever make ones), but please dont try to impose them on other people. Other people have brains to decide for themselves.
Even a moderator would intervene only on breach of forum rules. But you try to censor the peoples very legal suggestions when you are not even a moderator.

Janika
05-03-2012, 04:05 PM
But he's already done' that. And the ARB has already attempted what he has suggested and rejected it. Twice.

I'm just curious. Any idea why it was rejected? Resources please?

Alfonse Reinheart
05-09-2012, 12:14 AM
I'm just curious. Any idea why it was rejected? Resources please?

The first was called simply OpenGL 2.0, and it was initially proposed by 3D Labs. From an outsider's perspective, it seems like 3D Labs simply walked into a GDC one day in 2001 and said, "Here's some stuff; let's talk about it! (http://tech.slashdot.org/story/01/09/25/0318217/3d-labs-proposes-opengl-20-to-kick-directx)" According to that Slashdot article, they wanted an open dialog on the subject.

The only copy I can find of the original proposal is here (http://www.findthatfile.com/search-15834122-fPDF/download-documents-ogl2.pdf.htm). Be warned, it's an unvirus-checked PDF. The general idea was something like the current GL 3.0, only with what was probably a cleaner break between the older APIs and the newer ones. There was some form of backwards-compatibility layer between the two, such that you could use bits of 2.0 in 1.x code.

Exactly why the ARB abandoned it is not known. They weren't particularly forthcoming about it at the time.

The second effort was eventually called Longs Peak. There were four public newsletters released by the ARB about it during its development. They used to be available on this site, but I can't find them anymore.

This thread (http://www.opengl.org/discussion_boards/showthread.php/165271-The-ARB-announced-OpenGL-3-0-and-GLSL-1-30-today) is a catalog of the community reaction when told that 3.0 would not in fact be Longs Peak. This post by Barthold presents the ARB position on why it was ditched. (http://www.opengl.org/discussion_boards/showthread.php/165271-The-ARB-announced-OpenGL-3-0-and-GLSL-1-30-today?p=1168234&viewfull=1#post1168234) The gist of it is that it was taking too long, they couldn't commit to what exactly to remove, and many GL users aren't going to accept having to rewrite large parts of their apps.

That last point hasn't changed and isn't going to change. So long as the ARB prioritizes those who do not wish to do rewrites, they're not going to rewrite the API.

Also, note the "taking too long" point. Barthold's post was made over 2 years after the initial Longs Peak pipeline newsletter. There is information that they stopped working on Longs Peak in early 2008 or thereabouts. So even with that, you're still looking at 1.5 years.

The ARB could not settle on a new API in 1.5 years. Has something changed that would make them more productive?

Also, Barthold promised, "One of the early results of this is that we will work on folding object model improvements into the core in a more incremental manner."

It is closing in on 4 years since then. What "incremental" "improvements" have been done to the object model?

1. Texture storage. It creates partially immutable textures; immutability being one of the features of the "new" object model.

2. DSA-style uniform setting (thanks to separate_shader_objects, but only because it's a lot more convenient that the other way that SSO lets you set uniforms).

3. DSA-style shader objects.

... That's it.

You be the judge as to how much the ARB has fulfilled this promise.

thokra
05-09-2012, 01:21 AM
[..]and many GL users aren't going to accept having to rewrite large parts of their apps.

... and until they do all others are stuck in limbo. Personally I have made my peace with OpenGL's shortcoming a while ago but I believe that backwards compatibility can only be a valid reason for delaying long overdue API redesign for so long. At some point they have to do it anyway so it might as well be in the near future.


What I want is for people to stop asking for what they want. I want people to ask for something that the ARB would actually do.

A much more efficient route would be if the ARB told the community what features they are willing and able to incorporate in a certain time frame, have a vibrant discussion and then ratify the most promising draft. From my perspective it is very hard to tell what they would and would not do. The ARB and the interests of the companies involved aren't transparent. For instance, asking to get rid of object binding isn't something that's illogical and impossible to do and the discussion about it has gone on for years. This redesign is something one could shove down developers' throats without losing sleep. I doubt anyone would seriously oppose losing this ancient mechanism. And in my eyes such a proposal is completely valid and still they haven't done it until 4.2

We need more direct communication again.

Janika
05-09-2012, 08:42 AM
Taking so long to fulfill promises and keep disappointing the community over all these years every time they come up with a new version, shows one and only one thing, incompetence!
I understand driver and CAD developers don't want to rewrite. However laziness is not a valid excuse.

thokra
05-09-2012, 09:56 AM
Taking so long to fulfill promises and keep disappointing the community over all these years every time they come up with a new version, shows one and only one thing, incompetence!

I wouldn't necessarily blame that on incompetence. Although I don't know what the vetoing rules are I imagine that every, or at least major decisions have to be unanimous. If one member is blocking something intentionally, it's most likely due to business interest. No single corporation involved in the ARB would ratify anything out of good faith and software engineering idealism. If my little research is correct, Microsoft did just that before they left the ARB - blocking everything just to slow down the development of the API. In the case of Direct3D, however, there is only one decider - Microsoft. Of course, they will try to please their customers as much as possible, but if they want to do something drastic they don't ask hundreds of companies over multiple years, they simply tell them: "Look, the next version will break this and that and the simple truth is you will have to adopt the changes or stay with earlier versions."

I recently read one of NVIDIA's presentations on Longs Peak dating back to 2006 which already proposed a model to seperate legacy and new code to maintain compatibility while drastically renewing the API and making it easier for developers and implementors. Later presentations on the other hand clearly state, that NVIDIA doesn't believe in dropping "perfectly valid" (IIRC) functionality and therefore provides fully backwards compatible GL drivers. I cannot imagine that maintaining drivers which support everything up to 4.2 is what one can call "making it easier for implementors". The whole thing seems quite schizophrenic.

When it come to backwards compatibility is ask myself: Why don't they unanimously agree on breaking it and simply do it Microsoft's way? If they simply said "we're gonna redesign the whole GL so live with it and adopt the damn thing", would legacy developers choose not to invest time and money to port their apps? Would they abadon OpenGL and move to Direct3D thus creating the necessity to rewrite the whole rendering code anyway? What are all the legacy developers gonna do? Blow up AMD's or NVIDIA's headquarters? I imaging that every member of the ARB is aware of that and still they don't do it.

However, all speculations are ultimately irrelevant. As long as the ARB doesn't tell the community stuff we're simply doomed to live with it or abadon x-platform development and go Direct3D (which I for one will surely not do).

Janika
05-09-2012, 01:30 PM
But is not the case that CAD developers are already moving to Direct3D?

Gedolo
05-09-2012, 03:18 PM
Just to add something.

I looked at the way context creation is done.

The application should be able to
a) get major, minor and core or compatibility profile (this is done and good, please make this kind of a thing consistent across all khronos api's so you only have to develop it once.)
b) when an application wants to exist let it present a version and profile to the driver.
The driver then decides to execute it or gives an error with does not have <needed version> for application: <application name>.

(There seems to be inconsistencies between the GL and GL ES about this.
Also I'm not sure if I read correctly
but please allow for a general api mechanism where the application can just do a call with the version and profile it wants.)
This can be useful for all the api's, dealing with changing specifications.
Making a general thing across all khronos api's benefits from only having to develop it once.

old applications will be recognizable by new drivers because of the calls.
New applications can just work on new drivers since the drivers can have a very good idea of what is asked. You can theoretically even break the api constantly and still have old and new applications running on new drivers without problems related to compatibility.
(Provided that the driver writers can keep up implementing everything.)
No danger for legacy + able to change everything without problems related to the way changing something could mess up expectations between applications and drivers.

mhagain
05-09-2012, 05:10 PM
Sampler objects are also semi-DSA/bindless, but they miss one important piece of functionality. You can't bind a texture to GL_TEXTURE0 then sample it once with clamp/linear and a second time with wrap/point, for example. This can be very useful for encoding complex functions in textures, the hardware is capable of doing it (and has been since at latest 2002 or thereabouts), but GL doesn't expose that capability so far as I can see - separation of textures from samplers remains incomplete (see further discussion point 4 at http://www.opengl.org/registry/specs/ARB/sampler_objects.txt).

There's no reason why GL 4.3 (or 5.0 with 4.3 being the "expose as much functionality..." version) can't make a clean break. Freeze the spec at 4.2 for existing programs, build a new spec that makes a complete break with the legacy cruft, let those who have to maintain apps for older versions continue with the older spec, let those who want to move forward use the newer. Yes, hardware vendors will need to maintain 2 sets of GL drivers as a result, but is that really any worse than the current scenario where both newer stuff and ancient crap must be maintained in a single driver (and all the pain and suffering that comes from that)? How sustainable is the current situation? Something has to break, the only question is what is going to break first.

V-man
05-09-2012, 07:39 PM
But is not the case that CAD developers are already moving to Direct3D?

Probably. I don't know.

What surprises me is that they (CAD) care about backwards compatibility in GL 3.0, 3.1, 3.3, 4.0, 4.1 and future versions.
It seems to me that the features added are more usable in gaming situations rather then CAD.
That said, even most games don't utilize all that functionality.

Which CAD program uses geometry shaders or tesselation shaders or sampler objects or floating point formats for textures and FBO?

So, overall, it doesn't make sense.
The industry is run by FUD = Fear Uncertainty and Doubt.
Whenever a clean break was mentioned, people panick that old CAD programs and games would not run anymore.

Direct3D is a whole other world. It is a changing API. If CAD people want to move to it....I consider that moronic because it is a changing API. Something that they don't like.

Alfonse Reinheart
05-09-2012, 09:36 PM
There's no reason why GL 4.3 (or 5.0 with 4.3 being the "expose as much functionality..." version) can't make a clean break.

It would be for the same reason that 4.2 couldn't make a clean break. That 4.1 couldn't make a clean break. That 4.0 couldn't make a clean break. That ... that 3.0 couldn't make a clean break.

The fact that us people on a forum don't see the reason doesn't mean the reason doesn't exist. And even if it doesn't exist, that also doesn't mean it's going to happen.

Really guys, don't get your hopes up.

skynet
05-09-2012, 11:44 PM
Direct3D is a whole other world. It is a changing API. If CAD people want to move to it....I consider that moronic because it is a changing API. Something that they don't like.
You should read this:
http://archicad-talk.graphisoft.com/files/autodesk_inventor_opengl_to_directx_evolution_788. pdf (http://archicad-talk.graphisoft.com/files/autodesk_inventor_opengl_to_directx_evolution_788. pdf)

V-man
05-10-2012, 06:22 AM
You should read this:
http://archicad-talk.graphisoft.com/files/autodesk_inventor_opengl_to_directx_evolution_788. pdf (http://archicad-talk.graphisoft.com/files/autodesk_inventor_opengl_to_directx_evolution_788. pdf)

Thanks. The whole thing is funny but specially this part


OpenGL uses an older technology called sphere maps for reflections, which means you use the image of
your environment taken from the perspective of a perfectly reflecting sphere.
Direct3D uses a newer technology called cube maps for reflections which means that you supply six
textures as the faces of a cube surrounding your model. Direct3D does the reflection computations using
the cube.

and that was from 2007, so GL 2.1 was already around. LOL.

thokra
05-10-2012, 07:29 AM
In spite of the fact that we do not use any new fancy OpenGL extensions and
use OpenGL almost on the level of 1997 graphics HW technology, we routinely encounter OpenGL
graphics drivers that do not work correctly and as a result[..]

You don't even need to read past the first page to get stunned by massive amounts of irony. Of course, it's always better and easier to write and maintain more than 40 workarounds for crap that most likely has been redeemed by later GL revisions... :doh:

I really, really hope that the team at Autodesk developing the product is the only one with that policy. Otherwise I'd have to find a new desk to compensate for the hole I smashed into it with my head.

Janika
05-10-2012, 08:27 AM
The next has to be GL 5 and must be a clean break from all previous versions. And as mentioned, if CAD dady is favoring D3D, then why bother with backward compatibility profiles, and as someone mentioned, maintaining too much in a single driver???!!! Games use D3D already and D3D is not stable either. So again why bother?

menzel
05-10-2012, 09:45 AM
The next has to be GL 5 and must be a clean break from all previous versions.

I predict, that we will hear a lot more 'Version N+1 has to be a clean break' demands before there will acually be a clean break (if ever)...

Alfonse Reinheart
05-10-2012, 12:10 PM
The only reason I could see why the ARB might consider making a third try for a new API (and again: they've tried it twice before) is because graphics cards aren't getting that many truly new features that require API extension.

DX11.1 hardware features are... scant:


Shader tracing and compiler enhancements: Not a hardware feature. Not really.
Direct3D device sharing: Not a hardware feature.
Check support of new Direct3D 11.1 features and formats: Not a hardware feature.
Create larger constant buffers than a shader can access: Welcome to the party, D3D; glad you could make it ;)
Use logical operations in a render target: Ditto.
Force the sample count to create a rasterizer state: Ditto.
Process video resources with shaders: Not a hardware feature, per-se.
Extended support for shared Texture2D resources: Not a hardware feature.
Change subresources with new copy options: Not a hardware feature.
Discard resources and resource views: Not a hardware feature.
Support a larger number of UAVs: Hardware feature yes, but only because D3D doesn't provide a query and a flexible count of these...
Bind a subrange of a constant buffer to a shader: Welcome to the party, D3D; glad you could make it ;)
Retrieve the subrange of a constant buffer that is bound to a shader: Ditto.
Clear all or part of a resource view: It took you that long?
Map SRVs of dynamic buffers with NO_OVERWRITE: Welcome to the party, D3D; glad you could make it ;)
Use UAVs at every pipeline stage: Welcome to the party, D3D; glad you could make it ;)


Most of these have little to do with actual hardware. Basically, since D3D11, standardized cross-vendor hardware features have been fairly few and far between. Sure, we've got AMD pushing virtual texturing. NVIDIA's pushing "bindless" textures. Other than that? No.

One of the cited reasons to abandon Longs Peak was that it was taking too long, that OpenGL wasn't being responsive to new hardware. There isn't any right now. Or at least, not much that's cross-vendor.

Again, I remind you: Do not get your hopes up! This will not happen, no matter how much you want it. The sooner you accept this, the better.

V-man
05-10-2012, 03:20 PM
You don't even need to read past the first page to get stunned by massive amounts of irony. Of course, it's always better and easier to write and maintain more than 40 workarounds for crap that most likely has been redeemed by later GL revisions... :doh:

I really, really hope that the team at Autodesk developing the product is the only one with that policy. Otherwise I'd have to find a new desk to compensate for the hole I smashed into it with my head.

What do you mean by GL revisions? AFAIK, newer versions don't change much of the basics that these CAD programs are using (line rendering and non textured polygons).

The stupidity I see is that they say OpenGL doesn't support Cubemap and that was posted during 2007 while GL 2.1 was around.
The other big stupid thing is that they are using the software renderer (probably for preview and printing purposes) instead of using FBO. Again, we are talking about the GL 2.1 era when FBO support was available on ATI and nVidia. The FBO extension had been around since 2004 (GL 2.0).

They are stuck in the stoneage of GL 1.1 obviously but I'm sure that they have discovered quite a few bugs which pisses them off.
Someone should teach them how to use GLEW at least so that they can move to GL 2.1.

thokra
05-10-2012, 03:35 PM
What do you mean by GL revisions? AFAIK, newer versions don't change much of the basics that these CAD programs are using (line rendering and non textured polygons).

What I wanted to say is that they would have easily profited by incrementally leveraging newer features and spec revisions which are usually acompanied by improved drivers which expose new features and, at least for the most mainstream features, reach pretty good stability at least on Windows after a few weeks or months. That's what I meant by redeemed. So I fully agree that their problems would probably just have gone away by turning their brains on and moving to 2.1. Furthermore, if a company like Autodesk can't convince AMD and NVIDIA to get their stuff working then I don't know who could.

This whole development strategy blows my mind. Another thing I find very disturbing is the accuracy argument. If GL implementations from 1997 worked for them, how could they state 10 years later that the GL accuracy wasn't enough for their needs anymore? Didn't I read that part correctly?

Janika
05-10-2012, 04:32 PM
This is called the Direct3Dization of the graphics software industry. Prety much like the DOTNetization of software.

kyle_
05-10-2012, 05:35 PM
They are stuck in the stoneage of GL 1.1 obviously but I'm sure that they have discovered quite a few bugs which pisses them off.
Someone should teach them how to use GLEW at least so that they can move to GL 2.1.

You are being pretty harsh here. Its not like CAD's are standing in the same place entire time. Yeah, they have loads of legacy code (ive seen some pretty crazy stuff in various cads) and switching overnight (or at all) is silly when they have something working (probably with shitload of workarounds and whatnot).

Most arguments against clean API break are bullshit though. There is only one thats valid imo.
If driver vendors were to commit to GL5.0 that has nothing to do with old GL, fixing old bugs will probably be lower priority (those same teams wont suddenly develop two drivers instead of one).

V-man
05-10-2012, 10:14 PM
You are being pretty harsh here. Its not like CAD's are standing in the same place entire time. Yeah, they have loads of legacy code (ive seen some pretty crazy stuff in various cads) and switching overnight (or at all) is silly when they have something working (probably with shitload of workarounds and whatnot).

We are now 2012, therefore 15 years have passed. During that time, they (Autodesk) never considered rewriting their renderer?
But wait, they have decided to rewrite it! Except that it is in Direct3D. They are just assuming that it will be less troublesome than GL.

To me, it doesn't make much sense.
Direct3D 10 isn't going to last forever. At some, point Microsoft will stop releasing updates and just move on. It happens to all their products.


Furthermore, if a company like Autodesk can't convince AMD and NVIDIA to get their stuff working then I don't know who could.
I don't understand it either.

Alfonse Reinheart
05-11-2012, 01:52 AM
But wait, they have decided to rewrite it! Except that it is in Direct3D. They are just assuming that it will be less troublesome than GL.

To be quite honest, it probably will be.

They won't have to deal with GL driver bugs. If they're going to start using advanced, shader-based features, then they will likely run into GL driver bugs quite quickly (just as many people on this site do). D3D implementations don't have nearly as many bugs. D3D even works on Intel hardware, where trusting in any OpenGL version beyond about 1.4 is foolish.

They don't need cross-platform support.

In short: given the stability differences, and given the fact that they need to rewrite their rendering system... which would you choose? Why would you choose OpenGL for a Windows-only program that you are basing your company's survival on?

Can you think of even one reason to do so?


Direct3D 10 isn't going to last forever. At some, point Microsoft will stop releasing updates and just move on.

They will likely have planned for that. With a new codebase, rewritten from scratch (or near-enough), it'll likely be easier to switch API functions as they change. Besides, it's not like D3D10 is so massively different from D3D11 in terms of the basic API.

thokra
05-11-2012, 02:06 AM
They don't need cross-platform support. [..] Why would you choose OpenGL for a Windows-only program that you are basing your company's survival on? Can you think of even one reason to do so?

Nope, not me at least. However, an interesting question would be how many major companies out there think the same way and have already or will abandon their GL rendering code in the foreseeable future. If the amount was significant that would mean one major reason gone for not revamping the GL. (Which I too believe won't happen but I still maintain a glimpse of hope. ;) ) Another question would be, why aren't any of the CAD guys running around the forum anyway? Have there been encounters in the past?

kyle_
05-11-2012, 03:29 AM
If i was a major company i probably wouldnt care for OpenGL at all (and i do like it, kind of). That is of course assuming i (as a company) dont care for mobile & mac or linux, which may not be true.


Another question would be, why aren't any of the CAD guys running around the forum anyway? Have there been encounters in the past?

How do you know that :)

thokra
05-11-2012, 03:35 AM
How do you know that :)

Damn... ;)

Eosie
05-11-2012, 06:52 AM
NVIDIA's bindless APIs seem to be a clear proof that OpenGL is flawed and cannot perform well as far as the overall CPU overhead is concerned. See:


The ability to access textures without having to bind and/or re-bind them is similar to the capability provided by the NV_shader_buffer_load extension that allows shaders to access buffer objects without binding them. In both cases, these extensions significantly reduce the amount of API and internal GL driver overhead needed to manage resource bindings.

Such hacks would not be needed if the design of OpenGL allowed drivers to have low enough CPU overhead in the first place.

thokra
05-11-2012, 07:17 AM
OpenGL is flawed and cannot perform well as far as the overall CPU overhead is concerned.

OpenGL is flawed. That is true. But you cannot generally state that OpenGL implementations cannot perform well in regard to CPU overhead because the CPU overhead is highly dependent on the use case. For instance, VAOs are a great way to reduce CPU overhead and with a clever buffer manager, instancing, multi draws, all which is of course backed by the current API, you can reduce bindings and draw calls to a minimum already. It's the same for textures. If you don't use textures at all, i.e. you render everything procedurally, you don't have any CPU overhead in that regard.


Such hacks would not be needed if the design of OpenGL allowed drivers to have low enough CPU overhead in the first place.

It's not the GL which allows drivers to incur low overhead. It's the hardware. OpenGL and the drivers that implement the spec are merely exposing hardware features on a higher level. The extension is nothing more than a mapping of current hardware features to the GL. That's not a hack but has been at the center of the extension mechanism for all eternity. Of course, this 'hack' could and should be core but as this thread shows, very few of us believe it'll happen anytime soon.

Alfonse Reinheart
05-11-2012, 01:29 PM
NVIDIA's bindless APIs seem to be a clear proof that OpenGL is flawed and cannot perform well as far as the overall CPU overhead is concerned.

No, NVIDIA's bindless APIs is clear proof that OpenGL can be improved with regard to CPU caching performance. "cannot perform well as far as the overall CPU overhead is concerned" is errant nonsense; OpenGL is significantly better than D3D in this regard, as it allows the driver to do draw call marshalling.

Just check out NVIDIA's 10,000 draw call PDF (http://origin-developer.nvidia.com/docs/IO/8230/BatchBatchBatch.pdf?q=docs/IO/8230/BatchBatchBatch.pdf). Page 14 clearly shows that NVIDIA's OpenGL implementation has significantly better CPU batch behavior, to the point where batch size is clearly not the dominating factor in performance.

Bindless is, first and foremost, about exploiting NVIDIA hardware, providing access to lower-level aspects of what their hardware can do. Obviously lower-level APIs will be faster than higher-level ones.


Of course, this 'hack' could and should be core

No it shouldn't.

Bindless as far as uniforms are concerned is very hardware-specific. You're not going to be able to generalize that much beyond NVIDIA's hardware. Bindless vertex rendering might be possible, but even then, it's iffy. It's mostly about making buffers resident, and what restrictions you place on that. In NVIDIA-land, a resident buffer can still be mapped and modified; do you really want to force everyone to be able to do that?

In either case, we should not be giving people integer "GPU addresses" that they offset themselves. That's way too low-level for an abstraction. It should simply be a name for a buffer that has been made resident.

Eosie
05-11-2012, 06:25 PM
No, NVIDIA's bindless APIs is clear proof that OpenGL can be improved with regard to CPU caching performance. "cannot perform well as far as the overall CPU overhead is concerned" is errant nonsense; OpenGL is significantly better than D3D in this regard, as it allows the driver to do draw call marshalling.

Just check out NVIDIA's 10,000 draw call PDF (http://origin-developer.nvidia.com/docs/IO/8230/BatchBatchBatch.pdf?q=docs/IO/8230/BatchBatchBatch.pdf). Page 14 clearly shows that NVIDIA's OpenGL implementation has significantly better CPU batch behavior, to the point where batch size is clearly not the dominating factor in performance.

Oh please, are you kidding me? It's a PDF comparing GeForce 2/3/4/FX performance on some ancient OpenGL implementation and DirectX 8 (I guess?) on some ancient version of Windows. You would very surprised how much APIs, OS driver interfaces, drivers, and hardware have evolved since then. It's a whole new world today. ;)

Anyway, the point is the existence of the "bindless" extensions shows how desperate the driver developers are. They are obviously very aware that the whole ARB won't agree on a complete 0penGL rewrite unanimously, so they had to find another way. I don't blame them, it's logical. However if the OpenGL API could be reworked such that it achieves at least 80% of performance increase of what bindless APIs advertise, I'd call it a huge win.

Alfonse Reinheart
05-11-2012, 07:01 PM
You would very surprised how much APIs, OS driver interfaces, drivers, and hardware have evolved since then. It's a whole new world today.

And which of these changes would suddenly cause cache miss rates to increase? Obviously, if something has changed that would cause performance to degrade, you should be able to point to exactly what it was.

Obviously, modern CPUs outstrip the speed of memory to feed them by significantly more now than they did then. Thus cache misses hurt proportionately more nowadays. But that doesn't invalidate the previous data. It simply means that there are additional concerns besides batch size.

Batches still count, especially in D3D land.

The fact that bindless provides a remarkable speedup alone is not evidence that OpenGL performance has degraded. After all, for all you know, that level of performance speedup could have been possible back then if bindless vertex rendering had been implemented.


Anyway, the point is the existence of the "bindless" extensions shows how desperate the driver developers are.

By your logic, the existence of NV_path_rendering would mean that driver developers are "desperate" to get 2D rendering via OpenGL.

The problem with your claim is the incorrect assumption that NVIDIA == driver developers. If AMD and/or Intel had their own competing "bindless" specs out there, your claim might hold some weight. But as it stands, no; the absolute best you can conclude is that NVIDIA is "desperate".

Another point against this is that NVIDIA has shown a clear willingness to work with others on EXT extensions to expose shared hardware features, like EXT_shader_image_load_store. Indeed, EXT_separate_shader_objects was basically all NVIDIA's spec, with a bit of consulting with the outside world (the ARB version is what happens when a committee comes along and ruins something that wasn't terribly great to begin with). And yet, both of those are EXT extensions, not NVs.

Coupled with the possible patent on bindless textures, it's much more likely that NVIDIA is simply doing what NVIDIA does: expose hardware-specific features via extensions. That's what they've always done, and there's little likelihood that they're going to stop anytime soon. Bindless isn't some "desperate" act to kick the ARB in the rear or circumvent it. It's just NVIDIA saying "we've got cool proprietary stuff." Like they always do.

mhagain
05-12-2012, 07:22 AM
D3D10 or 11 no longer have the old draw call overhead; that's been dead for positively ages. D3D9 on Vista or 7 also shares this performance characteristic.

Every hardware vendor's marketing department would prefer you to be using their proprietary stuff. That was the entire motive behind AMD's fit of "make the API go away" a while back. It's a trifle disingenuous to make AMD look blameless in this.

The key important thing here is not NV bindless vs some other hypothetical implementation of same - the key important thing is addressing the bind-to-modify madness that has afflicted OpenGL since day one. There's absolutely nothing proprietary or even hardware-dependent about that; D3D doesn't have bind-to-modify, AMD hardware can do it, Intel hardware can do it.

It's not good enough to release a flawed, wonky or flat-out-insane first revision of a spec (buffer objects, GL2) and hope to patch it with extensions later on. Even in the absence of significant new hardware features (which it is by no means safe to predict) future versions of GL must focus on removing barriers to productivity.

Janika
05-12-2012, 12:53 PM
API design in general should be an abstraction driven by usability rather than how hardware can support some features or how it can be optimal for the hardware...Hardware changes, and it's unpredictable how it will change. The API designers should rather focus on how the API should be used instead of how it's implemented. Usability and elegance should take first priority here.
Anyway we can wait till September this year and see. There will be some big changes ;)

Alfonse Reinheart
05-12-2012, 05:36 PM
Every hardware vendor's marketing department would prefer you to be using their proprietary stuff. That was the entire motive behind AMD's fit of "make the API go away" a while back. It's a trifle disingenuous to make AMD look blameless in this.

It wasn't a "fit"; it was a comment. A "fit" would have been many comments over a long period of time. And considering the fact that they didn't do anything about it, it obviously wasn't a grave concern for them. Simply stating a fact.

Actions speak louder than words. And AMD's actions aren't saying much.


The key important thing here is not NV bindless vs some other hypothetical implementation of same - the key important thing is addressing the bind-to-modify madness that has afflicted OpenGL since day one.

But... that has nothing to do with the problem that NVIDIA's bindless solves.

Bindless doesn't get its performance from removing bind-to-modify. Indeed, it doesn't remove this at all. The problem isn't bind-to-modify. The problem is that binding an object for rendering requires a lot of overhead due to the nature of the objects themselves. Objects in OpenGL are not pointers to driver-created objects. They're references to pointers to driver-created objects. That's two levels of indirection and thus more opportunities for cache misses.

Bindless goes from 2 indirections to zero by directly using a GPU address. D3D has (possibly) one fewer indirections. Removing bind-to-modify would go from 2 indirections to... 2. Because it doesn't address the number of indirections.

To reduce the number of indirections, you have to deal with the objects themselves, not how you modify them. OpenGL objects would have to stop being numbers and start being actual pointers. You would have to be forbidden to do things like reallocate texture storage (which we already almost completely have with ARB_texture_storage), reallocate buffer object storage (ie: being able to call glBufferData more than once with a different size and usage hint) and so forth.

The fact that you'd be using glNamedBufferData instead of glBufferData to reallocate buffer object storage does nothing to resolve the underlying problem. The driver has to check to see if the buffer object has changed since the last time you talked about it. It has to resolve the buffer object into a GPU pointer, which also may mean DMA-ing it to video memory. And so forth.

These checks have nothing to do with bind-to-modify. Getting rid of bind-to-modify will not make OpenGL implementations faster.

mhagain
05-12-2012, 10:35 PM
Getting rid of bind-to-modify will not make OpenGL implementations faster.

Bind-to-modify pollutes GPU and driver caches, it pollutes state-change filtering, it affects design decisions in your program, it pollutes VAOs. This isn't some theoretical "more opportunities for cache misses" thing, this is "cache misses do happen, as well as all of this other unnecessary junk". An extra layer of indirection is down in the noise of any performance graph compared to this.

We're not talking about drawing teapots on planar surfaces here. We're not talking about loading everything once at startup and using static data for the entire program here. Real-world programs are very dynamic. Objects move into and out of the scene, transient effects come and go, on-screen GUI elements are updated and change, and this happens in every single frame.

Getting rid of bind-to-modify will make GL programs go faster.

Alfonse Reinheart
05-13-2012, 07:02 AM
Bind-to-modify pollutes GPU and driver caches

I cannot imagine a sane implementation of OpenGL that actually causes GPU changes from the act of binding an object. Unless it's a sampler object, and even then it's kinda iffy. Driver caches being polluted is far more about the extra indirection.

If I do this (with a previously created `buf`):



glBindBuffer(GL_UNIFORM_BUFFER, buf);
glBufferSubData(GL_UNIFORM_BUFFER, ...);


The first line will set the currently bound buffer object to refer to `buf`. That involves changing an effectively global value. There may be some memory reads to check for errors, and the actual object behind `buf` may need to be tracked down and allocated if it doesn't exist. So, that's a hash-table access to get the actual object behind `buf`, followed by some reads of the buffer's data (to see if it exists), followed by a memory write to the global value.

That's 3 memory accesses. And let's assume they're all uncached. So 3 cache misses.

The second line will do some uploading to the buffer. So we fetch from the global value the buffer object. We'll assume that this implementation was not written by idiots, so the global value being written was not `buf`, but a pointer to the actual internal buffer object. So we access the global pointer value, get the buffer's GPU and/or CPU address, and do whatever logic is needed to schedule an upload.

That's 2 memory accesses (outside of the scheduling logic). However, fetching the global pointer value is guaranteed to be a cached access, since we just wrote that value in the `glBindBuffer` call. Also, we may have brought the buffer object's data into the cache when we did those bind-time validation checks. So worst-case, this is only 1 cache miss. Best case, 0 misses, but let's say 1.

Total cache misses: 4. Total number of different cache lines accessed: 4.

Now, let's look at this:



glNamedBufferSubDataEXT(buf, ...);


So, first we need to resolve `buf` into a buffer object. That requires accessing our hash table to turn it into a pointer to our internal buffer object data. Following this, we must check to see if this is a valid object. After that, we have to get the buffer's GPU and/or CPU address, and do whatever logic is needed to schedule an upload. That's 3 memory accesses.

Total cache misses: 3. Total number of different cache lines accessed: 3.

So, the difference is 4:3 in both number of cache misses and how many separate lines are accessed. Fair enough.

Now, let's look at what happens when the hash table is removed and we deal directly with opaque pointers.

The first one goes from 4 cache misses down to 3. The second goes from 3 down to 2. So, that "extra indirection" seems to be a pretty significant thing, as removing it reduced our number of cache misses by 25% in the bind-to-modify case and by 33% in the DSA case.

DSA alone only reduces cache misses by 25%.

But wait; since we're dealing with "GL programs", we need to consider how often these cache misses will happen. How often will a bind point actually not be in the cache?

Obviously the first time you use a bind point in each rendering frame, it will not be in the cache. But after that? Since so many functions use these bind points, the number of cache misses is probably not going to be huge.

What about the cache hit/miss rate for the indirection, the hash table itself? That is in fact rather worse. Every time you use a new object (by "new", I mean unused this frame), that's a likely cache miss on the hash table. That's going to be pretty frequent.

As you say, "Real-world programs are very dynamic." You're going to have thousands of textures used in a frame. You may have a few dozen buffer objects (depending on how you use them). You may have hundreds of programs.

So which miss rate is going to be higher: new object within this frame? Or bind points?

My money is on new objects. So getting rid of that indirection ultimately gets you more. So this:


An extra layer of indirection is down in the noise of any performance graph compared to this.

doesn't seem to bear up to scrutiny.


Real-world programs are very dynamic. Objects move into and out of the scene, transient effects come and go, on-screen GUI elements are updated and change, and this happens in every single frame.

This seems like a non-sequitor. Objects moving out of a scene is simply a matter of what programs and buffers you bind to render with. It has nothing to do with what object state gets modified (outside of uniforms set to those programs, but I'll get to that in a bit).

GUI elements and particle systems are a matter of buffer streaming. The predominant performance bottleneck associated with that (when you manage to find the fast path) is in the generation of the new vertex data and in the uploading of it to the GPU. The extra time for binding that buffer in order to invalidate and map it is irrelevant next to issuing a DMA. So those don't count.

As for uniforms within programs, these are set all the time. It's not that you necessarily reset all the uniforms every time you render a new object of course. The fact is that uniform setting is a constant operation, something you do all the time when rendering.

Indeed, uniforms are probably the object state most likely to be modified when rendering. And that last part is the key: when you change uniform state, it is only because you want to render with that program.

It's not bind-to-modify with programs; it's bind-to-modify-and-render. Modifying uniforms without binding the program doesn't change the fact that when you change uniforms, you're also almost certainly going to immediately render with it. Which means you need to bind the program. So you've lost nothing with bind-to-modify for programs; you were going to bind it anyway.


it pollutes state-change filtering

In what way? No OpenGL implementation would actually trigger any GPU activity based solely on binding. Except for sampler objects, and even then, probably not.

The only time it would affect filtering is if you are in the middle of the render loop, and you do something stupid. Like bind an object, modify it, and then bind something else over top of it.

And I can't think of a sensible reason to do this in a real program.


Getting rid of bind-to-modify will make GL programs go faster.

There is strong evidence that bindless has a significant effect on GL programs. Where is your evidence that bind-to-modify has a similar effect?

Yes, it will probably have an effect. But I seriously doubt it's going to be anywhere near as what you get with bindless.

xahir
05-17-2012, 02:33 AM
I really don't know if binding or bindless should be faster or indifferent. But one thing I'm sure about is nvidia drivers are running on another thread and whatever call I make is being routed to the driver's thread(s) to be served. Getting the number of calls down should count.

Besides everything, in my opinion one of the best outcomes of binding gl objects is that driver ensures any previous commands regarding the object is complete.

And to be honest DSA is only-really good for wrapping opengl objects with language constructs. Lets say you want to make a Texture class, there is almost no way to do it without DSA. For example Texture.SetImage(...) method. For each call of such a method you need to make sure your texture is bound and you need to restore previous texture binding etc. that is kind of painful without DSA (using a Context object which ends up being sphagetti:)) Do you need such language constructs? Well it is easier for migrating/mirroring DX code, and it is easier to think of the code especially if you are educated like me...

Janika
05-17-2012, 08:37 AM
From a software engineering perspective, DSA is just ugly. It might be faster or easier to implement, but it has nothing to do with how the hardware works. Whether it works faster is something implementation dependent, and is determined by how much the implementation does not suck :D Remember the situation with VBO? Theoretically it should outperform the old drawing approaches, but in reality it's completely different. *Direct* does not guarantee practical performance gain.

Alfonse Reinheart
05-17-2012, 09:08 AM
And to be honest DSA is only-really good for wrapping opengl objects with language constructs.

And not polluting the global bind points just because you want to change something. And for good programming practice (ie: not using global variables to pass invisible parameters around, which causes all kinds of errors).


From a software engineering perspective, DSA is just ugly. It might be faster or easier to implement, but it has nothing to do with how the hardware works. Whether it works faster is something implementation dependent, and is determined by how much the implementation does not suck

Nonsense. Implementations have to not suck to be fast, but that doesn't mean that the API has zero effect on performance. Bad APIs can very easily induce performance difficulties.

DSA does match with how hardware works because objects are objects in the hardware. Textures are pointers to various GPU memory blocks plus some state. These are actual objects with actual GPU state. Modifying these objects has nothing to do with the context or context state. The OpenGL bind-to-modify abstraction is 100% wrong compared to the actual underlying implementation.


Remember the situation with VBO? Theoretically it should outperform the old drawing approaches, but in reality it's completely different.

Huh? The only "old drawing approach" that outperforms buffer objects (on static data) are display lists, and even the only on certain hardware. As for dynamic, the main problem here isn't the object itself, but the difficulty in finding the fast path for doing streaming of buffer objects.

Which, incidentally, is a very good example of how a poor API can ruin performance. A good API would prevent you from taking the slow path altogether.

Janika
05-17-2012, 11:55 AM
Nonsense. Implementations have to not suck to be fast, but that doesn't mean that the API has zero effect on performance. Bad APIs can very easily induce performance difficulties.

Do you even have an idea how drivers work?


The OpenGL bind-to-modify abstraction is 100% wrong compared to the actual underlying implementation

Nonsense. You clearly underestimating the whole idea behind binding. It's a bigger problem than you think.


Which, incidentally, is a very good example of how a poor API can ruin performance.

I agree. DirectX is a very good example.

aqnuep
05-17-2012, 02:39 PM
Do you even have an idea how drivers work?
And do you have any idea how drivers work? Actually, what VBOs abstract is the only thing that the hardware *actually* can do. That means, all the rest, including immediate mode, client side vertex arrays and display lists are all emulated through VBOs, thus means it involves an additional copy. If ever VBOs are slower than the other alternatives is because you, as the developer, choose worse data layouts than the driver internally choses when creating the "VBO" for emulating the old mechanisms.


Nonsense. You clearly underestimating the whole idea behind binding. It's a bigger problem than you think.
No, actually Alfonse got it pretty well. Binding usually does not do anything in practice, except setting some global state. This is because at this point a driver might not know whether this bind happened because of an upcoming state change or because the application actually wants to bind the resource for use by the GPU. Of course, this is not the only approach and drivers might handle it differently for different object types and also various implementations might use different policies. However, a bind is not required by the hardware to modify object state. This is a 100% wrong abstraction of the underlying hardware in all cases, as Alfonse said.


I agree. DirectX is a very good example.
DirectX? Which D3D are you talking about? D3D9, which is deprecated or modern D3D, i.e. D3D10+? D3D10 and D3D11 reflect better how the hardware works (even though it's not perfect) and that's what more or less OpenGL 3+ core + DSA does. Obviously, D3D9 suffers from many of the same issues like legacy OpenGL, but why bring up the example of a deprecated API?

V-man
05-17-2012, 04:55 PM
I agree. DirectX is a very good example.

You mean that DirectX should have bind to modify like OpenGL has? Are you nuts?

Direct3D is a pretty straight to the metal as you can get. D3D8 blew away GL. D3D9 was even better although the shaders made it difficult for the IHVs to optimize, but GL's asm shaders were in the same situation.
GLSL was nice since it was a high level language and provided more optimization opportunities for the IHVs (eventually, D3D got its HLSL) but GLSL had a lot of suckiness which eventually GL 3.0 and above addressed.

Although a lot more can be said, I'm going to stop here.

Janika
05-17-2012, 04:56 PM
If ever VBOs are slower than the other alternatives is because you, as the developer, choose worse data layouts than the driver internally choses when creating the "VBO" for emulating the old mechanisms.

Then please you, as a driver developer, provide us, the developers, what layout your driver likes. Though I still don't get your point here. How on earth do you expect millions of developers starving for performance chose the data layout your driver expects? Are you telling me that driver developers restrict the driver to work best with only one data layout?
These are not professional coders.


No, actually Alfonse got it pretty well. Binding usually does not do anything in practice, except setting some global state. This is because at this point a driver might not know whether this bind happened because of an upcoming state change or because the application actually wants to bind the resource for use by the GPU. Of course, this is not the only approach and drivers might handle it differently for different object types and also various implementations might use different policies. However, a bind is not required by the hardware to modify object state. This is a 100% wrong abstraction of the underlying hardware in all cases, as Alfonse said.

Your prophet got it right, we cannot argue with that anymore. Could you please stop being 100% sure all the time? If it's 100% wrong abstraction layer, then why has OpenGL maintained this approach for so many years?


D3D10 and D3D11 reflect better how the hardware works...

Then it's a bad API :) You just said it. This simply means poor abstraction level.

mhagain
05-17-2012, 05:24 PM
Then it's a bad API :) You just said it. This simply means poor abstraction level.

Have you ever actually written any modern D3D code? Even at version 9 - once you rip out all the fixed pipeline rubbish - it's actually a much cleaner and easier to use API than OpenGL. True, with D3D9 there were still some parts of it that looked as though they were designed by a tribe of monkeys on LSD (queries, lost devices, weird float to DWORD casts), but they're all gone or resolved in 10 and 11. It's clean, it's easy to use, it's fast to get stuff done in, you can be genuinely productive with it.

The core problem with bind-to-modify is that it messes up internal states. You want to modify a resource, you need to bind it, do your change, then put it back the way it was. The concept of binding doesn't differentiate between whether you're binding to modify or binding to draw, and that's an AWFUL abstraction; it doesn't reflect the way you actually USE resources in your program. Modifying a resource and using it to draw are two very different things, and should not be treated as if they were the same. It's even worse with buffer objects as there is just a single binding-point for each buffer object type. Suddenly the API is no longer helping you to be productive, it's getting in your way instead. You're no longer designing your code around the job you need your program to do, you're designing it around a bunch of arcane rules from the paleolithic era. How could that possibly be a good thing?

aqnuep
05-17-2012, 05:47 PM
Then please you, as a driver developer, provide us, the developers, what layout your driver likes. Though I still don't get your point here. How on earth do you expect millions of developers starving for performance chose the data layout your driver expects? Are you telling me that driver developers restrict the driver to work best with only one data layout?
These are not professional coders.
It's not the driver that expects proper layout but the hardware. You should learn or simply benchmark NVIDIA and AMD GPUs with various VBO layouts (alignment, stride, data format, component number, etc.). In general, don't use non-4-byte-aligned data, also some older hardware might not like 3 component data. Also, there are some GL3 capable GPUs that even though support half floats, they don't perform very well with half float vertex attributes. There are lot of aspects and, of course, some of them are non-trivial. Testing and benchmarking is usually the best way to reveal them.


If it's 100% wrong abstraction layer, then why has OpenGL maintained this approach for so many years?
Because OpenGL failed to remove any features even through deprecation. Also, no rewrite happened which could eliminate this. Finally, even though the DSA extension being nice, I can understand why it was not included in the core spec yet as it has many problems too.

I'm not objecting you just because I feel good about it, but because you mislead the readers of this forum.

thokra
05-18-2012, 01:49 AM
Your prophet got it right, we cannot argue with that anymore. Could you please stop being 100% sure all the time? If it's 100% wrong abstraction layer, then why has OpenGL maintained this approach for so many years?

In addition to aqnuep's remark, as everyone who is really concerned with OpenGL knows, the design decision and API evolution are not as simple when there's a ton of companies involved. You and all people who expect some piece of software to miraculously evolve just because it would make sense need to get a piece of reality.


Your prophet got it right, we cannot argue with that anymore. Could you please stop being 100% sure all the time?

I think there can be no doubt to whom you're referring. Although, and this has been stated earlier as well, Alfonse can be a little harsh at times he tends to be right when he brings something up. And no, if you simply know that what you're stating is 100% correct because you're very experienced and know a lot of stuff then this very forum is the place to share. If you can't accept that then you're in the wrong place. You should see such a discussion as a chance to learn and widen your horizon instead of complaining that you've been proven wrong.

Alfonse Reinheart
05-18-2012, 04:16 AM
No, actually Alfonse got it pretty well. Binding usually does not do anything in practice, except setting some global state. This is because at this point a driver might not know whether this bind happened because of an upcoming state change or because the application actually wants to bind the resource for use by the GPU. Of course, this is not the only approach and drivers might handle it differently for different object types and also various implementations might use different policies. However, a bind is not required by the hardware to modify object state. This is a 100% wrong abstraction of the underlying hardware in all cases, as Alfonse said.

Your prophet got it right, we cannot argue with that anymore. Could you please stop being 100% sure all the time? If it's 100% wrong abstraction layer, then why has OpenGL maintained this approach for so many years?

:doh: Your only evidence that the OpenGL way is correct is that... it's the OpenGL way? You're begging the question (http://en.wikipedia.org/wiki/Begging_the_question): assuming your own conclusion, thus creating circular reasoning.

You need evidence beyond "OpenGL does it" to say that it's right.

Have you not read anything in this thread that could explain why OpenGL did things this way? Not to mention that both of the rewrite attempts would have removed bind-to-modify.

mhagain
05-18-2012, 04:53 AM
If it's 100% wrong abstraction layer, then why has OpenGL maintained this approach for so many years?

Why did OpenGL not have separate shaders for so many years? Why did OpenGL not have sampler objects for so many years? In both cases the way OpenGL did things was clearly wrong and/or awkward and/or not reflecting the way hardware actually worked, yet OpenGL maintained them for a long time. Why?

It's clearly the case that there are other factors at work here. Call it perpetuation of initial bad design decisions (that may have even looked good at the time they were made), call it inertia, call it laziness, call it stubborn bone-headedness, call it a natural consequence of a design-by-committee process, call it whatever you like.

Reality is that hardware evolves. It develops new capabilities, and the way it handles existing functionality can change. An API that functions as an abstraction of that hardware must evolve too, and must evolve in a way that sensibly reflects the way the hardware is working.

Recent evolution of OpenGL has been doing just that - thankfully, and at last, but not to the extent that many would wish for. It could be worse.

But not doing it means that the driver needs to jump through tortured hoops to convert an ill-matching abstraction into something that the hardware can actually use to draw stuff with. That means complex and fragile driver code paths, it means weird behaviour with things that should just work, it means sudden and inexplicable performance loss, it means voodoo-programming in some cases ("if I put an empty glBegin/glEnd pair here it won't crash on Vendor X's driver - f--k knows why but it's working now" - that kind of thing sound familiar?)

Janika
05-18-2012, 08:54 AM
You mean that DirectX should have bind to modify like OpenGL has? Are you nuts?

Are you on crack? Who said that?

To some people on this forum who take it personally and react on others with insulting words, and they expect no response to what they say, this is not how it works. We are not bots, we are humans. No matter how you disagree with others you should still show some respect, and act politely. It's unacceptable to call "nuts," and other harsh words I see commonly used on this forums, because this reflects one and only thing, your immaturity. You cannot underestimate others judging by their sentences and how beautiful they can write their ideas. We all have different experiences, skills and points of views. Things here can be very subjective from different perspectives, software engineers see things differently than hardware designers, than driver writers, than application developers.
I'm pretty sure many people here are very mature and respectful, as there are a few others who are completely the opposite. Frankly speaking, do these quite famous angry members ever agree on anything? Just try to agree with something they already said in their replies and you will see they change, just to criticize, harshly. This is their job, they are desperate for anyone whom they can show their psychopathic malfunctioning social skills. Not only that, you find contradictions in their statements. So do you, "harsh" people, like to be believed blindly on anything you say just because you think you are the only one who have the experience while others not? Sorry to say this, you are completely wrong. Maybe you got some experience, but please don't tell you are the very experienced to the point you neglect others'. This is very ignorant and idiotic.

One more thing, if OpenGL is that badly designed, controlled by a lazy and incompetent group, and not evolving well with hardware changes, then why are you sticking with it? Why are you on this forum anyway?

V-man
05-18-2012, 10:32 AM
Are you on crack? Who said that?

To some people on this forum who take it personally and react on others with insulting words,......

I don't know what country you are from, but "Are you nuts?" is not an insult in Canada. It is something one says when they are shocked by what the other person says. No, I am not trying to insult or ridicule you just because you very much believe in "bind to modify".

Anyway, back to the bind to modify. GL didn't keep it because it is a good idea. I guess you weren't around when Long Peaks and the long discussions that went on about every little aspect of GL. I don't recall anyone wanting to keep "bind to modify" and when Long Peaks got axed, DSA surfaced.

Take a look at the spec for DSA
http://www.opengl.org/registry/specs/EXT/direct_state_access.txt




Cass Everitt, NVIDIA Daniel Pageau, Blizzard Daniel Koch, TransGaming Ian Romanick, IBM Jason Green, TransGaming Johan Andersson, DICE/Electronic Arts Jon Leech Mark Kilgard, NVIDIA Nicholas Vining, Destineer Pat Brown, NVIDIA Patrick Doane, Blizzard Robert Barris, Blizzard Ryan Gordon, Destineer Scott Nations, NVIDIA Yanjun Zhang, S3 Graphics Jeff Bolz, NVIDIA Jeff Juliano, NVIDIA Jon Burgess, NVIDIA Mike Marcin


Quite a few people from different industries are all for it and I think it is obvious the majority of the people on these forums want DSA to go core.


One more thing, if OpenGL is that badly designed, controlled by a lazy and incompetent group, and not evolving well with hardware changes, then why are you sticking with it? Why are you on this forum anyway?

They are not lazy and incompetent. They are busy people working for their company. They dedicate a slice of their time to OpenGL.

IMO, GL has evolved quite a bit and very fast starting from GL 3 and onwards. I expect to see DSA to go core.

Janika
05-18-2012, 11:21 AM
I don't know what country you are from, but "Are you nuts?" is not an insult in Canada. It is something one says when they are shocked by what the other person says.

Well regardless of you living in Canada, France or China, it's considered impolite when you say it to a stranger, where I'm from is some Nordic country, so yeah we expect a lot of respect. :)


No, I am not trying to insult or ridicule you just because you very much believe in "bind to modify".

I'm not the one who very much believes in bind-to-modify. It's the ones who kept it around for very long. I just try to give a point that how an API is abstracted should have little impact on performance and quality. This is the job of the driver. Period.


Quite a few people from different industries are all for it and I think it is obvious the majority of the people on these forums want DSA to go core.

Again then why is it not there yet? Who's objecting? Any IPs maybe?


They are not lazy and incompetent. They are busy people working for their company. They dedicate a slice of their time to OpenGL.

Ok now I see where the problem is.


IMO, GL has evolved quite a bit and very fast starting from GL 3 and onwards. I expect to see DSA to go core.

And that would be awesome, I cannot wait to see it core. But does this mean bind-to-modify will be around for "backward compatibility?" I mean if this is the case, how would you trust a lazy driver not implementing DSA on top of a pre-existing bind-to-modify path?

aqnuep
05-18-2012, 12:25 PM
I'm not the one who very much believes in bind-to-modify. It's the ones who kept it around for very long. I just try to give a point that how an API is abstracted should have little impact on performance and quality. This is the job of the driver. Period.
The job of the driver is to provide applications an API that they can use to access the underlying hardware. It can be an API with very high level abstraction or it can be a very low, close-to-the-metal abstraction. It's not the job of the driver to create functions like Enable(MY_FAVORITE_RENDERING_EFFECT) or DrawObject(myFavoriteModelFormat), etc. This is the job of a 3rd party framework/library/engine. It's already sad that OpenGL has a lot of fixed function features that don't have anything to do in a driver, but should be part of a high level framework built on top of it. We don't need any more of these. glBegin/glEnd, glLight*, glTranslate*, glRotate*, etc. are all just convenience functions that could be implemented as part of a 3rd party library that uses only GL3+ core features. Actually, there are even existing libraries (http://www.artifactgames.de/FILES/START.PHP?where=GLIM.PHP) that try to address this.


And that would be awesome, I cannot wait to see it core. But does this mean bind-to-modify will be around for "backward compatibility?" I mean if this is the case, how would you trust a lazy driver not implementing DSA on top of a pre-existing bind-to-modify path?
A lazy driver can implement DSA on top of bind-to-modify path no matter whether bind-to-modify path is kept or not on the external interface, but obviously it's not the way to go and hopefully nobody does that. Unfortunately, the issue of backward compatibility will be always there, it's there for all software that has a reasonable number of users. There's not much to do about it, but if you write code then you should use core OpenGL.

Alfonse Reinheart
05-18-2012, 12:47 PM
Nonsense. Implementations have to not suck to be fast, but that doesn't mean that the API has zero effect on performance. Bad APIs can very easily induce performance difficulties.
Do you even have an idea how drivers work?

Um, wait a second. You said this, not two lines later:



Which, incidentally, is a very good example of how a poor API can ruin performance.
I agree. DirectX is a very good example.

Hypocrisy much? You can't have it both ways. Either drivers can hide inefficiencies caused by bad APIs or they can't. Either your statement that APIs don't affect performance is nonsense, or it's correct and DirectX doesn't ruin performance.


No matter how you disagree with others you should still show some respect, and act politely.

:D I love it when people try to act innocent about being attacked in these cases.

Allow me to give you some choice quotes of yours:

- "Do you even have an idea how drivers work?"

- "Your prophet got it right, we cannot argue with that anymore."

- "Could you please stop being 100% sure all the time?"

- "as everyone who is really concerned with OpenGL knows"

None of these statements is respectful of anyone. Respect is a two-way street; you won't get any if you don't give it.

BTW, as for not "being 100% sure all the time", that's not how it works. If you want someone to respect your position, you have to actually have one. You have to make an actual argument, a case for your position. Thus far, your position has been nothing more than circular logic: bind-to-modify is right because OpenGL does it.

If you can't articulate a reason why your position is right and your opponent's is wrong (and no, simply declaring them to be wrong doesn't count), then you're not going to convince anybody of anything.


Just try to agree with something they already said in their replies and you will see they change, just to criticize, harshly.

I'll assume that you're talking about me. I replied to mhagain about how bind-to-modify was not a significant burden to performance. And I stand by that argument. But that does not mean I think bind-to-modify is good.

There is a difference between arguing against someone's position and arguing for the opposite. Bind-to-modify is primarily bad because of being a poor API: it forces you to use globals just to talk to objects. It pollutes the global namespace. And so forth. But that doesn't mean that bind-to-modify is of substantial concern for optimizing.

To put it simply, I think bind-to-modify is terrible and should have been removed at the earliest possible convenience of the ARB. But I don't believe that it is a performance issue.


if OpenGL is that badly designed, controlled by a lazy and incompetent group, and not evolving well with hardware changes, then why are you sticking with it?

For the same reason that anyone does anything with something: because it works for their needs. If you need 3D graphics to work on non-Windows platforms, you're going to use some dialect or version of OpenGL.

Believe me: if there were a cross-platform alternative, I'd have jumped ship after the Longs Peak fiasco.


They are not lazy and incompetent. They are busy people working for their company. They dedicate a slice of their time to OpenGL.

No, he had it right the first time; they're lazy and incompetent. You can offer excuses for it, but the fact is that these people couldn't agree on the details of an API after 1.5-2 years of working on it.

That's either laziness or incompetence. Or both. They admitted to still arguing over minute bikeshed issues like whether alpha testing should be around or which state should go into which objects.


I mean if this is the case, how would you trust a lazy driver not implementing DSA on top of a pre-existing bind-to-modify path?

So what if it does? Ultimately, you're always trusting the implementation to not do stupid things.

Remember: DSA is not about performance; it's about good programming practice and being closer to what the hardware's actually doing.

Janika
05-18-2012, 04:35 PM
Who decides what good API from a bad one? How can we judge it? I will tell you from a software engineering perspective only. So no hardware internals and details involved. Guess who? Surprised? This is very true. How? This is very easy.
We need to find a solution. We are struggling. Help please help. Hypocrisy much? Hypocrisy much? The game is over.
Don't forget this, "respect is a two-way street." No way...I'm under attack...
What? You're just acting innocent. I'm 100% sure you all are wrong and bad. I'm 100% sure of this because I'm always 100% right because I'm insulted whenever I find someone opposing, or even agree with me. How dare you???
I cannot accept this anymore. You have to make an actual argument, a case for your position.
You call me stupid? I know what I'm talking about and I have an argument. I always have it this way. Insult. Some Hypocrisy. Period. It does not matter. My goal is to insult and object.
You know what...I had enough, your position has been nothing more than circular logic.
So what?
So...stop it. It's taken personal by others. You should not try to look mean to people
Do you really think people will feel under attack when u say this to them? Hell no. they will attack you harsher and harder.
I know.
Then do you love it?
Actually yes I do. This feeds my...to-be-continued.

mhagain
05-18-2012, 05:22 PM
Who decides what good API from a bad one?

The people who use it. Not the designers of it, not those who have any kind of vested interest in it, but the people who have to use it to try get real productive work done. Nobody else.

Thing is, fundamentally, modern (3.3+) OpenGL is not a bad API. I personally rank it somewhere above D3D9 but below D3D11, and well above prior versions of both. It has some baggage from ancient design decisions that were obviously quite daft, and are long overdue revision, but overall it's quite good.

So why stick with OpenGL? I don't. I use both OpenGL and D3D, and have learned a lot from using both that I wouldn't have done otherwise. I'd recommend that to anyone. There is no reason whatsoever to be tribal/partisan in this; each API has useful lessons for the other, and using both will give you a better appreciation of each (for both bad and good).

Why still bitch about modern OpenGL despite the fact that I have an alternative option and despite the fact that I think it's not that bad to begin with? Because it could be so much better. I want it to be so much better. And it doesn't take any kind of particular genius to see ways in which it could be improved. This is where people saying things like "OpenGL is the API of the gods" or the (in)famous WolfFire blog post are doing OpenGL no favours. Perpetuating the myth that OpenGL as it is represents some kind of pinnacle of awesomeness, where it clearly does not, is neither wise nor good.