AMD Mantle API [updating]

[gongo]

Hi Dave/anyone AMD?

I have a major problem with your new Mantle drivers...like major...at every cold boot, my 290X would run at half the perf! GPU-z shows the full speed, but 3dmarks/bf4 perf cuts by half...i had to reset CCC and restart to get the 290X back to speed

When i first installed the new drivers, i saw this screen...first time i ever seen it for umpteen AMD driver updates and i thought nothing of it...until today when i tested BF4 again...from 60fps to 34fps...i thought my 290X (unlocked) is dying...but nope..works after some grease work restart.

Yes..i did uninstall the old drivers before upgrading to mantle driver as instructed...

Yes...I did use MSI AB 1.8b all this while..but i had it uninstalled now...reset CCC...uninstall AMD drivers...and reinstalled...i even when back to 13_12 WHQL for the CCC while keeping the Mantle drivers...no go..problems abound...perf is dead on first boot...

 

[gongo]

ok guys, after all elimination testings..i can confirm my win8.1 64bit 290X is suffering from cold boot problem...with or without OC apps installed...

on cold boot, it seems the new driver fails to hook onto the perf mode....all 3D fps is cut by half.
upon restarting pc, all is back to normal.
it is a PIA to have to double boot my pc, hope to see 14.1 b2 asap.

 

[Osamar]

should[/I] pair mid-range GPUs with mid-range CPUs, and they should explain why.

I think they should test games in three computers, low, mid and high range balanced computers. And show what are the payable levels (resolution and detail level) for each one. It is a lot of work, but for me is better a good analisys a week latter than most of the tests we see the day after the game is launch.

And I am are not taking account of last minutes patches that disturb some fist day tests

 

[Jawed]

I hope someone does an analysis of the CPU limitation of individual graphics settings. And the same with varying combinations of those settings.

I ask in light of comparisons that indicate that NVidia is "less CPU limited" at lower graphics settings. But at "ultra" settings that advantage seems to disappear.

There's a lot of focus on D3D draw call count per frame but it seems to me that within the GPU/driver architecture there's another structure of state that has its own update (call-count) performance implications.

e.g. back in the bad old days, when D3D issued a change in the value of a constant for a shader, the shader would need to be recompiled because the constant was baked in to the code running on the GPU. That's an extreme, but I can't help wondering about the degree of these hang-overs of fundamental GPU architectural choices that impact performance below D3D's belt.

 

[lanek]

ok guys, after all elimination testings..i can confirm my win8.1 64bit 290X is suffering from cold boot problem...with or without OC apps installed...

on cold boot, it seems the new driver fails to hook onto the perf mode....all 3D fps is cut by half.
upon restarting pc, all is back to normal.
it is a PIA to have to double boot my pc, hope to see 14.1 b2 asap.

Try disable UPLS and see if this is what affect the performance. On first driver 14.1 ( not the b6 ), it was needed to disable UPLS .. ( note the 14.1 b6 for CFX seems disable it by default )

 

[homerdog]

If that's the case then the only solution would be that you test it by yourself.
Btw., my first statement to this topic specifically mentioned monitors with 120 and 144Hz refresh rate.

A locked 120fps would certainly feel smoother than locked 60hz, but I don't think that's what Andy is referring to. Saying 120fps on a 60hz monitor feels more smooth that locked 60hz is complete nonsense obviously. So you're both right?

 

[gongo]

Try disable UPLS and see if this is what affect the performance. On first driver 14.1 ( not the b6 ), it was needed to disable UPLS .. ( note the 14.1 b6 for CFX seems disable it by default )

no change

