Originally Posted by bman87
This issue has been a real pain in the ass, and I think I finally figured out what was going on. The first clue was when I played BF3, sometimes it would be really choppy, even if I dropped the GFX settings to low. I would reboot and the issue would go away for some time.
Then I had a friend that wanted to play GuildWars 2, so I fired up the game and I was having severe FPS issues, no matter what resolution or video settings I used, I was only getting 10-20fps. After reading some forums for fixing this issue for GW2, I found my issue.
I opened up GPU-Z and checked the bus interface speed. There it was, set to PCI-E 1x v1.0. After I reboot, it goes back to normal 16x v2.0. I believe this gets stuck in 1x mode after I remote desktop into my PC.
Has anyone else experienced this? Is this a known bug? Is there any way to fix without rebooting the PC? This has been happening for a long period of time over different driver releases. I am currently on 13.9 and I still have the issue. I am glad I found the actual problem.
AMD 7950, Intel Core-i7 920, 12GB DDR3, Windows 7 64-bit.
A minor thing perhaps, but it should only take you a few minutes to correct--your system specs differ enormously from your signature specs...;) I take it for granted that your signature specs are the correct ones...?
I didn't see anything in those specs as listed that indicated you were doing Crossfire, and so if you are not you don't need to worry about ULPs as that setting chiefly gives some people problems only in Crossfire situations, where ULPs applies. I haven't touched the ULPs settings in any of my Catalysts--I don't run Crossfire--and I've had no problems at all related to my default ULP settings.
To answer your question: no, I've never had my system switch to PCIe.1.x simply because I allowed remote access
--which 99% of the time I never allow, anyway...;) But, GPU-Z 0.7.3. works this way for me...When I run it from the desktop it shows me the capability of my GPU in relation to the maximum version of the PCIe bus standard it will support: mine says: "PCIe 3.0x16 @x16 1.1"; this means that my card supports 16 lanes of PCIe 3.0 but that my PCIe bus is currently running with 16 lanes of PCIe 1.1 bandwidth, because I'm in 2d desktop mode and not running any D3d or OpenGL accelerated software.
When I hit the "?" beside this box in GPU-Z, and the GPU-Z 3d-accelerated software starts running, it changes to, "PCIe 3.0 x16 @2.0 x16," which means that my card will support 16 lanes of PCIe 3.0 but that the maximum my motherboard will support
under 3d acceleration is 16 lanes of PCIe 2.0 bandwidth. IE, the level of PCIe acceleration I run when running 3d-accelerated software is PCIe 2.0 because that's the max my motherboard supports even though my card will support a PCIe 3.0 motherboard (when I buy one.) So you see, switching between low to max PCIe bus bandwidth is quite the normal function of modern motherboards and therefore should have nothing to do with the problems you have indicated you are having as described in your post.
I deliberately bought a PCIe 2.0 motherboard, btw, because it was a better buy than the 3.0 boards at the time (they had just rolled out), and because I planned on running a discrete 2GB gpu anyway (as opposed to an IGP) and so 99% of the time the bus bandwidth of my discrete gpu is the bottleneck as opposed to the motherboard bottleneck of PCIe bandwidth, and the bandwidth of my card is some 10x-20x faster than either the bus bandwidth of PCIe 3.0 or PCIe 2.0. That's why today's gpus come standard with so much ram--the more local ram the gpu has to feed it the less it depends on the speed of the PCIe system bus--your card has 3GBs and mine has 2GBs and in most cases by far that almost completely rules out having to ever texture directly from system ram and therefore limited to the far lower bandwidth of the system PCIe bus, and texturing is the most bandwidth-dependent task the gpu will do. What all this means
is that with a fast, current 3d card installed with plenty of on-board local ram, the differences in overall system performance between a PCIe 2.0 system and PCIe 3.0 system are negligible at best.
The scenario in which PCIe bus bandwidth becomes critical is when there is no discrete gpu with plenty of fast ram--but in an IGP situation where graphics ram is shared with system ram. PCIe bandwidth makes a lot of difference in that situation for obvious reasons--PCIe bandwidth is all an IGP has to texture out of because it has no local pool of dedicated memory.
Boils down to this: your system changing PCIe bus modes is *normal* behavior between 2d and 3d-accelerated states, and would not cause the problems you are having. Neither would remote access to your system cause your described problems. Also, as you appear to have but one 3GB 7950 gpu installed then ULPs settings can be ruled out, as well. (The above information was a bit of background information to better explain my reasoning (hope it helps)...;))
In my system, as an example, I always have Cool'nQuiet turned on in my UEFI (bios)...because when I am doing 2d stuff like web browsing and word processing or streaming movies, etc., my gpu has no need to run flat out at ~4.2GHz-4.5GHz...;) But the *second* I fire up a 3d-accelerated application, game or otherwise, both my gpu and my cpu instantly and seamlessly jump to max performance--I've never experienced so much as single hesitation hiccup when the power is needed. My cpu jumps from 1.4GHz to ~4.5GHz instantly; and my gpu jumps from 300MHz gpu/150MHz local ram to 1.05GHz/1.4GHz (remember to quadruple gpu ram speed to get the effective speed.) Again, when this happens for me there are no performance problems even remotely similar to what you have reported--ie, power-saving profiles generally should not cause these kinds of problems.
However....;) There are a few caveats to the Windows power-saving profiles that could well contribute to some of the things you mention
. For instance, turn your power profile to maximum performance, and make sure that your hard drives and network adapters *never* turn themselves off--and make sure that no device has the authority to disconnect itself from the system as a power-saving measure. All of these settings can be manipulated in the Control Panel "Power Options/Advanced" settings. Make sure you set these correctly to never turn off these devices--otherwise you won't get the kind of instantaneous power boost that I get if your hard drive has to turn on and spin itself back up, your network adapter has to reconnect to the network, etc.
Just having to guess at probable causes for your problems, I'd say that tinkering with your power profile.cpl certainly will help if you have a lot of your devices disconnecting or shutting down when performance demand is low...so that when you need the power it is slow in coming and you have to "reboot" before everything comes up to speed and so on. And also, your performance problems sound a lot like what used to happen when for some reason the 3d card would take its time in going to 3d-acceleration from 2d mode (not talking about MHz speeds here.) This happened to some people regularly back when we were transitioning from PCI to AGP...;) But this kind of thing isn't experienced all that much these days, so all in all I'd have to say my guess at the moment is that your Power Profile in Windows is set for minimum usage and that a lot of stuff is set to turn off/disconnect after a certain period of time in which high-performance isn't needed.
Set the power profile to high performance, everything stays on/connected all the time. Then, set your Intel equivalency to AMD's Cool'nQuiet
however you wish to set it so your cpu will run nice & cool when you don't need the power but respond instantly with max power when you need it
. 1.4GHz is as low as my CnQ will let me go for my cpu, and that's plenty low enough for me--and you don't need to worry about your gpu as it will take care of itself through the Catalyst drivers.
--I hope this helps you out! I went into some depth here because these kinds of problems can be complex and it helps to understand the backgrounds of some functionality in the environments of other people before we can suitably understand our own rig behavior--at least, it's always helped me out in solving my problems to understand these things.
Heh...;) I'll have you know this post consumed a big chunk of my Saturday night! My pleasure though, as it's always nice when I can offer a constructive bit now & then...! Let me know if these suggestions paid off for you--if not, I'm sure I can think of a few more...! (Never leave any problem unsolved if at all possible!)