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

[mczak]

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'd be VERY surprised if it's true that AMD recommends compatibility contexts.
The interactions between newer (core context) and legacy (compat context) features range somewhere between completely undefined and batshit crazy. For that reason alone mesa does not (and most likely never will) support ARB_compatiblity.
Sure you can make it work somehow - it should be ok if you don't actually mix new features with old ones "too much" (so, only mix things which have at best "obvious" interactions).

 

[Silent_Buddha]

There is no tradeoff here.

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

There is, right now for games there is DX (competitive hardware from 2 vendors) and OGL (basically one hardware vendor only, Nvidia).

In professional and workstation there is only OGL really with only really one viable vendor (Nvidia) for many companies.

With OGLNG that would supplant OGL for new games making potentially DX and OGLNG with potentially multiple competitive IHVs. On the professional side OGL will still dominate, but it will slowly die out as OGLNG matures, meaning the potential would open up for a serious competitor to Nvidia in that space.

So, again, what does Nvidia stand to gain from OGLNG? Not much to gain with the potential to lose marketshare. What does Nvidia stand to gain from everyone using just slightly updated OGL? Everything.

I'm sure Nvidia aren't the only ones in that situation. There's likely quite a few entrenched professional software ISVs that would prefer not to give any upstart ISVs a potential opening in the high margin professional and HPC world.

If forced into it, Nvidia and other entrenched OGL IHV/ISVs will adapt and make the most of it. But I'm fairly sure they'll do whatever they can to derail it or delay it.

Regards,
SB

 

[DmitryKo]

You all are referring to OpenGL as if it was a single coherent API set like Direct3D, when in reality it has become an open set of extensions each tailored for some specific hardware features. Even Nvidia's OpenGL driver comes in two specific flavours - one for professional cards, and another one for gamer cards, with different sets of extensions and different optimization paths.

The point is that OpenGL NG will be a completely different, incompatible API, probably to the point of being linked to a different binary file, and not just another extension or compatibility profile.

So for example AMD display driver for Windows will come with:

I. Core Windows display driver:
1a. DXGI 1.x kernel-mode driver
1b WDDM 1.x user-mode driver (D3D9/10/11 DDI)
or
1c. WDDM 2.0 user-mode driver (D3D12 DDI on Windows 9)

II. Display driver extensions (user-mode DLLs):
2. OpenGL ICD ("legacy" 4.x )
3. Mantle
4. OpenGL NG
5. OpenCL
6. HSA
7. DXVA
8. GPUPerf
9. ???

 

[DmitryKo]

SIGGRAPH slides:
http://www.extremetech.com/gaming/1...-cross-platform-mantle-killer-dx12-competitor
http://www.anandtech.com/show/8363/khronos-announces-next-generation-opengl-initiative

Next Generation OpenGL Initiative

* Ground up design of open standard for high-efficiency access to graphics and compute on modern GPUs!

- Fast-paced work on detailed proposals and designs are already underway​

* Explicit application control over GPU and CPU workloads

- High performance and predictability​

* Multithreading-friendly API

- Greatly reduced overhead​

* Common shading language intermediate representation

- Simpler than a source language to improve shader reliability and portability
- Good target for machine-generated shaders and high-level languages
- Some IP protection for shader authors as don't have to ship shader source
- Can use common compiler front-end across multiple platforms​

Motivations

* GPU architecture has evolved a long way since OpenGL was first conceived

- API redesign to bring modern GPU access to all platforms​

* 3D capable platfroms proliferating - Mobile, desktop, web, embedded, cloud

- API for developers to easily deploy on diverse platforms becoming more urgent​

* Increase cross-vendor protability / reliability

- More streamlined API is easier to implement and test
- Standard intermediate language improves portability of shader programs
- Enhanced conformance testing methodology​

 

[Osamar]

I see this way easier for IHVs
- Display driver extensions (user-mode DLLs):
1. OpenGL NG with OpenGL ICD ("legacy" 4.x ) warpper on top
2. ???
3. ???

 

