from:"Shuang He"

Re: Where is the latest source code for libXp?

2009-09-06 Thread Shuang He


Peng Yu wrote:

On Sun, Sep 6, 2009 at 9:30 PM, Stephan Raue wrote:
  

Am 07.09.2009 04:22, schrieb Peng Yu:


I don't see which one I should download.

What is the user name and password for the following?

ssh://git.freedesktop.org/git/xorg/lib/libXp

  

try this
http://cgit.freedesktop.org/xorg/lib/libXp/snapshot/libXp-master.tar.bz2



I don't see the file 'configure'. How to generate it? I tried
'autogen'. But it gives me the following error.

$ ./autogen.sh
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal
configure.ac:31: error: must install xorg-macros 1.2 or later before
running autoconf/autogen
configure.ac:31: the top level
autom4te: /usr/bin/m4 failed with exit status: 1
aclocal: autom4te failed with exit status: 1
autoreconf: aclocal failed with exit status: 1

Do I need to install 'xorg-marcos 1.2'? Where to download its source code?

Regards,
Peng
  

All xorg related codes can be found here:
http://cgit.freedesktop.org/

Thanks
   --Shuang

___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
  


___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Where is the latest source code for libXp?

2009-09-06 Thread Shuang He


Peng Yu wrote:

On Sun, Sep 6, 2009 at 9:15 PM, Shuang He wrote:
  

Peng Yu wrote:

On Sun, Sep 6, 2009 at 9:11 PM, Shuang He wrote:


Try
  git clone git://anongit.freedesktop.org/xorg/lib/libXp


Is there a package (tar.bz2 or tar.gz) for it? I don't have to
download the development version.

Regards,
Peng


I think you could download from
http://cgit.freedesktop.org/xorg/lib/libXp/



I don't see which one I should download.

What is the user name and password for the following?

ssh://git.freedesktop.org/git/xorg/lib/libXp

Regards,
Peng
  

You could directly download source package from:

http://cgit.freedesktop.org/xorg/lib/libXp/
like this one:
http://cgit.freedesktop.org/xorg/lib/libXp/snapshot/xo-6_7_0.tar.bz2

ssh://git.freedesktop.org/git/xorg/lib/libXp is for developers.

Thanks
 --Shuang



___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
  


___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Where is the latest source code for libXp?

2009-09-06 Thread Shuang He


Peng Yu wrote:

On Sun, Sep 6, 2009 at 9:11 PM, Shuang He wrote:
  

Try
  git clone git://anongit.freedesktop.org/xorg/lib/libXp



Is there a package (tar.bz2 or tar.gz) for it? I don't have to
download the development version.

Regards,
Peng
  


I think you could download from
http://cgit.freedesktop.org/xorg/lib/libXp/

Thanks
   --Shuang

___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
  


___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Where is the latest source code for libXp?

2009-09-06 Thread Shuang He

Try
git clone git://anongit.freedesktop.org/xorg/lib/libXp

Thanks
--Shuang

Peng Yu wrote:
> Hi,
>
> I can not find the latest source code for libXp. Can somebody point me
> where it is?
>
> http://www.x.org/archive/X11R6.8.2/doc/libXp.3.html
>
> Regards,
> Peng
> ___
> xorg mailing list
> xorg@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
>   

___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: HD-Video Hardware Acceleration?

2009-08-31 Thread Shuang He




Goga777 wrote:

Hi

what about plans to implement 1080i/1080p h264/vc-1 decoding for G45 Gm45 ? 
will it in this year ?
  

Hi
   We're working on that. I'm not sure if it will be ready in this year.

Thanks
   --Shuang
  

   We have enabled VAAPI support for G45 and GM45 platform.

I have tested it with some high profile 1080p mpeg2 stream.
Using a patched mplayer at 
http://www.splitted-desktop.com/~gbeauchesne/mplayer-vaapi/

I can see CPU usage is dramatically reduced.

Currently, we only support mpeg2 decoding.

Welcome to test it.
The git repo is at git://git.freedesktop.org/git/libva, 
To successful compile the mplayer, you need to choose the libva31 branch.
  

___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
  


___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: HD-Video Hardwar Acceleration?

