Question 'Ampere'/Next-gen gaming uarch speculation thread

[Ottonomous]

How much is the Samsung 7nm EUV process expected to provide in terms of gains?
How will the RTX components be scaled/developed?
Any major architectural enhancements expected?
Will VRAM be bumped to 16/12/12 for the top three?
Will there be further fragmentation in the lineup? (Keeping turing at cheaper prices, while offering 'beefed up RTX' options at the top?)
Will the top card be capable of >4K60, at least 90?
Would Nvidia ever consider an HBM implementation in the gaming lineup?
Will Nvidia introduce new proprietary technologies again?

Sorry if imprudent/uncalled for, just interested in the forum member's thoughts.

 

[Mopetar]

Depends on the configuration. Lots of small memory chips will give significantly more bandwidth than fewer, but larger chips. If the rumors of 512bit memory interface are true, that would mean something like sixteen 1.5GB chips.

That's true, but why not use 1 GB chips that can clock a little faster as a trade off?

We've seen that in a lot of the more recent cards that bumping the memory speed is often a better use extra voltage. That may not be true in all cases or for all titles, but if it's a trade between faster memory that will be sufficient across the life of the card or having more memory than you would expect to utilize I think the choice would be obvious.

Consider going the other direction where NVidia uses 2 GB chips for 32 GB total VRAM. Obviously that uses more power that can't be used elsewhere.

My question is why is 24 GB the best choice?

 

[kurosaki]

So I had searched earlier, and found something saying Micron offered 12Gb chips. But looking at both Micron's and Samsung's parts lists, they only offer 8Gb and 16Gb. So apparently I am the stupid one

But there are 12gb chips. I belive sweclockers.com talked about it in their latest video. It's in Swedish though. If you want an odd configuration there is a possibility it will be tailor made. Not that far fetched. Now where is that stupid color?!

 

[Konan]

Speculation from Coreteks - Traversal Coprocessor
Going out on a limb a bit but nevertheless interesting insights

+ Patents https://patents.justia.com/inventor/tero-karras

 

[DooKey]

Speculation from Coreteks - Traversal Coprocessor
Going out on a limb a bit but nevertheless interesting insights

+ Patents https://patents.justia.com/inventor/tero-karras

That's a ton of interesting stuff. Can't wait to see if it turns out to be true or not.

 

[kurosaki]

Bogus. There are 2 PCBs, where the power MOSFETs are on the second. It is not going to be another chip on the back of the gpu. Mayyybeee, a separate acceleration card.

 

[Krteq]

Huh, where is the second PCB? There is no place for it anywhere on that leaked cooler.

 

[kurosaki]

Huh, where is the second PCB? There is no place for it anywhere on that leaked cooler.

It attaches to the 2x8 powerpins.

 

[Krteq]

And where are those "powerpins"?

 

[kurosaki]

Just look at the schematics, short end. 5.20 into the garbage video.

 

[Krteq]

Lol, nope, that's just someone's "representation" of those leaks. Look at those heatsinks, there is no room for PCIe power connectors or any other PCB. There are fins everywhere on that end, no room for any "second PCB" and even PCIe power connectors can't fit there.

Spoiler

 

[Konan]

a note on the leaked cooler/heat sink design -
Videocardz

The cooler design that was leaked this week is not actually the final design, which let’s be honest was to be expected. What Igor learned is that this design is just one of the two currently being evaluated by NVIDIA. The decision which design will end up in the actual product will be made in July, during the Design Validation Test.

We could have something quite different still. I think this is amplified in the Coreteks video where he zooms in and shows the fins aren’t aligned and different to what one would expect.
So basically not a confirmed cooler choice....

 

[kurosaki]

Lol, nope, that's just someone's "representation" of those leaks. Look at those heatsinks, there is no room for PCIe power connectors or any other PCB. There are fins everywhere on that end, no room for any "second PCB" and even PCIe power connectors can't fit there.

Spoiler

https://cdn.sweclockers.com/artikel/bild/83947?l=eyJyZXNvdXJjZSI6IlwvYXJ0aWtlbFwvYmlsZFwvODM5NDciLCJmaWx0ZXJzIjpbInQ9b3JpZ2luYWwiXSwicGFyYW1zIjpbXSwia2V5IjoiOWQ2NzFkNDcwMzc4ZTM1NzJiMGRhZDE1ZmIxNmI1MTQifQ%3D%3D

Just look at it.

 

[Krteq]

That's another flawed unofficial interpretation by Reddit user.

As you can see on that "heatsink" photo, there are no holes allowing airflow through those fins on sides in the middle of the heatsink.

Another thing is that fins on second part of a heatsink are in one piece, there is no space for any PCB fitted with SMDs. Anyway, IF there will be any "second PCB" in the middle of second part of that heatsink, that PCB will be blocking airflow through those fins... however, there will be no space left because there is fan already fitted

 

[DooKey]

It's going to be what it's going to be. No need to argue about it. As long as it keeps the beast cool enough to pump out frames without sounding like an FX or 290 we'll be fine.

 

[IntelUser2000]

Speculation from Coreteks - Traversal Coprocessor
Going out on a limb a bit but nevertheless interesting insights

I have to say, I have doubts on the video, but his videos are interesting nonetheless.

I particularly like 19:20 where he graphs out the performance gains and also compares to uarch gains at iso-process. According to that graph, except Maxwell generation, despite what AMD/Nvidia has claimed, all the gains came from process not uarch.

 

[Glo.]

I have to say, I have doubts on the video, but his videos are interesting nonetheless.

