Vulkan/OpenGL Next Generation Initiative: unified API for mobile and non-mobile devices.

  • Thread starter Deleted member 13524
  • Start date

Not in the current market environment.

With the introduction of Metal, there is absolutely no isv or ihv that is willing to be caught dead without a low-overhead API in mobile.

Which means a low overhead API for everyone. Which means no OpenGL.
 
Which means a low overhead API for everyone. Which means no OpenGL.

Except in the extremely high margin professional and HPC markets where Nvidia has a very dominant position due to companies being reliant on support for OpenGL. If a new OpenGL with a clean break from the past comes about it opens up an opportunity for competitors that currently does not exist.

So the question becomes how lucrative is the very high margin professional and HPC market and is it worth potentially losing that to chase lower margin (but potentially much higher volume) mobile market? Or can Nvidia carve out a high margin niche in mobile by offering high performance SOCs that use older legacy OpenGL that all competitors aren't as good at optimizing for.

Basically it comes down to a possibility for Nvidia to lose much of their dominance in OpenGL with OpenGL NG as there will likely be much greater input from various IHV and ISV members. Versus past OpenGL which is quite well tailored to Nvidia hardware as well as Nvidia having spent much time and money optimizing for it and building hardware for it.

Regards,
SB
 
Basically it comes down to a possibility for Nvidia to lose much of their dominance in OpenGL with OpenGL NG as there will likely be much greater input from various IHV and ISV members. Versus past OpenGL which is quite well tailored to Nvidia hardware as well as Nvidia having spent much time and money optimizing for it and building hardware for it.
http://www.g-truc.net/post-0672.html

On NVIDIA side, the only bugs that I am aware of are long standing GLSL compiler bugs that NVIDIA doesn't seem to want to resolve because that would break applications. A -pedantic option like GCC provides would be more than welcome for these cases as if we write shader on NVIDIA we are pretty guarantee they won't work on others implementations. AMD has worked around this issue by introducing support for the NVIDIA behaviors which is the worse way to resolve it for the ecosystem.
Riccio latest OpenGL driver review seems illustrative. He says nVidia has some OpenGL bugs in their implementation but refuses to fix them for compatibility reasons. nVidia's popularity is forcing AMD to implement the same bugs in their drivers making nVidia's OpenGL implementation the de facto standard.
 
Except in the extremely high margin professional and HPC markets where Nvidia has a very dominant position due to companies being reliant on support for OpenGL. If a new OpenGL with a clean break from the past comes about it opens up an opportunity for competitors that currently does not exist.

So the question becomes how lucrative is the very high margin professional and HPC market and is it worth potentially losing that to chase lower margin (but potentially much higher volume) mobile market? Or can Nvidia carve out a high margin niche in mobile by offering high performance SOCs that use older legacy OpenGL that all competitors aren't as good at optimizing for.

Basically it comes down to a possibility for Nvidia to lose much of their dominance in OpenGL with OpenGL NG as there will likely be much greater input from various IHV and ISV members. Versus past OpenGL which is quite well tailored to Nvidia hardware as well as Nvidia having spent much time and money optimizing for it and building hardware for it.

Regards,
SB

Professional graphics is and has always been a very profitable segment of NVIDIA's business, usually the most profitable one. It's also their most secure source of income, since it's not subject to the kind of competition that Tegra faces or to the cannibalization from APUs that jeopardizes the GeForce business.

NVIDIA will do everything it can to maintain that position, and certainly won't risk endangering it for dubious potential gains elsewhere.
 
http://www.g-truc.net/post-0672.html Riccio latest OpenGL driver review seems illustrative. He says nVidia has some OpenGL bugs in their implementation but refuses to fix them for compatibility reasons. nVidia's popularity is forcing AMD to implement the same bugs in their drivers making nVidia's OpenGL implementation the de facto standard.
The way he talks about it (-pedantic flag), it sounds like Nvidia is more permissive wrt errors in source code that's fed into it.

You can call that a bug if you want, but anyone who would fix that just for the sake being more ideologically pure would be batshit insane.

Microsoft has a tradition of making sure that entrenched bugs are kept in future released to avoid breaking software that depends on it. Nvidia clearly does the same thing. That's just a good business practice.

Can you imagine the fallout if applications that have worked for years start failing? What's the upside of fixing this if the only benefactor would be your competition and nobody else?
 
When I said essentially the same thing - that [post=1848057]Khronos Group should overcome its internal issues and set itself for a total rewrite of OpenGL, or risk being swiftly obsoleted by multi-platform version of Mantle[/post] - I was ridiculed for [post=1848607]reading too much into positive reactions from software developers[/post] (and also for being less than enthusiastic about underdog hardware from Intel).

Looks I was right in that Mantle is really making a substantial impact on the present and future of 3D graphics APIs, but I'm also glad to be proven wrong about Kronos' ability to get their act together.
 
Last edited by a moderator:
but I'm also glad to be proven wrong about Kronos' ability to get their act together.
Whats been bad about their handling of opengl es etc
yes opengl has been held back (though its more advanced than d3d today) but the reasons its been held back are from various members i.e.
first microsoft (until they got booted off) and then nvidia (maintain their dominance or 'serious' gfx)
 
