TFP and strict binding

 Hello,

 I've found the performance problem with TFP - once the
pixmap is bound to the 
texture, they share the same data, which means the texture
is updated as soon 
as the pixmap changes. Therefore there's no need to rebind
the pixmap on 
every change. As the commit log message says, TFP is now at
about 70% and SHM 
50% of non-composited glxgears performance.

 However, with these changed semantics of the binding, it is
possible there 
will redrawing problems. Specifically, I think that strict
binding now will 
be needed on some systems. Could somebody with non-nvidia
system check that 
strict binding is necessary for them
(kwinrc:Translucency:GLStrictBinding set 
to true)?

-- 
Lubos Lunak
KDE developer
------------------------------------------------------------
--
SUSE LINUX, s.r.o.   e-mail: l.lunaksuse.cz , l.lunakkde.org
Lihovarska 1060/12   tel: +420 284 028 972
190 00 Prague 9      fax: +420 284 028 951
Czech Republic       http//www.suse.cz
_______________________________________________
Kwin mailing list
Kwinkde.org
https://ma
il.kde.org/mailman/listinfo/kwin

Ühel kenal päeval (pühapäev 17 juuni 2007) kirjutas Lubos
Lunak:
>  Hello,
>
>  I've found the performance problem with TFP - once the
pixmap is bound to
> the texture, they share the same data, which means the
texture is updated
> as soon as the pixmap changes. Therefore there's no
need to rebind the
> pixmap on every change. As the commit log message says,
TFP is now at about
> 70% and SHM 50% of non-composited glxgears
performance.

Great work! 
I can confirm that TFP mode is a lot faster now and probably
faster than SHM.

>  However, with these changed semantics of the binding,
it is possible there
> will redrawing problems. Specifically, I think that
strict binding now will
> be needed on some systems. Could somebody with
non-nvidia system check that
> strict binding is necessary for them
(kwinrc:Translucency:GLStrictBinding
> set to true)?

Is it supposed to make any difference for NVidia users?
Setting it to false 
seems to make it a bit faster here.

Rivo
_______________________________________________
Kwin mailing list
Kwinkde.org
https://ma
il.kde.org/mailman/listinfo/kwin

On ne 17. června 2007, Rivo Laks wrote:
> Ɯhel kenal pƤeval (pĆ¼hapƤev 17 juuni 2007) kirjutas
Lubos Lunak:
> >  However, with these changed semantics of the
binding, it is possible
> > there will redrawing problems. Specifically, I
think that strict binding
> > now will be needed on some systems. Could somebody
with non-nvidia system
> > check that strict binding is necessary for them
> > (kwinrc:Translucency:GLStrictBinding set to true)?
>
> Is it supposed to make any difference for NVidia users?
Setting it to false
> seems to make it a bit faster here.

 Other than performance, no, AFAIK. We should do like Beryl
and set it to off 
with NVidia or XGL, with AIGLX having it enabled. I'd still
like if somebody 
with AIGLX could actually confirm it affects things.

-- 
Lubos Lunak
KDE developer
------------------------------------------------------------
--
SUSE LINUX, s.r.o.   e-mail: l.lunaksuse.cz , l.lunakkde.org
Lihovarska 1060/12   tel: +420 284 028 972
190 00 Prague 9      fax: +420 284 028 951
Czech Republic       http//www.suse.cz
_______________________________________________
Kwin mailing list
Kwinkde.org
https://ma
il.kde.org/mailman/listinfo/kwin

On Sunday 17 June 2007 14:43:57 Rivo Laks wrote:
> Ühel kenal päeval (pühapäev 17 juuni 2007) kirjutas
Lubos Lunak:
> >  Hello,
> >
> >  I've found the performance problem with TFP -
once the pixmap is bound
> > to the texture, they share the same data, which
means the texture is
> > updated as soon as the pixmap changes. Therefore
there's no need to
> > rebind the pixmap on every change. As the commit
log message says, TFP is
> > now at about 70% and SHM 50% of non-composited
glxgears performance.
>
> Great work! 
> I can confirm that TFP mode is a lot faster now and
probably faster than
> SHM.

I don't really understand, please help me, why is there TFP,
when you can 
reach (nearly?) the same performance via XSHM? Could you be
able to benchmark 
both against each other? - i'm just curious 

Thanks in advance,
Christian Parpart.

_______________________________________________
Kwin mailing list
Kwinkde.org
https://ma
il.kde.org/mailman/listinfo/kwin

On Monday 18 of June 2007, Christian Parpart wrote:
> On Sunday 17 June 2007 14:43:57 Rivo Laks wrote:
> > Ɯhel kenal pƤeval (pĆ¼hapƤev 17 juuni 2007)
kirjutas Lubos Lunak:
> > >  Hello,
> > >
> > >  I've found the performance problem with TFP
- once the pixmap is bound
> > > to the texture, they share the same data,
which means the texture is
> > > updated as soon as the pixmap changes.
Therefore there's no need to
> > > rebind the pixmap on every change. As the
commit log message says, TFP
> > > is now at about 70% and SHM 50% of
non-composited glxgears performance.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> >
> > Great work! 
> > I can confirm that TFP mode is a lot faster now
and probably faster than
> > SHM.
>
> I don't really understand, please help me, why is there
TFP, when you can
> reach (nearly?) the same performance via XSHM?

 You can't, apparently. The SHM mode is still going to stay,