I particularly like 19:20 where he graphs out the performance gains and also compares to uarch gains at iso-process. According to that graph, except Maxwell generation, despite what AMD/Nvidia has claimed, all the gains came from process not uarch.

Nvidia GPUs scale way better with clock speeds, than AMD GPUs do. AMD GPUs scale better with CU counts.

This is the reason why there is so small difference in performance between RTX 2080 Ti and RTX 2080 Super, despite RTX 2080 Ti having 40-45% more ALUs.

 

[IntelUser2000]

@Glo. There's 11% difference in 1080p, 16% in 1440p, and 18% in 4K.

-With 17% difference in ROP
-24% difference in memory bandwidth
-And 19.6% difference in compute power

It seems reasonable to me Glo!

 

[Glo.]

@Glo. There's 11% difference in 1080p, 16% in 1440p, and 18% in 4K.

-With 17% difference in ROP
-24% difference in memory bandwidth
-And 19.6% difference in compute power

It seems reasonable to me Glo!

And 40-45% difference in ALU count. So something is genuinely bottlenecking the ALUs.

 

[CastleBravo]

And 40-45% difference in ALU count. So something is genuinely bottlenecking the ALUs.

Frequency?

 

[HurleyBird]

Speculation from Coreteks - Traversal Coprocessor

This is extremely shoddy. Argument is:

The weird heatsink design is for cooling the back of the pcb. Therefore there's a chip there. And because transversal would make sense, that's what the chip is.

Except he doesn't show how the heatsink does this, and in fact just looking at it we can see that it doesn't help cool the back of the pcb. It's profoundly stupid conjecture.

 

[Veradun]

This is extremely shoddy. Argument is:

The weird heatsink design is for cooling the back of the pcb. Therefore there's a chip there. And because transversal would make sense, that's what the chip is.

Except it doesn't

Simplified for you

 

[kurosaki]

"
That's another flawed unofficial interpretation by Reddit user.

As you can see on that "heatsink" photo, there are no holes allowing airflow through those fins on sides in the middle of the heatsink.

Another thing is that fins on second part of a heatsink are in one piece, there is no space for any PCB fitted with SMDs. Anyway, IF there will be any "second PCB" in the middle of second part of that heatsink, that PCB will be blocking airflow through those fins... however, there will be no space left because there is fan already fitted
"


Let's just wait and see. As gentlemen i would prefer if the one wrong in this issue just posted a picture of oneself eating a piece of, or the whole: Hat.
I would like to see you have a bite of that hat, i suppose you would like too see me as well, if it came up to my faulty predictions?

Hats off bloke!

PS. Salt is allowed.

.DS

 

[HurleyBird]

I mean, the prediction could be right. But the entire rationale for making the prediction is completely insane.

 

[uzzi38]

Yeah, hate to say it but the idea of a co-processor for RTRT makes 0 sense. And the patents don't even suggest a seperate die either, they still show the RT hardware is in the GPCs.

 

[DisEnchantment]

The interpretation of that patent makes no sense for the context of RTRT in current Windows DirectX environment.
Imagine doing inline RT and your shader launch a ray query, it goes offchip ..

No amount of power and BW will save this.

Talk about people complaining that RT being BW intensive and being very divergent with bigger scenes when tons of boxes needed to be tested for intersection on the ray path.
Don't even know what this shader which launch the ray query will do. Who will resync the result.

It is just wild.

A more realistic interpretation is that the co-processor sits aside the SM or along side the other ALUs and has an idea of the context which shader is launching the ray query so that results can be passed back. ( quite similar to something ...)

Check the DXR code sample , this context has to be correct so that the shader running this code can proceed.

RaytracingAccelerationStructure myAccelerationStructure : register(t3);

float4 MyPixelShader(float2 uv : TEXCOORD) : SV_Target0
{
    ...
    // Instantiate ray query object.
    // Template parameter allows driver to generate a specialized
    // implementation.
    RayQuery<RAY_FLAG_CULL_NON_OPAQUE |
             RAY_FLAG_SKIP_PROCEDURAL_PRIMITIVES |
             RAY_FLAG_ACCEPT_FIRST_HIT_AND_END_SEARCH> q;

    // Set up a trace.  No work is done yet.
    q.TraceRayInline(
        myAccelerationStructure,
        myRayFlags, // OR'd with flags above
        myInstanceMask,
        myRay);

    // Proceed() below is where behind-the-scenes traversal happens,
    // including the heaviest of any driver inlined code.
    // In this simplest of scenarios, Proceed() only needs
    // to be called once rather than a loop:
    // Based on the template specialization above,
    // traversal completion is guaranteed.
    q.Proceed();

    // Examine and act on the result of the traversal.
    // Was a hit committed?
    if(q.CommittedStatus()) == COMMITTED_TRIANGLE_HIT)
    {
        ShadeMyTriangleHit(
            q.CommittedInstanceIndex(),
            q.CommittedPrimitiveIndex(),
            q.CommittedGeometryIndex(),
            q.CommittedRayT(),
            q.CommittedTriangleBarycentrics(),
            q.CommittedTriangleFrontFace() );
    }
    else // COMMITTED_NOTHING
         // From template specialization,
         // COMMITTED_PROCEDURAL_PRIMITIVE can't happen.
    {
        // Do miss shading
        MyMissColorCalculation(
            q.WorldRayOrigin(),
            q.WorldRayDirection());
    }
    ...
}

For each query, it matters which is the origin, the ray direction, current frame and so on.