Photoshop CS5 and NVIDIA GeForce GTX 295 Crash

[GargantulaKon]

My specifications:

Photoshop CS5 (x64)

Windows 7 x64

NVIDIA GeForce GTX 295 (latest v197.45 driver)

Intel i7 920 2.67 GHz

My card is listed as a tested card for CS5 and NVIDIA says this is compatible with CS5, but today after using it, my screen went blank and the display driver recovered itself. It took about 5 minutes until Photoshop CS5 became responsive again and the GPU features were disabled. I am going to try GPU advanced mode and basic mode instead of normal mode to see what happens, but this is a shame that I have issues like this. I also had issues with CS4 like this.

What I did to cause this issue: I clicked" Place.." to place an object and that is when it crashed. It only happens randomly as I use Photoshop. Please NVIDIA or Adobe fix this issue. I love the GPU features and I want to run them, but this crashing is annoying for spending so much on buying this product. I hate to have to pay to contact Adobe technical support, it should be included with the purchase of software!

How to fix this without having to go to basic GPU mode or disabled GPU mode?

[Astara_]

Well, I've tried 3 times to send that dang doc...Grr...first two times gave up due to a Tbird bug not likeing sending a .5G (.7z) email and last time, it went out...but bounced from recipients 12 ways from Sunday...  but worse, lst email got 2 bounces ... I was sure I had deleted the forum addr, but apparently not...got a bound back from them about 24 hours after the bounceback came from adobe....   Even .7z'ipped, it was still 400MB+ and by the time sendmail did it's overhead, it was up to 500MB...  How come email hasn't grown in size/capacity they way everything else has?

Oh well,... going to hve to find some file service that lets me upload a halfgig file...

FWIW...did some moer testing...it's not the vectors...it's the combination vectors+special effect layers.

I can turn off JUST the effect layers...leave the other layers most of which have the same vector around them, so 2/3rd of the layers around me still are turned on, just those with effects I described earlier are off...again, painting is near real-time.

[Noel Carboni]

As I mentioned earlier, can you reproduce the same problem if you crop the document to small dimensions?  That would be a way to reduce the size to tens of megabytes.

-Noel

[Astara_]

Well, not the same doc, obviuosly...once I got that out of head, much easier to create a doc that reproduces the problem BUT, it was 100MB Larger than the original!

Eh?  What I did, I deleted ALL the layers except for the strands, added a background around the strand area and filled it with an off-white beige, then added a paint layer below the strands.  Oh, and to 'emphasize the problem area' (thought deleting all layers might have some speedup effect, I duplicated the strands (which I'd grouped into 1 group).   At that point, testing, w/1 brush stroke troke about 504 long, , brush size 40px, 0%hardness, opac/flow 100/60, with pen controlling pressure on both, +options:airbrush,smoothing,protect texture. ... 1 brush stroke took 14 seconds to render.  That file saved at 100MB LARGER than my previous doc w/all the layers...\

Later, BTW, I thought to trim away the transparent pixels and the dimensions shrank to 1932x2004, so that was my 'active' dimensions.

BTW, is there any easy way to get a layer count?

How about do something like 'in each lowest level group, turn off/on layer X  OR if not by number, then address by named 'nnnn' (or better, name that contains 'nnnnn')....sure would make this testing (and work-ing around the prob MUCH easier/faster...as I mentioned,

if just toggle off the top layer in each lowest group, that gives instant speed).  Anyway, Was going to try deleting all non-effect layers and trying that to see if that dupped the prob, so first toggled them all off.  then I did that trim.  

Problem gone.  Untrim, problem still gone.  eh?!  backstep all the layer visibility changes.... problem still gone.  So now I was at th same point in my history where I did the 1st test (multiple times), that came out to a 14s render, but NOW no prob.  Diff?   Zoom.  Instead of zoomed in at 250%, I was zoomed out to 50%.    I zoomed in to 200%...tried it...*bingo*...problem back.

Next tried zoomed in and just trimming, and leaving in all the base layers (where I'm at now), ... problem goes away if I trim the test doc

down to 1934x2004 -- even zoomed in. 

So....not sure what I can do at this point....will try a few more things, and see how I progress....(just got distracted, so am feeling like I'm spinning in place a bit...)...

L8R...;-)

Astara

[Noel Carboni]

I have to admit I am having trouble following what you wrote simply because I'm not familiar with your document.

Perhaps I've not been clear...  If you use the CROP TOOL to eliminate everything but a small rectangle of pixels containing one of these "strands" you talk about, so that the canvas is now just a few hundred pixels on a side, but the document still has all the original layers, then you Save As a different file (e.g., Test.psd), can you still reproduce the slowness problem?  If so, that file will likely be small enough to share with Chris / me.

The one thing I picked out from what you just wrote...  I think you're saying that when you're zoomed in to the image you see long delays, but zoomed-out you don't?  If so, this really sounds like a display driver / video card issue.  I know OpenGL was discussed early in this thread, but have you tried disabling OpenGL and checking to see if you experience the same slowness issues? Remember that you'll have to close and reopen Photoshop to have the change take effect.

-Noel

[Astara_]

I used 'trim', not the crop tool, to trim off all transparent pixels.

After I deleted all layers EXCEPT for the strand "layers" (each strand is a group of 3 layers) representing a strand or segment of hair.

There are (I just counted) 38 of those groups.  Those.

Trim will remove any pixels on all sides where there are no pixels...after I removed all the image except the head area, it shrank down to dimensions I mentioned above.

To answer questions 1) can't reproduce in few hundred/few-hundred pixels (or it would be harder/take many mroe layers...).

2) simply zooming out so it draws at 50% hides the problem.

