Re: DirectShow Thread Priority

"Iain" <Iain@xxxxxxxxxxxxxxxxxx> wrote in message
news:1gq72hal9yibx.9896zxrj580w.dlg@xxxxxxxxxxxxx
> I'm not persuaded that it does run at a higher priority. Certainly the
> audio renderer does not.

Even if so, I think Tim's main point still stands. It is hard to know which
threads are the important ones, even if you identify the ones that are new
after you run the graph.

Also, it's unlikely that a performance issue would be related to thread
priority anyway. Thread priority is only one factor with respect to which
thread gets CPU time when. Most threads will wind up yielding long before
their slice is up, usually because they wind up blocked on i/o or waiting
for another thread.

IMHO, the original poster's goal isn't reasonable. Assuming there are no
other CPU-intensive tasks going on during video rendering, the rendering
will take most of the CPU time anyway. That will happen naturally as the
thread (presumably) would be one of the few threads (or the only thread) on
the system actually using 100% of its time slice. If there ARE other
CPU-intensive tasks, then either they are important or they are not. If
they are, then starving them for video isn't reasonable. If they aren't,
then why are they running in the first place?

Messing with thread priority is almost always the wrong strategy. Almost
always, the existing priorities are set that way for a reason.

Just as an example: one video application (if I recall correctly, it's
TMPGEnc) sets its priority to a high setting while encoding, rather than the
default normal setting. The application doesn't get its encoding done any
faster; it just winds up making everything else on the system run like crap.
The CPU time it takes to handle mouse-clicks, or even running a solitaire
card game, is completely inconsequential compared to the CPU time required
by the encoder, and doing stuff like that won't result in any noticeable
difference in performance by the encoder.

If I were trying to run a 3D game, or another encoder, or something like
that while the application was encoding, then sure...the application would
suffer and not encode as quickly. But doing that would be dumb.

I realize the rendering example is a little different. But it's not much
different. The rendering WILL take the necessary CPU time as long as
nothing else needs the CPU that badly. And if there is something else that
needs the CPU that badly, either it's a bad idea to allow that something to
run, or it's a bad idea to allow the rendering to starve that something.
Either way, there's no reason to mess with the thread priority.

Pete


.

Relevant Pages

  • Re: DirectShow Thread Priority
    ... the users clicks on a video in the list the application loads the video by ... >> I'm not persuaded that it does run at a higher priority. ... > other CPU-intensive tasks going on during video rendering, ... > will take most of the CPU time anyway. ...
    (microsoft.public.win32.programmer.directx.video)
  • Re: Time critical thread seems to pause briefly once every few seconds
    ... It runs on a dual core system with windows vista and xp. ... prepare for rendering; ... Generally with two cores and few processes, I beleive the core running the critical thread will be more or less reserved for the thread and the other core will be uses for low priority work. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Mexican customs to be stationed in Kansas City
    ... Chas wrote: ... rendering them irrelevant. ... Neither does raw capitalism take priority over every other consideration. ...
    (rec.martial-arts)
  • Re: profiler which does not just sum up used time
    ... seconds) will probably accumulate that much lower priority threads to ... to set a threads priority to realtime. ... I have an app doing rendering ... can not live with even a single lost frame unless the rendering is very ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: profiler which does not just sum up used time
    ... The time it will get off a CPU depends on the other threads activity, but keeping a single core busy for such a long period will probably accumulate that much lower priority threads to become ready, so that your thread will get pre-empted for at a complete quantum or more. ... An application can be set to realtime priority and according to what I have read, this should prevent preempting entirely, but that still does not seem to be the case.. ... I have an app doing rendering and it occationally gets preempted and when that happens I lose a few frames. ... I can not live with even a single lost frame unless the rendering is very complex, ...
    (microsoft.public.dotnet.languages.csharp)