getting access to VSync interrupt

[OSR_Community_User]

Yes, my work was done in another OS.

I like to say that the operating system has, at best, a loose grasp of the
concept of “time” which boils down to “time monotonically increases in
each core”. As others have suggested, D3D would be the safest approach.

At least one question I don’t have the answer to for flat displays is the
duration of the Vsync interval. There was a time when I could quote it
for a variety of screen resolutions, but that time is now more than 20
years in the past.

Probably tbe fastest way to accomplish a notification to user space is to
enqueue a DPC request, and let the DPC do the completion of a custom
DeviceIoControl. There seems to be a horrid fascination with using events
to notify user space, but this is a clumsy and convoluted way to handle
what is actually a very simple concept. Look for threads discussing
“inverted call”, and forget that you ever heard of events as a
kernel-to-userspace notification mechanism, except, just maybe, in the
context of using an Event in the OVERLAPPED structure–which, I might add,
is still a lousy way to handle it.
joe

Hi Joe,

swapping frame pointers (or maybe overlay frame pointers)
on VSync would be a dream, of course. That would be step 3,
if it is possible to achieve at all from my own driver. My first 2
steps would be (1) counting the VSyncs. And (2) notifying user
land about them. I guess you did that high-performance video
stuff on another OS and not on Windows?

I know that timing in user land isn’t too reliable, even if you use
the highest possible thread priority. My video rendering code is
working in such a way that I don’t necessarily have to run inside
of the VSync period (although of course that would be great!).
It’s ok if I’m getting the VSync notification a bit too late sometimes.

About the event: What would be the best (performing) way to
notify user land from within an ISR routine? Maybe using
IoQueueWorkItem would work? Of course that would involve
waking up 2 threads until notification reaches user land. I guess
there’s no way to do the wakeup initiation directly from within
the ISR routine?

Thanks, Mathias.

2012/7/8
>
>> First, you can’t set an event in an ISR. See the documentation for
>> KeSetEvent.
>>
>> Second, I don’t care how high the priority of your thread is, the
>> liklihood that it will start running before the vertical retrace is
>> complete is vanishingly small. Even if you use the new Multimedia
>> scheduler support in Vista+, the highest priority you can run a user
>> thread is something like 26, and scheduling a user thread is a
>> very-heavy-duty operation.
>>
>> Back in the days when I was involved in high-performance video, we used
>> Vsync to swap frame buffer pointers, and tat was pretty much all we
>> could
>> do. In the case of video, we would let the application get ahead, but
>> if
>> it fell behind we could skip N frames to get back into realtime sync.
>> But
>> this was all done in the ISR, with no user threads involved at all. As
>> soon as you introduce the concept of scheduling a thread, you are into
>> random and large delays relative to what you can tolerate. Think of
>> tens
>> of milliseconds to potentially hundreds of milliseconds latency between
>> setting the event and the user code running.
>> joe
>>
>> > Hey guys,
>> >
>> > in order to optimize the performance and reliability (tearing etc) of
>> my
>> > video renderer, I’d like to get access to the VSync interrupt for
>> > informational purposes. Basically what I have in mind is that I would
>> > write a little kernel mode driver which connects to the VSync
>> interrupt
>> > and then simply sets an event in the ISR routine. The event would then
>> > wake up a high-priority user mode thread, which would perform video
>> > playback related tasks.
>> >
>> > Of course, in an ideal world either the OS or the GPU drivers would
>> allow
>> > me to access this kind of functionality through APIs. But since this
>> is
>> > not available, I’d like to try to realize it myself. Obviously I can’t
>> > write a full GPU driver. Just want to send VSync notifications to my
>> user
>> > land video renderer somehow, if it is possible in any way.
>> >
>> > From what I can see, I can find out which interrupt vector the GPU
>> uses
>> > via setupapi in user land. And I already have code written for kernel
>> land
>> > which successfully finds the GPU PDO. So far, so good. So here are my
>> > questions:
>> >
>> > (1) Is it “ok” for me to simply call IoConnectInterrupt(Ex) in my
>> virtual
>> > driver to connect to the VSync interrupt? I understand that it’s not
>> > really strictly how the PnP model is supposed to work because my
>> driver
>> > isn’t really a hardware driver. So would doing this risk system
>> stability?
>> >
>> > (2) In my ISR routine, I would ideally like to directly call
>> ZwSetEvent.
>> > But that doesn’t seem to be possible because ZwSetEvent requires
>> > PASSIVE_LEVEL? Is there any other way I can directly set an event for
>> user
>> > land from inside my ISR routine?
>> >
>> > (3) I understand interrupts can be shared by multiple different
>> hardware
>> > devices. In my ISR routine, is there any way for me to find out which
>> > hardware the “current” interrupt came from?
>> >
>> > (4) From what I can see, every GPU just has one interrupt, even though
>> it
>> > might have multiple displays connected. Is there any way for me to
>> find
>> > out which display the VSync interrupt originates from? I guess
>> probably
>> > not, but I thought I’d ask, just in case…
>> >
>> > Thank you!
>> >
>> > —
>> > NTDEV is sponsored by OSR
>> >
>> > For our schedule of WDF, WDM, debugging and other seminars visit:
>> > http://www.osr.com/seminars
>> >
>> > To unsubscribe, visit the List Server section of OSR Online at
>> > http://www.osronline.com/page.cfm?name=ListServer
>> >
>>
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