2009-08-29 Thread Shuang He


Harald Braumann wrote:

On Sat, 29 Aug 2009 19:27:29 +0800
Shuang He  wrote:

  

You could give this a try.

Thanks
--Shuang

Zou, Nanhai wrote:

Hi, 
   We have enabled VAAPI support for G45 and GM45 platform.


I have tested it with some high profile 1080p mpeg2 stream.
Using a patched mplayer at 
http://www.splitted-desktop.com/~gbeauchesne/mplayer-vaapi/

I can see CPU usage is dramatically reduced.
  


Hi,

but I would still need a vaapi implementation that utilises hardware
acceleration.

Cheers,
harry
  

Hi, harry
   This vaapi implementation does utilize hardware acceleration.

Thanks
   --Shuang
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: HD-Video Hardwar Acceleration?

2009-08-29 Thread Shuang He

You could give this a try.

Thanks
--Shuang

Zou, Nanhai wrote:
> Hi, 
>We have enabled VAAPI support for G45 and GM45 platform.
>
> I have tested it with some high profile 1080p mpeg2 stream.
> Using a patched mplayer at 
> http://www.splitted-desktop.com/~gbeauchesne/mplayer-vaapi/
> I can see CPU usage is dramatically reduced.
>
> Currently, we only support mpeg2 decoding.
>
> Welcome to test it.
> The git repo is at git://git.freedesktop.org/git/libva, 
> To successful compile the mplayer, you need to choose the libva31 branch.
>
> Thanks
> Zou Nan hai
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>   


Harald Braumann wrote:
> Hi,
>
> is there any chip out there for which hardware accelerated HD video
> decoding is supported by an open-source driver? Or for which at least
> documentation exists so that it could be implemented?
>
> I for one care less about 3D acceleration. But it's very frustrating
> that it's still not possible to watch full HD videos on Linux. 
>
> Cheers,
> harry
>   

___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: about Intel(R) Textured Video and Overlay Video

2009-08-05 Thread Shuang He

Hi, That're two ways to render decoded video to screen.
You could check if your system support one/or both of them by issuing
command: xvinfo
and to explicitly specify one of them , you need also check the
corresponding port number for textured video or the overlay video.
The port number could also be get by command xvinfo.
For mplayer, you could specify the port this way:
mplayer -vo xv:port=port_number videofile

Thanks
--Shuang

kedahanzi wrote:
> dear everyone,
> what is the difference betweenIntel(R)TexturedVideoandOverlayVideo?
> how do i decide to use Intel(R)TexturedVideo way or OverlayVideo way?
> much thanks!
> 2009-08-05
> 
> kedahanzi

___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: [RFC] glx: fix DRI2 memory leak

2009-04-01 Thread Shuang He


Michel Dänzer wrote:

On Mon, 2009-03-30 at 13:04 +0800, Shuang He wrote:
  
Shuang He wrote: 

Jesse Barnes wrote: 
  

On Fri, 27 Mar 2009 13:20:25 -0400
Kristian Høgsberg  wrote:


The leak is (as you pointed out before) because we NULL the pDraw
pointer before calling the backend destructor, which then can't unref
the DRI2Drawable, which we then leak.  You had the right fix in the
originial post, we just need to not touch glxPriv after
__glXUnrefDrawable if it got destroyed.  I suggest this change to
DrawableGone in irc:

refcount = glxPriv->refcount;
__glXUnrefDrawable(glxPriv);
if (refcount > 1) {
glxPriv->pDraw = NULL;
glxPriv->drawId = 0;
}

  

Yep, that seems to work too...  Magnus or Vasily can you guys confirm?
  


