Thread: photoshop cs4 slowing down

Originally Posted by giantacroyear

If anyone else out there is running CS4 with a blown out PC config, I'd be interested to know how it runs!

I'm running a core i7 920 2.6 GHz and 12 GB of RAM with the CS4 Master Collection on Vista 64-bit

I just ran a little test of Photoshop. In a 4k x 3k file at 32bits / channel, I created 10 layers, filled each with clouds, changed the blending modes, applied some filters, made a smart object with a smart filter on it, and did some coloring.

My memory allocation for Photoshop wound up around 5.7 GB, and I had no slowdown. I have OpenGL turned off, so there was some tearing as I panned around across the image, but I had no trouble zooming in or out.

Unfortunately, Photoshop remains the only 64-bit app that Adobe has released. I'd love to be able to use the rest of that RAM in After Effects.

Hey guys,

Can't... let... this... thread... die...

Ok, so I said I would keep you posted, so here I am again after a week of messing about (in between doing what I'm supposed to be doing).

I found this link on the Adobe site which seems to acknowledge some of the issues, and address others: http://kb2.adobe.com/cps/404/kb404898.html

If anybody is having CS4 performance issues, it's a good starting point.

Okay, so here's where I'm at.

1) Updating to 11.0.1 apparently addresses a number of issues for XP and Vista, and installing it has actually seemed to help some of the brush performance issues we were having.

2) I can't tell if installing the latest nVidia drivers has helped or not, but there is definitely a problem with the 182.02 drivers, which some people were running. Briefly: "...has an incompatibility which results in the graphics chipset improperly reporting its OpenGL capabilities to the Adobe application". (http://kb2.adobe.com/cps/408/kb408986.html)

3) Turning off hardware acceleration for the video card seems to help, but I can't be entirely sure. I know it's messed up, but the update time between moving the mouse / Wacom pen and what's getting drawn on the screen seems to just be quicker with it completely off. That's about all I can say for sure, even though I have no technological argument to back that up. (Dumb, I know!). I was hoping to find an app that would tell me how much VRAM or what OpenGL calls are being performed by CS4, but to no avail. (RedRobes - you seem to be an OpenGL whiz, so if you know of anything, that'd be great! And! AND! I ran your ViewingDaleTestApp! Cool stuff!).

In any case, that's not really an option for us here, because we need hardware acceleration to be all the way on for using Maya. I've written wrappers that set up our environment / tools for both Photoshop and Maya, and thought maybe I could incorporate something into those to turn hardware acceleration completely on or completely off depending on what app you were running, but that's not going to be feasible since the artists will likely be running both at the same time. (As a quick aside, the reason being that they run both is because I wrote a javascript that calls a C++ app that talks to Maya via a command port to updates the textures in Maya when they re-export their images. Okay, I'll shutup... I'm gloating like a supervillain here...).

4) There are also apparently known issues using dual monitors (which some artists here happen to have), but it doesn't look like Adobe is actually going to tackle those - they just sort of say do your work in your primary monitor and keep your panels in your secondary monitor - or just use a single monitor. Not super helpful, but there you go.

That's about it. Hope this helps... somebody!

Cheers,
GA

P.S. @ Midgardsormr - thanks for the info! And, yeah, here's hoping for a 64-bit version of AE in CS5!

I will admit to being a bit of a whiz at OpenGL - well at least up to V2.0 anyway. I haven't previously said this but I used to write GL drivers for graphics cards for a few companies and on one of them I was part of the team that accelerated Maya with their card. Now before you get too excited, I was doing the low level card side stuff and others did the higher level stuff which is where all the Maya specific juicy knowledge comes in. So I did my bit of faffing in the kernel and then later on there would be the shout that the chameleon would get rendered properly in about 1/10th the time or whatever it was. This was not for nVidia I should add too.