[TheOldOne]

My users are a picky bunch. They do look at CPU consumption and complain if
it’s higher compared to other renderers. There’s also a valid reason for
that because many of my users have a HTPC setup which is optimized for low
noise. So if the CPU consumption goes up, fan noise will increase. Still, I
guess I could switch from Sleep(1) to Sleep(0) when I’m getting near to the
next VSync interrupt (my code knows when the next VSync interrupt is
roughly going to occur). Would be worth a try, thanks for the suggestion…

Best regards, Mathias.

2012/7/9 Jan Bottorff

> Why don?t you call Sleep(0). That will give up the processor to other
> runnable threads, but comes right back if there is no other work. It may
> APPEAR to consume 100% cpu on the thread, but only if there is no other
> work. Sleep(1) will often actually be Sleep(16), and will suspend the
> thread.
>
>
>
> Jan
>
> ****
>
> >The only case it would not help would be if it would not perform any
> better than a Sleep(1) polling loop, and that’s hard for me to believe.
>
> ****
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

[TheOldOne]

The timer resolution affects Sleep? Didn’t know that. Will check if I
already set the timer resolution, don’t know right now from the top of my
head…

Best regards, Mathias.

2012/7/9 Doron Holan

> Unless you set the timer resolution to 1 ms and then it could be a lot
> closer to a 1 ms acquiesce
>
> d
>
> debt from my phone
> ------------------------------
> From: Jan Bottorff
> Sent: 7/8/2012 4:08 PM
>
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] getting access to VSync interrupt
>
>
> Why don?t you call Sleep(0). That will give up the processor to other
> runnable threads, but comes right back if there is no other work. It may
> APPEAR to consume 100% cpu on the thread, but only if there is no other
> work. Sleep(1) will often actually be Sleep(16), and will suspend the
> thread.
>
>
>
> Jan
>
>
>
> >The only case it would not help would be if it would not perform any
> better than a Sleep(1) polling loop, and that’s hard for me to believe.
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

[TheOldOne]

Thanks for the hint about events and DPC, that sounds like a
good solution!

VSync intervals are similar for flat panel displays as they
were for CRTs. You can set VSync to 23.976Hz, 24.000Hz,
25.000Hz, 50.000Hz, 59.940Hz, 60.000Hz, 72.000Hz,
75.000Hz etc etc. Usually TV type flat panel displays support
many of these refresh rates, so motion smoothness can be
guaranteed. Computer type LCD monitors often only support
60.000Hz, though.

As mentioned before, I’m already using D3D, just looking
for ways to improve performance and reliability of my
renderer.

Thanks, Mathias.

2012/7/9

