Leif Delgass writes:
> On Thu, 28 Nov 2002, Svante Signell wrote:
>
> > Leif Delgass writes:
> > > On Wed, 27 Nov 2002, Svante Signell wrote:
> > I have now tested at 1024x768, and everything works OK, but I think there is
> > memory not returned to the card in the 3D driver, see below.
> > >
>
> Actually, those allocations only apply when a GL context is running.
> That's why the message was changed from "Using" to "Will use" -- no memory
> is allocated when that message is logged. When the X server actually
> allocates that memory for the DRI back and depth buffers (when changing
> from no GL contexts to one or more GL contexts -- not including the X
> server's context), you should see "Largest offscreen area available: ..."
At startup of the X server:
(II) ATI(0): Largest offscreen area available: 1280 x 2252
(II) ATI(0): Will use 511 kB of offscreen memory for XAA
(II) ATI(0): Will use back buffer at offset 0x2ff800
(II) ATI(0): Will use depth buffer at offset 0x57f800
Later in the log file:
(II) ATI(0): Largest offscreen area available: 1280 x 2252
> appear again at the end of the X log. Also when that happens, the XVideo
> memory (in use for the current frame) is freed. If the remaining
> offscreen memory after the DRI allocations (511 kB in this case) is not
> enough for subsequent video frame allocations, then you'll see the
> BadAlloc, which would cause mplayer to crash. Since the driver uses
> double-buffering for XVideo by default, this is _not_ enough for DVD and
> I'm pretty sure it's not enough for the video size you had the problem
> with in your first email (though I'd have to check the calculations for
> that video format). So if you have both a GL app and an XVideo app
> running at the same time, the XVideo app's allocations will fail unless
> the video size is fairly small. This is not very graceful, but it's
> expected with the current code and doesn't indicate a memory leak.
> However, if you run mplayer, exit mplayer, run a GL app, exit the GL app,
> and then run mplayer again, you shouldn't have a problem. If that's
> what's really happening, that's a bug.
Yes, this is what I did. I did exit from the atlantis demo but still
with xscreensaven running in the background. Also, stopping the
xscreensaver daemon does not change anything. In addition, after
failure to allocate off-screen memory I can still view small size
video applications in mplayer but not large size ones. So the
concusion would be that it's a bug, either in the mach64 driver or
somewhere else, eg. xscreensaver?
> You can check /proc/dri/0/clients
> to see the pids of all the DRI clients (there will always be at least one
> for the X server). Note however that when I run KDE, I get a few clients
> listed for some processes that are linked to libGL even though they
> haven't created a full-fledged context and don't cause the X server to
> allocate any memory for 3D.
Only one client remains after exiting from the xsceensaver demo.
cat /proc/dri/0/clients
a dev pid uid magic ioctls
y 0 1904 0 0 6292494
BTW: I'm running gnome2 and sawfish.
> > I can now reproduce the error for 1280x1024:
> > 1. Run mplayer using the XV driver: Everything is OK
> > 2. Run a 3D application, such as the atlantis demo in xscreensaver
2a) Exit the atlantis demo, with xscreensaver running in the background.
> > 3. Run mplayer using the XV driver again: Error state occurs
> > X11 error: BadAlloc (insufficient resources for operation)
>
> In the sequence above, do you close the atlantis demo between step 2 and
> 3? I can reproduce this if I leave atlantis open and then start an xvideo
> app (I tested with xine), or if I leave xine running and then start
> atlantis. This is the scenario I described above. But if
> atlantis/xscreensaver is not running after step 2 (check
> /proc/dri/0/clients to make sure), then #3 shouldn't fail.
See above.
>
> At any rate, the upshot is that you won't be able to have 3D accel and
> XVideo past a certain video size at the same time with 1280x1024 (with the
> current shared buffer scheme for DRI). Even if we can make the failure
> more graceful, we'll either have to revert to software GL or reduce the
> maximum XvImage size (though we could probably make it so any running apps
> would continue to work as expected).
I don't expect to have them active at the same time, running them one
at a time is OK for me.
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
