xf86-video-intel Textured Video vs Video Overlay

[Ken Mandelberg]

Today was the first chance I had to run the 2.0.0 code on my i915 2ghz 
Pentium M processor Laptop. Until now I had been running on a dual core 
mac.

I was surprised that running  HD video through any of the media players 
with the default Textured Video port was unusable. The frame drops were 
staggering. The media player would use close to half the cpu, and the X 
server would use all the rest (and needed more). This didn't show on the 
dual core, because there were cycles to burn.

As it happens I've been generally flip flopping the Textured Video with 
the Video Overlay initaliization on the mac, just to get brightness and 
contrast control.  Thats a fairly subtle need. On the single core laptop 
Overlay its essential. Using the Overlay the X server uses negligible 
cpu, and the media player  has enough cpu to keep up.

I know the client can intelligently pick the port, but the reality is 
that most of them don't (MythTV, xine, vlc). Actually, I think it would 
be expecting a lot for them to know if CPU limitation, or the need for 
dual monitors was more important.

I really think it would be a good idea in a future release to make the 
default XV port an xorg.conf option.


Keith Packard wrote:
> On Sun, 2007-03-18 at 14:27 -0400, Ken Mandelberg wrote:
>   
>> Tristan Willy wrote:
>>     
>>>  As I understand it, the intel driver provides video overlay if the
>>> chip supports it (no overlay in the 965). This is the only XV port
>>> that will not experience tearing, at least until there's a way for the
>>> driver to get a cheap vertical retrace signal.
>>>
>>>       
>> If the overlay code only has advantages compared with the textured code, 
>> on the hardware that supports it (like the 945), I wonder why the 
>> decision was made to make it the second adapter?
>>     
>
> Textured video can support multiple players, and the image is visible on
> multiple monitors. Plus, it (should) support the Composite extension.
>
> "dumb" applications that just want to show video should get the adapter
> with the fewest weird restrictions (at least, that was my thought).
>
> "smart" applications that want better output should be able to figure
> out which adapter to use.
>
>