> Yes, my work was done in another OS.
>
> I like to say that the operating system has, at best, a loose grasp of the
> concept of “time” which boils down to “time monotonically increases in
> each core”. As others have suggested, D3D would be the safest approach.
>
> At least one question I don’t have the answer to for flat displays is the
> duration of the Vsync interval. There was a time when I could quote it
> for a variety of screen resolutions, but that time is now more than 20
> years in the past.
>
> Probably tbe fastest way to accomplish a notification to user space is to
> enqueue a DPC request, and let the DPC do the completion of a custom
> DeviceIoControl. There seems to be a horrid fascination with using events
> to notify user space, but this is a clumsy and convoluted way to handle
> what is actually a very simple concept. Look for threads discussing
> “inverted call”, and forget that you ever heard of events as a
> kernel-to-userspace notification mechanism, except, just maybe, in the
> context of using an Event in the OVERLAPPED structure–which, I might add,
> is still a lousy way to handle it.
> joe
> > Hi Joe,
> >
> > swapping frame pointers (or maybe overlay frame pointers)
> > on VSync would be a dream, of course. That would be step 3,
> > if it is possible to achieve at all from my own driver. My first 2
> > steps would be (1) counting the VSyncs. And (2) notifying user
> > land about them. I guess you did that high-performance video
> > stuff on another OS and not on Windows?
> >
> > I know that timing in user land isn’t too reliable, even if you use
> > the highest possible thread priority. My video rendering code is
> > working in such a way that I don’t necessarily have to run inside
> > of the VSync period (although of course that would be great!).
> > It’s ok if I’m getting the VSync notification a bit too late sometimes.
> >
> > About the event: What would be the best (performing) way to
> > notify user land from within an ISR routine? Maybe using
> > IoQueueWorkItem would work? Of course that would involve
> > waking up 2 threads until notification reaches user land. I guess
> > there’s no way to do the wakeup initiation directly from within
> > the ISR routine?
> >
> > Thanks, Mathias.
> >
> >
> >
> >
> > 2012/7/8
> >
> >> First, you can’t set an event in an ISR. See the documentation for
> >> KeSetEvent.
> >>
> >> Second, I don’t care how high the priority of your thread is, the
> >> liklihood that it will start running before the vertical retrace is
> >> complete is vanishingly small. Even if you use the new Multimedia
> >> scheduler support in Vista+, the highest priority you can run a user
> >> thread is something like 26, and scheduling a user thread is a
> >> very-heavy-duty operation.
> >>
> >> Back in the days when I was involved in high-performance video, we used
> >> Vsync to swap frame buffer pointers, and tat was pretty much all we
> >> could
> >> do. In the case of video, we would let the application get ahead, but
> >> if
> >> it fell behind we could skip N frames to get back into realtime sync.
> >> But
> >> this was all done in the ISR, with no user threads involved at all. As
> >> soon as you introduce the concept of scheduling a thread, you are into
> >> random and large delays relative to what you can tolerate. Think of
> >> tens
> >> of milliseconds to potentially hundreds of milliseconds latency between
> >> setting the event and the user code running.
> >> joe
> >>
> >> > Hey guys,
> >> >
> >> > in order to optimize the performance and reliability (tearing etc) of
> >> my
> >> > video renderer, I’d like to get access to the VSync interrupt for
> >> > informational purposes. Basically what I have in mind is that I would
> >> > write a little kernel mode driver which connects to the VSync
> >> interrupt
> >> > and then simply sets an event in the ISR routine. The event would then
> >> > wake up a high-priority user mode thread, which would perform video
> >> > playback related tasks.
> >> >
> >> > Of course, in an ideal world either the OS or the GPU drivers would
> >> allow
> >> > me to access this kind of functionality through APIs. But since this
> >> is
> >> > not available, I’d like to try to realize it myself. Obviously I can’t
> >> > write a full GPU driver. Just want to send VSync notifications to my
> >> user
> >> > land video renderer somehow, if it is possible in any way.
> >> >
> >> > From what I can see, I can find out which interrupt vector the GPU
> >> uses
> >> > via setupapi in user land. And I already have code written for kernel
> >> land
> >> > which successfully finds the GPU PDO. So far, so good. So here are my
> >> > questions:
> >> >
> >> > (1) Is it “ok” for me to simply call IoConnectInterrupt(Ex) in my
> >> virtual
> >> > driver to connect to the VSync interrupt? I understand that it’s not
> >> > really strictly how the PnP model is supposed to work because my
> >> driver
> >> > isn’t really a hardware driver. So would doing this risk system
> >> stability?
> >> >
> >> > (2) In my ISR routine, I would ideally like to directly call
> >> ZwSetEvent.
> >> > But that doesn’t seem to be possible because ZwSetEvent requires
> >> > PASSIVE_LEVEL? Is there any other way I can directly set an event for
> >> user
> >> > land from inside my ISR routine?
> >> >
> >> > (3) I understand interrupts can be shared by multiple different
> >> hardware
> >> > devices. In my ISR routine, is there any way for me to find out which
> >> > hardware the “current” interrupt came from?
> >> >
> >> > (4) From what I can see, every GPU just has one interrupt, even though
> >> it
> >> > might have multiple displays connected. Is there any way for me to
> >> find
> >> > out which display the VSync interrupt originates from? I guess
> >> probably
> >> > not, but I thought I’d ask, just in case…
> >> >
> >> > Thank you!
> >> >
> >> > —
> >> > NTDEV is sponsored by OSR
> >> >
> >> > For our schedule of WDF, WDM, debugging and other seminars visit:
> >> > http://www.osr.com/seminars
> >> >
> >> > To unsubscribe, visit the List Server section of OSR Online at
> >> > http://www.osronline.com/page.cfm?name=ListServer
> >> >
> >>
> >>
> >>
> >> —
> >> NTDEV is sponsored by OSR
> >>
> >> For our schedule of WDF, WDM, debugging and other seminars visit:
> >> http://www.osr.com/seminars
> >>
> >> To unsubscribe, visit the List Server section of OSR Online at
> >> http://www.osronline.com/page.cfm?name=ListServer
> >>
> >
> > —
> > NTDEV is sponsored by OSR
> >
> > For our schedule of WDF, WDM, debugging and other seminars visit:
> > http://www.osr.com/seminars
> >
> > To unsubscribe, visit the List Server section of OSR Online at
> > http://www.osronline.com/page.cfm?name=ListServer
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

