NVIDIA GeForce driver 369.09

Hmmm...

https://msdn.microsoft.com/en-us/library/windows/hardware/dn894173(v=vs.85).aspx

 

4KB to 64KB alignment always worked, there is no magical way that makes the OS use larger pages than 4KB.
The OS never moves those 4KB pages directly to the GPU, that is what the driver handles.
So how can you claim that is why MS came up with WDDM 2.1?

https://msdn.microsoft.com/en-us/library/windows/hardware/dn894173(v=vs.85).aspx

If it didn't work we would have TDR's all over the place since we would hit one invalid address after the other.

 

Mineria: you right, it should work perfectly fine with 4kb and 64kb as well but for some reason with 64kb didn't. Not happening always but once is happening , it leads to TDR . It was the case in past, nv did some workaround but the full fix for this issue had to be delivered by MS. Older intel gpu has been also affected . I really much like to point out, nvidia shares nothing if possible or just giving out false info. Ask MS and nv about this. I am pretty sure, when lot of similar issue is going around , the reps are doing nothing but stay in silent. It is a very bad way of communiqué . Has to be fixed from nvidia side too.

 

Because you're on a 7970? =)

If only pre-emption had anything to do with async, "full" or not...

Yeah, but this is an OS/WDDM side of the story while the application would surely crash from this and the OS itself might BSOD is that has happened in some system compnent like DWM. You are correct when you say that with such error we'd be seeing issues left and right all the time. And I repeat - this isn't something which WDDM can even affect. Siriq is just full of it.

 

Thanks

Thanks for that , this will surely help some member's that get stuck implementing other driver into icafe/ bland window's update installer's.

 

Can you stop with the awful attack's on fellow guru's!

Can't you see , all we are asking kindly at the first insight was a confirmed page not a unrelated website link that can't be confirmed nor deemed fit by many. A trusted site could be anything from linus to tom'shardware , yet you provide unrealistic evidence based on a site that hardly has any credibility. Then when asked for a more stable bit of evidence you , mock fellow user's an guru's?. Think you may give up before you dig that far into you're BS topic's and uniformed debate's you reach china.


For every action there's a reaction and for that reason you gotta back it up. Cause for one you can't expect everyone to believe you. Under a simple post assumption. Therefore you have to have research and provide us clarity into what you state as most guru's here have been using hardware since the Sinclair system's and need fact based evidence without com-premising the assumption you provided firsthand. But yet all you seem to do is provide more garbage onto more garbage without a stable front foot on that soil under neath that garbage pile you created. Please supply a credible website link and you're own evidence c1: , or back off and admit you're wrongs without attacking other's!.

 

Pre-Emption was the Goal in The Roadmap back then but AMD superceded it with Async Shader and Compute.

https://en.wikipedia.org/wiki/Preemption_(computing)

Sure it's nice for Nvidia if their Pre Emption is still taken into account but its inferior by now compared to a real multithreaded multitasking execution model like we have on CPUs already.

or in ITC terms "Outdated" "EOL" *deprecated*

you don't need to respect Nvidias 3d drawcall boundary limitation you just execute and go without any stalls or additional latency whatsoever and add workloads and keep the performance consistent, that is a major advantage backed up by ACEs in Hardware and what you can call true Pre Emption.

Your CPU cycles are totally freed your sync always clear and fluctuations non existent if you above 80% CPU Core Utilization even.

 

Again, 4kb to 64kb does works (64/4), calling a wrong address in registry has nothing in common with it, which is what leads to a TDR upon a failed engine reset, looking for something that does not exist, WDDM does it job by resetting the driver instead of triggering a BSOD.

As for WDDM 2.1, you are stating that it addresses an alignment issue, right?
My question is: Where did you or others got that information from? MS did not yet release any public whitepaper nor details around 2.1

 

WTH linus can be trusted? c'mon~ i usually will read various side & compared side by side. every reviewer doin benchmark methodology are different so i personally don't care bout the FPS that much but the smooth gaming experience & cons side regarding shuttering or other bugs. some reviewer daily income is directly from vendor & FYI, majority consumers/youtubers purchase technology stuff are theoretically based on review side or watching youtube. we can't trust them blindly without using common sense & bias mindset. apparently, i watched jayztwocents, linustechtips & other reviewers for purely entertainment only.

 

i have gtx 970 and motherboard b85-plus
with fast boot DISABLED

sometimes dont shutdown when select shutdown in windows, pc still on
what can i do for fix it?

 

try to disable deep sleep power state S4/S5 or flash the latest bios.

 

