NVIDIA Kepler speculation thread

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.

 

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.

 

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

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

 

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.

 

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 ?

 

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).

 

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

 

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?

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

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.. )

 

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

 

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.

 

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 )

 

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.

 

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 :

Code:

  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;

 

Can somebody explain what UAV rendering is?

 

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.