[edwardk]

ChrisD, on 04 July 2015 - 10:27 AM, said:

OK, I understand, but please tell me why my GPU load goes from 55% (x3181) to 98% (x3186) without changing the weather.

Weather is selected to clear, so no raindrops are processed. What is then eating up my GPU Power?

This is not any GPU, my graphics card is a XFX 7970 GHz ED so the impact must be much more severe if You have a less capable GPU.

I thought that rain/snow was processed, only when the weather was selected to that, not when clear is selected..

ChrisD

I wish that were the case, but unfortunately not. Even with clear skies, the initial process initializes the needed resources.

Edit: Is the situation bad with non-LAA or LAA? Is it both??



James,

Do you think that this process must happen like this? The initial process sets up the needed resources based on MaxIntensity. Do you think its possible to set it up as needed using PrecipitationIntensity that is set up in weather.cs? I was thinking about this before, but now that we are experiencing these issues, something must be done evidently. If this is happening in non-LAA then the situation is actually worse since I did lower the initial values.

Edward K.

[disc]

LAA
LAA

I hardly can see any difference, except that my FPS is 60 (vsync enabled) with non-LAA, and 30 with LAA, (radeon HD5770 1GB).

Rain causes light fps drop, but snow causes heavy drop.

[edwardk]

Visually, there will not be a major difference. The difference is in the resources that are used between LAA and non-LAA. The non-LAA process is basically a step up from the initial 16bit process. It was impossible to raise the height which led to precipitation coming into view just above the train. Now with 32bit non-LAA, I am now have more room to work with, but at the same time working at keeping the resources used as low as possible since the non-LAA process only has up to I believe 2gigs of system memory to work with. With LAA, there is more memory to work with and so the precipitation box is a bit bigger. The only catch is that for both processes, the initial set up needs to set up space for what could be used. This is also the same if your system is locked into the using the 16bit process. The major difference here is that the resources used is low enough to the point you would not notice this. This may have to be changed.



Keep in mind there is a precipitation command to lower or raise the precipitation level so if your system is struggling with with snow or rain, you can change it.


Edward K.

[disc]

But what's that halved FPS when i use LAA at same place with same precipation (snow)? That does not seem to be lower the resource requirements, but does the opposite...

[James Ross]

edwardk, on 05 July 2015 - 09:00 AM, said:

Do you think that this process must happen like this? The initial process sets up the needed resources based on MaxIntensity. Do you think its possible to set it up as needed using PrecipitationIntensity that is set up in weather.cs?

That just defers the problem until someone encounters heavier precipitation. We're got dynamic weather already so it's not going to be easy to dynamically resize resource usage.

I am interested in why the GPU load is so much worse though, and we may need to reverse the change if we can't undo that easily.

[James Ross]

We've had someone else report bug 1471414 too by the looks of things.

[edwardk]

James Ross, on 05 July 2015 - 11:50 AM, said:

That just defers the problem until someone encounters heavier precipitation. We're got dynamic weather already so it's not going to be easy to dynamically resize resource usage.

I am interested in why the GPU load is so much worse though, and we may need to reverse the change if we can't undo that easily.

Under the screen information, there is Memory and GPU. Which one is showing the load and what is high? I thought it would be up to the video driver to take what is needed from system memory. In this case, the VertexBuffer. Before we determine this to be a total loss, I need to know if this is for both LAA and non-LAA? I am going to have to assume that the LAA process is the culprit since most of the resources is being used there. I was wondering at one point if there would be a worst case scenario and it looks as if there is one. If it turns out that its the LAA process, then I will cut it out and use the resources that is being used by the non-LAA process and if needed, lower the values being currently used.

Keep in mind that this is more than likely happening with the 16bit process as well. It just so happens that the resources being used is so small that the issue is barely noticeable.

Edward K.

[ChrisD]

As I see it, the LAA process may be to blame for the Out of Memory error, but does not explain the heavily increased GPU Load.

My reported GPU loads are as reported by GPU-Z.

Frame rate in OR is 15 with X3181 and 11 with X3182, but memory seems to be heavily restrained as the logfile suddenly overflows with memory exceptions and finally OR gives up.

There must be a way to find out what is bothering my GPU that much..

ChrisD

[edwardk]

James Ross, on 05 July 2015 - 11:55 AM, said:

We've had someone else report bug 1471414 too by the looks of things.

I read the bug report. On his system, non-LAA works and LAA does not. The only option I can exercise at this point is to use the non-LAA values as the base line and do away with the higher settings used for LAA ;)

I will start on this right away.

Edward K.

[copperpen]

The new precipitation effects have zero impact on CPU or GPU loads on my rig. Max is a 2% increase in the GPU load with it turned on. My FPS however are much higher than those of chrisd. 58 to 60 in general with fps locked to monitor refresh rate.