Can you explain where sync signal comes? Is it external sync or vsync or sync from your app?
The point is… sync drives swap. In case you do vsync SwapBuffer would do the job.
Now… problem can be a source. Is it same freq as output? If it is then start decoding thread and use wnidows sync objects (events, critical sections and semaphores) to sync decoding and rendering thread.
“Detach” rendering from any windows message processing. You can create window, get it’s DC, start new rendering thread, create gl context and run render loop.
Example:
void renderloop()
{
if (wait_for_decoder(20)) // wait max 20ms for new frame.
{
// new frame arrive. upload data...
upload_new_frame();
}
render();
swap();
}
decoder thread should raise event when new frame arrive.
Originally posted by knackered: I’ve done realtime video playing too - didn’t need to touch the thread priority. If you’re missing frames I would suggest your sequencing is wrong. (by missing frames I mean not rendering a frame at consistant monitor refreshes)
We’ve checked this MANY times and it works correctly on other platforms, so I’m sure this is not the case.
Originally posted by evanGLizr:
[b] Well, frankly speaking, if you are using REALTIME_PRIORITY, you get what you deserve:
[quote]When manipulating priorities, be very careful to ensure that a high-priority thread does not consume all of the available CPU time. A thread with a base priority level above 11 interferes with the normal operation of the operating system. Using REALTIME_PRIORITY_CLASS may cause disk caches to not flush, hang the mouse, and so on.
Windows is not a realtime system, if this is the only problem you’ve found, consider yourself lucky and expect many more due to priority inversion. [/b][/QUOTE]Believe me, we know all the above and do expect these issues. It is unfortunate that everyone considers this line of responses when highly skilled professional realtime programers are the ones asking the questions. We have many years of experience in realtime graphics systems.
Originally posted by knackered: he obviously hasn’t run it on a single processor machine.
Who he? Yes, we have run it on a single processor machine with and without hyperthreading. This is how we confirmed the problem. And, using ATI, there is no problem on said machines.
Originally posted by yooyo: Can you explain where sync signal comes? Is it external sync or vsync or sync from your app?
vsync.
The point is… sync drives swap. In case you do vsync SwapBuffer would do the job.
You haven’t read the thread close enough. vsync drives swap if swapbuffers has completed.
The problem is that a high priority realtime thread calling swapbuffers on nVidia will block if a lower priority thread is still running. Any thread above the priority stated in my previous post will cause swapbuffers to wait for it to complete. This is wrong.
The high priority realtime thread calling swapbuffers should not have to wait on a lower priority thread to actually do the work. Or, it should at least inherit the priority of the thread requesting the work.
Now… problem can be a source. Is it same freq as output?
Yes.
If it is then start decoding thread and use wnidows sync objects (events, critical sections and semaphores) to sync decoding and rendering thread.
This is realtime rendering, not video playback.
“Detach” rendering from any windows message processing. You can create window, get it’s DC, start new rendering thread, create gl context and run render loop.
Already all done long ago.
Originally posted by ccbrianf: [quote]Originally posted by evanGLizr: Windows is not a realtime system, if this is the only problem you’ve found, consider yourself lucky and expect many more due to priority inversion.
Believe me, we know all the above and do expect these issues. It is unfortunate that everyone considers this line of responses when highly skilled professional realtime programers are the ones asking the questions. We have many years of experience in realtime embeded proprietary IG systems. [/QUOTE]It’s also unfortunate that you keep being in denial when it’s a highly skilled professional OpenGL driver developer with many years of experience answering.
Like I said Windows is not an “embedded realtime system”, so your experience is of no help here. RTOS have mechanisms to deal with inversion priority, Windows doesn’t. RTOS have mechanisms to deal with hard and soft deadlines, Windows has nothing like that. And I should know, I wrote an RTOS kernel myself for x86 with immediate ceiling priorities and the works.
Originally posted by evanGLizr: [quote]Originally posted by ccbrianf: [quote]Originally posted by evanGLizr: Windows is not a realtime system, if this is the only problem you’ve found, consider yourself lucky and expect many more due to priority inversion.
Believe me, we know all the above and do expect these issues. It is unfortunate that everyone considers this line of responses when highly skilled professional realtime programers are the ones asking the questions. We have many years of experience in realtime graphics systems. [/QUOTE]It’s also unfortunate that you keep being in denial when it’s a highly skilled professional OpenGL driver developer with many years of experience answering.
I’m sorry if I offended you. That was not my intention. It’s also hard to know anyone’s background on these forums.
It just seems the typical response to any realtime question, Windows or otherwise, is “Don’t do that, you don’t know what your doing.” We in fact do know what we’re doing in realtime programming, so I was trying to discourage that. We are still learning the poor soft realtime nature of Windows, but have fought through these soft realtime issues on Solaris before.
Like I said Windows is not an “embedded realtime system”, so your experience is of no help here.
We well know that Windows is not an embedded realtime system. Unfortunately, we’re still figureing out exactly what that means. The same warnings you gave also apply to Solaris, but it does not have these issues.
RTOS have mechanisms to deal with inversion priority, Windows doesn’t. RTOS have mechanisms to deal with hard and soft deadlines, Windows has nothing like that.
Again, well known.
And I should know, I wrote an RTOS kernel myself for x86 with immediate ceiling priorities and the works. [/QUOTE]Us too.
After testing networking, which our application also needs soft realtime response for, and finding that the stack seems to run at the same priority as the swapbuffers helper, we have decided to reprioritize our application into the HIGH_PRIORITY class and carefully set thread priorities to avoid interfering with swapbuffers and the network stack.
so after insulting everyone who’s tried to help you, you just back down without admitting you’re wrong or apologising for your attitude.
Don’t hurry back with any further problems.
Originally posted by knackered: so after insulting everyone who’s tried to help you, you just back down without admitting you’re wrong or apologising for your attitude.
Don’t hurry back with any further problems.
Um… I thought I made it pretty clear in my last post that my intention was never to insult anyone. It was simply to emphasize that as a professional realtime programer I was well aware of the traditional warnings, priority inversion, and Windows soft realtime nature. It was only an attempt to direct the conversation toward constructive comments about specific realtime swapbuffers behavior on nVidia rather than generic “don’t do realtime because you don’t know what you’re doing” style of responses.
If I need to apologize personally to anyone, I will gladly do it. I thought that stating my intention would clear up the misunderstanding without need for that. I guess I was wrong. So, if anyone feels the need for a personal apology, please speak up.
I don’t believe I was wrong about how it “should” work in an ideal realtime world. However, I know that Windows is far from such. Conceeding that we decided to do what the evidence suggests is not admitting anyone is right or wrong, but that we have to live with what is provided. I do not believe anyone gave us the specific information necessary to make this determination via this thread.
Again, I’m sorry you were offended. I try to keep my discussions technical in nature without any personal connotations. It is not always easy doing that correctly in print.
Please accept my apology, knackerd, since I see you were one of the people offended.
Conceeding that we decided to do what the evidence suggests is not admitting anyone is right or wrong, but that we have to live with what is provided. I do not believe anyone gave us the specific information necessary to make this determination via this thread.
I gave the exact solution you are using on the first answer, if don’t want to listen, at least please don’t say nobody helped …
Originally posted by ccbrianf: Please accept my apology, knackerd, since I see you were one of the people offended.
Yes, I was offended, but seeing as though you’ve been gracious enough to admit you behaved like an arse, I accept your apology on behalf of the rest of the GL posse.
Also, who the hell is macarter? I imagine him as being some poor junior programmer you ordered to find the answer to your problem, before elbowing him out of the way when the choice to run your app at realtime priority on a notoriously non-realtime OS was ridiculed on a public forum.
I could be wrong though.
edit: removed corporate thingy, just a joke, not serious, but could feasibly be misunderstood.
Originally posted by ZbuffeR: I gave the exact solution you are using on the first answer, if don’t want to listen, at least please don’t say nobody helped …
Once again I have been misconstrued. I never said no one helped. Many people gave us usefull information. But, I believe your exact solution of:
Originally posted by ZbuffeR:
[b]to me realtime priority should be reserved to processes that have finite processing needs, not something having a render loop.
Do you really need realtime prio ? very high is not enough ?,[/b]
lacked the concrete details necessary for us to craft an exact solution or understand that you were making more than a somewhat educated guess.
If you had stated:
“Many system processes and drivers that launch helper threads run at HIGH_PRIORITY_CLASS, THREAD_PRIORITY_NORMAL, so you should be careful what threads run above this. I don’t know about nVidia swapbuffers specifically, but this is the general rule of thumb.”
that would have given us enough for an exact solution.
Our application is multithreaded and requires basic thread prioritization. It is important for us to know the exact priority at which swapbuffers and other important system process run in order to allocate these priorities correctly. Your resonse may have lead us in the right direction, but it was unfortunately not enought for an exact solution. evanGLizr’s response was much closer to this.
Originally posted by knackered: [quote]Originally posted by ccbrianf: Please accept my apology, knackerd, since I see you were one of the people offended.
Yes, I was offended, but seeing as though you’ve been gracious enough to admit you behaved like an arse, I accept your apology on behalf of the rest of the GL posse.
I am trying to be very professional about this and would appreciate you not using that kind of language to accept my apology, please.
I could be wrong though.[/QUOTE]You are very wrong, and please do not bring any corporate entity into this technical discussion. Thanks.
I would like to make one last sincere apology to anyone I offended, especially ZbuffR since my last response to him may be construed this way as well.
Again, my posts were never meant to be offensive, insulting, condescending, or otherwise. Since I can’t seem to properly word my posts to prevent this impression, I’ll be voluntarily leaving this community.
Thank you once again for all the constructive advice.