NVIDIA Kepler speculation thread

[iMacmatician]

Videocardz stays with their own sources which say 1920-2112 CCs (I'm guessing the 2110 is a typo), 160 TMUs, and 48 ROPs.

Oh, and speaking of

NVIDIA does not usually launch their cards with such round clock numbers.

I wonder if it is just a coincidence that all the desktop GeForce GK104 variants have core clocks very close to multiples of 91.5 MHz.

 

[Alexko]

Videocardz stays with their own sources which say 1920-2112 CCs (I'm guessing the 2110 is a typo), 160 TMUs, and 48 ROPs.

Oh, and speaking of
I wonder if it is just a coincidence that all the desktop GeForce GK104 variants have core clocks very close to multiples of 91.5 MHz.

NVIDIA's GPU Boost bins are increments of 13MHz. Now 91 = 7×13, and maybe there's a good reason for that 7, but as far as I can tell it's just a coincidence.

 

[tviceman]

If there really is a new Kepler variant coming, something in between GK104 and GK110 in size, then it would have the best of both worlds insofar as gk10x's leanness and GK110's potential graphics processing power. I guess it's plausible that Nvidia could push / add an additional SMX into each GPC in GK104, and also add 2 more memory controllers, but the work required to do all of that would be pretty substantial. GK104 with it's memory bus and ram speed can't be refreshed to be significantly faster, so perhaps there is a little bit of truth to these rumors. It would probably come down to the R&D of developing a new chip as opposed to just using GK110 as a geforce product.

 

[DSC]

http://www.geeks3d.com/20121112/nvi...ers-for-windows/comment-page-1/#comment-26221

nvcuda.dll exposes first life signs of Maxwell

CC 3.0 = K10?
CC 3.2 = ???
CC 3.5 = K20
CC 5.0 = Maxwell?

Kepler Refresh (GK11x or GK20x) might be Compute Capability 3.2 if the info in nvcuda.dll 310.54 drivers is correct.

 

[Blazkowicz]

If there really is a new Kepler variant coming, something in between GK104 and GK110 in size, then it would have the best of both worlds insofar as gk10x's leanness and GK110's potential graphics processing power. I guess it's plausible that Nvidia could push / add an additional SMX into each GPC in GK104, and also add 2 more memory controllers, but the work required to do all of that would be pretty substantial. GK104 with it's memory bus and ram speed can't be refreshed to be significantly faster, so perhaps there is a little bit of truth to these rumors. It would probably come down to the R&D of developing a new chip as opposed to just using GK110 as a geforce product.

The R&D work is infuriating (cost of lithography masks, long hours of extremely hard engineering) but a lot of it has been done already, the whole basic Kepler design and making a huge chip with it.

Maybe the whole Geforce line (plus low-end and mid-range Quadro) gets refreshed to GK20x, 20nm process for the Maxwell line probably takes a long time to get working, affordable and plentiful.

 

[tviceman]

The R&D work is infuriating (cost of lithography masks, long hours of extremely hard engineering) but a lot of it has been done already, the whole basic Kepler design and making a huge chip with it.

Maybe the whole Geforce line (plus low-end and mid-range Quadro) gets refreshed to GK20x, 20nm process for the Maxwell line probably takes a long time to get working, affordable and plentiful.

I have no doubt all of the Kepler chips will get refreshed (maybe some will simply be relabled) but the mystery as to whether Nvidia will release GK110 as a geforce card still exists. If they do NOT, then I assert that a slightly tweaked GK104 simply will not do as their flagship Geforce card vs. AMD's upcoming 8000 series. If it is the case that GK110 will not be a Geforce card, then there has to be another chip somewhere in between GK104 and GK110.

 

[AnarchX]

Nvidia confirmed Kepler is only feature-level 11_0: http://www.heise.de/newsticker/meld...endig-zu-DirectX-11-1-kompatibel-1754119.html

 

[DavidGraham]

Nvidia confirmed Kepler is only feature-level 11_0: http://www.heise.de/newsticker/meld...endig-zu-DirectX-11-1-kompatibel-1754119.html

So correct me if I am wrong , it supports DX11 in hardware , but DX11.1 in software ?

 

[AnarchX]

So correct me if I am wrong , it supports DX11 in hardware , but DX11.1 in software ?

So you think NV will emulate the missing features (right column of table)?
I do not think this is allowed by Microsoft.

The problem is, that NV stated a long time through driver panel, that there is DX11.1 support (even on GeForce 400/500 and under Windows 7). But now it turns out, that (current) Kepler GPUs only features some of the DX11.1 features, which leads to that they have to be limited on feature level 11_0. Maybe they will expose it through NVAPI, but you cannot use them under standard DirectX applications.


So we can speculate, that GK2xx will bring full DX11.1 support, and the mainstream/low-end GK208 makes the beginning, because OEMs like full feature lists and full OS support (see GT21x).

 

[MDolenc]

It is fascinating that Kepler for example does not support UAVs outside pixel shaders, when Fermi can do that in OpenGL.

 

[Psycho]

So nvidia has been straight out lying in press releases/confererences...

GTX 680 press release: http://pressroom.nvidia.com/easyir/...releasejsp=release_157&xhtml=true&prid=865433 (who long before that page is edited?

Manufactured on TSMC's new 28-nm process, with support for PCI-E Gen 3 and DX11.1

http://muropaketti.com/artikkelit/naytonohjaimet/nvidia-geforce-gtx-680-gk104

we also had to ask specifically whether the GK104 GPU with DirectX 11.1 support. The answer is yes, but NVIDIA's Drew Henry (General Manager for NVIDIA GPU's PC Business Unit), the "Who cares?"

The "who cares" part was back then mostly perceived as they wanted to downplay the dx11.1 importance as most of their product stack was still 11.0 (Fermi) cards competing with GCN..

Ofcourse they try to spin it now, like they support directx 11.1 api, just not feature level 11_1 ... well.. like any dx9 card with current drivers supports 11.1, just only feature level 9_0

(11.1 was also part of the old road maps, but fair enough, the 11.1 requirements may have changed over time.. )

 

[tviceman]

brightside of news, with quotes from Nvidia and game developers:

The GTX 680 supports DirectX 11.1 with hardware feature level 11_0, including all optional features. This includes a number of features useful for game developers such as:
Partial constant buffer updates
Logic operations in the Output Merger
16bpp rendering
UAV-only rendering
Partial clears
Large constant buffers
We did not enable four non-gaming features in Hardware in Kepler (for 11_1):
Target-Independent Rasterization (2D rendering only)
16xMSAA Rasterization (2D rendering only)
Orthogonal Line Rendering Mode
UAV in non-pixel-shader stages
So basically, we do support 11.1 features with 11_0 feature level through the DirectX 11.1 API. We do not support feature level 11_1. This is a bit confusing, due to Microsoft naming. So we do support 11.1 from a feature level for gaming related features."
[/qoute]

Read the rest of the article and quotes, but it basically sums it up as Nvidia supports what is needed for gaming.

 

[Kaotik]

They don't support 11_1 feature set, no matter how they twist it in quotes. If some of the features could be used for gaming, nV is out of luck unless the dev uses some NVAPI tricks to get past the fact that Kepler doesn't support 11_1 featureset completely.

 

[A1xLLcqAgt0qc2RyMz0y]

Making a Mountain out of a Mole Hill

How many PC games now or in the near future are going to use (or even would have used) these four non-gaming 11_1 features? :

• Target-Independent Rasterization (2D rendering only)
• 16xMSAA Rasterization (2D rendering only)
• Orthogonal Line Rendering Mode
• UAV in non-pixel-shader stages

I bet the answer is NOT a Single One.

"The GTX 680 supports DirectX 11.1 with hardware feature level 11_0, including all optional features.This includes a number of features useful for game developers such as:

• Partial constant buffer updates
• Logic operations in the Output Merger
• 16bpp rendering
• UAV-only rendering
• Partial clears
• Large constant buffers

We did not enable four non-gaming features in Hardware in Kepler (for 11_1):

• Target-Independent Rasterization (2D rendering only)
• 16xMSAA Rasterization (2D rendering only)
• Orthogonal Line Rendering Mode
• UAV in non-pixel-shader stages

So basically, we do support 11.1 features with 11_0 feature level through the DirectX 11.1 API. We do not support feature level 11_1. This is a bit confusing, due to Microsoft naming. So we do support 11.1 from a feature level for gaming related features."


http://www.brightsideofnews.com/new...directx-111-with-kepler-gpus2c-bute280a6.aspx

 

[lanek]

Personnally, but i could be wrong, i see this exactly like the DX10 and DX10.1.
When Nvidia was not support the feature on hardware level, AMD was, but the main difference is performance wise it is better to have them on hardware level instead of software level...

Still the way of tell it is a bit strange when you produce hardware... and not the software who use this features. If you say your hardware is DX11.1 it is cause it support in hardware DX11.1 features. ( will be anyway a bit complicate to put in short term )

Is it important ? not really as the result is the same in way of compatibility ( performance wise this can be an other story )

 

[AnarchX]

But GCN-based PS4/Xbox 720 could use UAV in tessellation-/compute shader stages.

 

[Gipsel]

But GCN-based PS4/Xbox 720 could use UAV in tessellation-/compute shader stages.

Kepler supports UAVs in pixel and compute shaders. But not in tessellation related (hull and domain shader) or any other shader type before the rasterizers. And in my opinion, that is gaming relevant. Use of UAVs in vertex, geometry, hull and domain shaders have no potential use for anything outside of gaming. Where else does one use this shader types? So nV's claim they support all gaming relevant DX11.1 features is plain wrong in my opinion.
If I'm not mistaken, they don't support a single feature of level 11_1 which is not optional for level 11_0.

 

[Tridam]

It is fascinating that Kepler for example does not support UAVs outside pixel shaders, when Fermi can do that in OpenGL.

It might just be that Microsoft didn't want UAV acces by all shader types to be a new option for level 11_0. If Kepler doesn't support 64 UAV or TIR or anything else from level 11_1, there is no way for Nvidia to expose UAV access by all shader types.

These are the only new optional features :

  BOOL OutputMergerLogicOp;
  BOOL UAVOnlyRenderingForcedSampleCount;
  BOOL DiscardAPIsSeenByDriver;
  BOOL FlagsForUpdateAndCopySeenByDriver;
  BOOL ClearView;
  BOOL CopyWithOverlap;
  BOOL ConstantBufferPartialUpdate;
  BOOL ConstantBufferOffsetting;
  BOOL MapNoOverwriteOnDynamicConstantBuffer;
  BOOL MapNoOverwriteOnDynamicBufferSRV;
  BOOL MultisampleRTVWithForcedSampleCountOne;
  BOOL SAD4ShaderInstructions;
  BOOL ExtendedDoublesShaderInstructions;
  BOOL ExtendedResourceSharing;

 

[silent_guy]

Can somebody explain what UAV rendering is?

 

[Ethatron]

UAV is a random access (read | write) view on a buffer. You can do scattered writes to an UAV fe. You can already render out into UAVs if you want in 11.0
I think you can not go without RT _and_ DS (+UAV) in 11.0, because then the whole pipeline goes to sleep basically. I'd say the "feature" it's really only a guarantee that nothing just turns off, you should be able to do the feature itself without problems if your hardware isn't a bit inflexible.
nVidias problem is likely the 64 UAVs, not that you can't turn off RT & DS together.

Edit: You also loose the resolution-information when you don't have a RT&DS bound, there it goes hand in hand with the "Target-Independent Rasterization" feature of DirectX 11.1.