Memory leak problem seems resolved, but I still see X crash with:
(gdb) bt
#0  0xb7fd5424 in __kernel_vsyscall ()
#1  0x03155660 in raise () from /lib/libc.so.6
#2  0x03157028 in abort () from /lib/libc.so.6
#3  0x031925bd in __libc_message () from /lib/libc.so.6
#4  0x031987e4 in malloc_printerr () from /lib/libc.so.6
#5  0x0319c441 in _int_realloc () from /lib/libc.so.6
#6  0x0319d176 in realloc () from /lib/libc.so.6
#7  0x08131002 in Xrealloc (ptr=0x6, amount=0) at utils.c:1133
#8  0x0806d10b in dixAllocatePrivate (privates=0x91487c8, key=0xb7e90a3c)
at privates.c:129
#9  0x0806d1cc in dixSetPrivate (privates=0x91487c8, key=0xb7e90a3c, val=0x0)
at privates.c:193
#10 0xb7e8eca1 in DRI2DestroyDrawable (pDraw=0x91487b0) at dri2.c:218
#11 0xb7eee668 in __glXDRIdrawableDestroy (drawable=0x9205ff0) at glxdri2.c:108
#12 0xb7ee49bb in __glXUnrefDrawable (glxPriv=0x9205ff0) at glxutil.c:58
#13 0xb7ee3183 in DrawableGone (glxPriv=0x9205ff0, xid=12583326)
at glxext.c:131
#14 0x0806efdc in FreeResource (id=12583326, skipDeleteFuncType=0)
at resource.c:561
#15 0xb7edffa6 in DoDestroyDrawable (cl=,
glxdrawable=12583326, type=1) at glxcmds.c:1225
#16 0xb7ee340a in __glXDispatch (client=0x8d79db8) at glxext.c:523
#17 0x080874cf in Dispatch () at dispatch.c:437
---Type  to continue, or q  to quit---
#18 0x0806c69d in main (argc=2, argv=0xbf9d2754, envp=Cannot access memory at
address 0xbde
  

Just debug a bit, check out this series of calls in DRI2DestroyDrawable when X
crashed:
in (*ds->DestroyBuffers)(pDraw, pPriv->buffers, pPriv->bufferCount);
  Xfree: free(0x9eef330)
  Xfree: free(0x9eeef20)
  Xfree: free(0x9efdde0)
  Xfree: free(0x9efce08)
  Xfree: free(0x9eee8b0)
  Xrealloc: ptr = 0x9efaf20
  Xrealloc: amount = 384
  Xfree: free(0x9efcd18)
  Xfree: free(0x9ef8468)
  Xrealloc: ptr = 0x9efa278
  Xrealloc: amount = 384
  Xfree: free(0x9efcd18)
  Xfree: free(0x9ef9808)
  Xfree: free(0x9eeef38)
  Xfree: free(0x9efa648)
  Xfree: free(0x9efd788)
in dixSetPrivate(&pPixmap->devPrivates, dri2PixmapPrivateKey, NULL);
  Xrealloc: ptr = 0x9efce08
  Xrealloc: amount = 512

So dixSetPrivate is trying to realloc memory at 0x9efce08, which is alreay
freed  in DetroyBuffers. So maybe we should also do this: [...]



The real problem was pointed out by Pierre Willenbrock: If
glxPriv->pDraw is a pixmap, DrawableGone() destroys it, then later
DRI2DestroyDrawable dereferences it... The patch below seems to work
here - at least it hasn't crashed in a couple of hours, not sure about
the leak yet.

Note that unless I'm missing something, it might still be possible for
this to occur with windows if the underlying DrawableRec is freed before
this code is reached.

Also, I don't really understand the logic behind clearing glxPriv->pDraw
and ->drawId here. In particular, I'm not sure DrawableGone will ever be
called with glxPriv->refCount > 1. If it won't, this change makes the
assignments unreachable. And if it will, we'll again leak because the
cleanup code won't be able to get to the underlying DrawableRec?


diff --git a/glx/glxext.c b/glx/glxext.c
index c882372..e74d00e 100644
--- a/glx/glxext.c
+++ b/glx/glxext.c
@@ -119,17 +119,25 @@ static int ContextGone(__GLXcontext* cx, XID id)
 static Bool DrawableGone(__GLXdrawable *glxPriv, XID xid)
 {
 ScreenPtr pScreen = glxPriv->pDraw->pScreen;
+PixmapPtr pPixmap = NULL;
+int refcount;
 
 switch (glxPriv->type) {

case GLX_DRAWABLE_PIXMAP:
case GLX_DRAWABLE_PBUFFER:
-   (*pScreen->DestroyPixmap)((PixmapPtr) glxPriv->pDraw);
+   pPixmap = (PixmapPtr) glxPriv->pDraw;
break;
 }
 
-glxPriv->pDraw = NULL;

-glxPriv->drawId = 0;
+refcount = glxPriv->refCount;
 __glXUnrefDrawable(glxPriv);
+if (refcount > 1) {
+   glxPriv->pDraw = NULL;
+   glxPriv->drawId = 0;
+}
+
+if (pPixmap)

+   (*pScreen->DestroyPixmap)(pPixmap);
 
 return True;

 }


  

