Topic Title: Frames rendered but not published
Topic Summary:
Created On: 04/10/2013 11:07 PM
Status: Post and Reply
Linear : Threading : Single : Branch
Search Topic Search Topic
Topic Tools Topic Tools
View similar topics View similar topics
View topic in raw text format. Print this topic.
 04/10/2013 11:07 PM
User is offline View Users Profile Print this message

Author Icon
JoJo T Magnifficent
Peon

Posts: 10
Joined: 04/10/2013

I have had an unusual problem which has been driving me up the wall for a while now and is seriously negatively impacting my gaming in certain games. I originally thought it was unique to Tribes: Ascend as it was the first game I noticed it in but it seems to be consistient across multiple games when the apropriate conditions are forced. Those conditions are namely having a low framerate (it can depend on the game, but generally anything lower than 60 can make it noticeable). It may be possible that it is happening at higher framerates as well but is not noticeable because of said higher framerates.

The basics of the issue is that despite the framerate being in the 40-50 fps region often enough, the game is practically unplayable and it feels much closer to 10-20 fps at times. I intially assumed it was a problem with Tribes (which has terrible optimization and has been getting notably worse as the patches have rolled in) and decided to try recording it so I could sho others just how awful the game ran. To my surprise though when I went to review my recording (taken at a capped 30 fps) the recording was perfectly smooth, exactly as a solid 30 fps shold look like (and decidedly NOT what I was seeing on my screen). After seeing this I decided to test other games too, ones I never had issues with. Sure enough, even in UT 2k4 where I get 200-500 fps and it felt perfectly fine, when I cap it to 30 fps it felt unplayable and looked like I was getting fps in the teens. Video recorded fine though again. I have also tried taking a recording using the nVidia FCAT overlay at 100 fps (when lossless and 360p my computer can manage recording at 100fps well enough) and going through frame by frame to see if FCAT brought up anything and FCAT seems to re-inforce this, each frame was being registered on the FCAT overlay just fine so obviously they are being rendered and even told to publish by Direct X (as per my understanding of how FCAT works). So that only really leaves me with two possible areas for this fault to be occuring, inside windows handling of Direct X calls or inside the AMD drivers themselves.

I'm inclined to think the problem is not windows as this problem has persisted over both winXP and win7 installs (just upgraded recently in an effort to make tribes playable) and affects some games worse than others (BF3 didn't pose a huge problem for me for example). It's also happened over multiple drivers though, both 12.8/12.9 on XP and 13.1 and the 13.3 beta on win7.

 

Has anyone ever heard of a problem like this or do you have any ideas on how to fix it?

 

Specs are:

Win7 Pro 64-bit

Core 2 Duo e6750@3.2GHz

3Gb supertalent DDR2800@~900MHz (2gb dual channel, 1Gb single)

MSI radeon r6850 PE OC @ 910/1100

Corsair HX 520W PSU

GA-P35 DS3P mobo

2 asus dvd-rw's

2x250Gb seagate hdd in raid 0 (OS+Games)

1x250Gb seagate hdd (project work)

1x1Tb seagate hdd (media n' stuff)

1x1Tb Samsung hdd (Steam+Games)

Screens:

Hyundai v773 17" CRT (DVI-A -> VGA)

Samsung 206BW (DVI-D)

 

All OC'd stuff is running stable and has been for years (cept the 6850 ebcause that was bought a year and a bit ago to replace a dead 8800 GTS 320), the 3gb of memory is cause I had one stick fail after about 4 years and it wasn't worth hunting down and overpaying for DDR2 (mobo can handle split dual/single channel too).

 04/15/2013 10:27 PM
User is offline View Users Profile Print this message

Author Icon
BatCat
Peon

Posts: 29
Joined: 04/15/2013

Do a search for "inside the second". Great article pointing out a problem.

 

Frames are not coming out evenly spaced. Clean 60fps that don't look it.

Like a big delay on one frame and the next near instantly ready.

Think of rocket wizzing by yer head, come at ya nice and smooth. Then one single frame rocket and its FX fill the screen, the transperancy in the smoke, or something, causes the entire world to be rendered TWICE. Then its gone.

Slow and fast single frame times = lumpy.

We notice the big FX slowing a number of frames and we tolerate it. Like buildings and a bunch of cars blowing up at once over a number of frames, lags some.

But lots of little ones on single frames. yuck

 



-------------------------

Phenom ][ 965, Gigabyte 790fx ud5, Saphire AMD 7970 Ghz, 4gig OCZ 1066, Eyefinity 3x ASUS vw266 (1920x1200x3), OCZ Vertex boot, assorted others.  Asus Xonar DSX > 5.1 ~700w Sony  :)

 04/15/2013 10:53 PM
