What i mean if you see the Advantage nvidia did from Kepler to Maxwell. (From Intermediate to tiled based rastizer) you will get my Point. Saves a lot of energy and dosen't argue the shader with workloads which are not needed.
What would be the benefits of a TBDR in a scene/engine, which does it's own HSR with a z-prepass for example.What i mean if you see the Advantage nvidia did from Kepler to Maxwell. (From Intermediate to tiled based rastizer) you will get my Point. Saves a lot of energy and dosen't argue the shader with workloads which are not needed.
That's true also for Maxwell/Pascal. They always have a fallback mode to the traditional behaviour. They have to (because some situation require it and don't allow binning or at least severely restrict it).
But the most games are now optimized for Nvidia.
I fail to see the connection between a synthetic tool which might be detected (whether or not correctly remains to be seen) by the driver as not profiting from DSBR and games that allegedly "prefer TBR because they are optimized for Nvidia" (UE and Cryengine for example would like to differ).But the most games are now optimized for Nvidia. That means the most games prefere a Tiled Base Rasterizer. Why not follow this way?
The fallback can be implemented differently, I guess. Two rasterizer methods or one, which has a "do not sort" option, but traverses the binning buffer nevertheless. And of course we could be looking at a simply misdetected application behaviour.That's true also for Maxwell/Pascal. They always have a fallback mode to the traditional behaviour. They have to (because some situation require it and don't allow binning or at least severely restrict it).
I fail to see the connection between a synthetic tool which might be detected (whether or not correctly remains to be seen) by the driver as not profiting from DSBR and games that allegedly "prefer TBR because they are optimized for Nvidia" (UE and Cryengine for example would like to differ).
The fallback can be implemented differently, I guess. Two rasterizer methods or one, which has a "do not sort" option, but traverses the binning buffer nevertheless. And of course we could be looking at a simply misdetected application behaviour.
In short: I am not yet convinced that the DSBR is completely inoperable with current drivers. That would be a major eff-up for AMD, since performance results WERE bound to be published regardless of the state the card and it's drivers are in right now.
Not sure if i would agree. I don't want stability issues on my PC in general. Just think of competitive e-sports, where real money might be at stake. And "Pro" is, as has been discussed at length earlier, not the same as "WX".You would not want "PRO" card to have any instability would you? If there is some issues, they would be wise to restrict that issue from happening. It's not so important on game cards is it? So basically "betatest" with RX Vegas.
I meant to quote this:
Cant find edit..
Process shrink? 14nm vs 28nm on the Fury X. Performance metrics so far basically make it a 14nm Fury X with seemingly no other optimizations or differences.Vegas NCUs must be different. How will you reach 1.6 Ghz whiout Major changes inside the CUs?
Believe Ryan mentioned running professional tests overnight (takes 12 hours) and should have the results when the live stream continues sometime this morning.Has anyone tested Vega FE in applications it is meant for? Such as Maya, 3ds Max, Solidworks... How it works with Radeon Pro Renderer? How good is it for VR?
Polaris is already on 14nm and can barely reach 1.5Ghz on liquid cooling.Process shrink? 14nm vs 28nm on the Fury X. Performance metrics so far basically make it a 14nm Fury X with seemingly no other optimizations or differences.
The z prepass could be a bit faster. And that prepass basically populates the z buffer (and the early-z metadata connected to it) so the early-z rejection can operate near peak efficiency in the following pass. But a TBDR should be even more efficient than that. And also the limited binning of Maxwell/Pascal or supposedly Vega can bring additional benefits (you can reject stuff even earlier than with an early z test).What would be the benefits of a TBDR in a scene/engine, which does it's own HSR with a z-prepass for example.
Even for a simple fillrate test (which often draws full screen quads back to front [or with switched off z test] to reduce the overhead for a new frame) a tile based binning offers the benefit of increased cache hitrate and (depending on the circumstances but potentially vastly) reduced bandwidth requirements (for all cases which aren't ROP bound but bandwidth bound, i.e. blending or fp16 framebuffers [transparent stuff]).Or in a synthetic test, that just renders a plane of two large quads to measure pixel fillrate, for that matter. I cannot think of any, and the binning stage would be unnecessary at best and a bottleneck at worst (depending on it's actually modus operandi). So, if you have the chance to turn your DSBR on and off based on a reasonably working detection scheme, I'd call that an advantage.
If it would bin (even without any sorting/hidden surface removal stuff Vega is supposedly capable of), the chip would work on all buffered geometry in a bin (or two or four, depending how many fit the caches simultaneously) before starting the next tile. That is definitely not visible with Vega in this triangle bin test. The geometry appears not to be binned at all, it is processed serially and not binned in tiles.The fallback can be implemented differently, I guess. Two rasterizer methods or one, which has a "do not sort" option, but traverses the binning buffer nevertheless.
I never said it is proof. I always wrote about what appears to be the case. And I explicitly hedged my bet and offered two possibilities:In short: I am not yet convinced that the DSBR is completely inoperable with current drivers. That would be a major eff-up for AMD, since performance results WERE bound to be published regardless of the state the card and it's drivers are in right now.
So either that tool can't catch it properly (but it can in case of nV's GPUs) or AMD still needs to switch it on in a later driver.
Not sure if i would agree. I don't want stability issues on my PC in general. Just think of competitive e-sports, where real money might be at stake. And "Pro" is, as has been discussed at length earlier, not the same as "WX".
And Vega has been "optimized" for higher clocks, which is one new feature I guess, but still on normal operation (FE) operates around 1.4Ghz without additional cooling being applied for sustained higher clocks. My point is that so far it's operating like a Fury X at much higher clocks.Polaris is already on 14nm and struggles to reach 1.4Ghz.
And has several new features as well. HBCC hasn't been tested since reviewers weren't sent any cards so we don't know how well that operates in memory management, we'll see more focus on that when RX Vega is released. Otherwise, for such a large chip, it doesn't seem to be performing as such.Vega's die size is considerably larger than a Fiji shrink should be.
Indeed, and controlling/triggering that is the big breakthrough that David Kanter made in order to prove there's TBR. When you're using standard debug tools, TBR isn't (or at least at the time, wasn't) turning on, possibly because NV wanted to hide it, but more likely because they didn't want TBR getting in the way of debugging. TBR is meant to be transparent to the developer.That's true also for Maxwell/Pascal. They always have a fallback mode to the traditional behaviour. They have to (because some situation require it and don't allow binning or at least severely restrict it).