Optimizations, 64bit native, CUDA support

This is my computer setup it cost around $12k to build, and FF only uses around $300 to $2k of the hardware at any given time. I would like to see that change. I'm perfectly fine with it using more of the hardware in exchange for improved speed.

Dual 16 core AMD Opteron 6376's
64GB ram
Nvidia Quadro K5000
IoFX 420GB PCIE-SSD (where Filter Forge is installed)
OCZ Deneva R 2 400GB SSD (where Win 7 Ult 64bit is installed)

I would very much like to see FF become a 64bit native application. I understand that this has already been deemed an unnecessary thing but I disagree. It would allow for much less HD swap and improve overall speed. If that is absolutely out of the question then at least enable the LARGEADDRESSAWARE handle for the 32bit version so it can make use of 4gb of ram. I have no concern for how much ram it needs to use just that it does what it needs to quickly, having FF concern itself with ram usage is a waste of processing, HD space, and my time.

I would also like to see CUDA support added so it can fully utilize my $2k graphics card instead of fumbling around consuming 98% of my 32 CPU cores for hours on end which also implies that it's doing that inefficiently anyway.

I frequently make use of the batch renderer for it's render speed advantages or at least the assumed advantages and even then on some filters it can take an hour per image. I realize this is partly due to the way the filter is set up and/or the complexity of the filter and likely many other factors but it can be resolved to some degree and lessened by simply making better use of the hardware.

If FF can parallel process a filter on 32 CPU cores then it could be made to take advantage of modern GPU's as they excel at parallel processing. CUDA for Nvidia and OPenCL for ATI are becoming easier to implement by the day, 64bit operating systems comprise at least 50%+ of the market share today, 8-16GB of ram is becoming the expected norm. There is no reason for FF to be a 32bit native app that only uses 1.5GB of ram, and makes no real use of available GPU's. That doesn't make any sense for a program that creates images entirely from math.

Please upgrade FF to use modern hardware effectively.

I see your point about CUDA and general code restructuring around GPU rendering. At the same time though, there should be some way for users that do have compute capable GPU's and huge amounts of ram to make use of their hardware better, and benefit from the money they invested in it by gaining better speed.
This issue is in no way exclusive to FF. Since I built this computer an overwhelming amount of the software I use has proven to be sub-par with hardware usage, that is the biggest thing this computer highlights is how very little software actually does to use the hardware it's been given. Seeing as this is creative design software I feel it should cater better to people with above average hardware, not exclusively but much better than it does currently. It's great to be efficient and optimized, and there is definitely no reason to use someones system resources when it isn't needed. However, when it is needed and when the resources are as above average as mine it would be nice to see software that knows how to use it, especially if it's for development or creative design purposes.

Having said all that, Adding support for extra ram means code base changes to make it 64bit compatible, which it needs, there isn't any way to argue that it doesn't. I just started rendering a 15k x 15k image and watched it sit there for 15 minutes throwing 65,000+ page faults in memory and only using 0.41%-3.12% ram which is a firm indication that all it was doing that whole time was swapping things to disk to keep it's ram usage lower since that size map maxed it at 1.5gb, meanwhile I still had at least 60GB of ram laying around begging to be used. So that was 15 minutes of ram management that wasn't necessary along with wasted CPU cycles, and time. I'm sure if I had let it go on it would have done that for at least another 15 minutes.

Adding support for GPU rendering doesn't have to mean a complete change in the code base. It could be done by way of an alternate renderer, sort of like the batch renderer. Just a separate .exe that you can direct it too though the options panel. This way you could swap out how you wish to render images and the primary code base wouldn't have to account for as many user setups and hardware situations. It would simply be an optional switch for users that did have the hardware for it. Additionally, the bugs it may introduce wouldn't affect the users that didn't use it, so it makes things a bit more modular, or node based since that's a big thing with FF

