I haven't had Photoshop Extended before CS6, so I've been experimenting with doing some simple 3D stuff, such as turning text into 3D shapes and trying to match it to a photographic background.
What I'm doing seems quite simple, and it seems to be working, but there's one glitch: A few things seem to take a really long time. At worst, Photoshop goes completely unresponsive for about 40 seconds.
A good example is this: I have a photo I've opened in RGB/16 mode at 4096 x 6144 pixels, and I create a new Text layer over the photo with one word in it: STOP
I click the 3D button in the Options area for the Text Tool, and wait a full 40+ seconds before seeing the pop-up that asks whether I want to switch to the 3D workspace.
I assume a 40 second delay isn't normal. It's certainly not acceptable.
Once in the 3D editing realm, I can do most things with relative ease, such as moving the 3D mesh around, rotating it, changing lighting, etc. The update time for any of those operations to show is maybe 1/2 second or so to show on the screen. Some things are a little faster. Even rendering it into a pretty clean state is fairly quick - just 10 seconds or so.
I've tested this in both Photoshop CS6 32 bit and 64 bit, and the performance seems about the same, as does the appearance of the long delay.
I have a decent 8 core machine, with (by today's standards) a modest graphics card: ATI Radeon HD 5670 with 1 GB DDR5. I'm on the ATI Catalyst 12.2 drivers because the 12.4 (latest) set has other problems. But when I did try the 3D stuff with 12.4 the delay was the same.
Example: Going from this screen to the one below takes 40 seconds.
...40 seconds later...
Ultimately tweaking it to look decent seems doable - no crashes or glitches...
Not knowing what to expect, or what I should expect to not try to do, what I'm doing seems pretty simple. Am I trying something I shouldn't? Is it just a given that to do 3D one is supposed to work on 8 bits/channel data?
I need to confirm more, but I'm not seeing the mesh generation (ie. 3D extrusion) step taking that long for RGB/16 mode at 4096 x 6144 pixels on Win7 64 | Ps x64. I do have 4x the cores (24) though. How much RAM do you have available, I'm working with 32GB which could also be skewing things. ;-)
My GPU is the HD 5870 1GB VRAM, but I'm currently using the much older 11.2 Catalyst drivers.
Generally 8-bit/channel docs work better for 3D, and image resolution settings at 72ppi.
I'll do more and forward this post on for more investigation.
Just ran a recreation of your steps with the same size image and data depth. It just took a few seconds, maybe 4, to extrude the text. No delay in history state change. Nothing special about my setup other than it is wimpy compared to yours.
Hi Steve, thanks for the reply.
Actually I think you have 1.5x the cores, plus Hyperthreading. But with 6 core processors you probably get upwards of double the throughput per core. Some quick math says that what I'm seeing might map to 10-15 seconds on your machine. Is that what you see?
Mine's a dual Xeon X5460 3.16 GHz machine with 2 quad core processors and no Hyperthreading. I have 16 GB, 94% of which is available to Photoshop. Your 5870 should be just about the equal of my 5670 at 3D processing.
Here are my detailed system specs: http://Noel.ProDigitalSoftware.com/temp/NoelsSystemInfo.txt
My files are normally set to 96ppi, and I just checked - 72ppi made no difference.
I have a suspicion that the 2012 ATI drivers may be at fault. Catalyst 11.7 was a really great version for Photoshop, and 12.2 is proving to be stable, but in general I think I have sensed some things slow down a hair since some time ago.
It's probably overkill, but here's a PSD file I can get a 40 second delay on, if it's helpful. Just select the STOP text layer, choose the T tool, and press the 3D button.
Thanks, Paulo. I'm thinking it's a quirk specific to my combination of GPU and display driver. Maybe ATI will do better with the Catalyst 12.5 release.
By the way, if I switch the simple file I posted a link to above to 8 bits it's almost instantaneous to extrude the text.
I haven't found anything else that's got a delay like this. All the GPU-enhanced functions seem very fast on 16 bit data - Liquify, Oil Paint, the blurs...
Thanks for the file. Can you zip up the results after 3D extrusion, as well?
I throttled my cores to 8 (yes, I do indeed have 24 physical cores) and installed ATI 12.2, but still don't see the 40 sec delay when using your file.
Some more data points might help, too. Can you try with just the 's' letter, and also with the letters 'stopstop'? What times do you get if you halve the document pixel dimension for each side?
Since you have smooth interaction after the 3D layer is generated, this doesn't smell like a GPU problem, but is also odd that 8-bit docs perform so differently for this simple case.
Wow, an honest 24 cores? Do you physically have 4 processors? I wasn't aware of any actual 12 core chips having become available yet.
That's the machine you use to determine if Photoshop delivers sufficiently fast performance, then?
Here's the additional information you requested:
> Can you zip up the results after 3D extrusion, as well?
I did this:
Faulting application name: Photoshop.exe, version: 188.8.131.52, time stamp: 0x4f61c045
Faulting module name: atio6axx.dll, version: 184.108.40.20654, time stamp: 0x4f3b249f
Exception code: 0xc0000005
Fault offset: 0x0000000000b63bf1
Faulting process id: 0x1410
Faulting application start time: 0x01cd3540bcac5b5b
Faulting application path: C:\Program Files\Adobe\Adobe Photoshop CS6 (64 Bit)\Photoshop.exe
Faulting module path: C:\Windows\system32\atio6axx.dll
Report Id: 13b66384-a136-11e1-8538-005056c00008
Since the module is atio6axx.dll, it sure smells like an ATI display driver problem.
A zip file containing the result of the first save (with Maximize Compatiblity on) is here:
Since I have had newer ATI drivers installed, then uninstalled them and installed older ones, there is the distinct possibility that something is left over from a prior installation (i.e., something newer than 12.2 is mixed with 12.2) because of ATI uninstaller deficiencies. However, all the ati*.* fand amd*.* files I can find appear to have February dates.
More in the next post...
More interesting results:
Reducing the STOP to S circumvents the problem. This tends to point a possible finger at the font, so I did this:
A review of the Arial fonts I have in C:\Windows\Fonts turns up more files than I expected to find, with some interesting names...
05/10/2011 06:30 PM 778,552 arial.ttf
01/16/2011 07:32 PM 749,004 arialbd.ttf
01/16/2011 07:32 PM 561,924 arialbi.ttf
01/16/2011 07:32 PM 555,884 ariali.ttf
07/14/2006 12:01 PM 173,936 ARIALN.TTF
07/14/2006 12:01 PM 178,864 ARIALNB.TTF
07/14/2006 12:01 PM 178,316 ARIALNBI.TTF
07/14/2006 12:01 PM 179,368 ARIALNI.TTF
Keeping in mind this was a clean Windows install in 2010, it's kind of surprising to see some older ARIALN*.TTF fonts in there.
I removed these fonts, leaving the 2011 models in place.
A repeat of the test yielded apparently fast operation on the entire STOP word. I am going to do a full log off and on and retry just to make sure I haven't accumulated something that's circumventing the problem somehow, but this seems hopeful.
More in the next post...
Okay, the "fix" seems to have stuck - it's still quick. Thanks, Steve, for prompting me to play with the text itself - that hadn't occurred to me.
If you're interested in trying to figure out what the heck is happening inside Photoshop, here are the actual font files:
I will continue to experiment with the 3D stuff to see if I run across any further crashes or anything.
Just as a follow-up, after removing the old fonts listed above, everything about the 3D editing process (on an extruded Arial font) has gotten much more responsive. Apparently the font issue was delaying some operations a little in addition to the long 40 second delays.
Also, a 6144 x 4096 photo with a rendered 3D object in it now only seems to be taking 123 MB to store. Everything got better from that one issue.
Just goes to show, some really wacky Photoshop problems can arise because of fonts!
Thanks for all the data; we'll dig into it here and see if we can make any sense out of why the font would cause problems with 16-bit and not 8-bit documents.
The chipsets (Opteron 6100 series) I have are targeted for servers, but help greatly when running RayTrace renders. ;-) I just have to remember and check things on machines a lot farther up on the bell curve.
Ah, AMD chips - that explains it. I had heard they were further along with multi-core chips. I saw a 16 core AMD processor advertised the other day.
Pretty soon CPUs will be like GPUs... 1024 core chips. LOL
Very interesting, but mystifying, results.
I suppose it depends on the nature of the font corruption or issue, but is it that the operation proceeded normally because a good letter in the font was used (the S) or was it because only a single letter was rendered ? If the former then one would expect that using a single T or O or P would cause the problem. if the latter then the text string S S might also cause the problem. I wonder what SG had in mind when he suggested trying only a single letter ?
Aside from having no idea how a font issue would be bit depth sensitive I also have no idea on why a font issue in the two cases you compared would render in each case, but create files whose sizes vary by a factor of 3. Do you have any theories?
I had considered potential font issues, but ruled it out in my head since the same font (and character set/count) in an 8-bit/channel mode worked. I haven't had the chance to look further if it is letter specific (but maybe the bowls in the O and P are problematic) or something else. By asking Noel to try a single letter and double the letter count, I was trying to see if there was any pattern to the amount of polygons generated (we would have 1, 4 and 8 lettters). Maybe there's some threshold that's in-betwen 1 letter and 4 letters?
Looking at his results file I don't see any obvious polygon count increase, but that was just looking at rendering results.
I kind of stopped looking when I removed those fonts, but I kept copies so I could restore them and try to reproduce the problem different ways if it would be at all helpful, Steve. Let me know.
Europe, Middle East and Africa