I understand that this OpenGL Next effort is at an early stage, and I'm cautious because [post=1841264]we all remember what happened to the Longs Peak specification[/post], which was blocked by some undisclosed independent hardware/software vendors.

But I'm still impressed that they decided to directly base this effort on Mantle, much like the good old days of IrisGL->OpenGL transition. This should essentially get them a working AMD driver right from the start, so hopefully they will be able to deliver a complete reference implementation this time, not just some abstract spec coupled with experimental lab code.

And if voted down again, at least AMD should be able to use this work [post=1841242]to add cross-platform and cross-vendor capabilities to Mantle, as they originally intended[/post].
 
Last edited by a moderator:
FYI I merged this thread with some OpenGL NG posts from the OpenGL 4.5 thread.

On topic:

It's not just Nvidia though. From what I understand, supporting "legacy OpenGL" is actually a non-trivial task in both hardware and software due to all the random edge cases. I've also heard various mobile ihv's don't really want to spend the resources on providing legacy OpenGL support. But if your hardware and software stack already support legacy OpenGL, this is a nice advantage. It's why Nvidia is trying to bring OpenGL to Android and why they still recommend using the compatibility profile for new OpenGL applications (I also heard amd recommends the same? not sure). I don't blame companies for trying to press this advantage and it's not clear to me why they would give up this advantage so easily. Hopefully they do! :D

And this is sort of the problem with an institution like Khronos. There will always be proposed features that may be beneficial to the graphics industry as a whole but not to ihv x's architecture or bottom line. So then ihv x has a choice between what's best for the industry and what's best for its investors. I suspect the investors often win. Unfortunately we lose. :cry:
 
Well, the most important users (as in: where the money is) of OpenGL on the desktop are probably those who use very expensive engineering software. I don't think they lose by being able to upgrade to the latest and greatest GPUs but still being 100% backwards compatible with their software.

Yes, it's less sexy than being able to deal with rewrite from scratch.
 
The solution seems simple. Have two different drivers. One with all the old legacy bugs and bullshit and one with fresh new well thought-out design and implementation.
 
The solution seems simple. Have two different drivers. One with all the old legacy bugs and bullshit and one with fresh new well thought-out design and implementation.
If only these kind of simple solutions were practical.
 
Why would they not be practical? It's not like the PC Workstation is going to be running a mix of old style and new style applications. Let the old schoool applications that require the old school crap run only that. Let the new school games that require the new school stuff run only that. Face it, they're not going to be mixing the two styles at the same time.
 
Actually, this is exactly how it's like.

Really? Because I don't see that happening at all. Perhaps on the developer workstations, but that would only be on the debug stations, right?
 
Really? Because I don't see that happening at all. Perhaps on the developer workstations, but that would only be on the debug stations, right?
I've personally seen cases a company was running old mechanical software on one hand because it did the job, yet on the other hand did the new design work on contemporary software. This was pure mechanical engineering: use SolidWorks for design entry, use old software for industry specific back-end manipulation. Say: converting design for an existing CNC machine that was once state-of-the-art. Software does the job and has been paid for. Why upgrade?

I imagine that this must be a pretty common situation.

We laugh when we think about the state of OpenGL 10 years ago, but 10 year is really not that long when you look at the lifetime of many big machines.

Also, I'm convinced that even new software gets still written in early OpenGL: say, again, some mechanical engineering package. It doesn't need all the fancy rendering stuff like shaders etc. The front-end visualization works fine with simple Phong shading. The new versions add analysis features, nothing graphics related.

Why rewrite all that for a new clean standard with features that aren't needed anyway?
 
Surely all software using OpenGL now falls under the legacy path, right? So it would only be the OpenGL NG titles, likely to be the actual games that fall under the new path.

Also, I'm not saying any of that existing software should or needs to be rewritten, hence my push for a dual-path situation. The only items I see pushing for new and improved would be the actual games engines and perhaps the built-in development tools that entitles. This seems like a nearly perfect opportunity to have a clean break.
 
Except in the extremely high margin professional and HPC markets where Nvidia has a very dominant position due to companies being reliant on support for OpenGL. If a new OpenGL with a clean break from the past comes about it opens up an opportunity for competitors that currently does not exist.

So the question becomes how lucrative is the very high margin professional and HPC market and is it worth potentially losing that to chase lower margin (but potentially much higher volume) mobile market? Or can Nvidia carve out a high margin niche in mobile by offering high performance SOCs that use older legacy OpenGL that all competitors aren't as good at optimizing for.

Basically it comes down to a possibility for Nvidia to lose much of their dominance in OpenGL with OpenGL NG as there will likely be much greater input from various IHV and ISV members. Versus past OpenGL which is quite well tailored to Nvidia hardware as well as Nvidia having spent much time and money optimizing for it and building hardware for it.

Regards,
SB
There is no tradeoff here.

IHVs will simply have 3 (dx, ogl, oglng) instead of 2 drivers.
 
Back
Top