[Maxim_S_Shatskih]

VSync interrupt in the days of Desktop Composition funny

Also I’m not sure modern 3D video chips have the VSync interrupt at all. Their interrupt can be the “3D task is done”, not VSync.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

wrote in message news:xxxxx@ntdev…
> Hey guys,
>
> in order to optimize the performance and reliability (tearing etc) of my video renderer, I’d like to get access to the VSync interrupt for informational purposes. Basically what I have in mind is that I would write a little kernel mode driver which connects to the VSync interrupt and then simply sets an event in the ISR routine. The event would then wake up a high-priority user mode thread, which would perform video playback related tasks.
>
> Of course, in an ideal world either the OS or the GPU drivers would allow me to access this kind of functionality through APIs. But since this is not available, I’d like to try to realize it myself. Obviously I can’t write a full GPU driver. Just want to send VSync notifications to my user land video renderer somehow, if it is possible in any way.
>
> From what I can see, I can find out which interrupt vector the GPU uses via setupapi in user land. And I already have code written for kernel land which successfully finds the GPU PDO. So far, so good. So here are my questions:
>
> (1) Is it “ok” for me to simply call IoConnectInterrupt(Ex) in my virtual driver to connect to the VSync interrupt? I understand that it’s not really strictly how the PnP model is supposed to work because my driver isn’t really a hardware driver. So would doing this risk system stability?
>
> (2) In my ISR routine, I would ideally like to directly call ZwSetEvent. But that doesn’t seem to be possible because ZwSetEvent requires PASSIVE_LEVEL? Is there any other way I can directly set an event for user land from inside my ISR routine?
>
> (3) I understand interrupts can be shared by multiple different hardware devices. In my ISR routine, is there any way for me to find out which hardware the “current” interrupt came from?
>
> (4) From what I can see, every GPU just has one interrupt, even though it might have multiple displays connected. Is there any way for me to find out which display the VSync interrupt originates from? I guess probably not, but I thought I’d ask, just in case…
>
> Thank you!
>

[Maxim_S_Shatskih]

>problem, but there are different problems. In the end, no matter what, my rendering code needs to

keep track of the VSync to make sure playback is totally smooth. No way around it.

Yes, there is a way.

Use the audio renderer as a master clock.

Smoothness issues with audio are by far more perceivable by human, then with video. So, you can 1) guarantee audio smoothness b) tie the video timeline to audio timeline.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

[TheOldOne]

It’s not so funny to me, unfortunately. I’ve written code to make use of
the special desktop composition APIs, letting desktop composition do all
the dirty work, but it doesn’t work as well as expected. My users are
reporting that the code path in my renderer which does all the vsync work
on its own and only lets desktop composition do the most minimal possible
processing produces the smoothest and most reliable video playback
experience.

