[other] Problems with dropping frames with EVR (1 Viewer)

[disaster123]

AW: Problems with dropping frames with EVR

tourettes
but for example on my second htpc client Athlon X2 4400 + ATI HD4350 on SD the hnssampletime is always about 30ms and the timeperframe is 20ms but still no dropped frames how could this be?

Also hnssampletime on HD is mostly lower than on SD? Doesn't HD require more GPU ressources?

 

[Scythe42]

Re: AW: Problems with dropping frames with EVR

Can anybody also tell my how it could be that the hnsSampletime is sometimes higher than timeperframe and still no frame drops? Or isn't hnsSampletime the time it took to present the last sample?

It's the delta to presentation time. The delta is larger than the display time of a frame for the next frames. When you have five frames in the queue only the one due for this vsync will have a delta to presentation time smaller or equal to the display time of a frame. All other will have a larger one until they are due. Late frames will have < 0 because their vsync is already gone. No there is no grace period.

That's why that portion of the code that took what's smaller (hnsSampleTime or timeperFrame) was removed as it reschedules future frames unnecessarily early. And it is also the reason why I proposed removed the /x from the CheckForScheduledSampl, which seems to work good for slower machines. The /x just limited the time left for rendering to a more specific value instead of giving as much time as possible.

About that timeKillEvents: they can probably be removed as the timer is already done at that point in time. It's might be a left over from when the timer was periodic I guess. Just log the result of the kill and the timerIDs to see which timer the code tries to kill when. Then you know...

 

[disaster123]

AW: Problems with dropping frames with EVR

Thanks for this explanation.

My idea is to make the scheduler a little bit more intelegent i will implement a third var which gives the status of the schedule think back to the scheduler. Perhaps this helps a bit

 

[tourettes]

Re: AW: Problems with dropping frames with EVR

Can anybody also tell my how it could be that the hnsSampletime is sometimes higher than timeperframe and still no frame drops? Or isn't hnsSampletime the time it took to present the last sample?

It's the delta to presentation time. The delta is larger than the display time of a frame for the next frames. When you have five frames in the queue only the one due for this vsync will have a delta to presentation time smaller or equal to the display time of a frame. All other will have a larger one until they are due. Late frames will have < 0 because their vsync is already gone. No there is no grace period.

Yep, indeed... dunno what I was thinking.

 

[disaster123]

AW: Problems with dropping frames with EVR

Can one of you both tell me where the code is which we execute when the timeSetEvent is raised? At which point is p->eHasWork.Wait() set to true? Or where is the function behind it located?

And which thread does enqueue the frames into:
m_qScheduledSamples?

I often have the problem that it is empty when the scheduler is raised. Doesn't it make sendeto have a buffer of 2-5 frames or so?

 

[Scythe42]

Re: AW: Problems with dropping frames with EVR

Can one of you both tell me where the code is which we execute when the timeSetEvent is raised? At which point is p->eHasWork.Wait() set to true? Or where is the function behind it located?

I'll try to explain it from memory.

We set a timeSetEvent that calls the TimerCallBack() function from Schedluer.cpp. This sets Set() of the CAMEvent object part of the schedulerParams typedef when the timer expires.

See CAMEvent Class (Windows) for more about CAMEvent objects.

When Set() is called the Wait() in the Scheduler loop becomes false and the scheduler loop continues for this thread (trying to kill the timer, measure the locking latency, try to kill the timer in case we are done with the scheduler). Then it gets the new delta to presentation time by calling CheckForScheduledSample() that breaks when the sample is not ready for presentation yet but returns the new delta. This delta is then used to schedule the sample again.

A sample get taken out of the queue by calling PopSample() in CheckForScheduledSample() if the sample is up for scheduling or already late. Based on that it's rendered or simply dropped.

In addition there's the WorkerThread pumping new samples (up to five - increasing doesn't do anything for performance) over ProcessInputNotify() into the queue.

