Maybe you should use a certified card instead of a
Let's clear up a few things first:
Is it CHrissa or CArissa? You have me confused.
nVidia constantly updates their drivers, but despite their marketing efforts, it is up to Adobe to make use of these drivers by optimizing their MPE code, which is an on-going effort.
AME export settings being slower than direct export is something I noticed with AVI exports, but I have not found any difference with H.264 exports and with MPEG2-DVD it is exactly the other way around. I have been discussing this with Adobe and they are aware of this issue with 5.02, but have not yet been able to replicate this issue with any reliability.
I don't think Ann's answer is the solution. AFAIK there are no known issues with 'hacked' cards like the 480 versus the 470.
have not yet been able to replicate this issue with any reliability.
That's odd, because Tom's Hardware had no trouble duplicating it with every test they ran. Here's a question they posed to Adobe:
“If the direct export and render queue functions in Premiere Pro CS5 do the same job, but direct export is faster, why do we still have the queue in CS5?" [Adobe] replied, “Because you can’t continue working when doing a direct export.”
Notice there is no challenge to the issue.
“If the direct export and render queue functions in Premiere Pro CS5 do the same job, but direct export is faster, why do we still have the queue in CS5?"
I have one word for the Tom's Hardware guys:
I'd like to see them set up a batch export without the queue. If they can, then I will have learned something I didn't know before.
> I have been discussing this with Adobe and they are aware of this issue with 5.02, but have not yet been able to replicate this issue with any reliability.
I had a pretty long conversation with one of the testers about this (difference in speeds between AME standalone encoding and direct export) yesterday, and he indicated that there appear to be several intertwined issues that mean that you get different results depending on various hardware variables. He said that he'd really appreciate people continuing to submit detailed bug reports on this issue, with details of hardware configurations, so that he can disentangle the various issues.
One of the factors is NVIDIA drivers, and Adobe and NVIDIA are right now testing some new drivers that should address some of the issues underlying this discrepancy in speeds.
LOL put an intern at the desk and leave em to export overnight.
I have one word for the Tom's Hardware guys:
That was pretty much Adobe's response to the question. My point was that no challenge to the issue of a speed difference was offered in the response, which indicates their awareness of it.
The question is if Tom's can replicate it with every test they did, why can't Adobe?
> The question is if Tom's can replicate it with every test they did, why can't Adobe?
See my answer above.
I have to admit, it doesn't make much sense. The functions do the same thing, using the same hardware and the same drivers. Yet they perform differently. That smacks of an internal code issue.
I'm the QE who investigated these performances issues that Harm brought to our attention--and the unnamed individual whom both Harm and Todd referred to. Let's see if I can clarify regarding the ability (or inability) to reproduce. To stay as close as possible to comparing apples to apples, I used Harm's "PPBM CS5" project, sequences, and assets. Broadly speaking, that project consists of three sequences designed to test different aspects of performance. Following Harm's lead, I conducted 4 tests with each sequence, and I ran through the complete battery more than once on two computers with substantially different configurations, particularly with regards to number of cores and amount of RAM:
- Queue (AME)/HW GPU Enabled
- Queue (AME)/HW GPU Disabled
- Export Now/HW GPU Enabled
- Export Now/HW GPU Disabled
I found considerable variation between Harm's results and mine, between my two test systems, and even to a lesser extent from one pass to the next on the same system. Here are just a few specifics. Note that Queue/GPU enabled is the baseline for the percentages provide, so a value lower than 100% means that the other scenario was faster (50% is twice as fast), while a value greater than 100% means the other scenario was slower (200% is twice as slow)
- "Disk Test" sequence, GPU enabled: Queue vs. Export Now
- Harm: 26%
- my T5500: 104%
- my 390: 55%
- "MPEG2-DVD" sequence, export via Queue: GPU enabled vs. disabled
- Harm: 63%
- my T5500: 113%
- my 390, first pass: 136%
- my 390, first pass: 157%
- "MPEG2-DVD" sequence, GPU enabled: Queue vs. Export Now
- Harm: 240%
- my T5500: 143%
- my 390, first pass: 120%
- my 390, first pass: 114%
You can see that in some cases all the results leaned one direction but to substantially different degrees, while in others they were split.
All of the results above were with PPRO 5.0.2/AME 5.0.1. More recently, I revisited this testing running the current code and with a new nVidia codec that's not yet released to the public, and here's the good news:
Notice that I've made no attempt to explain the varying results--I'm most assuredly not the right person to venture into that terrain. Hopefully, though, this has at least shed some light as to what we've been able to replicate.
- "MPEG2-DVD" sequence, GPU enabled: Queue vs. Export Now: No Difference (and both times were notably faster than on 5.0.1/5.0.2)
- "MPEG2-DVD" sequence, GPU disabled: Queue vs. Export Now: No Difference ("Software only" was slower than with GPU enabled--175%)
Thank you for clarifying this.
I will be testing this again and mail you my results in the usual way.