Clocks though are currently what give the difference between Fiji and Vega when it comes to compute with the professional models - putting aside the context regarding mixed-precision and FP64 difference.
Are they though? Do we actually know anything else about Vega 20 than 4096bit HBM2 memory and 7nm manufacturing process?
Simply ramping clocks from an improved process I don't consider an architectural improvement. Routing adjustments perhaps, but they could just as easily apply to 14nm. For compute and professional, HBCC and RPM would be the big gains. For graphics DSBR, DX12.1 features, primitive shaders, etc would make a difference. Initial benchmarks did have Vega as an overclocked Fiji, but once the new features are used there is an added benefit.
I'm not sure we can tell yet, but a simple change to 7nm alone shouldn't change the architecture. Unless an existing feature is somehow fixed or quad packed math is a thing, there doesn't seem to be much added. Even bandwidth with 4 stacks may be in proportion to clock gains from 7nm. Yes that's ignoring any efficiency hit from FP64 that was added. If there are more features coming with Vega 20, nobody has heard anything. Even the old roadmap leaks didn't show anything. I'd think there would have been some rumors or hints at what is coming. Changing cache sizes is all that really comes to mind.
xGMI?
Or they should implement it in one game. They invested so many time in wattman and link. They should more invest in Ngg fastpath.
AMD is morbidly silent about it for a good reason.
What do you mean by "open source community"?
I agree but that is different to the original reasons discussed which come back to compute and Vega 20, is 64CU important and efficiency of GCN where both are fine with compute-HPC type applications or even compute cryptomining if looking at consumers; clocks are part of that discussion.
They should post code and information in GitHub and hand it over to the Linux open source driver team.
amdgpu team is (almost?) all paid devs working at AMD.
Interesting, but more or less a fat PCIe connection. IMHO it won't really change the architecture, but accelerate certain tasks with a lot of traffic going off chip. The exception would be if it was enabling some sort of MCM interconnection like Epyc.
Not necessarily broken, but just not worth the effort given a more versatile solution. With compute based culling the implicit paths may perform worse. The explicit paths probably better, but that requires Vega specific programming that in the current mining environment I'm not sure makes sense. No devs, or even AMD for that matter, would see a point in CURRENTLY developing it for the existing Vega marketshare. That's in addition to or replacing the compute based culling implementation that should run on most if not all current hardware.
RPM and Tensor Cores are somewhat analogous, so more than just mixed precision. HBCC is probably working on some HPC workloads. Specifically the oil and gas or astronomy guys with extremely parallel workloads on large datasets. The oil guys were the ones requesting the feature in the first place as I recall. They were also likely using a SAN for storage and we haven't seen any relevant cards publicly.
I'd imagine there will be some changes to the CUs in the future. Personally I still favor cascaded DSPs to avoid heavy VGPR traffic and essentially create deeper pipelines if practical. Creating a systolic network for macro blocks. That design should be a step beyond what Nvidia is doing with the register file caching.
AMD actively maintains both, although the community one does have additional devs working on it. The problem lies in code that can't be freely distributed or readily meet kernel standards.
AMD has shown HBCC with all its functions as a working demo-concept (not the right word as it is more than that but not sure what to call it) with a GPU rather than scaled up/out use accelerator node, so far in this segment it is a traditional modern Unified Memory accelerator solution and that is good but best to temper expectations as one does when AMD showed all features/functions Vega had pre launch; HBCC storage-cache would be incredibly complex (with overheads) in a scaled up/out HPC solution; look at (not just the interconnect but where positioned/control-flow/etc) new HPC cache-storage solutions with products based around CCIX or IBM next gen to CAPI.
NGG wouldn't necessarily reduce the load on the shaders, but the 4 tri/clock bottleneck in the front end by removing culled triangles. That can occur with primitive shaders or a compute shader culling and compacting the stream. Technically they could be chained together, but that would be a bit redundant. Ignoring both shader types running on the shader array for the sake of argument, neither PS or CS would reduce the shader load unless presented with some interesting culling capability by the developer. Some culling operation being hinted the default path couldn't pick up on or implement due to guarantees. Typically GCN would have difficulty using the shader array from an inability to feed geometry through the front-end. Async works around this bottleneck and in this case the culling shaders are scheduled during the previous frame.
Complexity depends on how they are using it. For certain HPC tasks, large read-only datasets, most of that overhead would be nonexistent. That should be the case for the oil and gas guys and the implementation somewhat proprietary. Large scale rendering or raytracing could be similar. Multiple GPUs each working a subset of the screen space and HBCC caching pages that get hit. As each GPU would be completely independent the control flow issues go away. CCIX and CAPI are interesting for a certain segment of problems, but shouldn't be necessarily for a SSG type problem with a SAN. Once the GPUs have to start synchronizing it can get more difficult, but automated paging makes that far easier. No different than CPU programming where data pages automatically. That would be familiar to many researches with limited programming ability. It becomes a question of efficiency and any gaps are filled with other work thanks to async compute if practical. So long as all the jobs don't generate stalls simultaneously the chips should stay near peak performance. If that is occurring the implementation will be problematic on any hardware.
