There are a lot of questions here, I'll do my best to answer them all. I know this might sound like too much, but it's worth considering whether to post separate questions in their own threads. I know you have a lot of questions as you're just getting started though, so just keep it in mind.
I'll reply in a couple posts here since there are several separate subjects, some of which may get a little lengthy.
In regards to performance, there are a couple things to be aware of here. First you need to be clear about exactly where you're seeing slow down, whether it's in a calculation phase (e.g. "populating"), or if it's in a display/interaction context. They are affected by different things.
Performance of the default 3D Preview is largely affected by your GPU power, not CPU. Your graphics card is pretty old and won't be able to display a lot of population instances, that's true, however the default object display in the 3D preview is "box" mode which should be able to handle a million instances or so on your card without getting too horribly slow. Believe it or not if you have a decent CPU but your GPU is limited then switching to RTP (Ray Traced Preview) mode can give you faster (and more realistic) previews, especially with large amounts of objects. Just be aware that the *terrain* needs to calculate in the standard preview first (TerraTuts has a good tutorial on the RTP:
https://www.youtube.com/watch?v=7oPZt45NmW8)
What I *think* you're actually talking about though in terms of performance is the time to calculate a population, i.e. to assign positions to all of the instances of your objects in a population. That's a process that could take 5 minutes as you say, or even more, depending on how many instances you have and your CPU hardware. And this is a process that is *entirely* dependent on CPU performance. Unfortunately your CPU is also pretty old and comparatively slow, which is probably responsible for the performance issue here.
The amount of RAM you have will limit how *many* objects/instances you can populate, and how big their textures can be, among other things. But it doesn't really affect performance that much, unless you're running into your memory limit and using virtual memory, which will be extremely slow. I don't think that's the case here, so it's probably just that your CPU is not really able to keep up with your ambitions very well. While it was fairly good at the time it was released, it is now 8 years old, which is quite a long time in the CPU world of course. Unfortunately we don't have any FX CPUs in the newer Terragen 4 benchmark, but the older Terragen 3 benchmark does have a few which (including a 6100) might give you a sense of what kind of performance you can expect:
https://docs.google.com/spreadsheets/d/1eX9Ltn3_9BjsamA0Pxeflv5AKrjkgViEY8VuetB8e3k/As you can see the 6100 is pretty far down the list, and again the amount of RAM is not really going to affect performance of that benchmark. Even the fastest FX CPU on the list is only in the middle of the pack, and remember this is an older benchmark that mostly doesn't have the latest hardware (e.g. Ryzen CPUs, etc.). It's not my intention to beat a dead horse here, just want to make clear what you should expect based on the hardware you have.
So obviously an upgrade would be the biggest help, but I know that's usually not a helpful response.
So with that issue in mind, now how do we address the performance limitations and do the best you can with the hardware you have?
The CPU will affect rendering speed, RTP performance, and any calculations like Populating and Heightfield Generation. So for all of those things you want to try to keep your use confined to only what you need. For rendering that means optimizing render settings as much as possible and avoiding really high resolution renders on your own local machine (you can consider using a render farm for this purpose, e.g. if you want to make a printable image for display). For the RTP be aware that the size of the RTP window affects how demanding it is to calculate (which is not as true for the regular 3D preview). One good trick when using RTP on slower hardware is to use the Crop Region which limits the main RTP calculations to your selected area only, allowing you to focus calculation time where you really need it.
For Populations, it's important to understand that even if a population is masked or restricted e.g. to the camera view, it still calculates based on the whole rectangular area of the population. The mask makes it so that instances don't appear where they are masked-out, but the instance position still needs to be generated and checked against the mask, so it still incurs a calculation time. For that reason the two most important things to control with populations to avoid excess CPU use and calculation time are 1: the dimensions of the population itself, and 2: the density (spacing) of the population.
Try to confine the dimensions of the populated area to *only* what you need. As Ulco mentioned this can include making a relatively small population for grasses in the foreground, then transitioning to a procedural grass shader in the background. Without doing this you could end up with 10s of millions of grass object instances, which will take a long time to calculate as a population and use a lot of RAM. Even with "clip to camera" you'll still want to avoid a population that for example exists behind the camera. While the clipping will prevent those instances from actually being generated and thus taking up memory, they still need to be tested against the clipping area, as I mentioned above, so you'll find that the generating instances part of populating won't really be faster ("inserting" instances should be though because there are fewer of them when clipped to camera).
For the same reason you really want to determine exactly what density you need for the effects you want and don't increase beyond that. For close-up grass this may mean a very low spacing, to be sure. But consider that you might be able to use lower density for a further grass population, as one example.
Another thing to consider is the use of Population Caches. Once you have finalized the density and distribution of a population you can save it to disk as a cache. This will mainly only help to avoid recalculation when you re-load the scene since populations generated within a session are generally not recalculated. But there are still some changes you might make to your scene that do not affect your populations but might erroneously trigger a repopulation upon rendering, and with caching you can also avoid that. Just be sure to recalculate and save a new cache if you make a change to your population or anything that might affect it such as terrain shape, masks, etc.
Note that, as you have found, the number of population instances may take a while to calculate, but once finished it may not actually affect render time that much. It does have an impact, but it's less than you might think.
On to part 2...
- Oshyan