This works for me. I don't see the memory leaks or X crashes.

Thanks
   --Shuang
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: [RFC] glx: fix DRI2 memory leak

2009-03-30 Thread Shuang He


Magnus Kessler wrote:

On Monday 30 March 2009, Shuang He wrote:
  

Jesse Barnes wrote:


On Fri, 27 Mar 2009 13:20:25 -0400

Kristian Høgsberg  wrote:
  

On Thu, Mar 26, 2009 at 6:33 PM, Jesse Barnes

 wrote:


Ok, I think this is where the leak was:
__glXUnrefDrawable->DrawableGone->__glXUnrefDrawable.  This sequence
meant the glxPriv would stay around (since it was used), but
DrawableGone had generally already disposed of the pDrawable before
the call to Unref, so we never got into DRI2DestroyBuffers, thus
the leak.

The loop seems broken to me.  It *looks* like DrawableGone should be
the real free routine, only called when a drawable really is free,
so I've fixed up the code to conform to that.  This means removing
the GLX priv frees from DRI and DRI2 routines and putting them here
and using the GLX unref routine everwhere (since it will only free
the resource when the refcount reaches 0).

Any thoughts?  I'd appreciate some more testers too...  I'm not
quite sure about the generic DoDestroyDrawable change, but if the
refcount is always 1 there anyway it shouldn't make a difference
and seems more correct.
  

The __GLXdrawable is a reference counted object, and the glx code
references it in a couple of places: when there's an X resource
pointing to it (a GLXWindow, GLXPixmap or GLXPbuffer) and when it's
the current drawable or readable for a context.  The __GLXdrawable is
allocated by the backend in use (dri, dri2 or swrast) and must be
freed by the same backend (don't mix alloc and free across abstraction
barriers).  We unref the __GLXdrawable when we either set a different
drawable/readable and when the X resource goes away.

The leak is (as you pointed out before) because we NULL the pDraw
pointer before calling the backend destructor, which then can't unref
the DRI2Drawable, which we then leak.  You had the right fix in the
originial post, we just need to not touch glxPriv after
__glXUnrefDrawable if it got destroyed.  I suggest this change to
DrawableGone in irc:

refcount = glxPriv->refcount;
__glXUnrefDrawable(glxPriv);
if (refcount > 1) {
glxPriv->pDraw = NULL;
glxPriv->drawId = 0;
}


Yep, that seems to work too...  Magnus or Vasily can you guys confirm?

Thanks,
  

Memory leak problem seems resolved, but I still see X crash with:

(gdb) bt
#0  0xb7fd5424 in __kernel_vsyscall ()
#1  0x03155660 in raise () from /lib/libc.so.6
#2  0x03157028 in abort () from /lib/libc.so.6
#3  0x031925bd in __libc_message () from /lib/libc.so.6
#4  0x031987e4 in malloc_printerr () from /lib/libc.so.6
#5  0x0319c441 in _int_realloc () from /lib/libc.so.6
#6  0x0319d176 in realloc () from /lib/libc.so.6
#7  0x08131002 in Xrealloc (ptr=0x6, amount=0) at utils.c:1133
#8  0x0806d10b in dixAllocatePrivate (privates=0x91487c8, key=0xb7e90a3c)
at privates.c:129
#9  0x0806d1cc in dixSetPrivate (privates=0x91487c8, key=0xb7e90a3c,
val=0x0) at privates.c:193
#10 0xb7e8eca1 in DRI2DestroyDrawable (pDraw=0x91487b0) at dri2.c:218
#11 0xb7eee668 in __glXDRIdrawableDestroy (drawable=0x9205ff0) at
glxdri2.c:108 #12 0xb7ee49bb in __glXUnrefDrawable (glxPriv=0x9205ff0) at
glxutil.c:58 #13 0xb7ee3183 in DrawableGone (glxPriv=0x9205ff0,
xid=12583326) at glxext.c:131
#14 0x0806efdc in FreeResource (id=12583326, skipDeleteFuncType=0)
at resource.c:561
#15 0xb7edffa6 in DoDestroyDrawable (cl=,
glxdrawable=12583326, type=1) at glxcmds.c:1225
#16 0xb7ee340a in __glXDispatch (client=0x8d79db8) at glxext.c:523
#17 0x080874cf in Dispatch () at dispatch.c:437
---Type  to continue, or q  to quit---
#18 0x0806c69d in main (argc=2, argv=0xbf9d2754, envp=Cannot access
memory at address 0xbde