User is offline View Users Profile Print this message

Author Icon
Mkissner
Farming Materials

Posts: 597
Joined: 07/01/2010

Taking BatCat words a bit further, read this.. It's a bit technical (even I don't understand some parts of it), but you'll get an idea of how frames are brought to you..

http://www.anandtech.com/show/6857/amd-stuttering-issues-driver-roadmap-fraps

If I can't post this, please Mods, edit it..

Interesting reading too (I'll search yours, BatCat.. ), and it resumes a bunch of regular problems posted on this forums, with the respective answers why.. BTW, if you think it's not a partial Windows problem, then you're mistaken..

 

Best regards...



-------------------------

8320 @ 4,7 / 990FXA UD5 / CF-X 7970 + 7950 / Switch 810 / H110 p-p / 16 GB RAM / 23" 5760x1080 / SSD 64GB RAID0 / HX750 / SB Recon3D Fatal1ty Champion / z506

 04/16/2013 12:04 AM
User is offline View Users Profile Print this message

Author Icon
JoJo T Magnifficent
Peon

Posts: 10
Joined: 04/10/2013

Thanks for the articles BatCat and Mkissner, I'm going to try downloading Microsofts GPUView tool to see if I can turn up the exact problem with that. One thing I will add is that I have noticed several times that MSI Afterburners fps counter and frametime do not seem to be consistient (i.e. 60 fps doesn't have a frametime of 16.7ms).

 

EDIT: Okay, I gave GPUView a go but it seems it thrashes my CPU too hard to maintain 30 fps fo consistient readings of the present calls. They do seem to line up with the framerate I was getting while logging though. I did notice that there would quite often be large gaps in between the DirectX calls often exceeding 100ms though. It certainly wasn't meeting it's 30 fps target consistiently like the framerate counter was suggesting.



Edited: 04/16/2013 at 03:07 AM by JoJo T Magnifficent
 04/20/2013 11:31 PM
User is offline View Users Profile Print this message

Author Icon
JoJo T Magnifficent
Peon

Posts: 10
Joined: 04/10/2013

Sorry ephhansharding, I think you may have missunderstood my issue (or replied to the wrong thread). I'm not rendering offline with blender or anything, I'm talking about gaming. Frames are being renderd on my GPU but they are never making it to my screen.

 

After reviewing GPUView it's kind of hard to tell whats going on, despite the claims of only costing a couple of fps I found it absolutely wrecked performance in many cases so it's hard to tell what is the falt of GPUView and what is my computer. Perhaps I simply don't have enough memory to log and it has to massively thrash the HDD.

Looking at V-Sync (blue) vs Present calls (red) in the attached image it's easy to see why it's so unsmooth though, at ~30 fps I'm getting 1 present in two syncs, then one after 3, then one each sync for the next two etc. The presents are randomly strewn through out the syncs with no regard for apparent framerate. It should be 1,0,1,0,1,0,1,0,1 etc. for presents per sync, but instead I'm getting 0,1,0,1,0,0,1,0,1,1,0,0,1,1,0,0,1,0 etc.

Screen cap of GPUView is at http://i.imgur.com/1PTiMfE.png (forum attatch pretty much crashed my computer when I tried to use it :S Firefox claims one of the scripts on the page is broken.

 05/14/2013 05:54 PM
User is offline View Users Profile Print this message

Author Icon
JoJo T Magnifficent
Peon