If I crop away all the transparent area .. reducing pict from 4631^2 -> 1932x2004 which reduces

the 61.1MB image (with  3.74G of composing data) (I assume that's what the info panel means

when it says "Doc: 61.1M/3.74G"  yes?), down to a size of 11.1M/1.63G, the 11.1M looks very much like the pixel dimensions multiplied x 3 (RGB).

So at 1/6th the doc size, I have problems reproducing it, but if I took the number of layers and multipled them by 6...

i.e. went from 38 strands -> 228, it might reproduce at the smaller size.

---

Oops (thought openGL might have been it, but was testing on the 'reduced size' doc, that it's not in (the one cut to 11.1M/1.63G)...

And, apparently I have to quit before the openGL toggle turns off openGL (despite the fact that I've had it go off

in the middle of an edit session with my old card (the GTX-295)...(you did say that, didn't you...hmmm...)...was so focused

on your 'in bold' statement I jumped to try it w/even seeing that 2nd comment...;-)

------

Update: tested w/o openGL, ... but it was also a freshly opened Adobe with only the test document loaded (still had my original loaded

in the other test in another window)...

Render time for 543 pixel brush stroke (same settings as before: 12 seconds)....  2 seconds faster, but that's with no history no 2nd

doc...etc...so likely openGL isn't the issue....

(Sigh)...was sorta hoping it might be somethign as simple as mangled driver or bad settings on something...

Sigh.

[Astara_]

Latest steps:

1) flattened groups, so 1 giant group for all strand...no diff

turned off all NON-effect layers. (there were 2/strand, so cutting layercount by 2/3rds)

no diff

deleted all except effects layers... (no diff).

turned off effects, on all effects layers -- but left on layers -w/vector masks...maybe 1/2 to 1/3 of the strands have a gradient as the pixel layer which most of which have the blending option "layer is shaped by transparency" -... As I'd use a fade-to-transparent at the root end of the stand so it would blend (it's terrible when your roots don't blend well!)  ;-)...(hair color humor?)... 

So all I was left then were those gradients... ..  (I deleted the duplicate set of 'strands' for this testing, so my brush strokes averaged ~7.5 each.  low, maybe 6.6, high 8.9...maybe a low nine.  (tried to draw similar stroke each time, but not very scientific about it, I'll admit)...

With all effects off, but layers & vecs still on, render time  including the brush stroke 1.2-1.4 seconds.  I.e. A very slightly noticeable lag, but

almost real time..

Lets go back to our original assumption...

Layers+effects -> slowness...

+ 4K x 4K pic working with simple builtin brush @40px, @ 200-300% zoom. 

same set of effects (though blendings and exact settings varied)...

drop-shadow

bevel+emboss

color overlay

pattern overlay

latest file size 832M tiff, -> 255M .7z file...wonder if that one will go through?... 😉

I know not to try sending it from Tbird on Win....talks in 4K chunks to the sendmail through sendmail's line oriented interface

'C Data 4096 xxxxxxxx'CRNL

OK

C data 4096 xxxxxxxxxCRNL

OK....

ZZZZZZZzzzzz

[Astara_]

I think I got it...its on its way to you....

This one, besides being 7zipped, uses a HIGH level compression algorithm...the human brain...and

it will take one to expand it too, but it's ok, for a human brain it's easy, for a computer to reach these

levels of compression...well...  it's now down to a 26M file!  from 1.5G -- that's a 60x compression!

z-zip was responsible for 2x of that.  the other 30x...: 🙂

Anyway, open the doc, you'll see a group labeled 'dupme 2^5 - 2^6 times'...

Do that.

which, of course, you can do in 5-6 dup operations...( be sure to select newly dupped groups

each time...  I 'regrouped' after about 8 dups...  then 2-3 more dupals (dupe alls), and voila!

(depends on how intense of an effect you want...about 6-7 secs/paint @5, and maybe 11+ @6dups

then there's a layer that says 'paint on me...'

Used round 40px w/opacity and flow based on pen pressure.

zoom into the center of the drawing.... ~250x.... 

Enjoy the slowness!...(ok...feeling a bit silly...after going through all this...it's tiring...

would be great if it can be addressed....since it's not cpu bound (at least not in a parallel fasion...).

and it's not bound in the graphics card.... and it's not based on merging visible pixels.....  I mean, it's

almost like you go out and re-render each layer, sequentially, upon each brush stroke -- only to find that few or none

of them contribute to what's being painted...

will post this summary in the forum too, so anyone else will know what's going on...

(unless someone else wants a copy... you can post here or pm me... or send email to: Ａｂｏｂｅ﹫ｔｌｉｎｘ｡ｏｒｇ )

(you'll have to asci-ify the addr...it's be sad when scanners start reading unicode...(full, half and ideographic forms...)) 😉

.

[Astara_]

Dang!  that one bounced too?!  suggestions about where I can upload it to?

[Noel Carboni]

There's a free file transfer site called YouSendIt.com.  As I recall you have to create an account but you don't have to buy anything to transfer files up to 100 megabytes.

Just to be clear, I'm not with Adobe, Chris Cox is with Adobe.  It's Chris you want to send the file to.

-Noel

[Noel Carboni]

Astara_ wrote:

As now, I see how slow it really is and am seeing how Adobe only runs single-threaded for most paint operations...  I thought it was supposed to be multithreaded?   But I guess that's only for some operations...not like applying brush strokes... which brings my 6-core, 3.3GHz Xeon to almost a standstill as far as Photoshop is concerned  But it no longer is crashing (yet?)...

Could you please describe just what you're doing when you see the slowdowns?  Be specific, listing the brush settings.  I, as I'm sure will others, will be happy to try the operations you're doing and let you know how quickly they work on other systems.  With your system you certainly should be near the pinnacle of performance.

Some things, like painting with large, fuzzy-edged brushes, manipulate millions of pixels in complex ways, so you can expect to see some non-interactivity depending on the settings you've chosen.  For example, a fairly easy to reproduce slowdown is seen when brush Spacing is set to a small value.

-Noel

[wcblackburn]

Hi,

I have this problem with the Geforce GT 540M card (latest drivers) on my 8Gb Ram Asus NSV laptop running Windows 7 64. Its annoying because i can run things like GTA5 maxed out perfectly. Photoshop however crashes randomly when loading files or occasionally when i drag and drop a window. Like someone else said earlier, i think its a spike in memory switching from 2d to 3d opengl that causes the crash, its definitely not down to overheating nor is it a Windows issue.

I haver another Nvida card on my desktop computer (not sure of the name but its not as good) again running Windows 7 64 and everything is fine!!

[Noel Carboni]

I'm sorry to hear you're having trouble; this is a good illustration of why I personally prefer ATI's display driver quality.

Have you double-checked nVidia's web site to see if they have any updated display drivers for your card?  Looks like their latest, 270.61, is only a few weeks old.

http://www.nvidia.com/Download/index.aspx?lang=en-us

-Noel