When my solution A is the way it works, they're absolutely right that it's better.
You asked why I think 32 ROPs are enough and I think geometry discard could make ROPs more efficient. Is that a minor optimisation if that's how it works?
Why has it taken so long for delta colour compression to get to where it is? Or do you think that bandwidth isn't the single most important constraint in GPU design since forever?
Cross-node sharing/linked adapter mode (though some adapters may comes with multiple linked nodes, mostly 2 nodes), also known as SLI and CFX in the commercial names, allows explicit sharing of resources under Direct3D 12 (and I guess Vulkan too though I did not study in deep this one). This is different from Direct3D 11 and older high-level APIs where quite every resource needs a copy on every VRAM pool (though later versions of NVLINK and AGS APIs allowed a little control over them). What can be shared and what cannot be shared is expressed by the cross node sharing tier. A higher cross-node sharing tier can be nullify if the cross-node configuration is limited by bandwidth: SLI bridges - even the "new double" of Pascal - have a lower bandwidth compared to how many PCI-E lines a typical multi-GPU configuration can gain.
More surprising is that we haven't seen NVLink being used over their existing SLI connector. Might be a pin issue, but that would be a rough substitute for a lack of PCIE bandwidth. You could have a second card that was all memory.
In the case of compute shaders, especially asynchronous, I could see the sharing issues getting rather interesting. Some of the uses would only be practical on a single adapter.
actually not. it was on another forum a while ago(I think he got an ES)
When talking specifically about making ROPs more efficient, I mean it from a narrow point of view: increasing efficient from, say, 90% of their theoretical peak to 95% of their theoretical, not about avoiding them altogether.
Because the bandwidth is not improving as fast core shader performance and the gates required to implement compression are becoming relatively cheaper.
That's exactly what I think. I've stated many times in the past, in the context of the introduction of HBM, that there's no need yet to go all out on bandwidth. That doesn't mean that it's not important, but it's definitely not the single most important constraint. If it were, Fury X would blow all other GPUs out of the water.
I agree with the general content of your post, but PCIe is high bandwidth enough to guarantee the QoS levels needed to transfer real-time video streams by added enough buffering. Either by using of-chip RAM (which would eat up some extra MC bandwidth) or on-chip FIFOs to feed straight into the display output port.
With NVLink-like signaling, signal integrity could be a real issue.
True, but Nvidia still managed to get 8 working in a box. Granted that was using that mezzanine connector. With HBM likely removing some pin constraints, I'm still wondering if we'll see a dual die card where a link could be hardwired. What's to say they couldn't modify a motherboard for a socketed GPU either? The interconnects are likely all GMI now. A dual or quad socket board, while typically reserved for servers, could have GPUs stuck in some sockets.
I don't know if this was linked here before, for whatever its worth:
http://semiaccurate.com/forums/showpost.php?p=266518&postcount=2022
NVLink has a fairly exotic signaling protocol, which is one reason it gets good pJ/bit. But AFAIK, NVLink cables are not currently possible from a technical point of view because of signal integrity.
This is incorrect. GPUDirect RDMA is about network transferring, but the GPUDirect brand also includes peer-to-peer transfers within the same PCIe root complex.
Ignorant question of the day: on today's non-Polaris GPUs, how are pipeline stalls visible to the programmer and how does one typically have to deal with it? And what did Larrabee do different? Come to think of it: was Larrabee ever available as a GPU?