Unfortunately many people today make do with “seems to work ok”. My
renderer aims to be better than that. I’m only satisfied if I can display a
full movie without a single frame drop/repeat with perfect smoothness. And
naively relying on the vsync capabilities of the user mode APIs doesn’t
work well enough for that. Trust me, I’ve tried. And tried. And tried. And
…

Best regards, Mathias.

2012/7/9 Maxim S. Shatskih

> VSync interrupt in the days of Desktop Composition funny
>
> Also I’m not sure modern 3D video chips have the VSync interrupt at
> all. Their interrupt can be the “3D task is done”, not VSync.
>
> –
> Maxim S. Shatskih
> Windows DDK MVP
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
> wrote in message news:xxxxx@ntdev…
> > Hey guys,
> >
> > in order to optimize the performance and reliability (tearing etc) of my
> video renderer, I’d like to get access to the VSync interrupt for
> informational purposes. Basically what I have in mind is that I would write
> a little kernel mode driver which connects to the VSync interrupt and then
> simply sets an event in the ISR routine. The event would then wake up a
> high-priority user mode thread, which would perform video playback related
> tasks.
> >
> > Of course, in an ideal world either the OS or the GPU drivers would
> allow me to access this kind of functionality through APIs. But since this
> is not available, I’d like to try to realize it myself. Obviously I can’t
> write a full GPU driver. Just want to send VSync notifications to my user
> land video renderer somehow, if it is possible in any way.
> >
> > From what I can see, I can find out which interrupt vector the GPU uses
> via setupapi in user land. And I already have code written for kernel land
> which successfully finds the GPU PDO. So far, so good. So here are my
> questions:
> >
> > (1) Is it “ok” for me to simply call IoConnectInterrupt(Ex) in my
> virtual driver to connect to the VSync interrupt? I understand that it’s
> not really strictly how the PnP model is supposed to work because my driver
> isn’t really a hardware driver. So would doing this risk system stability?
> >
> > (2) In my ISR routine, I would ideally like to directly call ZwSetEvent.
> But that doesn’t seem to be possible because ZwSetEvent requires
> PASSIVE_LEVEL? Is there any other way I can directly set an event for user
> land from inside my ISR routine?
> >
> > (3) I understand interrupts can be shared by multiple different hardware
> devices. In my ISR routine, is there any way for me to find out which
> hardware the “current” interrupt came from?
> >
> > (4) From what I can see, every GPU just has one interrupt, even though
> it might have multiple displays connected. Is there any way for me to find
> out which display the VSync interrupt originates from? I guess probably
> not, but I thought I’d ask, just in case…
> >
> > Thank you!
> >
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

[TheOldOne]

Using the audio renderer as the master clock is the standard DirectShow way
of doing things. That’s already every DirectShow video renderer does,
including mine.

I don’t agree that video smoothness is less perceivable. A frame drop
during a camera pan is extremely visible to every human who isn’t blind.

Best regards, Mathias.

2012/7/9 Maxim S. Shatskih

> >problem, but there are different problems. In the end, no matter what, my
> rendering code needs to
> >keep track of the VSync to make sure playback is totally smooth. No way
> around it.
>
> Yes, there is a way.
>
> Use the audio renderer as a master clock.
>
> Smoothness issues with audio are by far more perceivable by human, then
> with video. So, you can 1) guarantee audio smoothness b) tie the video
> timeline to audio timeline.
>
> –
> Maxim S. Shatskih
> Windows DDK MVP
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

[Maxim_S_Shatskih]

> And, the latency is certainly higher than a vertical retrace (do flat

panel displays even have the concept?)

Yes they do, since the interface cable is the same as for CRT, and the video chip is unaware of whether the CRT or LCD is attached to it.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

[Daniel_Terhell]

You have to look at it this way: in case of a video frame drop during
playback, you still have the previous picture on your screen to stare at.
30fps, 29fps, who will notice the diffrerence ? An audio stream HAS to be
continuous or you will need a very complex real-time algorithm requiring FFT
and more that fills in the lost frames with audio that covers it up. A
silent buffer or a previous buffer simply repeated will be perceived as a
click or pop.

