[MPlayer-dev-eng] [PATCH] EOSD efficiency improvements

Reimar Döffinger Reimar.Doeffinger at gmx.de
Fri Mar 6 13:02:45 CET 2009


On Fri, Mar 06, 2009 at 12:38:39PM +0100, Grigori Goronzy wrote:
> Reimar Döffinger wrote:
> 
> > Sorry I just have no real time to look at it. The issue I have with that
> > kind of "complex" algorithms is that they usually are implemented in a
> > way that has pathological case where it would become completely unusable
> > while only providing a marginal speedup over simpler algorithms.
> > Which is the reason for the algorithm in vo_gl.
> >
> 
> OK.
> You're right in that there are pathological cases where the new
> allocation strategy doesn't offer any benefits, or is even worse than
> the old one, but usually it is a lot faster for VDPAU.

You should not compare it with the old code but with the OpenGL code.
I consider the OpenGL code quite simple and the worst case is that it
uses up an additional 0.5 MB of video RAM.
Whereas for your code, if I read it right, the worst case would be bitmaps
alternating between 1 pixels wide and 257 pixels high and 1 pixel high
and 511 pixels wide, which would allocate almost 1024 times as much
video RAM as necessary.
That is what I mean by pathological case, a case where the code becomes
unusable _only_ because of the optimization. I consider these cases
enough of a PITA that worse code is acceptable as long as it avoids
them.
Of course you can extend your code to handle those cases better, but the
question to me is if all that code is justifiable by the speed
advantages over a more simple approach like in vo_gl - I _assumed_ it
isn't, I do not know for sure though I admit.



More information about the MPlayer-dev-eng mailing list