No it won't. It might have similar functionality though, but HBCC needs that HBM "cache"
Is not necessary but better because of the latency and BW advantage of HBM over ddr.
No it won't. It might have similar functionality though, but HBCC needs that HBM "cache"
I believe this has been discussed before but the high polygon throughput is likely a potential based on culling primitives, not magically being able to generate more polygons than its 4 setup engines is capable of. That test you linked isn't designed to test any kind of discard from what I know.
I see, I missed that part of the screenshot sorry. I thought it was just a polygon throughput test.The data I posted is specifically for 100% culled primitives. Here is a larger version that includes Vega 64 at Fiji clocks.
Oops, I only just realized that the Hardwareluxx article had them leaving the power target at +50% and still getting reduced power consumption compared to stock. I had assumed they had reduced the +% power offset to the minimum necessary to sustain the combination of clocks and undervolting they were using, as the newest driver supposedly made it possible to undervolt and increase the power target only enough to stop throttling behavior, rather than having to set the power target to the full +50%. I was inferring the same would be true of what GN achieved on launch drivers (i.e. if you could reduce the power offset to the minimum necessary to sustain the boost clock at the lower voltage the resulting power usage would be below stock settings).Undervolted (1200->1025mV) and set to +50% power, Gamer's Nexus Vega 56 is drawing 30-70 Watts more than stock.
It's a different format, which prior to Polaris AMD's setup pipeline had lower throughput for.I see, I missed that part of the screenshot sorry. I thought it was just a polygon throughput test.
Why is Strip so low on Fury? I assume List is the indication that it isn't working.
That bottleneck, if the case, would be no different than prior GCN products and readily bypassed with async compute. Primitive shaders likely needing dev intervention to cull more than before. The only automatic gains should be the deferred attributes which will be difficult to attach a number too. Less cache usage on a cache that is likely significantly larger than prior generations based on Scorpio's parameter cache increase. Along with less wasted bandwidth.I believe the explanation is that RX64 is suffering much more severely from being front end bottlenecked by its polygon throughput still being on the order of 4 triangles per clock since primitive shaders have not been enabled in drivers yet.
Not wasted, as the device should be dynamically scaling towards the demands. Not doing work will conserve energy and the cards still hit that limit easily enough. The cards would need to be extremely power limited if hitting that 4 triangle limit and power limit while most ALUs are idling from lack of work. As mentioned above, that limitation would be easily worked around with async.As a result the higher power target and CUs of RX64 are simply being wasted. RX56 is proportionally less effected by the front end bottleneck so its showing much better perf/watt even without primitive shaders enabled.
You forgot packed math and intriniscs/SM6 which should stack as well. Now AMD just needs to change Omega to Magic for their drivers and run with the free advertising.So, primitive shaders have not been enabled in the drivers yet. Also, DSBR is not working for each and every application out there. Also, HBCC is disabled by default, even though it can potentially increase performance by double-digit percentages. Add all of that together (if those are accumulates) and you have your 1080 Ti competitor.
So, primitive shaders have not been enabled in the drivers yet. Also, DSBR is not working for each and every application out there. Also, HBCC is disabled by default, even though it can potentially increase performance by double-digit percentages. Add all of that together (if those are accumulates) and you have your 1080 Ti competitor.
I doubt that is actually the case. I think its more people trying to figure out why vega suck that much(actual performance in games vs raw power vs last gen) when it was so hyped.If that is acuatlly the case, the whole management of the Radeon Group needs urgent replacement. If you have a powerful piece of hardware and your driver hold it back that much, your organisation, planing and execution are just bad.
LC Vega 64 Vs 1080FE in 27 games:
http://www.babeltechreviews.com/veg...led-edition-vs-gtx-1080-gtx-1080-ti/view-all/
This is not a matter of "if". The B3D Suite results directly show that Vega currently has a culled triangle throughput of 3.75 triangles per clock, which is not compatible with the claims made in the whitepaper about primitive shaders and their effect on culled triangle throughput. Unless someone is going to assert that RTGs claims in the whitepaper are fabrications, one is forced to infer from the B3D Suite results that this feature is not activated in drivers yet.If that is acuatlly the case
All the really bad outliers appear to have MSAA on.....Nice grouping by time/age and API. Tempting to project the results to 2018 and DX12.1 or Vk1.1.
Questions in no particular order:This is not a matter of "if". The B3D Suite results directly show that Vega currently has a culled triangle throughput of 3.75 triangles per clock, which is not compatible with the claims made in the whitepaper about primitive shaders and their effect on culled triangle throughput.
It's tempting to presume something, but there's so many choices!Unless someone is going to assert that RTGs claims in the whitepaper are fabrications, one is forced to infer from the B3D Suite results that this feature is not activated in drivers yet.
Drivers, by definition, are always sub-optimal. There's always new code they've not encountered before, and tweaks are required. Compilers can always be improved. etc.As for why RTG would throw RX Vega out the front door with the drivers in this state? Who knows. Personally, I would have delayed until the drivers were in better shape than this.
Fair enough. I still think it is fair to say that the results of this test, when combined with the apparent 100% identical performance between Vega 56 and Vega 64 at the same clocks in both this test and games strongly suggest that primitive shaders are not currently enabled in the RX drivers for any application, not merely the test suite.Questions in no particular order:
- Is the B3D suite working properly?
- Does the driver detect the B3D suite as unsuitable for primitive shading?
- Has the driver been coded to preserve image quality, at the cost of performance, when in doubt?
- Is there a bug in the driver when running this test?
- Is the driver just crap on the entire subject of primitive shaders?
- Is the performance of Vega in the B3D culling test exactly what it should be with primitive shading active?
- What else?
I have no idea, but I certainly hope the answer is sooner rather than later as my curiosity is killing me.Drivers, by definition, are always sub-optimal. There's always new code they've not encountered before, and tweaks are required. Compilers can always be improved. etc.
So, while it seems reasonable to assume the driver is indeed crap at extracting the best performance from Vega, the question is really, how close to "working as intended" is the hardware/software combination of Vega. 1 month? 6 months? A year?