//Daniel

“madshi” wrote in message news:xxxxx@ntdev…
> I don’t agree that video smoothness is less perceivable. A frame drop
> during a camera pan is extremely visible to every human who isn’t blind.
>
> Best regards, Mathias.
>
>
>
> 2012/7/9 Maxim S. Shatskih
>
>> >problem, but there are different problems. In the end, no matter what,
>> >my
>> rendering code needs to
>> >keep track of the VSync to make sure playback is totally smooth. No way
>> around it.
>>
>> Yes, there is a way.
>>
>> Use the audio renderer as a master clock.
>>
>> Smoothness issues with audio are by far more perceivable by human, then
>> with video. So, you can 1) guarantee audio smoothness b) tie the video
>> timeline to audio timeline.
>>
>> –
>> Maxim S. Shatskih
>> Windows DDK MVP
>> xxxxx@storagecraft.com
>> http://www.storagecraft.com
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>

[TheOldOne]

Sure, audio drops can be really bad (unless they happen during silence).
But video drops are bad, too, if they happen in a scene where there’s lots
of motion. The human eye/brain tries to follow motion. If there’s a break
in that motion, it is very noticeable. Anyway, my task as a video renderer
developer is to make sure that the video performs well, while syncing to
the master (= audio) clock. It’s not my job to care about audio rendering.
Audio rendering is actually pretty easy in DirectShow because the audio
hardware clock is the master clock. So all an audio renderer has to do is
to deliver the audio packages one by one. No special synchronization work
is needed at all. The video side of things is quite a bit more difficult
because audio and video hardware clocks often don’t match exactly and the
video renderer needs to sync to the master/audio clock. But we’re getting a
bit OT here…

Best regards, Mathias.

2012/7/9

> You have to look at it this way: in case of a video frame drop during
> playback, you still have the previous picture on your screen to stare at.
> 30fps, 29fps, who will notice the diffrerence ? An audio stream HAS to be
> continuous or you will need a very complex real-time algorithm requiring
> FFT
> and more that fills in the lost frames with audio that covers it up. A
> silent buffer or a previous buffer simply repeated will be perceived as a
> click or pop.
>
> //Daniel
>
>
>
> “madshi” wrote in message news:xxxxx@ntdev…
> > I don’t agree that video smoothness is less perceivable. A frame drop
> > during a camera pan is extremely visible to every human who isn’t blind.
> >
> > Best regards, Mathias.
> >
> >
> >
> > 2012/7/9 Maxim S. Shatskih
> >
> >> >problem, but there are different problems. In the end, no matter what,
> >> >my
> >> rendering code needs to
> >> >keep track of the VSync to make sure playback is totally smooth. No way
> >> around it.
> >>
> >> Yes, there is a way.
> >>
> >> Use the audio renderer as a master clock.
> >>
> >> Smoothness issues with audio are by far more perceivable by human, then
> >> with video. So, you can 1) guarantee audio smoothness b) tie the video
> >> timeline to audio timeline.
> >>
> >> –
> >> Maxim S. Shatskih
> >> Windows DDK MVP
> >> xxxxx@storagecraft.com
> >> http://www.storagecraft.com
> >>
> >>
> >> —
> >> NTDEV is sponsored by OSR
> >>
> >> For our schedule of WDF, WDM, debugging and other seminars visit:
> >> http://www.osr.com/seminars
> >>
> >> To unsubscribe, visit the List Server section of OSR Online at
> >> http://www.osronline.com/page.cfm?name=ListServer
> >>
> >
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

[Tim_Roberts]

madshi wrote:

So is there any supported way for me to get some more control over the
GPU in kernel mode? I’ve read that GPU mirror drivers don’t work that
well in Vista+, anymore (they seem to result in desktop composition
being turned off etc). Any other options? Writing a
filter/mini/whatever driver? Or am I totally out of luck? I’m willing
to go the “proper” way, if there is one…

What are you writing? Today’s video renderers use DirectX to draw video
into overlay or texture surfaces. By doing that, the GPU’s DirectX
provider handles the synchronization with vertical blank automatically.
It’s not up to the renderer to do that timing.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

[Tim_Roberts]

madshi wrote:

The timer resolution affects Sleep? Didn’t know that.