well at least i figured how to solve the above warning screen...it was because i chose not to install HDMI drivers (cos' AMD still dont do independent audio streams)...well now i have to lived with plenty of greyed out HDMI devices icons ..

The half-fps startup bug still unsolvable...there is no CTD, no BSOD, no event viewer errors...well only 3DMark error/unable to complete a run on first boot....so i cant submit error message to AMD....And upon a restart, everything is back to normal...terribly buggy drivers...I had tried to uninstall full, clean out the inf files using CMD....and no change..

It seems AMD was better when they were on the monthly updates schedule...right now they looks lazy and un-organised..

 

[mc6809e]

A locked 120fps would certainly feel smoother than locked 60hz, but I don't think that's what Andy is referring to. Saying 120fps on a 60hz monitor feels more smooth that locked 60hz is complete nonsense obviously.

Well let's not go that far.

It's possible that what users are seeing are variations in the time between snapshots of the world.

At 60Hz each image is displayed 16.7ms after the last, but at what time was the displayed image made between frames?

There's an effect similar to stutter that occurs when snapshots of the world are taken at irregular intervals but displayed at regular intervals.

For example, suppose (for whatever reason) the world is imaged at intervals 0ms, 3ms, 17ms, 20ms, 34ms, 37ms, etc. This avaerages 60fps. It's possible that each of these images will be displayed 16.7ms apart on a 60Hz monitor.

The trouble in this case is that moving objects probably don't quite occupy the expected locations on the display over time. The distance covered between 0ms and 3 ms, for example, would probably be less than the distance covered by the object from 3ms to 17ms, but if all frames are displayed at 60Hz, the object will appear to be moving slower between 0ms and 3ms (simulated world time) and faster between 3ms and 17ms.

What we really need to know is the difference and variation in times between simulated world time and display time.

I would expect a higher fps to give smaller time differences. It's also possible that Mantle through increased efficiency somehow reduces the time between completing the build of last snapshot of the world and it's actual display compared to D3D11. That would also tend to reduce the difference.

Then again, maybe everyone is seeing what they want to see. The only way to know for sure is to do a proper experiment.

Is there anyway to measure the difference between simulated world time and actual display time? I've never seen that done.

 

[hughJ]

Saying 120fps on a 60hz monitor feels more smooth that locked 60hz is complete nonsense obviously. So you're both right?

Would an unsynced ~120fps on a 60hz monitor not result in less latency between input and output? I would think that the time between the mouse polling and eventual scan-out would be much shorter than it would be at a vsynced 60hz.

 

[Gipsel]

A locked 120fps would certainly feel smoother than locked 60hz, but I don't think that's what Andy is referring to. Saying 120fps on a 60hz monitor feels more smooth that locked 60hz is complete nonsense obviously.

It's not complete nonsense, no. One has a lower absolute latency in the 120fps case. And if the time steps of the game world updates are coupled to the frame times (no clue how BF4 is doing it), it would also be a factor.

Edit:
Funny how 3 people essentially wrote the same within a few minutes.

 

[Andrew Lauritzen]

It's possible that what users are seeing are variations in the time between snapshots of the world.

If you're locked at vsync the "snapshots" are going to occur at the same intervals (~16.7ms @ 60Hz) and indeed roughly the same delta between vsync too. That's the whole point in vsync, it aligns the CPU loop to the monitor refresh rate. Most engines take the time-stamp shortly after the blocking present call, and even when they don't the CPU execution of a frame is still aligned unless the game does something silly and takes time-stamps after some highly variable section of code (and nothing can fix that issue other than the devs themselves - vsync off doesn't help).

I would expect a higher fps to give smaller time differences. It's also possible that Mantle through increased efficiency somehow reduces the time between completing the build of last snapshot of the world and it's actual display compared to D3D11.

No.

One has a lower absolute latency in the 120fps case.

Potentially slightly lower latency between pressing a key and seeing at most half of the screen... and usually the top half. You can't get around the fact that the screen only updates 60 times/second so for a given scanline there is at least 16.7ms of latency. And that's fine, because that's tiny compared to all the latency added in the software pipeline.