Thats a bit of a digression but I can add some helpful stuff. Firstly much of what is used to accelerate Maya is using the programmable raster language of the cards and at the time there was not a lot of GL V2 shading language about so it used to be done in the nVidia extension language. Now at the time AMD had the competing language - I forget the names, was it that close to the metal and shader language X or something like that as the two sets. It used to be that the architecture of the cards made doing some stuff much easier in one card than another. Again, this was not my specific bit of the work so I forget the details. Its all about whether the card is strong in raster ops or whether is supports a certain vector instruction or not. I believe in the case of Maya tho it was that the shader required to do its job was sufficiently complicated that you either ran out of instructions or some other shader language resource. You can tell I don't do much programmable shader language stuff cant you... Now it ought to be the case that the guys at Maya or nVidia should go back and reengineer the shaders using the newer GL2 type or using Gelato or CUDA or whatever but I expect that this is not the case. Or maybe it is the case and that older cards which dont support the newer languages are still using the old way and its not being maintained.

I noted in those links that a lot of the problems are to do with driver incompatibility. I can see stuff like where it says when you use a brush it leaves garbage behind as you draw until you let go. I know what that's all about but its complicated to go into. Lost weeks of my life to seeing garbage like that. There wont be a lot you can do about that other than either turn off acceleration or change driver. Another thing was the dual screen. That's called single surface dual view or SSDV and its a PITA really. Its burning twice as much VRAM everytime you open a buffer and I can see bugs listed where its saying with that on and opening 30+ windows it crashes. Yeah been there. (Interesting that it also says you cant virtualize the VRAM... wanna bet ????) Anyway, you can drive the card to give two independent monitors or one SSDV screen space. If stability is paramount then its probably better to go with two independent ones.

Anyway, heres a simple programming mantra that you will no doubt be well aware of. The more obscure things you do with something the more chance you will hit a bug with it. I think PS has been using some bizarreo aspects of GL in the naive belief that all cards support all features flawlessly. nVidia have excellent drivers but they are not flawless. What you need to do really is to get a conformant driver which is certified for use with that app and try to find one version which has been thoroughly tested with both Maya and PS. I'm guessing that right now there is no driver which is suitably stable. I am also willing to bet that almost all of the issues are with the PS and not Maya too. Given that you have gone for a pro card you might find that the driver has a drop down list of application specific enhacements. These are made by the driver folk to break the conformance of the driver as a trade off for making some apps work. It might for example not list some acceleration capable thing because if you do the app tries to use it wrongly and stuffs itself. If the PS is on that list I would recommend trying it as the testers of the driver writers do test almost all of the big gun apps. Maya especially naturally but also Max, Duke Nukem clones, Doom etc.

I should also add that in my experience of a few companies the OGL and DX teams are entirely independent ! So expect the bugs to be too. That may not be true of them all tho. I don't wish to say which companies I worked for tho.

If you do want to see the GL calls being made between card and app you can do it. You install a special driver and that driver acts like a proxy. The ole man in the middle attack. I cant remember who does it but there was one which listed everything and decoded it all and listed it to file. Its used to scrape the video images out of games too since they are (well used to be) sent over GL calls in a standard format which is declared beforehand. You used to put the DLL for the GL proxy ICD as the ole OpenGL32.dll and get it to call the card vendor one by proxy.

msdn.microsoft.com/en-us/library/ms970779.aspx

Oh yeah here it is - or one of them...

http://www.opengl.org/sdk/tools/GLIntercept/

I dont know if that would help tho. Its more for debugging GL apps but it might show up what extensions its trying to use.

EDIT -- Oh yeah, on a reread. GL Card VRAM. Actually, I dont know how to get this ! You can get to in DX but because GL is client server then its not something that the client is supposed to care about. Your supposed to make calls asking if you have enough to load a texture or whatever and then do it if you have but I dont know how to get at how much is left on the card available. Apart from loading up the card with oodles of textures until it runs out then count how much you free up as you unpack it. Thats not a very nice way to go about the task if you ask me. Yeah my ViewingDale app has some buttons to click to set the amount of total card ram so it can try to optimize usage. If you find out then let me know !