I don't think that programming things for the GPU is as difficult as your making it out to be though, I may be wrong and don't mean to offend if I am. I'm not entirely sure what the code base for FF is written in but a good deal of languages have "wrappers" for GPU processing now that allow you to simply pass directives to the GPU for processing instead of letting them go to the CPU. In the case of CUDAfy .NET you simply add a few includes in your code and then call the GPU whenever you have a line you want sent there instead, and go on coding as usual everywhere else. Other languages may be more complex but the basic idea is the same. To have truly high performance GPU code that gets the absolute most from the card you would likely have to do a complete rewrite but to get something that can use the GPU fairly effectively, which is still far more effective than doing the same process on the CPU, it should be about the same as any other language port. I'm pretty sure it wasn't a 5-6 year port for FF to come out with their Mac version, so I don't see that porting it to make use of GPU's would take any longer than Windows->Mac did.

Lastly, I would like to say that despite all the arguments against 64bit and GPU capabilities being added to FF, they aren't going anywhere. In other words, these things are a part of the industry now and rapidly becoming the standard.
Websites that haven't been updated since 1995 don't get the traffic that their newer flashier counterparts get cause they don't work correctly and look like crap. The same holds true with software, if it isn't going to keep up with the times it's doomed to get left behind. As, a developer I understand how annoying that is, every time I turn around things are being replaced with better things. PHP is soon to be squashed out by HHVM + Hack thanks to Facebook. MySQL is rapidly getting stomped out by MariaDB. This is a constant in the computer industry, but it always has been, so you have to be prepared for it going in to things. Monstrous code bases that refuse to keep up with these changes eventually fall to newer, less bloated, more streamlined, and efficient code bases. That is why MySQL is losing to MariaDB right now.
If FF just keeps adding features, and fixing bugs, and hacking performance improvements to the original code base it will become similar to MySQL and become an unmanageable behemoth with only one direction left to it. I really like this program and don't want to see that happen to it.

A year or so of effort to port/upgrade to better hardware support, essentially future proofing to some degree, doesn't seem that bad really. It is potentially a set back fr om other things but at the same time it's a nice step forward as well. Besides, if they do upgrade to 64bit and especially if they add GPU capabilities we can make even more complex filters than we already have without having to worry about crazy render times. The render time is the deciding factor that limits the level of complexity that a filter can reasonably have. Making it 64bit native resolves all the Ram/HD swap issues, thereby saving a ton of currently wasted time. I'm pretty sure it has a few other benefits as well such as some % gains in parallel processing speed or something along those lines. Adding GPU support obviously speeds up render times even further, in some cases a whole lot further.

They do still have to contend directly with Genetica and Allegorithmic's "MapZone" which is now free, and indirectly there is Allegorithmic's other products as well as Quixel's product lineup. So it's in their best interest ultimately to make it as desirable as possible. Genetica already has the ability to do batching and create animations, which they have yet to implement for FF despite the many attempts by the community to get them too. I believe Genetica is also 64bit capable depending on the machine it's installed on, if not it's only a matter of time.

There are limits to how long people will stick around and remain loyal to a particular software if begins to fall behind the competition. Also, I think many people tend to overlook the fact that for every 1 person such as myself that makes effort and voices an opinion there are likely dozens more that don't, and feel the same way. So if you have a reasonable portion of your active community saying the same thing, it's a safe bet that a much larger portion of the overall users feel that way and just haven't spoken up.

When software gets to a certain point and has a certain number of customers that repeatedly buy upgrades and participate in the community surrounding the software the development path needs to begin to lend itself to the community's will more than it did in it's earlier stages. Those who pay the bills should be able to help determine what they would like to see added, they are going to be the ones using it after all. As best I can tell that isn't the case around here. It seems FF devs are just following their own path, which is fine, but 64bit compatibility has been a very popular feature request for about 6 years around here and that's just sad.
To me that implies there isn't any concern for what the paying customers are asking for, which is a good way to drive them elsewh ere. If this were just a hobby software that they did in their spare time, and made available to others for some extra cash that would be acceptable. I'm pretty sure this is a business though and they intend to make their income entirely from this software. Making buyers beg for a feature for years on end is no longer acceptable in that case.

In summation I would like see a 64bit native standalone finally, modern GPU support, and native batching and animation support as outlined in my other post

All in that prioritized order.

