NVIDIA: DirectX 12 will support unannounced features on future graphics chips

Microsoft officially announced DirectX 12 last week at the Game Developers Conference, and said the upcoming revamp of their graphics API would work on a lot of hardware that's already available, such as the Xbox One game console, along with many current NVIDIA and AMD GPUs for the PC. However, the first games that will fully support DirectX 12 won't be released until "holiday 2015".

That means both NVIDIA and AMD will be releasing new graphics chips in their GeForce and Radeon lines, respectively, between now and when DirectX 12 is launched. The Tech Report got a chance to chat with NVIDIA spokesperson Tony Tamasi, who said that while DirectX 12 will add things like lower-level abstraction to current graphics hardware, it will also include a number of features that will only be supported on future GPUs.

Two of them are new blend modes and "conservative rasterization", which will help improve hit detection in games. However, Tamasi indicated that Microsoft has a number of other unannounced DirectX 12 features that will also only work on upcoming GPU hardware.

In the meantime, the company is already accepting sign ups from developers to participate in a DirectX 12 early access program, with a preview version of the API scheduled to be released later this year.

Source: The Tech Report | Image via Microsoft

Report a problem with article
Previous Story

Blackberry OS 10.3 screenshots leaked, leaked OS now available for Z10

Next Story

White developer Xbox One Day One console currently on eBay

35 Comments

View more comments

duddit2 said,
for hardware independent features you kind of need the hardware the features depend on
Didn't you mean "dependent"?

This was probably supposed to be out for the xbox one, which was probably supposed to be released in November of 2014. And if this is as big of an update as they say, it would fix the frame rate disparity the xbo currently has.

greenwizard88 said,
This was probably supposed to be out for the xbox one, which was probably supposed to be released in November of 2014. And if this is as big of an update as they say, it would fix the frame rate disparity the xbo currently has.

Doubtful since consoles are already made with low level access in mind. The big performance improvement will be on PC.

Luc2k said,

Doubtful since consoles are already made with low level access in mind. The big performance improvement will be on PC.

they stated improvements are also for XB1 so let's not get carried away with the low level access they have. It will just get better. so many people dismissing what they already said.

It's good that DX12's improvements aren't focused entirely on software optimisation / consoles. That said, it really comes down to what the hardware features add to the gaming experience - it really needs to be at least as substantial as DX11's tessellation for it to be worthwhile.

Hopefully the multi-platform nature of DX12 will lead to PC games implementing it sooner rather than later, as DX10 had extremely slow adoption and DX11 was only marginally better. Afterall, there's no point implementing DX12 for the XB1 and then not including it for PC.

I knew the fact they won't have those API ready immediately after that announcement and mantle really done a good job for making it available one year ahead of other API and ensuring the next version of DirectX and OpenGl will be heavily optimized for PC rather than console. AMD deserved some applause for helping out mitigate the excruciating pain that majority of game flat out just ported to PC without consider taking advantage of the incredibly powerful GPU. The days of getting diluted games for PC are almost going away.

Edited by Master of Earth, Mar 24 2014, 2:09pm :

Master of Earth said,
The days of getting diluted games for PC are almost going away.

ha. that has been the claim since...they have been making claims.

"NVIDIA: DirectX 12 will support unannounced features on future graphics chips"

funny. i remember reading the exact same thing about dx long time ago. obviously nvidia and / or microsoft is recycling their marketing campaign.

deadonthefloor said,
Is it possible that some of these unannounced GPU features are already baked into XBOX ONE?

possibly but remember the XB1 will keep getting drivers and low level access updates much faster than the DX 12 PC spec does because MSFT doesn't have to worry about all the complexities of the windows PC hardware chain. So while DX12 will be a nice boost to the XB1, it will neither stop after that nor will MS wait to improve it until then.

Then there is the Dev tools part of it. The SKD will mature and allow ISVs to extract more power out of the system.

If there new hardware features id say none otherwise GPUs would have hardware features that dx cant use. It'll get added to OpenGL after release/when gpus with those hardware features come out

psionicinversion said,
If there new hardware features id say none otherwise GPUs would have hardware features that dx cant use. It'll get added to OpenGL after release/when gpus with those hardware features come out

Such events have already occurred, see the timeline of the Radeon HD 7-series and AMD/ARB_sparse_texture vs "Tiled Resources" in DirectX 11.2

psionicinversion said,
yeah but not many games really use it? seems like its only being added to DX cus the X1 is built around that feature

You do not build a console around one small specific feature of a graphics API. Your statement is absurd.

Athernar said,

Such events have already occurred, see the timeline of the Radeon HD 7-series and AMD/ARB_sparse_texture vs "Tiled Resources" in DirectX 11.2

They were virtually simultaneous. Sparse Texture support was officially added to the OpenGL spec with 4.4 which was released on July 22 2013. Tiled Resources was officially part of the DX11.2 release which launched with Windows 8.1 on Oct. 17 2013. So there was less than 3 months between them. It's fair to say they were developed in parallel not one after the other.

