When IHVs find a good specification they will respond somehow. But I see your point, as always, do nothing because no body care. And please don't speak on behalf of others, I bet there are many driver developers on this forum, who post regularly, and ARB members as well. Or maybe someone from Microsoft who will adopt this idea who knows
Cannot be more terrible than the existing hack.In short: all of this API is terrible.
The existing hack, for all that it is terrible (let's not kid ourselves over that one) has this much going for it:
It works. It's been proven to work over the history of OpenGL programs on Windows. There is a significant existing codebase that uses it.
Personally I don't mind it. It allows different platforms to have the ability to implement OpenGL in the manner that best suits the platform, rather than trying to shoehorn things into a misguided "one size fits all" approach. A classic example would be the ability to implement OpenGL in cases where the client and server are two different machines. That's mostly appropriate to only one platform, so why should other platforms that don't have this ability have to take on the baggage required to implement it in a hypothetical cross-platform cross-vendor solution? Or why should the platform that currently supports this ability have to lose it in the same scenario? The answer to both questions, by the way, is "they shouldn't".
It's also a pipe-dream of mine that maybe one day MS will layer OpenGL on top of DXGI. I know it'll never happen, but it would be awesome.
Seriously, by this point in time you've developed a huge obsession over something that is already a solved problem for at least 99% of other OpenGL programmers on the planet. You want a solution that targets your own very specific problems and ignores everything else. Including the existing working codebase. The code is ugly for sure, but you write it once, you reuse it every other time you need it, and you get over it and move on.
I know! How about no? I'm sorry I can't give more productive input on the matter but that's simply because I really don't think anyone can.Originally Posted by Janika
Then this is unfortunate. Our only hope is just to sit and pray to God.
Oh wait i just remembered something...was it GS...instancing...where the word "NO" came from the same ppl???
No worries.I'm sorry...
There are differences here that you're ignoring. The rationale behind instancing was not clearly understood at first; see http://www.opengl.org/archives/about...004-09-21.html and http://www.opengl.org/archives/about...004-12-07.html for further elaboration on that one (basically the idea was that you'd make an immediate mode call to set per-instance data, then a vertex array/VBO call to draw the object, which was kind of completely missing the point). Geometry shaders are crap anyway; more a case of a solution looking for a problem and never very well implemented in hardware, with only one use case (expanding points to quads for a particle system) being any way viable, and even that being slower (owing to having to have an extra shader stage active) than just sending and individually transforming all 4 verts for a quad. A clear case of it being correct to say "no".
The main point is that OpenGL specifies itself as a rendering API, and only as a rendering API. It does not specify any windowing system interaction, never has, that's always been left to be implemented in a platform-specific way for each platform and by those responsible for each platform. (Curious aside - even D3D has pulled windowing system interaction out of the main API in more recent versions.) So you're not comparing apples to apples; features that are appropriate to be added to a rendering API may eventually get added to it, even if an initial answer is "no". Features that are appropriate to a windowing system layer will not.
Like I said before, this is a really odd obsession for you. Write the code once, reach for a sick-bag when done, get over it and move on. You're better off spending the time being productive.
Or you could just write the initialization code. Really, it's like 20 minutes of your time. You have literally spent more time arguing about it than it would take to actually implement.Then this is unfortunate . Our only hope is just to sit and pray to God.
Even better, you could employ the many, many cross-platform alternatives.
Seriously, what exactly bothers you about this? Yes, it's ugly; we get that. But it's not going to change just because we want it to. So you need to decide which is more important to you: that all of your code is pretty, or that you're getting something done with OpenGL? If you want the latter, then pick one of the available alternatives.
Nonsense. GS's are vital for layered rendering, which allows you to send rasterized triangles to different render targets. Very handy for things like cube-based shadow maps for point lights.Geometry shaders are crap anyway; more a case of a solution looking for a problem and never very well implemented in hardware, with only one use case (expanding points to quads for a particle system) being any way viable, and even that being slower (owing to having to have an extra shader stage active) than just sending and individually transforming all 4 verts for a quad. A clear case of it being correct to say "no".
Of course, AMD decided that this was a stupid use for an entire shader stage and created AMD_vertex_shader_layer and AMD_vertex_shader_viewport_index. Both of these, coupled with instancing remove the need for most uses of GS's.
That's more or less true. But I wouldn't consider GS's useless just because of these AMD extensions. GS is useful for a lot of other stuff.
One example is shadow volume generation. Yes, I know that stencil shadows are too old-school, but that's not the only thing shadow volumes could be useful for.
Another thing is that GS based layered rendering is still useful as if your vertex shader is doing quite some work or even worse, if you use tessellation, you probably don't want the same task to be done for each layer/instance as probably the GS overhead might still be less than that.
Not to mention the non-rendering specific stuff, like geometry shader based culling using transform feedback. Yes, I know that now you could use atomic counters and image stores to kind-of "emulate" 1:N transform feedback in a vertex shader, but that's still not the same as append buffers (i.e. image stores routed by atomic counters) don't preserve primitive order while GS + transform feedback does.
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/
I wouldn't say that they were useless. Just that 90% of the practical uses of them are covered.But I wouldn't consider GS's useless just because of these AMD extensions.
EGL 1.4 (with EGL_KHR_create_context) specifies how to create OpenGL contexts with all the options that wGL offers, so the lack of a suitable API specification is not the reason why we have to live with the current mess.When IHVs find a good specification they will respond somehow. But I see your point, as always, do nothing because no body care. And please don't speak on behalf of others, I bet there are many driver developers on this forum, who post regularly, and ARB members as well. Or maybe someone from Microsoft who will adopt this idea who knows
The reason is that wGL and opengl32.dll exist and work and thousands of applications depend on them. Sure it would be nice to get an update to wGL to support modern OpenGL better, but unfortunately wGL is not an ARB spec, but is owned by Microsoft, and Microsoft hasn't shown any interest in improving wGL for a decade or so.
If Microsoft ever drops wGL/opengl32.dll completely (which I don't believe), I'm sure the IHVs will quickly settle on a EGL based way to access OpenGL.
Technically, they've already done that. If you're writing a Metro app using WinRT windowing functions, you can't use OpenGL. Of course, if you're doing that, you can't do a lot of things, like create HWNDs, etc.If Microsoft ever drops wGL/opengl32.dll completely (which I don't believe), I'm sure the IHVs will quickly settle on a EGL based way to access OpenGL.
If WinRT (the OS) takes off and Microsoft continues to support ARM as a separate Windows platform, then this might be important.
AMD implemented EGL, but only for getting ES 2.0 contexts (due to the lack of provisions in EGL for getting desktop GL contexts, outside of an extension).
Posting Permissions