[BRiT]

Nope, easiest for IHV is to not change or do any work at all on the legacy OpenGL. Just cut it loose and only touch it for major bug fixes. Making it a layer on top of OpenGL NG sounds like hell and extremely painful and a total waste of engineering time to develop and test.

 

[DieH@rd]

Nice plans for new OpenGL, but I don't see this implemented anytime soon.

 

[DmitryKo]

I see this way easier for IHVs
1. OpenGL NG with OpenGL ICD ("legacy" 4.x ) warpper on top

How exactly would this be easier when OpenGL NG will have almost nothing in common with OpenGL 4.x?

Proprietary user-mode components like Mantle and OpenGL ICD talk directly to the display driver - that's far closer to the actual hardware than what D3D12, Mantle or OpenGL NG would ever be able to expose. There is no lowest common denominator in the form of a standard cross-vendor API, like DXGI, D3D10 DDI, or DXVA, so they can change the internal APIs and IOCLTLs back and forth as they deem fit.


And actually, since [post=1841448]D3D12/WDDM 2.0 does not depend on a kernel-mode display driver anymore[/post], with Windows 9 there comes the opportunity for vendors to refactor their display drivers to move all low-level resource management code to user mode components. This would probably make it easier for them to handle the legacy APIs in the long run.

Maybe they should even let Khronos handle most of the actual API code and the cross-platform shader compiler infrastructure, much like Microsoft does with Direct3D.

 

[rpg.314]

There is, right now for games there is DX (competitive hardware from 2 vendors) and OGL (basically one hardware vendor only, Nvidia).

In professional and workstation there is only OGL really with only really one viable vendor (Nvidia) for many companies.

With OGLNG that would supplant OGL for new games making potentially DX and OGLNG with potentially multiple competitive IHVs. On the professional side OGL will still dominate, but it will slowly die out as OGLNG matures, meaning the potential would open up for a serious competitor to Nvidia in that space.

So, again, what does Nvidia stand to gain from OGLNG? Not much to gain with the potential to lose marketshare. What does Nvidia stand to gain from everyone using just slightly updated OGL? Everything.

I'm sure Nvidia aren't the only ones in that situation. There's likely quite a few entrenched professional software ISVs that would prefer not to give any upstart ISVs a potential opening in the high margin professional and HPC world.

If forced into it, Nvidia and other entrenched OGL IHV/ISVs will adapt and make the most of it. But I'm fairly sure they'll do whatever they can to derail it or delay it.

Regards,
SB

It will take a decade or more for professional sw to migrate from ogl to oglng, even if they decide to do that. There is no reason to do that, actually, current sw works fine. IF nv doesn't support oglng, they would lose current customers, a big no-no.


If nv decides to stall the oglng effort, the rest can see through the bs and form a new group excluding nv. The rest don't have any attachment to professional ogl but want to sell stuff in non-pro markets.

Making new professional graphics sw is a lot more that just API, so I don't see any reason for an isv to interfere with oglng. As it is, there are no pro graphics isv's in the oglng working group.


All in all, I don't see any business reason for anyone to stall oglng but plenty of reasons for everyone to want this.

 

[rpg.314]

How exactly would this be easier when OpenGL NG will have almost nothing in common with OpenGL 4.x?

Proprietary user-mode components like Mantle and OpenGL ICD talk directly to the display driver - that's far closer to the actual hardware than what D3D12, Mantle or OpenGL NG would ever be able to expose. There is no lowest common denominator in the form of a standard cross-vendor API, like DXGI, D3D10 DDI, or DXVA, so they can change the internal APIs and IOCLTLs back and forth as they deem fit.


And actually, since [post=1841448]D3D12/WDDM 2.0 does not depend on a kernel-mode display driver anymore[/post], with Windows 9 there comes the opportunity for vendors to refactor their display drivers to move all low-level resource management code to user mode components. This would probably make it easier for them to handle the legacy APIs in the long run.