Let's not get rat-holed on this any more than we already are. Go look in GPUView if you're curious about how this all works in practice (pretty sure that'll work fine with Mantle too), but let's leave the anecdotes out of the thread please.

And again I'll reiterate that obviously on higher refresh rate monitors you can do better. I'm not saying the limit of human perception is 60Hz or anything (VR stuff is pointing more towards ~100ish), just that when you're v-sync locked with no drops on a given monitor, you're done. More performance beyond that point is not "better".

 

[Gipsel]

I'm all for not letting the thread to go too far OT, but the last few posts specifically adressed the question of running 120fps, i.e. a 8.3ms frametime (obviosly without vsync, or with vsync and TB for that matter), on a 60 Hz display. And this indeed reduces the delay between the "snapshot" of the game world and the display on the monitor (and not only the lower half, but for the complete picture; btw., without vsync, the lower pixels are usually the newer ones when the flip happens during refresh, the newest ones being the pixels right below the tearline ). You can't deny that.
And the theoretical minimum latency for a scanline is actually 0 (or lets say the time required for its transfer) also on a 60 Hz display (with infinitely fast computation), not 16.7 ms. 16.7 ms you get only when locked to the refresh with vsync. Without that lock and spinning faster than with 60Hz through the game loop reduces the latency (but may make it a bit jumpy for parts of the screen because of tearing). That's not a fairytale.

 

[Andrew Lauritzen]

without vsync, the lower pixels are usually the newer ones when the flip happens during refresh, the newest ones being the pixels right below the tearline

Indeed, bottom half not top. Not a critical detail to my point though.

And the theoretical minimum latency for a scanline is actually 0

Yeah, yeah but you can't "race the beam" in any meaningful way in current APIs, nor can you even do the low-latency variant of "triple buffering"... frame queuing is pretty much what you're stuck with, so the best you can do is minimize the queuing to a single frame ahead. Many games don't even do that, which makes any arguments about sub-refresh rate latency completely moot anyways.

With a 120Hz monitor (or better, gsync on such a underlying panel) I'm completely fine with the argument. On a regular LCD with tearing it just doesn't matter.

Ultimately Mantle syncs and presents the same way as D3D AFAIK (otherwise it would break the OS), so there's no magic there. Thus I'll leave this discussion at that and let the thread meander back on topic

 

[gongo]

after further testings...i found that on cold boot, the vddc voltage hangs around 1175-1180v when running 3D game.
this is unlike normal scenario where the vddc/pt will jump around from 1125-1210v....

i admit i did messed around with AB b18 vddc control on the mantle drivers trying to gain more mhz out of the OC. but i reset everything, uninstalled everything, delete AMD inf files...well it seems something was hit at the kernel level and needing to restart the PC....

i wonder who should i be contacting...? AMD or MSI AB...we have both reps here..if you guys are reading this, please help to attention to your bugs team.

 

[Gipsel]

nor can you even do the low-latency variant of "triple buffering"... frame queuing is pretty much what you're stuck with, so the best you can do is minimize the queuing to a single frame ahead.

So you can't discard the first backbuffer when the second one is completed (as the "classical" TB does)? Really? And is that also true for Mantle? I mean, it shouldn't be a problem for the hardware but just a limitation of the framequeue handling through DX (and DWM, it's too long ago that I looked into that to remember the details).

Edit: To ask the pros here, what are the DXGI_PRESENT_DO_NOT_SEQUENCE and DXGI_PRESENT_RESTART flags are doing with the queued frames on a present call?

 

[neliz]

i wonder who should i be contacting...? AMD or MSI AB...we have both reps here..if you guys are reading this, please help to attention to your bugs team.

IF you have an AB issue, there's only one place to go:

http://forums.guru3d.com/forumdisplay.php?f=55

 

[heli]

after further testings...i found that on cold boot, the vddc voltage hangs around 1175-1180v when running 3D game.
this is unlike normal scenario where the vddc/pt will jump around from 1125-1210v....

i admit i did messed around with AB b18 vddc control on the mantle drivers trying to gain more mhz out of the OC. but i reset everything, uninstalled everything, delete AMD inf files...well it seems something was hit at the kernel level and needing to restart the PC....

i wonder who should i be contacting...? AMD or MSI AB...we have both reps here..if you guys are reading this, please help to attention to your bugs team.

Is it possible 14.1 flashed the card to a different firmware? Is your card reference or newer one with custom cooler? Not sure if it makes difference though. If you have a test system that didn't go through the same things as your current system and problem still persists on that test system then it points to problem with the card.

One thing AMD doesn't do as well as NVIDIA is their support forum. On NVIDIA forum there are actually internal people from NVIDIA that relay or help customers with their problems. Not every problem of course, but knowing there is visibility makes huge difference. There is a feedback thread started by NV rep with each driver release including Beta. Right now if you are posting problem with Beta driver sometimes you're been yelled at by certain individuals saying that "it's Beta driver what do you expect" and tell you to use the report tool instead.

 

[Lightman]

@gongo - if it's of any help, my system with Z68A and i5 2500k was fine in gaming for both DX and Mantle in single card but wrecked for CF with almost instant hangs under my worn out Win 7 Pro x64 install. CF works well in W8.1 for DX but again not in BF4 Mantle.
One thing which wasn't right and sound similar to your case is when coin mining using cGminer 3.7.4 I was getting roughly half the speed most of the system restarts. Sometimes it would run at full speed as on previous drivers but more often at just half the speed (cold starts, restarts, tried even going into sleep and back but this made no difference). That happened both under W8.1 and W7 and I've tried uninstalling AfterBurner and resetting CCC settings to no effect on this weird bug. In the end I moved back to Cat.13.12 on W7 for mining and left Mantle driver on my W8.1 partition.

 

[lanek]

Is it possible 14.1 flashed the card to a different firmware? Is your card reference or newer one with custom cooler? Not sure if it makes difference though. If you have a test system that didn't go through the same things as your current system and problem still persists on that test system then it points to problem with the card.

One thing AMD doesn't do as well as NVIDIA is their support forum. On NVIDIA forum there are actually internal people from NVIDIA that relay or help customers with their problems. Not every problem of course, but knowing there is visibility makes huge difference. There is a feedback thread started by NV rep with each driver release including Beta. Right now if you are posting problem with Beta driver sometimes you're been yelled at by certain individuals saying that "it's Beta driver what do you expect" and tell you to use the report tool instead.

There's a forum on AMD site for driver / hardware related problem, now i think they count too much on the community.

 

[lanek]

Is it possible 14.1 flashed the card to a different firmware? Is your card reference or newer one with custom cooler? Not sure if it makes difference though. If you have a test system that didn't go through the same things as your current system and problem still persists on that test system then it points to problem with the card.

One thing AMD doesn't do as well as NVIDIA is their support forum. On NVIDIA forum there are actually internal people from NVIDIA that relay or help customers with their problems. Not every problem of course, but knowing there is visibility makes huge difference. There is a feedback thread started by NV rep with each driver release including Beta. Right now if you are posting problem with Beta driver sometimes you're been yelled at by certain individuals saying that "it's Beta driver what do you expect" and tell you to use the report tool instead.

There's a forum on AMD site for driver / hardware related problem, now i think they count too much on the community. http://forums.amd.com/game/