Of course it does. By default, the scheduler timer interrupt only
happens about every 15 or 16ms. The system cannot age the timer queues
any more often than the timer interrupt, so sleep values will always be
rounded up to the nearest scheduler interval. Thus, a Sleep(1) will
typically sleep about 16ms.

If you set the timer resolution to 1ms, then Sleep(1) can take as little
as 1ms.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

[TheOldOne]

> 2012/7/9 Tim Roberts

What are you writing? Today’s video renderers use DirectX to
draw video into overlay or texture surfaces. By doing that, the
GPU’s DirectX provider handles the synchronization with
vertical blank automatically. It’s not up to the renderer to do
that timing.

I’m writing a DirectShow video renderer, using D3D9. Leaving
synchronization to DirectX doesn’t always work as well as expected. Trust
me, I tried. I started with the naive idea that I could simply render the
frames and then present them to DirectX and not have to deal with VSync etc
at all. I’ve soon learned that things are not that easy in real
(programming) life. I could tell you tales about driver bugs, bad DirectX
design and many other related things.

If you want to write a good video renderer, you *have* to keep track of the
exact refresh rate and when the next vsync blank periods are going to
happen. Depending on which OS you’re running on, which GPU/drivers you’re
using, whether desktop composition is active or not, and the position of
the planets, you may be able to leave it to the OS/GPU drivers to flip the
“next” video frame during the next vsync blank period, but if your renderer
doesn’t care at all about when the next vsync blank periods are going to
be, you can say goodbye to smooth video playback in many real life
situations. I could explain it in more detail, or look for that Intel paper
I once read which explained some of these things nicely (don’t have the
paper at hand atm), but I guess this is not really the right place for in
depth discussions about DirectShow video renderer design. If you’re
interested in this topic and want to continue the discussion, please feel
free to personally email me.

Best regards, Mathias.

[Chris_Aseltine]

Joseph M. Newcomer wrote:

Best case was slightly under 100 milliseconds, worst case
was 450ms, average was 225ms. Real numbers, measured
on a real system. By someone who cared a lot about realtime
response.

I’m coming into this thread late but this is probably the biggest bunch of baloney I’ve ever read on this list. There is no way that Windows takes 450 milliseconds to schedule some code to start running in response to an interrupt; such a system would be completely unusable. Ever see your mouse pointer take half a second to start moving after you moved the mouse? Yeah, didn’t think so.

[James_Harper]

>

Joseph M. Newcomer wrote:

> Best case was slightly under 100 milliseconds, worst case was 450ms,
> average was 225ms. Real numbers, measured on a real system. By
someone
> who cared a lot about realtime response.

I’m coming into this thread late but this is probably the biggest bunch of
baloney I’ve ever read on this list. There is no way that Windows takes 450
milliseconds to schedule some code to start running in response to an
interrupt; such a system would be completely unusable. Ever see your
mouse pointer take half a second to start moving after you moved the
mouse? Yeah, didn’t think so.

The mouse pointer lag happens once or twice a week for me on my Windows 7 laptop, and yes it makes the system unusable until I manage to kill whatever process has run away (or press the power button). Now it’s possible that this is a usermode lag causing the mouse lag, and DPC’s are still scheduled in under 450ms, but you asked the question and I answered it

What I find really annoying is touching the volume up/down slider and having to wait 4 seconds (I just timed it) for the OSD volume control to appear, even when the laptop is idle. Windows swapping stuff like that out to disk is a royal pain on a device that likes to keep the disks spun down.

James

[Alex_Grig]

>The mouse pointer lag happens once or twice a week for me on my Windows 7
laptop

I suggest you check for the NIC/Wifi driver update. Also, see if you need to clean the CPU heatsink fins. In laptops, they get clogged with time.

[OSR_Community_User]

.
You have cofused interrupt latency with scheduler latency. Scheduler
latency has two components: the actual cost of doing the scheduling of the
thread, including page table management and its side effects, and
preemption.

Preemption is far and away the single largest factor. Sure, your thread
is in “run” state, but it ain’t the Biggest, Baddest, Thread On The Block.
So it patiently waits its turn.

Part of the problem I have with your assertion is that it is based on an
opinion that an OS shouldn’t work in the way I described. But you seem to
offer no evidence, other than your feeling, that this is baloney. The
other problem is that I helped in the design of the experiment, and I’ve
seen the real data.