You are right that WDDM can't affect a program or driver from doing it wrong, it is however responsible for taking action and calling the TDR if the engine reset fails, I guess to prevent further damage.
I think we can fully agree on that it is working as intended with WDDM 2.0

Besides that 369.09 seems to run pretty smooth, no issues so far.

 

and where change disable deep sleep power state S4/S5

 

No that's not what i meant

What i meant was that at-least a website or linked provided that has some credibility would be sufficient but the fact is, all he has done is provide website links or NONE with no credibility at all. At-least you know of Linus but i didn't state all of Linus is true based evidence. I stated that using a website like that of , passmark , cpuz reports, tomshardware etc would be a good start , but all he has done as ive stated is provide literately nothing. Yet when asked "he either doesn't reply or reply's with things like, "not my fault you guru's cant research an find my evidence im referring too". Yet provide's nothing to his remark like an actual website with at-least some credibility than none at all.

 

Bios

bio's

 

Again? Really? Ok.

Async compute has nothing to do or is anyhow related to pre-emption. You can have async compute the way GCN does it and no fine grained pre-emption (which is in fact what you have on GCN at the moment) or you can have instruction level pre-emption on Kepler with no async compute in sight. In no way does one substitute another.

To make things even more complex, you'd have to say that while pre-emption is a known h/w feature of any execution pipeline, "async compute" is just AMD's marketing term which have no solid meaning whatsoever beyond the ability to submit compute kernels to the GPU in parallel to graphics commands. Even "multi engine" feature of D3D12 and Vulkan is just an API side s/w construct which - again - says jack **** about h/w execution of said feature as it's just s/w queues submitted to s/w driver, nothing more.

All GPUs need pre-emption, the finer the better. Not all GPUs need or will benefit from running async compute the way AMD does it. There is no "real multithreading", there is no "like we have on CPUs already", there is no "3d drawcall boudary limitation", there is no "without any stalls or additional latency" (that one was especially funny considering how much work it takes to actually make async compute produce solid performance gains on GCN h/w across the board), no CPU cycles are freed by running several queues instead of one (it's actually the exact opposite; the only reason we're seeing gains there is because in old APIs a lot of CPU cycles are just wasted) and in no way in this universe does "async compute" is a "true pre-emption".

Please, take your time to learn the things you're talking about.

 

How should i know everything? As i said before , ask them. I got other things going around here. One of the car just had accident and so on. I don't care too much now about further details, at least atm. The problem here, people like to say anything but act and ask. Most likely nv will give you some miss info anyway as they did with asyn maxwell case.

Also what really disturb me: Most of the optimizations we add to our drivers are not architecture specific so they should help most GPUs Means no more maxwell specific hw optimizations will be carry out. What can i say....

 

The features of WDDM 2.1 were already discussed 10 years ago (!) in this WinHEC 2006 presentation:

Windows Display Driver Model (WDDM) v2 And Beyond

Steve Pronovost, Microsoft
Henry Moreton, NVIDIA
Tim Kelley, ATI

http://download.microsoft.com/download/5/b/9/5b97017b-e28a-4bae-ba48-174cf47d23cd/pri103_wh06.ppt

 

You can be sure that Compute tasks will become more and more in a render Pipeline take a look at the whole Gameworks that is entirely Compute operated via Optix and Cuda and it has a lot of issues because the workloads need to be precisely timed or you lose performance heavily if you don't schedule it right it takes a big margin of your latency and that happens over and over on Nvidia Hardware.
And those Gamers really believe they can alleviate the issue with Overclocking which is another freaking Marketing stunt of a entire AIB sellers Industry.

I take the bet here how long it will take before you see Maxwell and Pascal results shifting in benchmarks away bellow AMD like back then when the opposite happened in favor of Nvidia

The Real star anyway is neither Nvidia nor AMD it's Intel they have the most advanced GPU currently at their Hand developed from the Ground up and its amazing if you once had the chance to work on it, i really still have hope Intel will bring out a Discrete Card like they planned with the MIC Consumer Larabee release and make some real fire here especially bellow Nvidias continuously upwards going Prices for their Midrange Products

 

These are old plans, they have nothing in common with what was actually done in WDDM 2.0, no reason to suspect that they relate to WDDM 2.1 either.

Using compute tasks in the rendering pipeline is of no issue even on an older architectures like Fermi.
Gameworks doesn't use Optix and only PhysX is using CUDA.
There are no issues with running Gameworks on GPUs, even PhysX.
There are no issues with scheduling compute into the graphics pipeline.
You can take whatever you want. What you write clearly shows that you don't know anything.
Intel's "most advanced GPU" have the exact same support for async compute as Kepler and AFAIK an even worse pre-emption granularity.

As I've said, learn things before talking about them.