for the time 
being.

> Could you be able to 
> benchmark both against each other? - i'm just curious


-- 
Lubos Lunak
KDE developer
------------------------------------------------------------
--
SUSE LINUX, s.r.o.   e-mail: l.lunaksuse.cz , l.lunakkde.org
Lihovarska 1060/12   tel: +420 284 028 972
190 00 Prague 9      fax: +420 284 028 951
Czech Republic       http//www.suse.cz
_______________________________________________
Kwin mailing list
Kwinkde.org
https://ma
il.kde.org/mailman/listinfo/kwin

On Sunday 17 June 2007 08:25:31 am Lubos Lunak wrote:
>  I've found the performance problem with TFP - once the
pixmap is bound to
> the texture, they share the same data, which means the
texture is updated
> as soon as the pixmap changes. Therefore there's no
need to rebind the
> pixmap on every change.

That's not really true. They can share the same data, but in
the big picture I 
wouldn't count on that.

The reason's are two-fold:
- Pixmap's don't match 1x1 texture formats. It's a little
complicated  to make 
the pixmap scratch memory match the texture memory space.
Michel Denzer tried 
to make it work with his zero-copy patch for tfp.
- Command streams for both can be very different. The
command stream for X and 
GL goes through different pipes, so it's very possible
(actually you should 
see that) that the composition manager will grab a pixmap
that is not fully 
updated. The rebinding is meant to assure the sync between
the both. Part of 
the reason for the slowdown in rebinding is likely directly
caused by that - 
to assure consistent state of the texture/pixmap NVIDIA
driver is likely to 
do an explicit sync on one/both of the the pipes. I think we
mentioned this 
in section 5 of the GLX_ext_texture_from_pixmap where it was
pointed out that 
without explicit re-bind after pixmap changes it's kinda
hard to guarantee a 
consistent state of the texture.

Now having said that, if the performance gain are big enough
and you're ok 
with occasional glitches, you should leave it like that and
then bug others 
to make the drivers work better/faster.

z
_______________________________________________
Kwin mailing list
Kwinkde.org
https://ma
il.kde.org/mailman/listinfo/kwin

On Monday 18 of June 2007, Zack Rusin wrote:
> On Sunday 17 June 2007 08:25:31 am Lubos Lunak wrote:
> >  I've found the performance problem with TFP -
once the pixmap is bound
> > to the texture, they share the same data, which
means the texture is
> > updated as soon as the pixmap changes. Therefore
there's no need to
> > rebind the pixmap on every change.
>
> That's not really true. They can share the same data,
but in the big
> picture I wouldn't count on that.
>
> The reason's are two-fold:
> - Pixmap's don't match 1x1 texture formats. It's a
little complicated  to
> make the pixmap scratch memory match the texture memory
space. Michel
> Denzer tried to make it work with his zero-copy patch
for tfp.
> - Command streams for both can be very different. The
command stream for X
> and GL goes through different pipes, so it's very
possible (actually you
> should see that) that the composition manager will grab
a pixmap that is
> not fully updated. The rebinding is meant to assure the
sync between the
> both. Part of the reason for the slowdown in rebinding
is likely directly
> caused by that - to assure consistent state of the
texture/pixmap NVIDIA
> driver is likely to do an explicit sync on one/both of
the the pipes. I
> think we mentioned this in section 5 of the
GLX_ext_texture_from_pixmap
> where it was pointed out that without explicit re-bind
after pixmap changes
> it's kinda hard to guarantee a consistent state of the
texture.

 That's what strict binding does, isn't it?

> Now having said that, if the performance gain are big
enough and you're ok
> with occasional glitches, you should leave it like that
and then bug others
> to make the drivers work better/faster.

-- 
Lubos Lunak
KDE developer
------------------------------------------------------------
--
SUSE LINUX, s.r.o.   e-mail: l.lunaksuse.cz , l.lunakkde.org
Lihovarska 1060/12   tel: +420 284 028 972
190 00 Prague 9      fax: +420 284 028 951
Czech Republic       http//www.suse.cz
_______________________________________________
Kwin mailing list
Kwinkde.org
https://ma
il.kde.org/mailman/listinfo/kwin