You also seem to have a misunderstanding about how the mouse pointer is
managed. To correct your impression of this, I suggest you do the
following experiment.

Create a dialog-based app with two buttons, marked “Run” and “Stop”. When
the “Run” button is clicked, you start a Priority 15 thread whose thread
function is

UINT thread(LPVOID)
{
while(running);
return 0;
}

Before you start the thread, you set the BOOL running to TRUE. When the
Stop button is clicked, it sets the running flag to FALSE.

Enabling/disabling the buttons appropriately is left as An Exercise For
The Reader.

This exhibits quite different behavior on single core and multicore
systems. So, to see the proper effect, you either have to set the thread
affinities of the two threads to the same core, or spin off as many
threads as you have cores.

Please report back on the observed mouse behavior.

Facts trump opinion any day of the week.

Joseph M. Newcomer wrote:

> Best case was slightly under 100 milliseconds, worst case
> was 450ms, average was 225ms. Real numbers, measured
> on a real system. By someone who cared a lot about realtime
> response.

I’m coming into this thread late but this is probably the biggest bunch of
baloney I’ve ever read on this list. There is no way that Windows takes
450 milliseconds to schedule some code to start running in response to an
interrupt; such a system would be completely unusable. Ever see your
mouse pointer take half a second to start moving after you moved the
mouse? Yeah, didn’t think so.

---

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

[Chris_Aseltine]

Joseph M. Newcomer wrote:

Create a dialog-based app with two buttons, marked “Run”
and “Stop”. When the “Run” button is clicked, you start a
Priority 15 thread whose thread function is

UINT thread(LPVOID)
{
while(running);
return 0;
}

Forgetting about your “worst case” figure of 450ms for a moment, in your original post, you said, without qualification or elaboration, that the “average” case for interrupt latency to userspace was 225ms.

Now you’re saying, well, if you fire up N threads (for N cores) all spinning in a tight loop all at time critical thread priority, that your system will become sluggish. Well, no kidding. However, that is hardly the “average case” for a given application. So the example you’re giving is one gigantic straw man. Sorry, no takers.

[OSR_Community_User]

> Joseph M. Newcomer wrote:

> Create a dialog-based app with two buttons, marked “Run”
> and “Stop”. When the “Run” button is clicked, you start a
> Priority 15 thread whose thread function is
>
> UINT thread(LPVOID)
> {
> while(running);
> return 0;
> }

Forgetting about your “worst case” figure of 450ms for a moment, in your
original post, you said, without qualification or elaboration, that the
“average” case for interrupt latency to userspace was 225ms.

Now you’re saying, well, if you fire up N threads (for N cores) all
spinning in a tight loop all at time critical thread priority, that your
system will become sluggish. Well, no kidding. However, that is hardly
the “average case” for a given application. So the example you’re giving
is one gigantic straw man. Sorry, no takers.

What qualification or elaboration would you have liked? This experiment
was conducted some years ago, not by me, so I have no access to the
original source. The person doing it was a senior researcher at a local
university. The average case was 225ms, interrupt-to-app-run.

The point of the example was that you said that the mouse would be
sluggish if the numbers I quoted were true. Key here is that you seem to
think that the mouse behavior you see would be subject to the same lags as
I reported, and I pointed out that it didn’t. Under normal operating
conditions, there are several threads that can be running, including file
system and other kernel threads. The consequence of these threads is a
significant delay, interrupt-to-run, in the app, which were above the
“real time window” that could be accepted. Yes, I know, Windows is not a
“real time” system, but “real time” is subject to a number of
interpretations, such as “timely response to the events in the problem
domain”. The study was done because the system was not being responsive
in a satisfactory manner, and the researcher decided to get some numbers
to see what was going on. He got the numbers. He and I were both amazed
at the values.

Some years later, I was involved in a similar problem, and we were getting
“jitter” in excess of 100ms on a fairly modern 2.2GHz uniprocessor. With
a bit of cleverness, I reduced the “jitter” to under 100us, which is what
they needed. So again, I have the numbers to show that delay, but I am
not permitted to publish them (the nature of the experiment dealt with
product development for the company I was consulting for at the time, and
therefore are covered by my NDA, which has not expired yet).

So you have opinion, and I have data. Who’s right?
joe

---

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer