Do we expect GV104 to have tensor cores, part of Volta feature set?
AMD Vega 10, Vega 11, Vega 12 and Vega 20 Rumors and Discussion
No, but I would expect it to have their tiling rasterizer. I do not expect R9 390X to have half-rate DP either.Do we expect GV104 to have tensor cores, part of Volta feature set?
edit: And I do not expect GV104 to have a price premium on Tesla V100, as it is probably the case with Vega FE vs. RX Vega.
Last edited:
It depends on how the fillrate test is designed. I've seen tests, which render multiple full screen quads per frame (depending on what you want to measure exactly either with disabled z test or from back to front) and can have a significant overdraw. This is done to get rid of the overhead associated with a new frame (and at >40,000 fps @1080p for a GPU with 90GPixel/s fillrate [if you draw only one fullscreen quad per frame] that overhead used to be significant [you can also cut down on it by not clearing the framebuffer for a new frame]) and to approach the theoretical maximum. It works pretty well for an IMR (that approach can give too high numbers for a TBDR without enabling blending as you basically measure the performance of the HSR). It also means the bandwidth savings with binning are potentially significant in that case.
I would expect that solution. Nobody (also not nV) is going to implement two separate rasterizers in hardware. All you need to do is to skip the binning and just pass through the primitives and raster them immediately (as an IMR used to do). And as I said before, any binning rasterizer basically need this capability as a fallback anyway, afaiu.
The sort of localized deferred binning that it is attempting is limited by the finite capacity of the binning hardware, and certain operations that make it unknown at the time of binning what should be culled, may unpredictably/incorrectly affect something outside of the tile, or may compromise the intended function of the code.
That means bins can overflow or stop prematurely, and that means there may be a dependence or culling relationship between bins, or transparency. Given where it plugs in, the binning hardware's link to the rest of the GPU may constrain their ordering. Once binning starts the data in the bin may have dropped or compressed information that would make it difficult to do to bins what they did to the geometry in them, and it may constrain the overall geometry pipeline.
At a minimum, it makes this front end of the pipeline have longer latency, which if it degrades to the fail-safe method means it's a strict immediate mode renderer with a longer latency setup pipeline.
The fail-safe position from AMD's patent that seems most applicable is that binning doesn't stop. The hardware instead drops to 1 triangle per bin.
The way the triangle tiling test works depends on each pixel rendered incrementing a counter, allowing those whose count is higher than the threshold to be killed. If the deferred binning method were in play, why wouldn't it just show the very last triangle all the time if all other occluded pixels were never permitted to run the increment?
Per this https://www.google.com/patents/US20140292756:
There may be constraints on how serialized execution gets because there is binning and culling going on. As a first-gen product there could also be more conservative fallback cases, assuming it's working correctly.
I came across this post on Reddit and thought, "this makes the most sense of any analysis I've seen re: AMD's design decisions over the last several years that I've seen."
Comments?
Comments?
D
Deleted member 2197
Guest
Problem with your Reddit link.
Edit: Thanks. Using IE.
Edit: Thanks. Using IE.
Last edited by a moderator:
Shows up as an embedded post for me in Chrome (desktop).
But here's a direct link:
edit: guess everything gets auto-parsed by the forum software now...
But here's a direct link:
edit: guess everything gets auto-parsed by the forum software now...
I find some items believable, and some questions on some of the points.
The work stealing and scheduling optimization in hardware vs software seems like it might be conflating a number of things.
Nvidia still puts a lot of instruction issue and kernel scheduling work on hardware. Volta's thread grouping and handling of divergence actually expands this. Items like that are general parallel computation problems that AMD ***(edit: incomplete thought, would have added that AMD wouldn't be alone in this)
The specific points where it doesn't is more on an optimization of the in-kernel stream. However, I would say that generally AMD isn't devoting scads of hardware to optimize bad instruction streams--it just doesn't optimize.
Technically, AMD does have a gaming-dedicated set of GPUs. It's announced at least two bespoke GPU architectures in the last two years, one with leading features ahead of Vega and one that will be larger than Polaris and using GDDR5. I wouldn't blame the PS4 Pro and Xbox One X on HBM, although perhaps the diversion of resources into two variants of several-generations-old architectures should be examined.
Elements such as the underinvestment and lack of due diligence throughout its IP range seem plausible. My personal addition to the over-generalized architecture point, which I feel is broadly true, is that some of that isn't out of commitment to a jack-of-all-trades philosophy as a decision not improve any existing mastery out of an economy of effort and/or not valuing it.
Last edited:
Anarchist4000
Veteran
Looks like they have a few options.
gamervivek
Regular
The tiled based rasterizer has been said to be the secret sauce for nvidia's power efficiency but I think the answer is less arcane. nvidia have such a large lead in clockspeeds that AMD can't overcome despite being ahead in perf/mm2(normalized for clockspeeds). So AMD have to turn up the voltages and the result is a power-hungry chip that just nips at the heels of the corresponding nvidia card. AMD had similar lead in TFLOPs during the VLIW era that didn't translate into gaming performance, but they were ahead on clockspeeds, the 48xx series vs. the gtx 2xx series being the best example, and that made up for it. Polaris with clockspeeds north of 2Ghz would've been right next to 1080, 48xx was based on similar chip size with the >300mm2 dx11 chip coming in 58xx series a year later. Nothing new under the sun.
Anyway, the latest TPU review puts Fury X right next to a 1070, enough so that I think that if Fury had 8GB it would have made up the difference. A straight up Fury shrink clocked to 1600Mhz would have end up comfortably better than 1080, but the Vega FE results have been pretty disappointing even if you account for the throttling and excuse the power draw. Even the LN2 1400Mhz Fury chip got ahead of 1080 in 3DMark.
Anyway, the latest TPU review puts Fury X right next to a 1070, enough so that I think that if Fury had 8GB it would have made up the difference. A straight up Fury shrink clocked to 1600Mhz would have end up comfortably better than 1080, but the Vega FE results have been pretty disappointing even if you account for the throttling and excuse the power draw. Even the LN2 1400Mhz Fury chip got ahead of 1080 in 3DMark.
DavidGraham
Veteran
I remember back in the G80 days, NVIDIA had enormous amount of scheduling done in hardware compared to AMD's VLIW5 which relied heavily on the compiler, that remained the case through Tesla to Fermi. Kepler changed that a bit and relied on a mixture of compiler and hardware.
AMD was never ahead in clock speeds ever since Terscale was created. NV had double bumped ALUs which compensated for their lack of ALUs count, they also relied more on hardware scheduling, while AMD's VLIW suffered both lower clocks and lower utilization rate.
I don't know if it's straightforward to take clockspeed out like that, when it goes to judging performance per area. It goes to who made the right call with regards to the market, workloads, and the realities of manufacturing.
GP102 is roughly the area of Vega, has roughly the same base/turbo range for standard versions, is faster, and draws the same or less power.
Vega is acting like a Polaris/Fiji that is twice the size--with a memory bus that should have freed up area and power for the main silicon to waste.
Which basically means it is not binning anymore but processing the triangles serially (save for some overlap between different triangles falling into different screen tiles assigned to different parallel raster engines). You wrote yourself, that is is basically reverting to the classical IMR behaviour.
I don't get it. My conclusion was that the observed behaviour is a hint, that the binning is not in play for Vega right now. That's why it doesn't show just the last triangle color.
If you ask for Maxwell/Pascal. Well, if you don't do sorting of geometry / hidden surface removal (either because the circumstances don't allow it [transparencies, side effects or whatever] or your hardware is incapable of doing so), you still do all the work and just save bandwidth from the increased cache hitrate. That means you can still catch pixels after any amount of drawn triangles. But it still processes tile by tile (you have completed tiles with all triangles drawn and tiles with no triangles drawn on screen [in the framebuffer] at the same time), so binning is still working.
It's still binning per the patent because the hardware is still exercised and the additional latency is still there.
The binning is ineffective. It's also potentially injecting a specific order to where ordering isn't required.
Even if the binning were in play, it doesn't seem like skipping to the end of a shader that is supposed to be keeping a global count incremented by every pixel is valid.
Depending on how the hardware works, all the hardware locally evaluating a tile may know is that bin 1 has some unspecified serial dependence on bin 0. The binning process is at least locally sequential. It creates a first bin, then iteratively sends primitives that intersect with other tiles to those tiles for binning.
This first bin is reducing everything it is doing to one triangle, and the hardware is flagged as needing to pause any issue for the next tile until this tile is done.
That information is passed to every other tile, which will mark this in-sequence behavior and dependence on primitive 0, or it's because each triangle in the test has the exact same starting coordinates and bin coverage.
If the hardware/driver are conservative, they may say a screen tile cannot issue primitives in bin N if N-1 is still in progress and there was a dependence flagged for the initial bin.
In this case there's just one primitive, and there all tiles have the exact same sequences of bins due to identical coverage. The patent also indicates something like double-buffering the binning process, so it may also only queue up a few bins before stalling.
The process could be more parallel if there weren't a dependence, and probably if there were more than one initiating tile.
There might be some historical truth there... say in the AMD of 18 months to 2+ years ago. However, I don't get the impression that is an accurate representation of the AMD of today. Of course, Vega did not just manifest itself out of thin air a week ago. My impression is that after Maxwell, attitudes regarding energy efficiency started to shift, but the full gravity of the situation probably hadn't struck them. I suspect they genuinely expected to gain a little ground with Polaris... not lose more, and that Pascal was a wake up call that they actually took to heart. I do believe that AMD "gets it" now, but getting it and translating that into a product already in the pipeline while being stuck at 16/14nm when your competitor already has existing products in the market aren't the best conditions for success. While the early benchmarks show a practically flat efficiency curve, tiling is apparently not being used. Assuming that gets rectified, I would anticipate a 10-15% efficiency gain in general usage (perhaps even more in certain pathological situations). And that would be progress. Now, if I did not sincerely believe that they "get it" I would be less forgiving. And by the time products hit with the next node shrink (next year), they damn well better have made significant progress.
As for execution and ecosystems, yeah they need to settle on something and stick with it. With the launches, I think one easy improvement they could make is to understand paper launching architectures can be quite beneficial (both for them and their customers). You don't have to reveal everything, but get some solid details out there (mostly for devs but maybe even consumers). Plant the seed so that people start thinking about how they might want to use the new features, even before any specific product is announced. That way when product becomes available people already have in mind things they want to try and do with hardware. Inspiration happens randomly and sporadically, give it some time to grow. That way you foster demand for your products even before they are launched. Paper launch of specific products - bad.... paper launch of future architectures - good.
Anarchist4000
Veteran
Code:
#define V_008F14_IMG_DATA_FORMAT_16_AS_16_16_16_16_GFX9 0x2B
#define V_008F14_IMG_DATA_FORMAT_16_AS_32_32_32_32_GFX9 0x2C
...
#define V_008F14_IMG_DATA_FORMAT_32_AS_32_32_32_32 0x3FAnyone know what these are exactly? Context is all the usual color and compressed texture formats.
https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/radeonsi/si_descriptors.c#n2717
Other tidbits I came across.