On Sunday 17 June 2007 09:34:56 Lubos Lunak wrote:
> On ne 17. června 2007, Rivo Laks wrote:
> > Ɯhel kenal pƤeval (pĆ¼hapƤev 17 juuni 2007)
kirjutas Lubos Lunak:
> > >  However, with these changed semantics of the
binding, it is possible
> > > there will redrawing problems. Specifically,
I think that strict
> > > binding now will be needed on some systems.
Could somebody with
> > > non-nvidia system check that strict binding
is necessary for them
> > > (kwinrc:Translucency:GLStrictBinding set to
true)?
> >
> > Is it supposed to make any difference for NVidia
users? Setting it to
> > false seems to make it a bit faster here.
>
>  Other than performance, no, AFAIK. We should do like
Beryl and set it to
> off with NVidia or XGL, with AIGLX having it enabled.
I'd still like if
> somebody with AIGLX could actually confirm it affects
things.

Without strict binding, kwin doesn't update windows, or even
necessarily draw 
them properly.  With strict binding, it works almost
perfectly.

I say almost, because since we now only check if
bound_glxpixmap is None, we 
don't check if it's pointing to the right pixmap.  Once
discardWindowPixmap() 
is called, window_pix is None, but bound_glxpixmap is
unchanged (and not 
None).  To trigger this, map, unmap, and map a window, and
it stops updating.

I think the right answer is to release the binding (when
non-strict binding), 
and destroy bound_glxpixmap from discardWindowPixmap(). 
Then the next 
SceneOpenGL::Texture::load() will just pick it up.  Does
that make sense?

-- 
Philip Falkner

_______________________________________________
Kwin mailing list
Kwinkde.org
https://ma
il.kde.org/mailman/listinfo/kwin

Ɯhel kenal pƤeval (esmaspƤev 25 juuni 2007) kirjutas
Philip Falkner:
> On Sunday 17 June 2007 09:34:56 Lubos Lunak wrote:
> > On ne 17. června 2007, Rivo Laks wrote:
> > > Ɯhel kenal pƤeval (pĆ¼hapƤev 17 juuni
2007) kirjutas Lubos Lunak:
> > > >  However, with these changed semantics
of the binding, it is possible
> > > > there will redrawing problems.
Specifically, I think that strict
> > > > binding now will be needed on some
systems. Could somebody with
> > > > non-nvidia system check that strict
binding is necessary for them
> > > > (kwinrc:Translucency:GLStrictBinding set
to true)?
> > >
> > > Is it supposed to make any difference for
NVidia users? Setting it to
> > > false seems to make it a bit faster here.
> >
> >  Other than performance, no, AFAIK. We should do
like Beryl and set it to
> > off with NVidia or XGL, with AIGLX having it
enabled. I'd still like if
> > somebody with AIGLX could actually confirm it
affects things.
>
> Without strict binding, kwin doesn't update windows, or
even necessarily
> draw them properly.  With strict binding, it works
almost perfectly.
>
> I say almost, because since we now only check if
bound_glxpixmap is None,
> we don't check if it's pointing to the right pixmap. 
Once
> discardWindowPixmap() is called, window_pix is None,
but bound_glxpixmap is
> unchanged (and not None).  To trigger this, map, unmap,
and map a window,
> and it stops updating.

I can confirm that bug. Doesn't matter if strict binding is
enabled or not, 
unmap+map makes it window stop updating.

> I think the right answer is to release the binding
(when non-strict
> binding), and destroy bound_glxpixmap from
discardWindowPixmap().  Then the
> next SceneOpenGL::Texture::load() will just pick it up.
 Does that make
> sense?

Your patch mostly works but sometimes it crashes when
choosing desktop in 
DesktopGrid because  effectWindow()->sceneWindow()  is 0
in composite.cpp:410

Rivo
_______________________________________________
Kwin mailing list
Kwinkde.org
https://ma
il.kde.org/mailman/listinfo/kwin

On Monday 25 June 2007 11:31:48 Rivo Laks wrote:
> Ɯhel kenal pƤeval (esmaspƤev 25 juuni 2007) kirjutas
Philip Falkner:
> > On Sunday 17 June 2007 09:34:56 Lubos Lunak wrote:
> > I say almost, because since we now only check if
bound_glxpixmap is None,
> > we don't check if it's pointing to the right
pixmap.  Once
> > discardWindowPixmap() is called, window_pix is
None, but bound_glxpixmap
> > is unchanged (and not None).  To trigger this,
map, unmap, and map a
> > window, and it stops updating.
>
> I can confirm that bug. Doesn't matter if strict
binding is enabled or not,
> unmap+map makes it window stop updating.
>
> > I think the right answer is to release the binding
(when non-strict
> > binding), and destroy bound_glxpixmap from
discardWindowPixmap().  Then
> > the next SceneOpenGL::Texture::load() will just
pick it up.  Does that
> > make sense?
>
> Your patch mostly works but sometimes it crashes when
choosing desktop in
> DesktopGrid because  effectWindow()->sceneWindow() 
is 0 in
> composite.cpp:410

Fixed, thanks.

-- 
Philip Falkner
_______________________________________________
Kwin mailing list
Kwinkde.org
https://ma
il.kde.org/mailman/listinfo/kwin