I'm wondering if he's having issues with h.264 because he has a non cert GPU using accleration. Because my h.264 exports work fine as well.
Ugh. Well, that's not awesome. I mean, I'm glad you're not having any issues, but I guess my Friday will be spent troubleshooting.
Have you tried Premiere to MPE software only mode instead of GPU acclerated?
That's what I was thinking, but it worked fine before the update. I suppose it's possible the update caused some sort of issue with the H.264 encoding w/ the non-supported card.
Update: Using MPE only didn't fix the issue. It's gonna remain a mystery for now. I'll remove the card from the text file, restart and try again when I get a chance.
Already did that and I'm still experiencing the issue. I don't know if removing the text file will work, but I only experienced the issue after adding my card to it after the 6.0.2 update. I had no issues with the card added to the text file while using 6.0.1. If that makes any sense... To clear up any confusion, the update removed my card from the compatibility list in the text file and I had to add it again. After I did, I began experiencing the H.264 output issue. Thanks for everyone's comments. I'll get it figured out I hope.
I just had another person report the threading issue and they have a 570GTX card. What Nvidia driver version are you both running and how much ram do you have installed? I received a report from a client with a 285M card on a laptop and their encoding performance increased by 3x. So this is definitely not across the board and is configuration specific.
Eric, I am having the same bad performance issue with Hyper Threading on my HP Z820 - GTX 570 system.
With the CUDA set to software I see all 32 threads active in the Task Manager
When I select CUDA hardware it drops down to 16 threads , which appears as every other thread is inactive.
I have 64GB of ram on the system
I am running the GTX 570 with the System Driver 188.8.131.52 , Driver File Version 8.17.13.0142 and Familair Drive Version 301.42.. Memory for card is 1.25GB.Registry Frimware Version 184.108.40.206.1.
Info from the HP Performance Advisor
It doesn't take the load of the CPU, it splits the load within a given time segment. If the CPU can handle more and the requests demand it then the CPU load will still remain high. The GPU acceleration however will allow exponential increase in the amount of data processed at one time so you process twice as much data in a microsecond versus the same data in the same time. That is the part people forget. The acceleration does not always mean half the load split equals less load. It often means processing more data by both in the same amount of time.
The observation Lasvideo has is the same I am seeing here. The Hyperthreading is not occurring when it was before with the exact same project loaded with 6.0.2. When I played this same project in 6.0.1 on this system the load scaled across all threads and it played smooth at 1/2 res or full res. In 6.0.2 it would no longer play smooth at 1/2 res and the CPU would still not use the HyperThreading Cores. When I changed the Playback res to full the playback was horrible barely handling 1 to 4 frames a second and yet the CPU load did not change nor did it thread any better. Increasing the scale from 1/2 to Full always increases the load on the CPU. However with 6.0.2 it did not do that at all. It simply degraded the playback further. To add to this, of the 6 threads actually processing only 1 or 2 were above 40% and those 2 did not peak at 100%. So the threading was not accurate to the load at all. When I made the changes to the registry, everything return to normal and the playback was smooth at 1/2 or full with threading across all cores and the CPU load relecting the change between 1/2 and Full Res.
I am looking for differences with the Caching by the current updates to the player effecting the CPU processing. Memory available or caching changes would effect the CPU threading like this. What I meant by memory was system ram. Thank you for the driver version. I am testing with 301.42.
Hmm, This test system has 32GB of ram. My client who reported exponential increase in performance has 12GB. Lasvideo has 64GB. Will have to test a lower ram configurations. Thanks for the info.
I'm using 16Gb of RAM, and my CPU is a 2500 i5 and my GPU's driver is 301.42. I'm going to test my other work and home 2600k system's that have a 570 and the other a 470 next because it's almost sounding like it affects machines with HT.
Very strange some people have issues and others don't. It's starting to sound like it affects HT more than non HT cpu's
I'm also willing to test on other hardware configs if needed Eric. Just let me know I have access to a i7 920 system with a 470 and also two i5 750's one with a 470 and the other with a 570 in it.
So far has not seemed to effect Main Cores other than not reflecting load increases by the MPE engine on the CPU in general. Still to early to isolate but definitely seems to point to amount of ram.
I tried 16GB of ram with the Test system and it still would not use Hyperthreading most of the time although it did use 1 of the Hyperthreading cores for a short time. Playback however was better at 16GB of ram than 32GB by a large margin.
I think I have an idea what is going on now. It seems the new update has significantly optimized the Cuda block allocation going on in the background. When I was testing at 16GB of ram I saw far more fluctuation of ram usage going as low as 4GB on the same project that normally pushes 10 to 13GB with all threads active. When all threads are active the ram usage is staying relatively consistent at 8 to 11GB with far less flushing. However with far more ram available it seems the optimizations are triggering some Windows 7 ACPI Power management features that are shutting down cores as not needed even though the actual application really could use the processing to complete the task. Each system board has different ACPI sets that will adjust what Windows 7 does, how, and when regarding power management. This would explain why this is not consistent. This unfortunately is looking like a side effect of optimizations to the Cuda Player Memory allocation and not a bug. Lasvideo you may have to make those registry adjustments after all since this may not be fixable on Adobe's side.
So do you think my RAM allocation on my work's Intel 2500 16Gb RAM system will suffer in some manor and not function optimally? Even though I'm not seeing any of the CPU side effects?
The reason I'm wondering is because I'm trying to figure out if I should make the reg edits or not. Or just wait and see...
My other question is have you seen this problem on any standard Sandy Bridge based CPU's?
Because LasVid is obviously not using a standard Sandy Bridge system since he has 32-Core's overall. Do you think it's possible it might also have something to do with CPU architecture?
I took a close look at what is going on in my machine and it's really weird. All cores are going full blast. It's the GPU that is not used consistently. It fluctuates between 0 and 40%.
My configuration is: Win7 Pro, 64 gig ram, 3930K at 4.5 gHz and GTX680.
I don't know if this will apply to you or not, but for me my GPU does that all the time. What happens for me and anyone else is that if the video you're exporting has a effect or scaling that uses GPU accleration then you're GPU will pick up. Then as soon as it moves onto something that doesn't use GPU accleration it chills out. For instance programs that I edit for TV often will not use GPU accleration until it gets to one of my Lower-Thirds in the timeline. This is normal behavior. Although I don't know if this is exactly whats going on in your case. But I would suggest checking testing what I've said by taking a clip and splitting it into two pieces in your timeline. Make the first half have nothing done to it at all. Then cut the first clip you put in the timeline in half then scale the 2nd half of the original clip to 90. Then export it, if as soon as the export hits the 2nd half your GPU picks up and stays up until near finished you know it's acting normally. Just make sure to export it so it's set to exactly the same as your seqeunce settings as far as pixel size and stuff anyways.
The way Eric explained it to me, Adobe really just optimzed its player to allow folks with less memory to get good playback. The issue is more related to how Windows 7 interprets and controls the need for processor power when its sees the GPU doing such a great jog. So it cuts back, much to my chagrin. But not for long!
Windows 7 ACPI Power management features that are shutting down cores
Isn't that easily handled with the "Processor Power Management" setting in the Advanced Power Settings? I have my Min and Max set to 100%. Could this be why I see no degredation of performance?
Jim - "Isn't that easily handled with the "Processor Power Management" setting in the Advanced Power Settings? I have my MIn and Max set to 100%. Could this be why I see no degredation of performance?"
I dont think they have any bearing on this issue. My settings are the same as yours and yet I still manifest the problem.
I went ahead and made the changes in the Registry outlined on page 1 of this thread on my HP Z820 in order to fix the issue with HT. It worked like a charm. I know have full HT activity in combination with GPU support.
Thanks to Eric Bowen and his very large brain!
I only did this after testing my system, conferring with Eric and confirming I was seeing the manifestation of the problem.
DO NOT DO THIS WITHOUT KNOWING FOR SURE THIS IS AN ISSUE FOR YOU.
Jim Curtis wrote:
Loses video often (screen goes white), forcing a relaunch. Sliding a ProRes4444 with alpha clip is one cause. Inserting a Title from the titler is another cause.
Goes into Not Responding on Quit - 100% of the time. Must Force Quit to exit the app.
Adobe MUST provide us a method to downgrade back to 6.0.2. I can't get any work done when I have to force quit Pr every few minutes and relaunch the app.
I'm updating this post as new information comes in.
The behavior I described above was for a 4K sequence that contained 4K-sized R3D, ProRes4444+ and PNG media. And I had to force quit only after getting the white screen. If I quit without getting the white screen first, Pr exited normally.
I wrapped up a separate 720p project yesterday, and I didn't get the white screen, and when I quit, Pr quit without problems.
About three times since updating to 602 I got a Serious Error immediately after a project loaded. I deleted Pr prefs the 2nd and 3rd time, and the project loaded without error.
It may also help to delete your caches and preview files if you get the same error.
I got a problem that the CPU never hits over 40-50% when encoding. Before it always hit 70-90%. The GPU is working like before. The % depends on what effects is laid on the clips.
And the program in itself is reeeeaaaally slow! I've tried deleting all preview and cache, no difference then either.
I've den the thing with the regid and it didn't got better. All cores and threads are working.
i7 3930k @ 4.2ghz
Geforce GTX 470
SSD disk for media cache and previews.
...it seems the optimizations are triggering some Windows 7 ACPI Power management features that are shutting down cores as not needed even though the actual application really could use the processing to complete the task. Each system board has different ACPI sets that will adjust what Windows 7 does, how, and when regarding power management. This would explain why this is not consistent. This unfortunately is looking like a side effect of optimizations to the Cuda Player Memory allocation and not a bug. ... this may not be fixable on Adobe's side.
Kudos Eric, that's major detective work.
In terms of Red Scarlet/Epic footages:
After re-installed the Red Importer Plugins, the image is now showing; however, the audio of any Red footages will plays for a second at the source window and then drop out/disappear completely!!!
Europe, Middle East and Africa