T3D 1.1BETA 1, 2 and 3 BLUE SCREEN OF DOOM! Possibly reflections - RESOLVED

#41 Nvidia's desperate attempts to snatch defeat from the jaws of victory ...

#42 Nvidia's new driver (197.13)
"NO CORRUPTION WHEN SHOOTING OVER WATER!" -which makes a nice change ... still locks up though, but no bad GPU crash - I can just bring up task manager to get a cursor and close T3D. So that's an improvement.

Maybe after setting scores of people's computers on fire with the previous recalled driver, Nvidia's done a bit of looking at stability.

#43 I am running the new Nvidia driver and I still get the corruption and occasionally BSOD

#44 Random pop in thin air here, but has anyone tried rolling back GPU drivers to 2 or more versions back to see if the problems still occur?

#45 I didn't have the corruption issue with drivers 2 sets back. Dont remember the exact # but it was a 196.**
would still get the lockups and freezes but not sparkles or BSOD

#46 I have been having this issue too, I thought at first it was a card issue and I RMAed the card. I am using the latest drivers as well.

#47 Ok... i *might* have an idea of what this bug is. Please anyone that can reproduce this bug reliably give this experiment a try...

In engine\source\T3D\fx\particleEmitter.cpp around line 725 in the function ParticleEmitter::prepBatchRender()...

void ParticleEmitter::prepBatchRender( SceneState *state, const ColorF &ambientColor )
{
   if (  mDead ||
         n_parts == 0 || 
         part_list_head.next == NULL )
      return;

   RenderPassManager *renderManager = state->getRenderPass();
   const Point3F &camPos = state->getDiffuseCameraPosition();

   // Only update the particle vertex buffer once per frame
   if(state->isDiffusePass())
      copyToVB( camPos, ambientColor );

   if ( mVertBuff.isNull() ) // ADDED!
      return; // ADDED!

   ParticleRenderInst *ri = renderManager->allocInst<ParticleRenderInst>();

Let me know what you guys experience after that change.

#48 Alas nope, still get a lockup after a few shots. Latest nv Driver 197.13

#49 Well i think we have multiple bugs here... for sure my fix solved one of them.

I've been able to reproduce the other bug (the OcclusionQuery lockup) on one of the boxes here in the office. Its a really tricky one... but i hope to post a fix for that one soon.

#50 This thread has been tagged as resolved, however I can still reproduce this effect 1.1B2 fairly easily. Not actually crashing, but short freezes and occasional temporary graphical corruption. Still doesn't really seem like a "solved" issue.

To be specific:
Load stock DB Desert level, add a waterplane, fire rockets over the water until experiencing short freezes w/ screen blackouts.

Disabling OcclusionQuery on the waterblock doesn't seem to improve or change anything.

Win 7 64-bit,
GeForce GTX 285 running just-updated drivers 258.96.

Upgrading to these drivers seems to have reduced the chance that the freezes and flickers will evolve into a full-fledged driver failure with lasting graphical corruption, but the freezes themselves remain easy to reproduce, especially if you turn up the refire rate on the rocket launcher and add some more ammo. On random occasions I've still been able to produce graphical oddities such as certain materials being replaced with solid colors. Unforunately I wasn't able to get a screenshot of this effect.

As a workaround for now, I've disabled reflect pass rendering of particles entirely. Following Tom's example from above, I figured I could just bail from this function if this was the reflect pass, and it seems to have worked:

void ParticleEmitter::prepBatchRender( SceneState *state, const ColorF &ambientColor )
{
   if (  mDead ||
         n_parts == 0 || 
         part_list_head.next == NULL )
      return;

   RenderPassManager *renderManager = state->getRenderPass();
   const Point3F &camPos = state->getCameraPosition();

   // Only update the particle vertex buffer once per frame
   if(state->isDiffusePass())
      copyToVB( camPos, ambientColor );

   // [HNT] particle reflections still cause freezes
   if (state->isReflectPass()) // ADDED
      return; // ADDED
   // [/HNT]

Not the best solution, but freeze/stutter-free reflections w/out particles is still better than the alternative. I'd be happy to do more testing, but I'm not really sure what I should be looking for/recording/debugging.

#51 Henry I get stutter, but infinitely prefereable to before - I still think that it's because the particle effect for the rocket trail is ridiculously dense.

Make a new bug report for 1.1.beta2, and link to this thread.

#52 I'm getting the same.. firing over a river using he rocket launcher projectile causes a lock up on the gpu, then after two more goes it blue screens. July 2010 nvidia drivers. 1.1b2

Edit: applying your fix Henry (based off Tom's) did work for me, I fired over 400 projectiles over water and no lock ups as of yet, with quarter of a second delay between each shot.

#53

Quote:Not actually crashing, but short freezes and occasional temporary graphical corruption.

That short freeze is a sort of GPU reboot that the driver is doing when it detects that the card is having a problem.

Most definately there is still an issue here and we're still looking into it.

#54 I agree there is still an issue, this resembles a RAM or overclocking failure on a card. Tons of artifacts and other issues directly related to what looks to be video memory or core clock issues.

#55 Gotcha Tom, not knowing bugger all about hardware in general never mind rendering stuff, just figured it was lag on rendering a whole set of new particles.

Moved back to bug thread!

#56 Logged as TQA-799 for the QA team to verify.

#57 I do not know if this is related or helpful, but I will post it anyway on the off-chance it is relevant. I used to get the same error as described under similar circumstances, but I no longer have the rocket gun in the game, so that removed me from the crash pool.

However, I began receiving BSOD repeatedly with the nVidia driver release 258.96 in (AFX) T3D (Beta 1).

It happens within five or ten minutes of a full reboot.

This only happens when running the Torque engine--Visual Studio, Constructor*, Champions and City of Heroes did not exhibit the issue and can run for hours on the same machine. This machine is normally stable, running for weeks on end.

The specific error is:

NV_4_DISP
0x000000EA
(0x89FCD3F0,
0x8AO33980,
0xF78C6CBC,
0x00000001)

Rolling back the drivers to 197.45 caused the error to completely disappear.

*The error could be generated with 100% replicability when both Constructor 1.06 and the T3D engine were running by the following means:

1) Run a T3D mission.
2) Run Constructor with a model open.
3) AltTab to T3D.
4) AltTab back to Constructor.
5) Click the File menu with the mouse.
6) BSOD with the above error.

Windows XP SP 2
Nvidia GeForce 240GT 1 GB
Intel Pentium 4

Editing to note that that is one way to guarantee replicability--the engine will crash to BSOD for me with the newer nVidia package with or without Constructor open. That was just one way I discovered to make the crash immediate.

#58 I was able to get windows to create a minidump of this issue (Windows 7) i have yet to examine it, I will try to do that later.

#59 For those who still run into this bug:
1. Go to your driver settings -> advanced -> Troubleshoot
2. Make sure you have zero 'Hardware Acceleration' and uncheck 'Enable write combining'.
4. Press OK,and OK again to apply these changes.
4. Restart Windows.
5. Post results.

#60 Ivan, that is not an acceptable work around. That disables all hardware acceleration in Windows and is only done on machines as a temporary fix to address issues in the 2d/3d desktop environment. Since Windows Vista and 7 utilize hardware acceleration for the "Aero" theme, disabling this would effectively remove this capability aand other features. This should ONLY ever be done as a troubleshooting method to identify a potential driver or card related issue. In addition, this issue has been corrected in beta 3 and with a small "fix" you can disable the reflections with resolve it almost completely. The fix that resolves this almost 100% http://www.torquepowered.com/community/forums/viewthread/110795/3#comment-769375