Maybe they should even let Khronos handle most of the actual API code and the cross-platform shader compiler infrastructure, much like Microsoft does with Direct3D.

AFAIK, Opengl does not follow WDDM.

 

[3dcgi]

There is, right now for games there is DX (competitive hardware from 2 vendors) and OGL (basically one hardware vendor only, Nvidia).

In professional and workstation there is only OGL really with only really one viable vendor (Nvidia) for many companies.

You're entitled to your opinion, but despite having lower market share than Nvidia AMD FirePro has many customers. So there are many that think there are two viable workstation vendors.

 

[silent_guy]

You're entitled to your opinion, but despite having lower market share than Nvidia AMD FirePro has many customers. So there are many that think there are two viable workstation vendors.

But is AMD on its own viable enough to justify writing software for it exclusively?

 

[Andrew Lauritzen]

AFAIK, Opengl does not follow WDDM.

Everything has to go through WDDM to draw on the swap chain, etc. And the OS owns the GPU memory on Windows, so that includes OpenGL. See for instance:
http://msdn.microsoft.com/en-us/library/windows/hardware/ff568606(v=vs.85).aspx

 

[3dcgi]

But is AMD on its own viable enough to justify writing software for it exclusively?

I don't know, but there could be some niche cases. For example, Visual Effects studios like Dreamworks and Pixar write custom animation software. If a company like these settles on one hardware vendor for a period of time they might be willing to use a custom API. Plus, it's probably less work to use a custom API than to write an entire program in a custom language like CUDA yet companies use CUDA.

I was replying to SB's assertion that AMD wasn't viable for OpenGL. AMD might have lower marketshare than Nvidia, but is still a viable competitor.

 

[Dave Baumann]

As reported, workstation ISVs are already looking at Mantle, so clearly there is interest in the FirePro space from the software side.

 

[rpg.314]

Everything has to go through WDDM to draw on the swap chain, etc. And the OS owns the GPU memory on Windows, so that includes OpenGL. See for instance:
http://msdn.microsoft.com/en-us/library/windows/hardware/ff568606(v=vs.85).aspx

Thanks for letting me know.

 

[iroboto]

Valve will unveil glNext at GDC [Mar 2-6] 2015

http://news.softpedia.com/news/Valv...or-That-Will-Change-Linux-Gaming-472103.shtml

 

[DmitryKo]

http://schedule.gdconf.com/session/glnext-the-future-of-high-performance-graphics-presented-by-valve

glNext: The Future of High Performance Graphics (Presented by Valve)
Johan Andersson | Technical Fellow, Electronic Arts, Frostbite Engine Team
Pierre-Loup Griffais | Developer, Valve Software
John McDonald | Developer, Valve Software
Niklas Smedberg | Senior Engine Programmer, Epic Games
Dan Baker | Graphics Architect, Oxide Games
Aras Pranckevicius | Graphics Architect, Unity Technologies
Tom Olson | Chair of the Working Group, Khronos

Date: Thursday, March 5
Time: 10:00am - 11:00am

Join us for the unveiling of Khronos' glNext initiative, the upcoming cross-platform graphics API designed for modern programming techniques and processors. glNext will be the singular choice for developers who demand peak performance in their applications. We will present a technical breakdown of the API, advanced techniques and live demos of real-world applications running on glNext drivers and hardware.

 

[Dominik D]

So it looks like it's called Vulkan.

https://www.khronos.org/vulkan
https://www.khronos.org/news/press/...-high-efficiency-graphics-and-compute-on-gpus
http://blog.imgtec.com/powervr/trying-out-the-new-vulkan-graphics-api-on-powervr-gpus

 

[AlexV]

So it looks like it's called Vulkan.

https://www.khronos.org/vulkan

Shade long and render. Albeit in this case it is more a case of "when all you have is a graphics API, everything looks like a pixel" (consider Vulcan's role in Roman mythology and his preferred tool).