Thanks
--Shuang
) at main.c:397



I have observed this crash once as well, but haven't yet found a way to 
reproduce it. Can you post a few steps that make this crash more likely? On 
the bug report (http://bugs.freedesktop.org/show_bug.cgi?id=20704) you 
mention it has something to do with resizing by small amounts.


Thanks

Magnus
  
I could easily reproduce this by just resizing the window several 
times.  Most of times, it's just costing 1 or 2 minutes.


Thanks
   --Shuang


___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
  


___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: [RFC] glx: fix DRI2 memory leak

2009-03-29 Thread Shuang He


Shuang He wrote:

Jesse Barnes wrote:

On Fri, 27 Mar 2009 13:20:25 -0400
Kristian Høgsberg  wrote:

  

On Thu, Mar 26, 2009 at 6:33 PM, Jesse Barnes
 wrote:


Ok, I think this is where the leak was:
__glXUnrefDrawable->DrawableGone->__glXUnrefDrawable.  This sequence
meant the glxPriv would stay around (since it was used), but
DrawableGone had generally already disposed of the pDrawable before
the call to Unref, so we never got into DRI2DestroyBuffers, thus
the leak.

The loop seems broken to me.  It *looks* like DrawableGone should be
the real free routine, only called when a drawable really is free,
so I've fixed up the code to conform to that.  This means removing
the GLX priv frees from DRI and DRI2 routines and putting them here
and using the GLX unref routine everwhere (since it will only free
the resource when the refcount reaches 0).

Any thoughts?  I'd appreciate some more testers too...  I'm not
quite sure about the generic DoDestroyDrawable change, but if the
refcount is always 1 there anyway it shouldn't make a difference
and seems more correct.
  

The __GLXdrawable is a reference counted object, and the glx code
references it in a couple of places: when there's an X resource
pointing to it (a GLXWindow, GLXPixmap or GLXPbuffer) and when it's
the current drawable or readable for a context.  The __GLXdrawable is
allocated by the backend in use (dri, dri2 or swrast) and must be
freed by the same backend (don't mix alloc and free across abstraction
barriers).  We unref the __GLXdrawable when we either set a different
drawable/readable and when the X resource goes away.

The leak is (as you pointed out before) because we NULL the pDraw
pointer before calling the backend destructor, which then can't unref
the DRI2Drawable, which we then leak.  You had the right fix in the
originial post, we just need to not touch glxPriv after
__glXUnrefDrawable if it got destroyed.  I suggest this change to
DrawableGone in irc:

refcount = glxPriv->refcount;
__glXUnrefDrawable(glxPriv);
if (refcount > 1) {
glxPriv->pDraw = NULL;
glxPriv->drawId = 0;
}



Yep, that seems to work too...  Magnus or Vasily can you guys confirm?

Thanks,
  

Memory leak problem seems resolved, but I still see X crash with:
(gdb) bt
#0  0xb7fd5424 in __kernel_vsyscall ()
#1  0x03155660 in raise () from /lib/libc.so.6
#2  0x03157028 in abort () from /lib/libc.so.6
#3  0x031925bd in __libc_message () from /lib/libc.so.6
#4  0x031987e4 in malloc_printerr () from /lib/libc.so.6
#5  0x0319c441 in _int_realloc () from /lib/libc.so.6
#6  0x0319d176 in realloc () from /lib/libc.so.6
#7  0x08131002 in Xrealloc (ptr=0x6, amount=0) at utils.c:1133
#8  0x0806d10b in dixAllocatePrivate (privates=0x91487c8, key=0xb7e90a3c)
at privates.c:129
#9  0x0806d1cc in dixSetPrivate (privates=0x91487c8, key=0xb7e90a3c, val=0x0)
at privates.c:193
#10 0xb7e8eca1 in DRI2DestroyDrawable (pDraw=0x91487b0) at dri2.c:218
#11 0xb7eee668 in __glXDRIdrawableDestroy (drawable=0x9205ff0) at glxdri2.c:108
#12 0xb7ee49bb in __glXUnrefDrawable (glxPriv=0x9205ff0) at glxutil.c:58
#13 0xb7ee3183 in DrawableGone (glxPriv=0x9205ff0, xid=12583326)
at glxext.c:131
#14 0x0806efdc in FreeResource (id=12583326, skipDeleteFuncType=0)
at resource.c:561
#15 0xb7edffa6 in DoDestroyDrawable (cl=,
glxdrawable=12583326, type=1) at glxcmds.c:1225
#16 0xb7ee340a in __glXDispatch (client=0x8d79db8) at glxext.c:523
#17 0x080874cf in Dispatch () at dispatch.c:437
---Type  to continue, or q  to quit---
#18 0x0806c69d in main (argc=2, argv=0xbf9d2754, envp=Cannot access memory at
address 0xbde

