Author Topic: Lockups: Finally found cause (and it's AH) (Read 1420 times)

Skuzzy · « **Reply #30 on:** April 23, 2007, 06:12:32 AM »

I have a EE and have been practicing it for over 30 years. Let's just stop the personal attacks. They are not productive. None of you know how the game actuially works. And I am not going to go into details about that, for obvious reasons. I have also written a rendering engine as well.

As far as the game goes, there is no difference between locking at 60FPS or running with vsync enabled or disabled. The game loop which renders each frame does the the same thing in all three circumstances. However, DirectX can stall the game loop by not returning from a draw call. This only happens in a stall condition inside of DirectX or the video card driver and it is rare for that to happen.

The only difference is the video card driver and the DirectX stack. Yes, I did not speak to those components. Those components can/will effect the amount of CPU time used based on the video configuration. I was in error in the way I presented the data earlier.

The video rendering is not done by the game, unless software vertex processing is chosen.

38ruk · « **Reply #31 on:** April 23, 2007, 07:17:59 AM »

Quote

I only argue with them when they are flat-out wrong. And frankly, from reading his posts for several years, I really don't think Skuzzy has a very broad computer science or engineering background, or that he actually writes rendering code, at the very least. This doesn't make him a bad resource on how to get AH running for you, of course.

Lol , obviously you have an axe to grind with skuzzy,but what i cant understand is how someone on the outside of HTC can tell someone on the inside of HTC that they are wrong when it come's to THEIR own product? Who are you to queston Skuzzy's background ? The only thing you have accomplished in this thread has been to show how arrogant you are .

SkyGnome · « **Reply #32 on:** April 23, 2007, 10:08:34 AM »

Quote

Originally posted by 38ruk
Lol , obviously you have an axe to grind with skuzzy,but what i cant understand is how someone on the outside of HTC can tell someone on the inside of HTC that they are wrong when it come's to THEIR own product? Who are you to queston Skuzzy's background ? The only thing you have accomplished in this thread has been to show how arrogant you are .

I don't have to have built something to understand how some aspects of it work - and this thread is an obvious confirmation of that.

In this case, Skuzzy made a false statement that was potentially relevent to the problem of the initial thread poster with the lockup problem, and refused to be corrected. I think that people who are in a position that leads others to believe what they say without question have a real obligation to be careful that what they say is correct. Mistakes happen, but those people also need to recognize that and double check accordingly when the facts don't agree with their statements.

As to why I'm a banana about it, it's partly that I'm a banana, and partly my own devious designs.

As to the lockups, one might want to make sure that the voltages out of the PSU and those indicated by the motherboard monitor are stable and within spec both under load and idle. A problem with regulation somewhere could cause a problem that doesn't show up under full load. It could be any number of other unrelated things though - these are toughies.

Eagler · « **Reply #33 on:** April 23, 2007, 10:12:18 AM »

Quote

Originally posted by SkyGnome
As to why I'm a banana about it, it's partly that I'm a banana...

If I got anything out of this thread, I did get that ..

SkyGnome · « **Reply #34 on:** April 23, 2007, 10:21:55 AM »

Quote

Originally posted by Skuzzy
However, DirectX can stall the game loop by not returning from a draw call. This only happens in a stall condition inside of DirectX or the video card driver and it is rare for that to happen.

With vsync on (and with frame-rate pegged against it), this "rare" "stall condition" happens every frame, until the monitor is done presenting the current frame.

Skuzzy · « **Reply #35 on:** April 23, 2007, 12:11:10 PM »

Actually it is pretty rare, but I guess that is a somewhat subjective term. What you visually see is no where near the granularity of what can happen. If the game was consistently stalled, the video output would consist of small jitters or non-linear motions. This would happen as the time between each fram draw would be very inconsistent. Remember, the game does run triple buffered, which helps alleviate this situation.

And in some driver/video cards, they actually dump a buffer in favor of a new one to reduce the chance of stalling.

And in a worse case scenario, such as a very slow video card, with a very fast CPU, it would happen more often.

By the way, I did not make a false statement, per se. But I did fail to take into account the DX stack and video card driver in my previous statements, which I have already corrected.

If you want to drive that home, then feel free to. I make mistakes from time to time. I do my best to be accurate, but I am not perfect. I do not need to be insulted in order to correct my mistakes.

humble · « **Reply #36 on:** April 23, 2007, 12:39:15 PM »

Skuzzy,

you didnt make any error at all. I had absolutely no problem understanding what you ment (and I'm sure 99% didn't). Basically the amount of "work" required by AH is constant. Any additional overhead {for rendering}required is specific to the computer in question. Differences in configuration & components will effect what amount (if any) additional overhead is placed on the CPU.

My broader question is pretty simple. A CPU cycle is like an airplane seat...its filled or its not. There is no inherent benifit to an "open seat"....so marginal variations in workload do not effect "total thruput"....the system is in effect bottlenecked or its not. Looking at either SkyGnomes CPU usage chart or mine you can establish a "maximum demand"...in both graphs that maximum is identical with V sync on or off...its not ever higher specifically due to v sync. I certainly agree that Sky's system "tabletops"...but he either way his max demand is the same.

So my perspective is that the "workload" required to calculate and render a frame is constant in any system {for that system}. Enabling or disabling V-sync wont change that. So the basic demand placed on the CPU does not go up. In a system that is misconfigured or less efficient or overloaded you may get a temporary break in demand...but your maximum demand is unchanged.

Basically all this is doing is proving all the time and effort you spend in providing "best configuration" 411 is well spent in providing help in "streamlining" a system so a noob like me can run my box with none of the issues Skygnome seems to have.

I guess I just dont see how you would view any GPU specific rendering demands as an AH issue. I wonder just how different these figures would be between various drivers and the same VC?

airhog99 · « **Reply #37 on:** April 23, 2007, 01:51:35 PM »

Quote

Originally posted by Skuzzy
Actually it is pretty rare, but I guess that is a somewhat subjective term. What you visually see is no where near the granularity of what can happen. If the game was consistently stalled, the video output would consist of small jitters or non-linear motions. This would happen as the time between each fram draw would be very inconsistent. Remember, the game does run triple buffered, which helps alleviate this situation.

And in some driver/video cards, they actually dump a buffer in favor of a new one to reduce the chance of stalling.

And in a worse case scenario, such as a very slow video card, with a very fast CPU, it would happen more often.

By the way, I did not make a false statement, per se. But I did fail to take into account the DX stack and video card driver in my previous statements, which I have already corrected.

If you want to drive that home, then feel free to. I make mistakes from time to time. I do my best to be accurate, but I am not perfect. I do not need to be insulted in order to correct my mistakes.

Could you please expand on what "stalled" means in your explanation. Would it freeze up the video output and stop any processing in it's tracks (like I and others have experienced), or are you talking about something else?

Stegahorse · « **Reply #38 on:** April 23, 2007, 02:35:02 PM »

Humble. What is setting your CPU to 50% at idle? If I have 4% at idle I'm into shutting off start up programs. If 50% is idle CPU you nedd to shut down some background programs, badly.

humble · « **Reply #39 on:** April 23, 2007, 03:51:49 PM »

AH was still running, what your seeing is the CPU use specific to rendering the frames. With my system the additional overhead is "almost" identical. Open the task manager and then run AH sitting in the tower...minimize it and you'll see your CPU load without rendering and with. I'm on another computer I'm reconfiguring, I'll post my CPU use from the other box in a sec here....

The "flat line" at roughly 50% is AH minimized. The preceding higher platue is with the rendering load. My "arguement" with Skygnome is in a higher end system properly configured v-sync on or off should not effect that higher load level by more then a fractional %......

Skuzzy · « **Reply #40 on:** April 23, 2007, 04:31:58 PM »

Humble, I did make a mistake. I stated an absolute without properly mentioning the other variables in the equation. Not a good thing to do as you end up wrong more than you are right. I worded that very poorly.

We have little to no control over DirectX and the video card driver/hardware. They are going to do what they do when they want to do it. We have three layers of software under us. DirectX, the video card driver, and the video card firmware. The CPU is involved in driving all but the video card firmware.

humble · « **Reply #41 on:** April 23, 2007, 04:32:51 PM »

OK........

Now I'm totally confused....

This the box I'm reconfiguring. It's a compaqI was using but it had "issues" related to my Nvidia 7900 on its ATI chipset (onboard VC). This box uses the onboard card so I'm guessing its using hardware vertexing. I'd still have expected some level of CPU use seperate from rendering...here it drops back to the floor when U minimize AH.......

Skuzzy · « **Reply #42 on:** April 23, 2007, 04:54:28 PM »

When you minimize AH, we stop rendering altogether. So you lose the CPU cycles DX and the video card driver was using up during the render time.

Everything else is still being done. But if you are offline when you are doing this, there just is not much for the game to do.

humble · « **Reply #43 on:** April 23, 2007, 06:30:01 PM »

ahhh....

Since I didnt load the patch on this box I loaded it up offline....was scratching my head a bit...so the base footprint is actually very low. It's all the online "realtime" load that creates the overhead....makes sense once you turn the lightbulb on for me:)....