Posts: 10
Joined: 04/10/2013

Okay, I am now 99% sure this is an issue with AMD's divers. I found a dll hack caled d3d antilag which basically takes the d3d9.dll and intercepts game calls to inject two things. The first is an override for the frame render-ahead/flip queue size (the anti-lag part) which by default sets it to two (same as default in AMD drivers?). The second part is it introduces a framerate cap and, more importantly, frame metering.

Using the dll to run UT3 (one of the most problematic games for me) at 30 fps resulted in a nice smooth experience (relatively speaking) with none of the horrible stutter that left it practically unplayable before. Capping at 60 (I get 80-110 fps generally) resulted in it feeling like I just built a whole new system, it was amazing It is my suspicion that part of my issue is because of the mismatch between my c2d and 6850 the driver simply doesn't get a high enough workload and constantly gets put to sleep, resulting in frames getting published late frequently, resulting in what should be a smooth 30 fps running at a jerky 15-60 fps instead.

I know AMD have the mystical prototype driver in the works, so hopefully that will come out and fix everything (although I've only seen it said to adress crossfire?). It's nice to know that my hardware is okay and it's definately a software issue (I guess there is a small chance it is D3D and not drivers, but it seems highly unlikely to me), but unfortunately it's a dll injection hack so it's quite possibly going to get me banned in any MP game (was lpaying UT3 offline). plz hurry with new driver AMD.

 05/15/2013 04:21 PM
User is offline View Users Profile Print this message

Author Icon
Eydee
Ninja Zombie Killer

Posts: 4905
Joined: 12/27/2008

Originally posted by: JoJo T Magnifficent Using the dll to run UT3 (one of the most problematic games for me) ...

The UT3 engine has a stupid thing designed for consoles called frame smoothing. Unfortunately game developers don't even know about it, so games come with it turned on. If you edit the game's engine.ini file and turn off this smoothing, you get a much better experience (despite what the name says, it doen't smooth anything on the PC).



-------------------------

CPU: AMD Phenom II X4 810 @ 3120MHz | RAM: Kingmax 2x2GB DDR2 800 @ 833MHz| MoBo: MSI K9A2 CF v1.0 (BIOS: 1.D)| GPU: Asus HD 6850 1024MB (DirectCu) @ 835/1135MHz | Display: L24FHD | PSU: PC Power & Cooling Silencer 750 Quad | OS: MS Windows 3.11 Pro x64

 05/15/2013 05:16 PM
User is offline View Users Profile Print this message

Author Icon
JoJo T Magnifficent
Peon

Posts: 10
Joined: 04/10/2013

Frame Smoothing is off already. I play Tribes: Ascend competetively so believe me, I know all about UE3 and how terrible it is. It's more to do with how unbalanced UE3's CPU and GPU requirements are. Even the most demanding UE3 game tends not to need that much GPU power but it will happily eat up CPU time cause everything runs on interpreted scripts instead of natively in the engine.

 05/15/2013 07:15 PM
User is offline View Users Profile Print this message

Author Icon
Thanny
Alpha Geek

Posts: 1417
Joined: 07/13/2009

RadeonPro has a built-in frame limiter which shouldn't trip any cheat-detecting systems.  I found I had to use it with Skyrim to get smooth frame times.  I expect it would work well for your purposes as well.

As for the whole FCAT craze you see lately, it's important to note that every site I've seen that covers it has made a fundamental conceptual error in their conclusions.  They're using terms like "practical frame rate" that arbitrarily subtracts partial frames less than a certain size from the count of frames rendered (they call them "runt frames").

The problem, of course, is that if you're not using vsync, every single frame you render is only partially displayed on any given screen refresh.  While it's clear that AMD should do some work to more evenly pace their frames, simply declaring that the real frame rate is lower is nonsense.  The *real* frame rate is the lesser of the actual frame rate and the monitor refresh rate.  Without vsync, every frame will be either only partially displayed, or split across multiple screen refreshes.  With vsync, every single frame ever displayed is complete.

I just find it simultaneously amusing and maddening that these "tech" sites never discuss screen tearing, and now that they've latched onto a method of analysis which doesn't even exist without screen tearing, they're even more oblivious than ever.

 05/15/2013 07:43 PM
User is offline View Users Profile Print this message

Author Icon
JoJo T Magnifficent
Peon

Posts: 10
Joined: 04/10/2013

It's not frame limiting that helps (I can do that with MSI afterburner and it's how I've been testing stuff at 30 fps), it's actual metering that fixes the frame pacing (not sure if Radeon Pro does this). I've also tried Radeon Pro but I could never get it to hook correctly with many games (particularly Tribes because it uses a launcher).

 

As for FCAT and runt frames, while I agree that they don't seem to have properly grasped the issue correctly, for analysis of crossfire at least it is still pretty valid. You are essentially missing a frame that is still part of the simulation at the end of the day, and that does drop the apparent framerate. The bigger issue though I think is how frame timings align with V-Sync pulses, but I don't think there is any way to measure that other than GPU view which is kind of impractical for benchmarking numbers.

I do quite like the "frametime spread" graphs they produce though, I find them the most useful because the average gives you a good idea of theoretical performance while the "spread" or width of the line indicates how smooth it actually is. I would be interested in seeing V-Sync adjusted graphs that roudn up to the nearest sync pulse, that would probably give the best indication of "practical perofrmance."

 05/16/2013 08:22 PM
User is offline View Users Profile Print this message

Author Icon
Thanny
Alpha Geek

Posts: 1417
Joined: 07/13/2009

Originally posted by: JoJo T MagnifficentAs for FCAT and runt frames, while I agree that they don't seem to have properly grasped the issue correctly, for analysis of crossfire at least it is still pretty valid. You are essentially missing a frame that is still part of the simulation at the end of the day, and that does drop the apparent framerate.

 

Well, that's just the conceptual error I'm talking about.  With a refresh rate of 60Hz, you're only getting 60 frames per second, no matter what you do.  With vsync off and a render rate of more than 60 frames per second, that means the frames you see are going to be a combination of parts of different frames.  If the render rate is fast enough that some frames aren't even being displayed partially, you're not actually missing anything.  Those dropped frames will still be surrounded by frames rendered inside the same refresh interval. 

So if you have a consistent frame rate of 180 on a 60Hz display, perfect pacing with no dropped frames would mean each screen refresh will be composed of a third of frame A, a third of frame B, and a third of frame C.  If one of the frames is dropped, then maybe you're looking at half of frame A and half of frame C.  Or maybe a third of A and two thirds of B.  Either way, you're looking at multiple partial frames slapped together into one complete frame.  The only thing you actually lose is another seam eligible to show screen tearing with.

With vsync, nothing is ever sent to the display except at the vertical blanking interval.  Either there's a new frame ready at that time or there isn't.  If there always is, then you get a perfectly paced 60fps (or whatever the screen refresh is).  If there isn't, then the screen doesn't change for one refresh cycle, and the process repeats.  With double buffering, if the frame time is between 16.67ms and 33.33ms, you will be at 30fps.  That's because buffer swaps only happen at the vertical blanking interval, so a render time of 17ms means the GPU finishes a frame 0.33ms after the skipped refresh, and has to sit idle for 16.33ms because there's nothing to write to.  Triple buffering adds an additional buffer so there's always either nothing left for the GPU to do until the next screen refresh (two complete frames waiting to be displayed) or an unlocked buffer that it can continue rendering to.  That means only some refresh intervals are skipped with frame times >16.67ms, rather than every other one.  Either way, it's always the case that only a single complete frame is displayed, and the time elapsed since the previous frame is a multiple of 16.67ms.

 

 05/16/2013 09:05 PM
User is offline View Users Profile Print this message

Author Icon
JoJo T Magnifficent
Peon

Posts: 10
Joined: 04/10/2013

Originally posted by: ThannyWell, that's just the conceptual error I'm talking about.  With a refresh rate of 60Hz, you're only getting 60 frames per second, no matter what you do.  With vsync off and a render rate of more than 60 frames per second, that means the frames you see are going to be a combination of parts of different frames.  If the render rate is fast enough that some frames aren't even being displayed partially, you're not actually missing anything.  Those dropped frames will still be surrounded by frames rendered inside the same refresh interval.

 

Thats not quite correct. Yes if you get 200fps it's not a big deal, it will manifest as a bad tear but Vsync can fix that. At ~60 fps though the actual PRESENT separation might still be inside 16.7ms, but that doesn't always mean the internal rendering simulation has them separated that much. I can't remember who it was but there was a good video demonstrating why it was an issue, it creates very noticeable hitches and jumps that drastically impact visual performance negatively. The present intervals might only be 16ms apart but they can be 33ms or more apart in the game simulation. You might still be getting updates at 60hz, but the game simulation is being presented at 30-120hz in a constantly varying and unpredictable manner. The issue is also generally much bigger at below refresh than above (which you can't always guarantee).

 

This benchmark I took with FRAPS of me playing Tribes Ascend shows the problem quite well. http://i.imgur.com/PW1Hn5m.png You can see in this image that even though the internal simulation is capped at 90Hz the actual frametimes regularly exceed that so that I might see on step on time, the next is the same frame with the enxt part of the simulation jammed in partially down the bottom and then I ge the next two steps at random spots in the next update. What should be a consistient 90fps actually ends up appearing more like a randomly flailing 15-150 fps.

To further illustrate, http://i.imgur.com/F1HJmcX.png shows what things are like for me capped at 30 fps. I should be getting a new frame every second sync, instead though it randomly spreads them out, some syncs will give me 2 updates in a row while others might have to wait 4-5. Let's just say it leads to some pretty unoptimal gaming at anything below refresh and even above it can still have a bad affect untill you get into the hundreds of frames.

 05/17/2013 08:31 PM
User is offline View Users Profile Print this message

Author Icon
Thanny
Alpha Geek

Posts: 1417
Joined: 07/13/2009

I didn't mean to suggest that vsync can cure all engine problems (whether they be caused by a flaw in the game or in the driver).  I downloaded the utility you used for those graphs, and created the same for my experience with Skyrim. 

Here's what happens with just triple-buffered vsync, which is quite horrid, as you can see.  It looks incredibly jittery on screen, and makes the game entirely unplayable.  Precisely the same thing happens both with and without Crossfire.

This is what happens when you force the game to use a single CPU core.  A huge improvement, as you can see (both on the graph and in the game), but not a great solution given that many parts of the game really need more than one core to keep up.

Finally, here's what RadeonPro's dynamic framerate control does.  Butter smooth.  There are occasional hitches here and there, but it overall it completely solves the problem.  A problem that no other game I own seems to have, which tells me it's not a driver fault, though it's certainly conceivable that a driver update could fix it.

Have you actually tried using RadeonPro's dynamic framerate control in Tribes: Ascend?

 

 05/18/2013 03:41 AM
User is offline View Users Profile Print this message

Author Icon
JoJo T Magnifficent
Peon

Posts: 10
Joined: 04/10/2013

Yea, I couldn't get Radeon Pro to hook with Tribes at all. Guess I can give it another go. I'm also very reluctant to use any V-Sync implementations because Tribes being the terribly optimized game that it is it regularly drops below 60, plus being UE3 it adds a huge amount of input lag. I snipe in competition team for Tribes so as much as the stuttering wrecks thigns for me, the massive input latency would just be worse.

 

It's also my understanding that the dynamic framerate control relies on dynamic V-Sync doesn't it? Framerates might come out smooth but I'm not a fan of the unpredictable changes in input latency that it incurs.

 05/18/2013 11:58 AM
User is offline View Users Profile Print this message

Author Icon
Thanny
Alpha Geek

Posts: 1417
Joined: 07/13/2009

I've only ever seen one game that has "input lag" with vsync on, and that's Dead Space.  I've actively looked for it in other games, and it's just not there.  That includes twitch shooters.  Back when Wolfenstein: Enemy Territory was still in use, I played a lot on sniper-only servers while using vsync, and cleaned up.

As for getting RadeonPro to work, try the link I put in a previous post.  That points to the latest version, the release notes of which mention Tribes: Ascend explicitly (and it probably works).

As for the dynamic framerate control, it's entirely separate from dynamic vsync.  The latter entails turning vsync off when the frame rate drops below 60, and back on when it goes above 60.  That allows tearing, but lets you use vsync without triple buffering, which is the only thing that might add any amount of latency (i.e. the badly named "input lag").  As I said, though, I don't get any latency problems with or without triple buffering. 

I don't know exactly what the dynamic framerate control is doing behind the scenes.  All I know is that it fixes the badly bugged Skyrim engine, and I suspect it might help you with Tribes: Ascend.

 

 05/18/2013 06:34 PM
User is offline View Users Profile Print this message

Author Icon
JoJo T Magnifficent
Peon

Posts: 10
Joined: 04/10/2013

Deadspace didn't even use V-Sync, their option was actually just a 30 fps cap

It's worse in some games than others, your example of wolfenstein is one where it's much better, iDTech and Source games tend to be pretty good about it and you only get one frame delay tops. Others though (such as UE3) completely tank and gain massive amounts of lag. I'm pretty sensitive to input lag unfortunately so I tend to find it quite noitceable. I can certainly tolerate it in Source games or iDTech games or even Crysis 1, but in some games, mainly UE3 ones, even with tripple buffering I find it intolerable.

I gave Radeon Pro another go and managed to get it working this time. Unfortunately it only seems to have a noticeable affect when I cap it at the lowest possible framerate I can get (which in Tribes is ~30). Unfortunately thanks to UE3s way of rendering and handling input (and the fact that in Tribes 1 frame is the difference between hitting a capper and missing him by 50m at 30 fps, it still is basically unplayable. It didn't really feel like it gave the improvement that the antilag dll hack did at higher uncapepd framerates unfortunately. UE3 is natuarally pretty high in input latency anyway thanks to it's long rendering pipeline that usses lots of multi-frame buffers, adding V-Sync in there to stall it just makes things go bonkers I find.

 

Given that the potential driver fix is still possibly months away I've just given up and decided to get a new CPU (and RAM, and MOBO), ironically an AMD one :S Hopefully that will fix the issue by not starving the driver of work, or at the very least push my fps high enough that it is not much of an issue any more.

 05/19/2013 10:03 PM
User is offline View Users Profile Print this message

Author Icon
Eydee
Ninja Zombie Killer

Posts: 4905
Joined: 12/27/2008

Do not take this as an insult, but I seriously advise you to get a console and play the console games on it instead of trying to fix the crappy ports. If you think it's the drivers, just go ahead and buy something from a different vendor, no one's going to stop you. The important thing is to get these games work for you.



-------------------------

CPU: AMD Phenom II X4 810 @ 3120MHz | RAM: Kingmax 2x2GB DDR2 800 @ 833MHz| MoBo: MSI K9A2 CF v1.0 (BIOS: 1.D)| GPU: Asus HD 6850 1024MB (DirectCu) @ 835/1135MHz | Display: L24FHD | PSU: PC Power & Cooling Silencer 750 Quad | OS: MS Windows 3.11 Pro x64

 05/19/2013 11:06 PM
User is offline View Users Profile Print this message

Author Icon
JoJo T Magnifficent
Peon

Posts: 10
Joined: 04/10/2013

I have been tempted, but consoles are stupidly expensive over here and I don't have a TV (barely watch TV anyway, mostly what I do is on PC). Fixing what I do have is the cheaper solution. I've ordered a new CPU (FX-6300) so that should hopefully resolve the issues if my suspicions are correct, or at least give me the fps boost I need to minimize them signifficantly. I do kinda wish AMD would work harder on their drivers though, their hardware is largely pretty good and the competition in the market place is only a good thing for consumers.

Statistics
85719 users are registered to the AMD Support and Game forum.
There are currently 9 users logged in.

FuseTalk Hosting Executive Plan v3.2 - © 1999-2014 FuseTalk Inc. All rights reserved.