Originally Posted by Janika
Your only evidence that the OpenGL way is correct is that... it's the OpenGL way? You're 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.
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?)
Are you on crack? Who said that?You mean that DirectX should have bind to modify like OpenGL has? Are you nuts?
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?
Last edited by Janika; 05-18-2012 at 08:00 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. 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...ate_access.txt
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.
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
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.
------------------------------
Sig: http://glhlib.sourceforge.net
an open source GLU replacement library. Much more modern than GLU.
float matrix[16], inverse_matrix[16];
glhLoadIdentityf2(matrix);
glhTranslatef2(matrix, 0.0, 0.0, 5.0);
glhRotateAboutXf2(matrix, angleInRadians);
glhScalef2(matrix, 1.0, 1.0, -1.0);
glhQuickInvertMatrixf2(matrix, inverse_matrix);
glUniformMatrix4fv(uniformLocation1, 1, FALSE, matrix);
glUniformMatrix4fv(uniformLocation2, 1, FALSE, inverse_matrix);
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.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.
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.No, I am not trying to insult or ridicule you just because you very much believe in "bind to modify".
Again then why is it not there yet? Who's objecting? Any IPs maybe?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.
Ok now I see where the problem is.They are not lazy and incompetent. They are busy people working for their company. They dedicate a slice of their time to OpenGL.
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?IMO, GL has evolved quite a bit and very fast starting from GL 3 and onwards. I expect to see DSA to go core.
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 that try to address this.
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.
Disclaimer: This is my personal profile. Whatever I write here is my personal opinion and none of my statements or speculations are anyhow related to my employer and as such should not be treated as accurate or valid and in no case should those be considered to represent the opinions of my employer.
Technical Blog: http://www.rastergrid.com/blog/
Um, wait a second. You said this, not two lines later:
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.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.
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.Just try to agree with something they already said in their replies and you will see they change, just to criticize, harshly.
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.
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.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?
Believe me: if there were a cross-platform alternative, I'd have jumped ship after the Longs Peak fiasco.
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.They are not lazy and incompetent. They are busy people working for their company. They dedicate a slice of their time to OpenGL.
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.
So what if it does? Ultimately, you're always trusting the implementation to not do stupid things.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?
Remember: DSA is not about performance; it's about good programming practice and being closer to what the hardware's actually doing.
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.
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.
Last edited by mhagain; 05-18-2012 at 05:13 PM.
Posting Permissions
