Ugly Core Profile Creation

[thokra]

The ARB *SHOULD* write code for us. The future of OpenGL depends on it.

And what would you have them write?

An official function loader? Simply not necessary as there are tons of loaders out there. Use Alfonse's one, use GLEW, use gl3w - if none of these seem to provide what you need, you can get query whatever function pointer you need at runtime yourself or do what Alfonse suggested, submit bug report or patches and do something for the community if you feel that the community doesn't get what it needs with the current products. BTW, stating that GLEW is outdated is simply not true as it fully supports compat and core OpenGL 4.2. If you need up to date extension function pointer, just query what you need yourself. It doesn't mean you have to rewrite everything under the hood just because one or two vendor-specific extensions are not yet supported.

What else? An official implementation? Something equivalent to XNA? Other arbitraty libraries providing functionality based on the API?

I still fail to see the point.

OpenGL faces D3D. Which works. out of the box. [..] OpenGL doesn't.

It does? Without any actions by IHVs? Out of the box? Just by installing Windows? Why doesn't OpenGL work that way?

No fucking around.

Good point. Then please stop doing that and explain your claims instead of just shoving them down out throats and giving us unwarranted face palms.

[Janika]

Let me make my point clear. First I'm saying I want to roll my own GL function loader because other existing libraries cannot do the job. However I tried GLEW and there's a known issue with it when used with 4.2 core profile, it calls some deprecated function.
As suggested I could report or even correct the problem myself but I thought of the amount of work and decided to write my own library, at least something I fully understand and maintain. Running my own was even more painful process as I has to extracts the relevant definitions, types, and function names from ARB ancient messy headers that clutter old and new functionality all together. Whether I could accomplish it or how, or should I make it public or use others attempt is not the point. The point is why on earth a client of the library has to write their own? Whether it's me, John, Dave, Sandra, ...or the existing loader creators, why we wanted to write our own regardless of make it public or private??? IHVs implement the API but they don't define values and headers, they just implement existing stubs. So you telling me the library client should either shove it up their throats and use whatever is there or write their own??? Do you guys forget that a library should always provide a clean interface to the client? Software Engineering 101??? Helloooo???

And yeah please don't argue with me about why using core or mixed profiles. This is something the system requirements decide. If using core profile has no advantage then scrap it and get everything in one big messy ball. This probably will make our life easier.

BTW can anyone name some real professional applications that use OpenGL functionality beyond 2.1?

If you cannot make your recent library features easily accessible then you will find no consumers. Imagine a gaming console that's very powerful but users have to in stall and fix ports themselves so that they can plug in their game controllers to it. Do you think anyone will bother use it except for the gang who created it? Get the point???

[menzel]

Yes, GLEW on core is broken, but it's not too hard to fix AND there are alternatives. Yes, you might need to use core (MacOS X). Rolling your own extension loader is not the simplest solution to replace GLEW as other alternatives exist, thats all that was said.

Yes, a cross-plattform ARB loader would be nice but history tells us it's not going to happen, no need to argue with the persons on this forum about it! If you like, file a bug report: https://www.khronos.org/bugzilla/ .

I can't tell you which 'professional' applications use OpenGL > 2.1 as I don't know what you define as 'professional' (there are some 3.2 games but sticking with 2.1 might have more to do with sticking with DX9 due to consoles as anything else...).

[thokra]

If using core profile has no advantage then scrap it and get everything in one big messy ball.

