Right. Just as many games as supported that 3D sound shit AMD introduced with R9 290 series cards, which is zero for all intents and purposes.
These high-performance APUs needs Primitive Shaders!
What clients though? The vast majority of the bandwidth is between the CUs and HBM2 and somehow applicable to MI25 or one of the server products. There may be some overhead, but that shouldn't be making the chip significantly larger than otherwise necessary. There don't appear to be any indications Vega is scaling past 64 CUs either to add more clients for IF. There's just no reason for it in the current incarnation. None of the clients listed in the hotchips presentation should have significantly large requirements for IF.
So situations where GPU limited? Absolutely shocking that reducing GPU load would increase performance when limited by the GPU. Almost as if bandwidth wasn't a limiting factor for Vega. With AMD's limited FLOPs holding them back and all. That might have been one of the dumbest comments I've seen in a while.
The alternative to primitive shaders was using a compute shader asynchronously to perform the culling. Ideally with RPM/FP16 where the front end has little if any culling to perform. Might even be faster. Wolfenstein I believe was doing something similar, but was disabled in some benchmarks with the FP16 issues to my understanding. At least the last time anyone looked at it. Might be a better implementation for mGPU workload distribution as well.
My impression was there's still a direct feed from the primitive pipeline into the pixel shader stage. I'm not sure where the compute shader would interject.
AMD's offering a discrete mobile Vega that appears roughly in the same range as the Intel custom chip.
It would be a niche product, which AMD seems to be de-prioritizing in favor of lower-hanging fruit in the form of Ryzen in its 8-core form or existing MCM CPU products. An APU would take on a significant portion of the up-front cost of a new package format while the GPU tied to an 8-core makes it less desirable for most markets either the GPU or CPU would otherwise be sold to.
Indexing doesn't spill registers, and the overall register file is not really growing much or possibly shrinking if the virtual register scheme is implemented.
Not if the sizing is dominated by other resource limits and fixed-function pipeline granularity, which the various patches indicate is the case.
We have pictures of Vega, which don't seem to show extra IO (edits: besides some SATA, probably). PHYs don't do internal networking.
Perhaps AMD would be publishing documentation on them, as well as what it would take to expose them.
So now no need for unicorn drivers? We just need a unicorn developer to code stuff for a GPU that pretty much has near zero marketshare?
Poised and have are two different things, historically APUs have never captured a great deal of the important marketshare that developers cater for. As of right now NVIDIA holds the majority of dGPUs. AMD's share has dwindled to a historically dangerous level due to a combination of uncompetitive high end solutions and the mining craze. It's not hard to see who is in the distant third right now and the future.
We've also seen a Vega around a 1070 several times with no effort whatsoever! So does that make the GP104 the future king of GPUs according to your logic? right?
At this point, this is not a prediction, just wishful thinking wrapped into denial.
Paper dragons and shiny slides. That's really a shame. It's good to see Raja gone.
You're asking the right questions. Exactly because none of the clients listed in the hotchips presentation has a very large bandwidth requirement, IF is overbuild. IMHO, that's what the argument started with and now we have reached common grounds answering that question.
So consoles aren't important nor catered to for game developers? Nvidia's "majority" of dGPU was something along the lines of 15% of the graphics marketshare last I checked. AMDs share will dwindle as the move towards APUs and integrated designs continues from that discussion we had a year or so ago. We've seen Raven with better performance, Intel added Vega graphics as well that are advertised as VR capable, and Nintendo Switch seems rather popular with it's typically less than dGPU level of performance. With 580/1060 mid-range marketshare shifting towards APU designs those dGPU sales will drop. Even Intel is getting in on that action.
Not really wishful, we've already seen parity without everything fully enabled in well optimized titles where the cards run close to max. So in this case "denial" is just common sense unless the new features slow things down or DX12/Vulkan titles are optimized horribly. The potential FP16 performance is well above 1080ti and that feature is attractive if going towards that low-power APU market with lots of users.
That can be a tricky situation. It can be preferable for all involved if the head steps aside during any reorganization regardless of performance.
None of the clients normally have large requirements, but some(xDMA for example) could. IF is scalable so there is no reason to really overbuild it unless there exists a situation where it may be necessary. Back to the xDMA part, that would be the Crossfire connection to other cards over PCIe. Typically limited to 16x PCIe, making it larger would make sense and still be covered in the hotchips presentation. Just not drawn to scale. That would nominally be 16GB/s, doubled to 32GB's if a second link or PCIe4 was added(IF on Epyc runs above PCIe spec), and perhaps even >64/128GB/s(if designed to extend Epyc's fabric). It's conceivable that xDMA could be on the level of a memory controller. That client may also be switching between multiple IO devices including video encode/decode.
Nope, consoles are not that important for the "PC" gaming ecosystem. Almost all titles already come with NVIDIA optimized code for PC despite the console heritage, which enables NVIDIA GPUs to run them better, further alienating AMD GPUs in PC space, making them less desirable, impacting R&D, impacting competitiveness, eventually might lead AMD to lose even the console market (like they lost the Switch). It's a cycle of causality and effect.
We are already seeing 70% of DX12 titles being optimized horribly.
Not according to developers invested in the matter (like DICE), right now the feature is in limited use, (being only available on the PS4Pro), even when in use it is accelerating parts of the code by 30%, which means the overall impact is probably less than 10% depending on the code discussed. Not every feature is to be blown out of proportions like it's the second coming. How many chips have FP16 enabled again?
Actually, we've seen huge disparity more than parity. The concept of "well optimized titles" can be played by both sides, the amount of games where a 1080 far exceeds the Vega 64 is higher than the one or two cases where Vega 64 achieves close results to a 1080Ti (let alone the fully enabled TitanXP).
Intel's KabyLake G is nowhere near the 1060/580 level, not unless you believe some botched and skewed Intel marketing numbers. And Intel is only doing it for a niche market. AMD seems reluctant to even approach that level any time soon. And by the time they decide to the midrange will have moved on to an even higher level. Rinse and repeat. I won't go into the economics of this again, not when both Intel and AMD don't see it as a feasible option just yet.
The compute shader wouldn't be injected, it would generate a coherent stream of culled geometry or indices prior to the traditional pipeline. The 4SEs can still only rasterize so much geometry with the high primitive shader geometry rate applying to culling. The compute variation should also work on Nvidia hardware.
Which chip was that? What I recall was Mobile Ryzen with up to a dozen CUs and KabyG's up to 24CUs. While similar performance could be possible based on power envelopes, I wouldn't consider those in direct competition. I haven't seen any >24CU Vega variants besides Vega56/64 and possibly a rumored 32CU Nano. I'd agree AMD can't match Intel's scale there, but Ryzen APUs would be well positioned for affordable NUCs, Chromebook/box, etc that wouldn't require thin and low powered designs.
Perhaps, but it may be the only option with current supplies. With high RAM prices and GPUs near impossible to find. For OEMs the smaller form factors would be more popular as the market moves away from larger desktops. Inevitably AMD needs to get into the market. They could cede the higher in mobile/ultra-thin market and still be positioned with moderately sized NUCs.
We're not disagreeing here. I'm stating that some scheduling constraints could be relaxed and larger, more complex shaders scheduled with acceptable performance. Avoiding situations where a spike in VGPR usage at some point in a shader's execution consumes most of the registers. The virtual registers would allow those inactive registers be paged, discarded, etc so more work could be dispatched. VGPR scheduling requirements changing temporally within a shader.
I'm suggesting a bin would be a fixed, consistent number of wavefronts with variable amount of geometry and long running shaders. Shift the pipline entirely into one CU with bin sized screen space dimensions. The occupancy constraint would shift as waves could be oversubscribed with the paging mechanism. A more compute oriented pipeline than the traditional fixed function that could be better distributed. Primitive count would be variable with bin dimensions determined by ROP cache. Have a CU focus on one section of screen space until all geometry has been rendered there. Removing the global synchronization with primitives only being ordered within the scope of a CU/bin.
I wasn't suggesting the PHYs for internal networking, but tying in external adapters that may only be present on server parts. Sized for 20 PCIe lanes instead of 16 or perhaps larger. If we can get a good die shot it might be interesting to compare Vega and Epyc PHYs to see if they are similarly sized.
That would be able to avoid insertion, since that is a different spot than originally stated.
Radeon Vega Mobile was announced at CES. A discrete Vega with 1 stack of HBM2 and 28 CUs.
Then perhaps I did not interpret the statement I was replying to as it was intended.
This seems to be assuming an additional change to the architecture, since waves are capped at 10 per SIMD. Relaxing register occupancy only goes so far.
That's likely to run into more complex trade-offs. There's a potentially somewhat stable working set of opaque geometry that may give somewhat similar wavefront counts, or at least with limited variation between adjacent batches assuming similar coverage and overdraw with the DSBR's shade-once fully in effect. The forward progress guarantees for the virtual register file would likely only give one primary wavefront per SIMD a guarantee of progress if register spills start to spike. More complex regions of screen space may do better spread over more CUs, as they can give more wavefronts forward progress guarantees while spreading any spill storms across more register files and caches.
That's nothing we haven't seen or knew already.A slide from the CES techday:
Source:
https://www.forum-3dcenter.org/vbulletin/showthread.php?p=11612392#post11612392