It could very well be the case. I don't think NVIDIA discussed at what granularity they can switch between graphics and compute tasks and I agree that a finer granularity is likely to bring more performance to the table.To my understanding Pascal can now switch between Compute and Graphics at the GPC boundary, which definitely is a form of concurrent compute + graphics. I'm just not entirely convinced of the usefulness when you can only switch between the two in 25% granularity (GP106 might be limited to 33% or 50% granularity, GP102 could increase this to 17%).
In comparison, AMD can switch between the two workloads in >3% granularity on Hawaii to stuff holes in the graphics pipeline. This seems a lot more useful to be honest to fill both expected and unexpected gaps in the graphics workload.
Emh, some just don't want to understand (not you).No point talking if nobody can understand each other. Which every post seems to imply.
There is no lack of visual quality. Nvidia is not rendering the snow properly so the scene looks sharper when compressed in a youtube video.Yep.
What's your take on the lack of visual quality shown in the side by side comparison?
I'm going to assume that -if this GPC boundary context switch is true- an implementation with a lot of context switches and heavy use of small compute tasks will still run slower than not using concurrent c&g at all. But game engines that keep Pascals architecture in mind and use heavy, bulked compute workloads could be able to get a performance benefit out of both Pascal and GCN.It could very well be the case. I don't think NVIDIA discussed at what granularity they can switch between graphics and compute tasks and I agree that a finer granularity is likely to bring more performance to the table.
Mistakes can be made. It could be a driver bug (either NVIDIA and/or AMD), an app bug, an error made by the person that recorded the benchmark/videos, etc..
With the information we have at this point I am more inclined to believe the developers never tested that FP16 path on Pascal. Pascal is simply ignoring the minprec hints, as the API spec document says it should do, and it's running the whole shader in full precision. In this sense there is not right or wrong, both GPUs are playing by the book and according the specs but still generate different results.
For instance neither OpenGL nor DX really specify how anisotropic filtering should really be implemented and HW vendors are free to use whatever they choose (and competition drove this feature to be implemented very well across all vendors over many years..)
Anyway, we will probably find out soon what is really happening.
...stuff...Someone edited the source code ...stuff... somebody EDITED the source code
Do you see a problem here?
Original quote from Brad Wardell
"...whether someone has reduced the precision on the new FP16 pipe...we can evaluate whether someone is trying to modify the game behavior"
If someone random can edit source code and Oxide not checking it but still publishing it. Then Oxide got a huge problem with their procedures. Sounds like Oxide is making another excuse.
I agree but it's nothing new. It happened pretty much for every new feature.I'm going to assume that -if this GPC boundary context switch is true- an implementation with a lot of context switches and heavy use of small compute tasks will still run slower than not using concurrent c&g at all. But game engines that keep Pascals architecture in mind and use heavy, bulked compute workloads could be able to get a performance benefit out of both Pascal and GCN.
Ironically, that could hurt a quick adoption of concurrent c&g since you can just hack-job compute elements into your graphics engine on GCN and it will give you a performance benefit, but Pascal will likely need a "do it well or don't do it at all" approach.
Renderstate - I'm assuming that you're "Ieldra" from HardOCP, this correct?[
I'm asking cause that Guy spends most of his day flooding every thread over there if asynchronous compute is ever mentioned. If it's not you, then I'm sorry for the call out.
Anybow, my point is: Nvidia stated that Maxwell will be able to perform asynchronous compute within the context of dx12 - this was last year, where is it?
I'm happy that Pascal can handle the workload, but Nvidia made big claims about Maxwell and it seems as though they don't want to acknowledge any faults within dx12.
Why won't anyone do a follow up article about Maxwell?
The issue is that the term "Asynchronous Compute" was a bad choice to describe what is actually happening.Anybow, my point is: Nvidia stated that Maxwell will be able to perform asynchronous compute within the context of dx12 - this was last year, where is it?
I'm happy that Pascal can handle the workload, but Nvidia made big claims about Maxwell and it seems as though they don't want to acknowledge any faults within dx12.
Why won't anyone do a follow up article about Maxwell?
Sorry to disappoint you but I am not leldra.
Even if Maxwell supports async compute it doesn't mean you'll get improved performance out of it. Maxwell implementation is likely not very good to begin with.
Async compute is not a magical wand that makes every application go faster.
I don't believe for a second utilization is close to 100%. Some rendering passes simply don't fill the shader cores, like shadow map rendering. Care toNever said it was some magic wand.
Some say that asynchronous shading isn't needed by Nvidia because their GPUs are already close to 100% utilization, yet these seem people neglect the mention that increased utilization isn't the only benefit - what about reduced latency?
There's one possible explanation that isn't too far fetched: Maxwell does have different schedulers for graphics and compute. They probably thought that there could be a way to effectively use them at the same time with controlled boundaries defined within their driver stack. Probably ended in a compatibility nightmare, as changing a software scheduler often does.About Maxwell and asynchronous shading, Nvidia was disingenuous when they somehow said that their driver team would solve their deficiencies in this area. I would hope everyone could agree on this - no?
If someone random can edit source code and Oxide not checking it but still publishing it. Then Oxide got a huge problem with their procedures. Sounds like Oxide is making another excuse.
Asynchronous Compute as a name makes perfect sense. It implies that you can feed the CUs with compute shaders at any point in the pipeline, without having to worry about the order they need to be executed in. It allows your engine to be multithreaded and queue graphics and compute shaders asynchronously, as in independent of each other.The issue is that the term "Asynchronous Compute" was a bad choice to describe what is actually happening.
Technically Maxwell can do asynchronous compute - as in, if your context of the chip has been switched to the compute mode then you can have multiple compute threads scheduled asynchronously (sorry for the complicated sentence). DX11 or 12 doesn't matter in that case.
What it can't do (to the best of my knowledge) is to do both compute and graphics workloads at the same time on different parts of the GPU (also called concurrent compute and graphics). GCN can do this, it can freely schedule any number of CUs to graphics and the rest to compute at the same time with very little side effects.
It should have been called concurrent c&g from the start, really.
Correct, and Maxwell can do this as long as you already are in compute context.Asynchronous Compute as a name makes perfect sense. It implies that you can feed the CUs with compute shaders at any point in the pipeline, without having to worry about the order they need to be executed in.
That isn't described in the term "Async Compute" though, that's just something GCN can do beyond scheduling compute tasks asynchronously - to schedule compute along graphics with no need for global context switching.It allows your engine to be multithreaded and queue graphics and compute shaders asynchronously, as in independent of each other.
So it appears to us that the screen disparity on Ashes snow rendering was caused by NV driver 368.19. Driver 368.25 should be fixed.