Now let's not confuse unofficial releases. OpenGL allows for unofficial "extensions" which DirectX does not. As a result most hardware companies will release new features via unofficial OpenGL extensions until they get formally accepted. That is what happened with Sparse Textures and AMD has had them for a while via unofficial extensions but OpenGL didn't formally adopt them into a vendor neutral part of the standard until 4.4.

Asmodai said,

They were virtually simultaneous. Sparse Texture support was officially added to the OpenGL spec with 4.4 which was released on July 22 2013. Tiled Resources was officially part of the DX11.2 release which launched with Windows 8.1 on Oct. 17 2013. So there was less than 3 months between them. It's fair to say they were developed in parallel not one after the other.

Now let's not confuse unofficial releases. OpenGL allows for unofficial "extensions" which DirectX does not. As a result most hardware companies will release new features via unofficial OpenGL extensions until they get formally accepted. That is what happened with Sparse Textures and AMD has had them for a while via unofficial extensions but OpenGL didn't formally adopt them into a vendor neutral part of the standard until 4.4.

Extensions being vendor specific do not preclude other vendors from implementing them, look at the list of supported extension for your vendor and you'll see a number of them from other (competing) vendors.

For example see: http://www.g-truc.net/doc/OpenGL%20matrix%202014-02.pdf

Athernar said,

Extensions being vendor specific do not preclude other vendors from implementing them, look at the list of supported extension for your vendor and you'll see a number of them from other (competing) vendors.

For example see: http://www.g-truc.net/doc/OpenGL%20matrix%202014-02.pdf


At no point did I say others were precluded from implementing extensions created by other vendors. It doesn't make sense to compare OpenGL with unofficial extensions to DirectX though. Some extensions are never adopted, some extensions do the same as other extensions from a different vendor just in a different way, even when an extension IS officially adopted its exact implementation may be tweaked in its officially adopted form. To compare a version of DirectX with a version of OpenGL excludes unofficial extensions. The extension in question didn't become officially supported by OpenGL until v4.4 which was less then 3 months before Microsoft supported a similar capability in DirectX.

Asmodai said,

At no point did I say others were precluded from implementing extensions created by other vendors. It doesn't make sense to compare OpenGL with unofficial extensions to DirectX though. Some extensions are never adopted, some extensions do the same as other extensions from a different vendor just in a different way, even when an extension IS officially adopted its exact implementation may be tweaked in its officially adopted form. To compare a version of DirectX with a version of OpenGL excludes unofficial extensions. The extension in question didn't become officially supported by OpenGL until v4.4 which was less then 3 months before Microsoft supported a similar capability in DirectX.

It makes perfect sense to compare them. The ARB is useful in refining and guiding the evolution of the API in the long-term, but there is absolutely no reason why utilising agreed-upon vendor extensions should be ignored.

There is no point in having an extension system if it's not going to be utilised.

Athernar said,

It makes perfect sense to compare them. The ARB is useful in refining and guiding the evolution of the API in the long-term, but there is absolutely no reason why utilising agreed-upon vendor extensions should be ignored.

There is no point in having an extension system if it's not going to be utilised.


You just keep arguing against points I didn't even make.
At no point did I say it shouldn't be utilized or should be ignored by developers/vendors. It just doesn't make sense to user non-standard extensions in a comparison between a version of OpenGL and a version of DX. I specifically said vendors add them so that they may utilize a new hardware capability before it has been accepted by the official spec. Most, if not all, new features in a new version of OpenGL are adapted from ARB extensions so in a way they're like a RFC where someone proposes a way to do something new and others can accept that implementation, reject it, or offer an alternative. The ARB process is extremely useful as it's how OpenGL evolves but it has no place in comparing released versions with released versions of DirectX. Who knows MS may have had "Tiled Resources" on development builds for ages but it just never got the green light for release until 11.2. DirectX development is closed so we just don't know. A vendor can make a fully compliant OpenGL 4.3 Video card without support for Sparse Textures, it wasn't added to the spec until 4.4.

Vendor A could make an entirely new hardware capability and create an OpenGL extension for it. Maybe other people use it, maybe they don't. When comparing what OpenGL can do with what DirectX can do it doesn't make sense to include these extensions. Maybe Vendor A decides to use a completely different and incompatible extension in revision 2 of this capability. Maybe Vendor B does the same type of thing but has their own entirely different and incompatible OpenGL extension to do it. Maybe that capability NEVER gets added to OpenGL proper. Maybe that capability is awesome and everyone agrees to add it but the vendor-neutral implementation they agree upon takes aspects from various different vendors specific implementations and even adds some new features none of the prior ones had making incompatible with everything that came before it even though it does conceptually the same thing. OpenGL didn't really support that capability for the purposes of comparing to DirectX until that common implementation was agreed upon and formally adopted by the specs. If you're going to include any extension then I guess OpenGL can do darn near anything because you could write an extension to do whatever you like, it just probably won't get added to the formal standard.

Asmodai said,
<snip>

It makes perfect sense to utilise vendor extension in such a comparison, the extension system itself is just as much a feature of OpenGL as the extensions themselves.

DirectX lacks this functionality and thus both puts itself at a disadvantage and stifles innovation.

Commenting is disabled on this article.