DX12 on fermi

Kepler/maxwell will be left in the dark on async side. If Fastsync also will be killed then one more nail in the coffin. Just way to many issues withe drivers in the past 7 months already. I am also effected by these fantastic issues.

 

Only a beta driver(has been released in okt 1015) with very limited features. It works in 3dmark api overhead test dolphin and god knows in what else.

 

IIRC there was one driver that enabled it for a few applications.

Honestly if anything it seems like Nvidia thought they could make it work, began testing/bring up and ran into some bug or issue that they couldn't work around or would cost too much to create a work around.

What I don't get is why they wouldn't just say that. I think if they came out with a statement like:

"Hey guys we thought we could get DX12 on Fermi but it turns out X.Thingamajig doesn't work with Y.Thingamajig for reason Z.Thingamajig."

I think people would appreciate that more then just silence.

 

Nvidia assured multiple times fermi owners the driver will be released .

Gotta go now.

 

Ok, so at least we know it exists then rather than a fabled never-released driver.

Well guys, I wish you the best of luck with this. I had a GTX570+i5 750 system which I sold in 2013 and did have great fun with it during the time I had it.

 

I can confirm that with latest drivers 368.71 and 368.81 I'm not able to use FastSync with my fermi card. In previous drivers it was working real good and I didn't have problems with FastSync. I tested this function in FIFA 16 and with previous drivers it works as it should, I had instat reaction of my players but now I need to use normal V-sync to keep 60fps and my players reaction are much worse.

As for async I thought that all cards that have sheduler in hardware (Fermi, Kepler, Maxwell, Pascal) are able to use async and the ability to enable this function is for the Nvidia and their driver side.

 

Async on nvidia side is very limited by hw. It is capable but the performance is as i mentioned limited. Nv can do some optimizations to compensate the negative impact once the async is turned on. In reality , not much benefit will be seen. Lies down to the code path and hw scheduler design . Pascal indeed is bit better design but don't expect any miracle to happen.

 

It is my understanding that maxwell and pascal do not support asynchronous execution of tasks. They instead rely on preemption to achieve a similar effect(techincally running asynchronously i suppose?).
The idea is that Maxwell's preemption capabilities for switching between a graphics and compute workloads is too slow to gain performance , most of the time costing performance.
Pascal would appear to be a much need improvement in this area, not as effective as amd's ACE's but good enough to achieve a net performance gain

BUT I still don't really understand it that well, so take it with a grain of salt i guess.

 

Pre-emption has nothing to do with asynchronous compute and concurrent multiengine execution especially.

 

It's kind of ironic that everyone bashed AMD for announcing they won't be supporting DX12 for pre-GCN GPU's (the HD5xxx and 6xxx series), and praising nVidia they DO support DX12 on Fermi...
And now in hindsight we can only say that at least AMD was honest...

 

Then why does maxwell need to perform a context switch when executing graphics and compute workloads concurently?,

Just curious.

I am only referring to handling of mixed workloads to be clear.

 

You have to perform a context switch to execute a different context on the same h/w. This has nothing to do with executing anything concurrently because with concurrent execution 2+ contexts are being executed at the same time and as a result there's no context switch needed.

Maxwell have an ability to execute compute concurrently with graphics by partitioning the SMs between these two contexts. However, this partitioning is static during the application activity (i.e. it is created when the application starts and can't be changed after that) and as a result most applications are performing better when running graphics and compute sequentially instead of concurrently.

Pascal improved that ability and is now able to change the partitioning at any moment making concurrent execution applicable to all s/w which submit work into asynchronous compute queues. This have nothing to do with pre-emption.

 

Maxwell scheduling = static allocation. This would explain the context switch and the entire pipeline stall to switch from the graphics queue execution to a compute queue execution.

 

ah that makes more sense, reminds me of the difference between unified shaders vs separate pixel /vertex shaders.

where do you read this stuff anyway, good info can be scarce these days.

 

Most of this was disclosed when they've launched Pascal, most sites covered that in their Pascal reviews.

 

there is alot of crap floating around too,
don't really want to filter through all of that.




In other news, timespy crashes as expected with the 358.70 dev driver unfortunately.

 

I think it'll be better if you switch to amd, no need to keep up with nvidia and their lies anymore, I will switch also after this 3.5 GB of a card got sold.

RX 480 would be a nice upgrade from your 570.

 

Someone here having issues with 368.x drivers related to clocks? I tested with my two 560 separately, it keeps downclocking to 405MHz, not everytime, but sometimes when I open games, or browsing (rarely), it happens when I'm on overclock, but the clock is stable, I can run Heaven Benchmark for days if I want, even with newest drivers, the problem just happens when the game is closed and you open, randomly it downclocks to 405MHz, but if the downclock does not happen, you can play without problems.

I'm using 314.22 drivers for 2 weeks now, overclocked etc, and no problems until now. I've playing some games, CS:GO, MGS TPP, and Overwatch, everything is fine with more old drivers.

EDIT: I think that the problem is related to P-State changing, I use dual monitor, the P-state is always P0 when is in dual monitor (it's normal on Nvidia). When I open a game, if it's full screen, maybe for a sec it changes the P-state and can't go back to P0, I think, but not sure.

 

Nvidia did change the power management mode default to the new "Optimal power" option in 368 ,you could try settting the global 3d profile in nvcp to maximum performance and see if that makes a difference, other wise you'd might as well stay on older drivers, since they don't really effect performance on fermi.

 

Did they remove adaptive option in 368.xx ?