On Newegg in US at the moment you can't buy a Vega unless it's in a bundle with other hardware like, motherboard, Ryzen CPU, monitor etc.
AMD Vega 10, Vega 11, Vega 12 and Vega 20 Rumors and Discussion
There is usually a difference between the usage of the word "made" versus "diffused".
The silicon can be fabbed in one place, but would be assembled in another.
The differences in packaging may be related to when in the sequence of packaging and testing the chips were discarded, if there aren't engineering samples in the mix.
It's possible the stage for applying the filler wouldn't be reached if early testing of the MCM and DRAM indicates an irrecoverable fault.
Indeed, there's no indication of Vega 10's being diffused at anywhere but GloFo, but we've been able to confirm that they are packaged ("made") by two different parties and filler or lack of filler is related to who's packing the thing
AMD will supposedly release a statement regarding it soon(ish)
AMD will supposedly release a statement regarding it soon(ish)
If it comes down to a which contractor is finalizing assembly, it would seem like this would be a significant variance mechanically. It's potentially different thermally if the noted difference in chip and stack height exists in devices sold.
Has anyone come up with a concrete hardware reason why Vega should perform so poorly? I mean, given its raw specifications, it ought to be much faster than the GTX 1080. Apart from immature drivers, is there anything noticeably wrong with the architecture?
It seems to me that "magic" drivers are a pipe dream but that we can expect very significant performance improvements over the coming months, unless there's a big issue I'm missing.
It seems to me that "magic" drivers are a pipe dream but that we can expect very significant performance improvements over the coming months, unless there's a big issue I'm missing.
All I can say is the driver situation is really mess. RX Vega has it's own driver package, Vega FE has it's own driver package, both separate from the mainstream crimson/pro all-in-one packages... And now FE has a beta driver which is missing the pro/gaming mode switch. Hope they can get this all reorganized sometime yesterday.
Meant to say "from a consumer's point of view" at least ^ (I guess I can't edit my posts yet, sorry)
Last edited by a moderator:
<ignore>
gamervivek
Regular
From the whitepaper, the geometry numbers keep going up, I thought this was 11 before,
Also L2 is 4MB now and,
Also L2 is 4MB now and,
https://www.computerbase.de/2017-08...ramm-deus-ex-mankind-divided-hbcc-aktiv-16-gb
I'm thinking the performance difference between Pascal and Vega is largely because of Nvidias memory compression advantage. Vega looks to be severely bandwidth limited.
I'm thinking the performance difference between Pascal and Vega is largely because of Nvidias memory compression advantage. Vega looks to be severely bandwidth limited.
Last edited:
I don't think so. Vega 56 has 20 % lower bandwidth than Vega 64, but average gaming performance is only 10 % lower. I think pixel fillrate might be quite significant limiting factor (64 ROPs at ~1500 MHz). Even GTX 1070 has ~13 % higher pixel fillrate than Vega 64 (GTX 1080 even ~20 % higher).
Pascal gains from memory OC too. There are different amounts of bandwidth "bound", and usually 100% unbound by bandwidth is a highly inefficient waste of resources.
Pixel fillrate being the limiter would have Vega lose ground at higher resolutions. The opposite happens.
I don't think it can be that simple. With increasing resolution, ALU:TEX ratio gets slightly higher and with the huge arithmetic performace of Vega, overall utilisation gets better. It probably (more than) compensates the low pixel fillrate. Anyway, real-world performance difference between Vega 56 and Vega 64 are in line with the fillrate difference (and not in line with bandwidth, ALU and texturing performance).
Anarchist4000
Veteran
More likely culling than memory compression. The color compression advantages were rather minimal as they fall to extreme cases. Lots of identically colored pixels over an area. Maybe 1% of the workload unless the game is cell shaded. The culling would be that many shader invocations that ultimately get discarded. That's less ALU, cache thrashing, fill rate, etc. Gets worse as resolution increases as pixel density goes up. It's more or less a driver issue dependent on the binning and tiled rasterization. Nvidia may currently have the bins ordered better. Binning helps with texture caching, but they need ordered front to back for occlusion culling along the lines of TBDR.
I personally think that it depends on how well the driver can replace Vertex Shaders with primitve Shaders, which then seem to improve binning and with that effective bandwith. There is a lot of potential hidden in VEGA, but I fear the driver team will have to work hard to unlock it and looking at the current driver state, I fear it will always be a bit hit and miss performance wise.
Don't the ROPs handle MSAA?
Binning could hurt texture caching too, so it's workload dependent. Think of a big triangle mixed with a bunch of small triangles. Normally the big triangle renders all together and cache hits are maximized at all levels of the cache hierarchy.
Now think of the big triangle being rendered in a bin with a bunch of small triangles. By the time the big triangle gets PS threads back on the same CU/SM with another bin the texture data in the L1 has likely been flushed. A big L2 cache means you'll probably keep hitting there, but you might incur more L2->L1 bandwidth. We've seen Nvidia has a large bin size and this is likely to ensure they don't miss in the L2 cache for textures and ROP data.
Since they go through the L2 now, maybe they're just thrashing it with the amount of sample data?
Last edited:
Perhaps some quirks with ROPs being now attached to L2 instead of memory controller, hopefully it's just a driver issue