Thanks
--Shuang
) at main.c:397
  



Just debug a bit, check out this series of calls in DRI2DestroyDrawable when X
crashed:
in (*ds->DestroyBuffers)(pDraw, pPriv->buffers, pPriv->bufferCount);
 Xfree: free(0x9eef330)
 Xfree: free(0x9eeef20)
 Xfree: free(0x9efdde0)
 Xfree: free(0x9efce08)
 Xfree: free(0x9eee8b0)
 Xrealloc: ptr = 0x9efaf20
 Xrealloc: amount = 384
 Xfree: free(0x9efcd18)
 Xfree: free(0x9ef8468)
 Xrealloc: ptr = 0x9efa278
 Xrealloc: amount = 384
 Xfree: free(0x9efcd18)
 Xfree: free(0x9ef9808)
 Xfree: free(0x9eeef38)
 Xfree: free(0x9efa648)
 Xfree: free(0x9efd788)
in dixSetPrivate(&pPixmap->devPrivates, dri2PixmapPrivateKey, NULL);
 Xrealloc: ptr = 0x9efce08
 Xrealloc: amount = 512

So dixSetPrivate is trying to realloc memory at 0x9efce08, which is alreay
freed  in DetroyBuffers. So maybe we should also do this:

diff --git a/hw/xfree86/dri2/dri2.c b/hw/xfree86/dri2/dri2.c
index 0f2e24b..dddcfdc 100644
--- a/hw/xfree86/dri2/dri2.c
+++ b/hw/xfree86/dri2/dri2.c
@@ -204,9 +204,6 @@ DRI2DestroyDrawable(DrawablePtr pDraw)
if (pPriv->refCount > 0)
   return;

