[MPlayer-dev-eng] Removal of backing store

[Stephane Marchesin]

On Fri, Aug 22, 2008 at 11:03 AM, Vladimir Mosgalin
<mosgalin at vm10124.spb.edu> wrote:
> Hi Stephane Marchesin!
>
>  On 2008.08.22 at 02:41:21 +0200, Stephane Marchesin wrote next:
>
>> >> some recent drivers (notably the open source ones using EXA). There
>> >
>> > Have you checked it for intel, ati and radeonhd drivers?
>> >
>> I don't have the hardware, but it should make no difference.
>
> Well.. If it makes a lot of difference on one card, at least it makes
> sense to check out what it does for others.
>
>> In nouveau, we have a port that is the hardware overlay, but it will
>> transparently fallback to the blitter when run in composite
>
> Hm. Why, is this driver limitation?
> I'll check what happens on intel with compiz (though driver I'm using is
> kinda old, 2.2.1, but it uses EXA).
>
> And what exactly does composite has to do with backing store?

The link is that when you use an EXA driver, windows with a backing
store flag are redirected. From then you can't use the hw overlay.

> Actually,
> what cases are you talking about? Composite-enabled desktop which
> doesn't use compiz or other stuff like that? Because I don't quite
> understand why compiz-enabled desktop would need or use backing store

Hmm, compiz doesn't use backing store, it's mplayer that enables it.
And yes, the flag still exists for backwards compatibility.

> anyway - when windows are rendered to textures and the textures are kept
> anyway and compiz renders in any order without actually making applications
> redraw them, isn't that making backing store obsolete?

Yeah, backing store is completely obsolete. So why does mplayer enable it ?

>
>> > Well, I tried this on radeon X1900 card with fglrx 8.8, using
>> > -vo gl:yuv=2:force-pbo, -vo xv and -vo x11 output drivers and
>> > performance was identical in each case, with or without patch. Is this
>> > patch nvidia-specific?
>> >
>>
>> OpenGL is not affected by backing store, so your benchmark is meaningless.
>
> Well, I tried both xv and plain x11 too.
>

Sure, and it made no difference. So again, what good does it do ?

>> However, this change is beneficial to:
>> 1. drivers that use EXA and implement a hardware overlay which is able
>> to fallback to a blitter/texture
>
> Intel provides two xv adaptors, one for hardware overlay and one for
> textured video. Not sure about fallback, probably there isn't (when you
> specify adaptor directly).

Intel has the textured adapter as default, and overlay as 2nd. So you
will use the textured adapter usually. This means you don't encounter
the issue by default. But it you do the following :
- mplayer -vo xv:port=[the overlay port]
- make the mplayer window transparent or whatever under a composited
desktop (using xcompmgr + transset for example).
you will get a blue window. This could be fixed if intel added an
automatic fallback (except it would fallback all the time because of
backing store, like nouveau).

>
>> 2. drivers that have a real hw overlay where you waste vram
>
> Radeon cards based on R5xx and higher can have hw overlay, but it's
> never used (it's kinda crippled or something, and supposed to be
> obsolete). In all cases, only textured video xv adaptor is provided by
> driver.

The R500 overlay has limitations pertaining to scaling (only 1x or 2x
scaling) and is really intended for CAD applications. The
R100/R200/R300 overlay work fine and can't be used with composite
either. Currently the radeon drivers use the textured adapted by
default I think.

>
> IOW, are you sure your fix applies to anything but older nvidia cards?
>

I think for now it applies to nouveau only. Once this is fixed, other
drivers can enable their hw overlay in a composited situation too, and
everyone wins.

Stephane