Think of it as a fancy way to get multithreaded sleeps...

As mentioned earlier the two timeKillEvent() calls can be removed as they seem to be leftovers from the time when the timeSetEvent was probably periodic. At least this is my guess because they were already there when I started to work on the code and I was too lazy to go back through SVN to see what changed here over time.

I'm not 100% sure here yet. When I have time for testing I will remove these two from SVN. But one change after another. I don't like to test more than one change at a time in such a sensitive area.

That's mainly the only optimization still left here. The rest is just about some timings. And with the recent test we get some experience from the users what works well. More on that and the various DLLs once we finished the testing.

There isn't much you can do better here beside what's already discussed and currently under user test (among other patches).

If you want to do some real optimization than start looking at PresentSample() and follow it up through the C# code.

That's were the CPU bottleneck comes in because of varies copy operations as explained by tourettes in this thread. And this is the place where you can improve things by branching code for ATi/Nvidia or XP/Win7 etc.

So please no more daily DLLs with other timings or sleep vs. timer unless you find something to provide way more render time. But as said this is limited by the display time of a frame and we already near the limit here in the currently ongoing test.

Playing more with the scheduler doesn't improve things. Yes I know, it is such easy code that it is tempting. But it's the wrong place. Samples are presented as early as possible with my recent suggestion and rendered as early as possible. What else do you want to improve here? It's not like samples are scheduled wrong.

 

[disaster123]

AW: Problems with dropping frames with EVR

Thanks again for great post - you're correct i know that there isn't the problem - my small goal at the moment is to provide a .dll which is working for everybody - everybody doesn't mean to solve all dropped frames as this is not a scheduler problem but it means a single dll that ION and ATI HD3200 users like me can use. At the moment ION users want ver 2 and i want ver 3 . But we'll do this via PM i've mailed onkelchris and nyt. If they say my dll provide good results (it does for me) than we perhaps have not solved this problem but we have a dll for ION users and others where ver 2 isn't an option.

But i'll have a look at PresentSample too.

Scythe42
strange the paint method is going from 0.5ms up to 40ms on my system - really strange.

 

[nyt]

just found something big. Perfect playback through bird scene with no dropped frames and a perfectly smooth graph. I set windows refresh rate to 23hz and disabled automatic refresh rate changer. Going to test some more and see exactly whats doing it.

 

[Scythe42]

Re: AW: Problems with dropping frames with EVR

But we'll do this via PM i've mailed onkelchris and nyt. If they say my dll provide good results (it does for me) than we perhaps have not solved this problem but we have a dll for ION users and others where ver 2 isn't an option.

I just want to avoid having each day a couple of new dshlepers as this confuses the majority of users and I want a result on the current test before taking it forward or combining approaches. Taking it private for some more testing it probably the best idea for now. If you guys come up with a good compromise let me know.

Again, I really appreciate your efforts to get a solution that works for most of the users. Even though I'm getting a little bit tired of explaining what the current presenter does

strange the paint method is going from 0.5ms up to 40ms on my system - really strange.

The paint time currently does include the time up to and including the next vsync until the sample is presented. That's why it was removed from the stats renderer No time to fix it..

40ms probably means that it was called very early in the current vsync cycle and had the whole display time up to the vsync for rendering if you used a 23.976fps sample.

just found something big. Perfect playback through bird scene with no dropped frames and a perfectly smooth graph. I set windows refresh rate to 23hz and disabled automatic refresh rate changer. Going to test some more and see exactly whats doing it.

23Hz selection on NVidia or ATI means 23.976Hz. They have some really odd labels, which confuses users even more.

 

[disaster123]

AW: Problems with dropping frames with EVR

Scythe42
sorry I know it's exhausting to explain it again and again and to others but it helped me a lot. At least for me i've now a scheduler even better than version 3 in the post. Now i try to track down the problem in the paint sub - never seen something that "randomly" goes from 0.3ms up to 40ms.