The theory is that it could have. However, to date there is no indication that using a core profile context actually gives you a noticeable advantage in regards to rendering performance - neither with AMD nor NVIDIA hardware (Intel ... well... ARM, don't know.). If such proof is out there, please, please, share your findings.

As suggested I could report or even correct the problem myself but I thought of the amount of work and decided to write my own library, at least something I fully understand and maintain.

You think the amount of work fixing the dysfunctional (depending on the way you look at it) part of GLEW like stated in the corresponding ticket is more work than implementing a complete library from scratch? Really? It is beyond me why this admittedly quite simple fix isn't in yet but there you go, a few lines of code fix the whole problem. Yet you want to do it from scratch. So, I continue to state: I fail to see the point. I don't want to degrade your efforts but I can't help but feel that you're wasting your time and, if this is work done for a customer, you're also wasting money.

Running my own was even more painful process as I has to extracts the relevant definitions, types, and function names from ARB ancient messy headers that clutter old and new functionality all together.

If you realized that, why would you stick with your approach then? This completely contradicts your assumption that writing your own stuff is easier and saves you something.

Helloooo???

Hey there!

And yeah please don't argue with me about why using core or mixed profiles. This is something the system requirements decide.

True. I just don't see why such a requirement would be made by anyone knowing what they're talking about. Again, you can write perfectly fine core GL code without a core context. Again, it has yet to be proven that a core context actually has real benefits.

[Janika]

However, to date there is no indication that using a core profile context actually gives you a noticeable advantage in regards to rendering performance - neither with AMD nor NVIDIA hardware (Intel ... well... ARM, don't know.). If such proof is out there, please, please, share your findings.

Again, it has yet to be proven that a core context actually has real benefits.

Could you please tell me why it's there then? I'm not saying that I've found any benefits from using core profile, but I'm basing my argument on that fact that there's a core profile, and hence assuming a separate render path which theoretically should be faster.

I can't tell you which 'professional' applications use OpenGL > 2.1 as I don't know what you define as 'professional' (there are some 3.2 games but sticking with 2.1 might have more to do with sticking with DX9 due to consoles as anything else...).

Professional is simply judged by how much it costs? So we cannot consider that GL screen saver, free molecule visualizer, or Tettris clone... as valid examples.
I would like to hear something like Maya, Softimage, 3DS Max, ZBrush, Lightwave3D, Chief Architect, and other CAD/CAM high end software.

I'm very familiar with some replies I will get, "Will never happen," "Don't complain to us," "They don't care," "Use Direct3D," ...etc. I'm saying it now and I've been always trying to make it clear that I'm not complaining to you, when I write here about a problem I'm trying to make it clear to ARB ppl that, sorry to say this, your move beyond version 2.1 was a horrible mistake, at least the design is just incompetent. Unless you are an ARB member you should have no prob with this.

[thokra]

Could you please tell me why it's there then? I'm not saying that I've found any benefits from using core profile, but I'm basing my argument on that fact that there's a core profile, and hence assuming a separate render path which theoretically should be faster.

Theoretically that may be true. Using a core context does have a meaning. For instance, using legacy functions when a context is current will generate an error, so you can enforce a policy, i.e. to only use core functions. Also, you loose unnecessary buffers like the accumulation buffer and auxiliary buffers but that's not again either because you're not forced to use them with a compat context either. The fact seems to be that no IHV which implements the core profile does actually provide such an optimized core path. I have yet to see a performance gain on either GeForce or Radeon with a core context - so I assume it simply isn't there. Can't speak about Apple and Intel is ... well, Intel. This is not to say that writing core conforming applications isn't advisable - quite the contrary. Nowadays I'd always go for that. Granted, there are some extensions which give you useful tools but aren't necessarily completely core conforming, like GL_EXT_direct_state_access.

We got some employees of both major companies here so maybe the guys can garnish this discussion with a little more technical foundation and insight.

Unless you are an ARB member you should have no prob with this.

Since this is an open discussion forum, it's up to the reader to decide what's relevant to them and what's not. Some may simply ignore it but some may simply object because they feel something isn't portrayed correctly. Personally I like to see inaccuracies being dismantled by experienced members of the community - especially my own mistakes, simple because it widen my horizon in some cases.

[..]your move beyond version 2.1 was a horrible mistake, at least the design is just incompetent.

I think very few would disagree that compared to GL 2.1, GL 4.2 is a huge step into the right direction. Legacy GL is what's horrible. Yes, we all know the countless discussion about how the spec is imperfect and how it would be much better to do this and do that to improve it but IMHO GL4 is a much, much better API. Why do you feel that GL3+ was a horrible mistake to make?

[Janika]

Why do you feel that GL3+ was a horrible mistake to make?

The idea of keeping legacy stuff by means of compatibility profiles shows that the ARB was not so confident about the new API.

[Alfonse Reinheart]

Unless you are an ARB member you should have no prob with this.

My problem with this is that you're using our forum to talk to people who may well not be paying attention to it. Or to put it another way, your words will only possibly be read by the people you actually are complaining to, while they will certainly be read by the people you're not complaining to. How does that make sense?

If you want to talk to the ARB directly, the Khronos Group's website has contact information. In short, use the proper channels to talk to the people you want to talk to.

The idea of keeping legacy stuff by means of compatibility profiles shows that the ARB was not so confident about the new API.

You say that as though it was the ARB's idea and not NVIDIA shoving it down their throats. They publicly spoke out against deprecation and removal and basically sandbagged any effort to force people to upgrade by saying that they would support legacy stuff in perpetuity. After that, there wasn't much choice except to create the compatibility profile, since it was going to be a de facto construct anyway.

[Aleksandar]

The idea of keeping legacy stuff by means of compatibility profiles shows that the ARB was not so confident about the new API.

It is not a short story that can be told in a few sentences here, in the forum. The period from the late 2006. and August 2008. was a very dramatic one considering OpenGL and it's perspective for further development. Unlike D3D, OpenGL is a standard developed by a consortium. New hardware, a more efficient rendering and a decade old API with hundreds of functions and multiple paths to accomplish the same thing were arguments to cut down drivers and make them more efficient ("lean and mean"). But, on the other hand, there were a lot of "strong players" with products based on legacy OpenGL code and years of good reputation and tons of code that would be thrown away instantly with the radical change in the API. Forces for leaving support for the legacy API prevailed. That's how profiles are born.

Since drivers have to support both core and compatibility profiles, there is little chance to make significant difference in the performance yet. If you are making a software that needs some functionality don't hesitate to use compatibility profile. Your users will not be aware of it, but they will certainly notice lack of visual elements. If you need clear path and want to squeeze better performance, use core profile and follow your own way to the solution.

[mbentrup]

Since drivers have to support both core and compatibility profiles

AFAIK drivers have to support core only, compatibility is optional.

I think the whole point of the core profile wasn't to make it easier for OpenGL users but for OpenGL implementors. As many already pointed out, you can use all the core functions in a compatibility context too. If you don't use e.g. stipple patters in your application, the fact that there exist stipple functions in a compatibility context doesn't mean that you suddenly have to change your code to make it work.

Performance wise I wouldn't expect a major difference between core and compatibility profiles even if they were implemented as separate drivers. After all memory bandwidth, shader execution speed etc. will be the same. Granted the core only driver may have some opportunities to optimize object creation etc., but those costs are usually one-time costs that (for most applications) don't affect the rendering loop at all.

The real benefit of the core profile is to make it easier to implement a GL3+ driver, without having to care for all the legacy quirks in OpenGL. That also explains why those who already invested into developing drivers which can support all the legacy code have no interest in pushing users to the core profile.