On Thu, 28 Nov 2002, Svante Signell wrote: > Leif Delgass writes: > > On Wed, 27 Nov 2002, Svante Signell wrote: > > > > > Leif Delgass writes: > > > > Have you tried a lower resolution? > > > Not yet. > > > > Try restarting X with 1024x768@16bpp for a while and see if you still have > > the same problem. > 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. > > > > > > If it's some sort of memory leak, I'd > > > > expect that you'd run into it eventually even at a lower resolution. If > > > > it doesn't happen at lower resolutions, maybe you really just don't have > > > > enough offscreen memory at 1280x1024. > > > What is meant with offscreen memory, main memory + card memory or smth else? > > > free: > > > total used free shared buffers cached > > > Mem: 127660 123760 3900 0 9104 44884 > > > -/+ buffers/cache: 69772 57888 > > > Swap: 130748 84172 46576 > > > > Offscreen memory refers to the on-card memory left over after the > > framebuffer allocation(s). When there are no GL contexts, the framebuffer > > memory is equal to display width x display height x bytes per pixel (2 for > > 16-bit). With GL contexts running, there is an additional back buffer > > (same size as the 2D "front" framebuffer) plus a depth buffer which is > > width x height x 2 (depth buffer is always 16-bit). The remaining > > offscreen memory is used for XAA and XVideo buffers. You can get a > > BadAlloc when there is not enough offscreen memory left. > > Doing the calculations one gets: > 8Meg - 3x(1280x1024)= 8388608 - 7864320 = 524288 bytes = 512 kbytes > which is close to what the log file reports: > (II) ATI(0): Will use 511 kB of offscreen memory for XAA > > It seems that the 3D driver already has allocated the frame buffer, > back buffer and depth buffer memory at startup, right. Obviously the > remaining 512k of memory is sufficient for the XV driver when no 3D > applications has been activated.
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: ..." 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. 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. > > > > > > Also, did you run any GL apps > > > > before starting mplayer or between attempts (or during attempts)? > > > xscreensaver is running, so some 3D applications are possibly run when > > > it activates. The box is usually on all day. > 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 > 3. Run mplayer using the XV driver again: Error state occurs > X11 error: BadAlloc (insufficient resources for operation) > Running the xscreensaver demo again works, no problem. > > Conclusion: Memory available for XAA and XV before running the 3D > application is not returned when the application exits!! > Maybe this in not possible to do for this card without > leaving X and reentering, but it is _very_ annoying. I > don't really like to run the desktop at 1024x768. I will > robably use another X display for 3D applications or for > viewing movie clips. The best alternative though, would be > if you can find a solution in the mach64 driver. 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. 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). -- Leif Delgass http://www.retinalburn.net ------------------------------------------------------- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
