But to measure this kind of performance, it's not enough to enable/disable BPT, since Cycles/Superfly have several critical parameters that affect performance exponentially. For example, "Pixel Sanples" works as a multiplier to all parameters, so changing it from 3 to 4 already multiplies the value of all other parameters, which on its turn increases rendering time exponentially (not linearly). So if you can't speed your renders with BPT, it probably means your rendering params are way too high to make a difference. For once, the included built-in presets are WAAAY overblown and should take forever to render (hours).
By manually optimizing the Cycles params to more down-to-Earth levels, so far none of my renders took longer than 20 minutes. Enabling GPT in GPU mode can reduce this time down to up to 2 or 3 minutes - but then it crashes Windows altogether with a nice BSOD followed by a hard reboot and corrupts the Poser scene file (fills it with zeroes). Disabling BPT in GPU mode defeats the purpose of using the GPU in the first place, because it cannot distribute the workload into multiple threads. So GPU rendering without BPT means running a single rendering thread, disregarding how many SPs your video card may have, which is as good as having just a single one. In that case, even a Hyperthreaded dual core CPU can render faster than a Titan X, because it has 4 threads to work with.
The settings don't quite work like that in Blender. When you turn on BPT, you no longer can choose your overall Pixel Samples. You can choose your AA Pixel Samples, and that acts the way you describe. But it's clearly separate and defaults to relatively low settings. But even in Poser, I'm perfectly able to read the progress bar. My BPT renders tests both in Poser and Blender used _much_lower samples. By about half. It just wasn't as fast. In my Cycles tests, BPT was at best measurably slower with lower quality results. In Poser, those same _exact_ settings as I used in Blender (so again, lower quality), were set to take hours, and possibly days.
It is not a quality issue. You know how I know? I use progressive rendering. I can read my Poser progress bar. I could see how long it took to get to 512 or so samples. Not Tracing Samples. Just samples. It took _ages_. IIRC, when I stopped Poser using BPT + CPU, after more than an hour, it had only gotten to less than 100 Path Tracing Samples and looked horribly grainy. Using Poser BPT + GPU was even slower. In Poser, it was way, way slow in every case, regardless of how unacceptably low I made my settings.
Under absolutely no circumstances, including rendering in Blender with what I'd consider inferior settings and results, did Cycles BPT render in 2 or 3 minutes. That 13:30 BPT render was significantly _lower_ quality than the 11:16 PT render, and not just by stats. It was too grainy for what I'd consider acceptable in a final render. Despite using my two pretty decent video cards, BPT performed significantly worse.
Again, I'm not addressing theory. I'm doing practical tests of Cycles. In Cycles, I'm consistently (as in including multiple renders that whose data I haven't posted because I'm not being as methodical) seeing BPT perform slower for visibly grainier results and fewer samples. Since Cycles BPT settings don't work the way you describe, and you're saying you can't test BPT with GPU in Poser but posting BPT + GPU results, I'm guessing that you're throwing in data from your experiences in another renderer. Like Octane. Which probably implements BPT much better, and is _much_ older (and therefore, more developed) than Cycles.
Also, if you note my times, using PT doesn't _at all_ defeat the purpose of using my GPU. In Blender, I observed about an order of magnitude difference (1 hour vs. 11 minutes). Also, I just did a test, and I'm finding that using only one card just about doubles my render time. So even without BPT, Cycles is using my video cards in parallel.
In short, no, I'm sorry, but you're wrong about my test results. They are legit. It is not an issue of settings that are "too high." It is an issue of Cycles BPT being consistently less efficient, at least on my box. I suspect the same is true for most people. I'm seeing lots of grainy render results that people are saying took a long time to render. The Superfly default is BPT with CPU. That combo gave me a _much_ longer render time than PT with GPU. As in rendering so very slowly that it might have taken more than a day. With settings that were _much_ lower than my PT settings. I could see how long it took to go through one pass, and each pass was at least 10x's slower.
Oh, and I don't have my computer crash consistently using Poser's BPT with GPU. Hence my numbers. I had it crash only once that way. And I haven't had a BSOD yet. It seems to just crash my driver, and black out my screen. Mostly it worked very slowly. Interestingly, I just experienced the same crash in Blender using BPT + GPU.
As far as I can tell, it's just a bad idea to use BPT in Cycles at this point. I'm not saying the theoretical principle is bad. I'm not even saying that Cycles BPT won't improve. When I started using Cycles, I had to use a Beer's law absorption equation to fake SSS, there were no volumetrics at all, and it didn't render particles. It's already come a long way in a pretty short time. I haven't seen evidence of its progress slowing down. But right now, my tests definitively show Cycles BPT working significantly slower in both Blender and Poser with lower quality settings and grainier render results. I also experience intermittent crashes using Cycles BPT + GPU, despite that being significantly faster than BPT + CPU when it works. Oh! And this was really weird, IMHO. Using BPT + GPU, in both Blender and Poser, caused my whole box to become loggy. As in finding it hard to write because of the lag. I checked, and there was no unexpected hit to my CPU or RAM (I thought maybe it triggered some kind of process as a bug). Just using PT, I didn't experience any noticeable slow-down at all.
Oh, and just to add, my video driver is up to date. I last checked it right before doing my first tests.