In my case I'm often creating images with FF by chaining multiple filters together. In this latest use case I had 1 texture filter for the base image, and 4 effect filters before the final image was created. I needed around 1,000 of these and they had to have great eye appeal. So I made a macro to randomize the base image values and save them to disk, it generated 30,000 of them over the course of a week or so. Then I used the batch renderer to eventually pass those through the other 4 filter, which took another few weeks.
Due to the extreme difference between the first image and the final output there was no way to tell which ones would be up to the standard I wanted so they all had to be taken to the final stage till I had the 1,000 I was after.

In a case like this extra render speed goes a long way. If the batch renderer had made use of the $2k GPU I have, that time could have been reduced drastically. If the batch renderer had been 64bit then the dead time between images could have been lessened or eliminated.
If the images hadn't been 200x200 and had instead been 1200x1200 that would have taken around a year to render. The images the initial filter generates take around 30sec-1.5min at 200x200, at 1200x1200 they take 5min-1hour averaging around 30min and then the other 4 filters would have taken longer as well.

My point with all of this is that utilizing the users hardware to the fullest is the responsible thing to do. The FF devs shouldn't presume to know what people will use their software for or why they'll do it. They should just be happy they do and make sure that it works as quickly for them as it can so they'll continue to use it.

As for all the past mentions of how FF wouldn't benefit fr om 64bit. That's either a bold face lie or an indication that the code base needs a severe makeover. I can sit here and watch it fumbling with itself to manage memory usage. I can pop open all sorts of monitoring software and watch FF sit around managing memory and swapping to disk. If I tell FF to render a complex texture filter as a new image that's 15k x 15k and set preview to actual it will sit around for at least 15min without doing anything visible on screen. If you watch that same scenario in the process viewers you'll see the ram balloon to 1.5GB within the first minute and after that you see it throw thousands of page faults while it swaps ram to disk and back. You can literally watch FF sit there for 15min playing with ram.
So if it actually won't benefit from 64bit then the code base needs to be reworked. From wh ere I'm sitting though I'd say it needs to be 64bit and would absolutely benefit from it. My guess is that all this came about from the limited ram an average user had when FF was first created. I'm guessing the problem is that they hard coded methods for it to avoid ram usage as much as possible and now they don't want to have to rework all that code.

Quote
A year or so of effort <...> doesn't seem that bad really.

Do you think we have the same resources as Adobe does? Well, thanks for the compliment

Quote
they don't want to have to rework all that code

"Don't want" would be incorrect. We don't have spare developers and other resources to spend several years reworking all that code.

No problem, I don't find anything offensive here! I just wanted to point that we can't put aside every other task and start implementing a GPU renderer or a 64-bit memory manager.

Well they are going to stop producing 32 bit chips....

The 64 bit is the boy on the block..

And I wish the Software companies would Migrate there software to 64 bit.
Memory is Why.
32 bit can only go to 3 gig.
64 bit can exceed 64 gig.

Granted FF works well on my 64 bit machine with 64 bit Windows 7 Ultimate..

Yes I have Lightwave 64 bit, 3DMAX 64 bit, AutoCAD 64 Bit, etc etc
Its Just that Memory is the Factor here...
Sooner or later MS will stop 32 bit support, they are pushing it now.
In a few years they are taking the 32 bit support out of the Operating system.

Then what???

They are working on the 128 bit chips now in alpha...


Mike

Quote
Then what???

You quit using FilterForge and move on to a different piece of texturing software, assuming the 64bit version never comes out on time. Pretty sure that's one solution. right? Just hand paint your textures. Don't need 64bit for that. lol

My gut says 32bit won't be going away that soon time given there are still programs making the conversion to 64bit. Kinda like how certain application frameworks refuse to die in the year 2014.

[Edit] Honestly probably not the best of advice but it kinda comes down to that sometimes. In the end if FF doesn't evolve further, I wouldn't really care, that's sad but I think there are enough alternatives out there that I don't see it being that big of an issue. In the thread I do mention Substance Designer, it's recommended if people already have great hardware and it does what most people want: procedural texturing.

And I guess people already know that Earth, the planet you live on, is a great textural resource provided free by mother nature. It renders at the speed of light so you really can't complain about having no textures. hehe