-(*ds->DestroyBuffers)(pDraw, pPriv->buffers, pPriv->bufferCount);
-xfree(pPriv);
-
if (pDraw->type == DRAWABLE_WINDOW)
{
   pWin = (WindowPtr) p

Re: [RFC] glx: fix DRI2 memory leak

2009-03-29 Thread Shuang He


Jesse Barnes wrote:

On Fri, 27 Mar 2009 13:20:25 -0400
Kristian Høgsberg  wrote:

  

On Thu, Mar 26, 2009 at 6:33 PM, Jesse Barnes
 wrote:


Ok, I think this is where the leak was:
__glXUnrefDrawable->DrawableGone->__glXUnrefDrawable.  This sequence
meant the glxPriv would stay around (since it was used), but
DrawableGone had generally already disposed of the pDrawable before
the call to Unref, so we never got into DRI2DestroyBuffers, thus
the leak.

The loop seems broken to me.  It *looks* like DrawableGone should be
the real free routine, only called when a drawable really is free,
so I've fixed up the code to conform to that.  This means removing
the GLX priv frees from DRI and DRI2 routines and putting them here
and using the GLX unref routine everwhere (since it will only free
the resource when the refcount reaches 0).

Any thoughts?  I'd appreciate some more testers too...  I'm not
quite sure about the generic DoDestroyDrawable change, but if the
refcount is always 1 there anyway it shouldn't make a difference
and seems more correct.
  

The __GLXdrawable is a reference counted object, and the glx code
references it in a couple of places: when there's an X resource
pointing to it (a GLXWindow, GLXPixmap or GLXPbuffer) and when it's
the current drawable or readable for a context.  The __GLXdrawable is
allocated by the backend in use (dri, dri2 or swrast) and must be
freed by the same backend (don't mix alloc and free across abstraction
barriers).  We unref the __GLXdrawable when we either set a different
drawable/readable and when the X resource goes away.

The leak is (as you pointed out before) because we NULL the pDraw
pointer before calling the backend destructor, which then can't unref
the DRI2Drawable, which we then leak.  You had the right fix in the
originial post, we just need to not touch glxPriv after
__glXUnrefDrawable if it got destroyed.  I suggest this change to
DrawableGone in irc:

refcount = glxPriv->refcount;
__glXUnrefDrawable(glxPriv);
if (refcount > 1) {
glxPriv->pDraw = NULL;
glxPriv->drawId = 0;
}



Yep, that seems to work too...  Magnus or Vasily can you guys confirm?

Thanks,
  

Memory leak problem seems resolved, but I still see X crash with:

(gdb) bt
#0  0xb7fd5424 in __kernel_vsyscall ()
#1  0x03155660 in raise () from /lib/libc.so.6
#2  0x03157028 in abort () from /lib/libc.so.6
#3  0x031925bd in __libc_message () from /lib/libc.so.6
#4  0x031987e4 in malloc_printerr () from /lib/libc.so.6
#5  0x0319c441 in _int_realloc () from /lib/libc.so.6
#6  0x0319d176 in realloc () from /lib/libc.so.6
#7  0x08131002 in Xrealloc (ptr=0x6, amount=0) at utils.c:1133
#8  0x0806d10b in dixAllocatePrivate (privates=0x91487c8, key=0xb7e90a3c)
   at privates.c:129
#9  0x0806d1cc in dixSetPrivate (privates=0x91487c8, key=0xb7e90a3c, val=0x0)
   at privates.c:193
#10 0xb7e8eca1 in DRI2DestroyDrawable (pDraw=0x91487b0) at dri2.c:218
#11 0xb7eee668 in __glXDRIdrawableDestroy (drawable=0x9205ff0) at glxdri2.c:108
#12 0xb7ee49bb in __glXUnrefDrawable (glxPriv=0x9205ff0) at glxutil.c:58
#13 0xb7ee3183 in DrawableGone (glxPriv=0x9205ff0, xid=12583326)
   at glxext.c:131
#14 0x0806efdc in FreeResource (id=12583326, skipDeleteFuncType=0)
   at resource.c:561
#15 0xb7edffa6 in DoDestroyDrawable (cl=,
   glxdrawable=12583326, type=1) at glxcmds.c:1225
#16 0xb7ee340a in __glXDispatch (client=0x8d79db8) at glxext.c:523
#17 0x080874cf in Dispatch () at dispatch.c:437
---Type  to continue, or q  to quit---
#18 0x0806c69d in main (argc=2, argv=0xbf9d2754, envp=Cannot access memory at
address 0xbde

Thanks
--Shuang
) at main.c:397


___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Where is the latest source code for libXp?

Re: Where is the latest source code for libXp?

Re: Where is the latest source code for libXp?

Re: Where is the latest source code for libXp?

Re: HD-Video Hardware Acceleration?

Re: HD-Video Hardwar Acceleration?

Re: HD-Video Hardwar Acceleration?

Re: about Intel(R) Textured Video and Overlay Video

Re: [RFC] glx: fix DRI2 memory leak

Re: [RFC] glx: fix DRI2 memory leak

Re: [RFC] glx: fix DRI2 memory leak

Re: [RFC] glx: fix DRI2 memory leak

12 matches

Site Navigation

Mail list logo

Footer information