Bug 16844 - r500, textured video: XVideo fails with error: BadAlloc
Summary: r500, textured video: XVideo fails with error: BadAlloc
Status: RESOLVED WONTFIX
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/Radeon (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: xf86-video-ati maintainers
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-07-25 01:29 UTC by Hans de Goede
Modified: 2008-07-25 06:24 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
xorg.conf (736 bytes, text/plain)
2008-07-25 02:12 UTC, Hans de Goede
no flags Details
xorg.log (447.35 KB, text/plain)
2008-07-25 02:16 UTC, Hans de Goede
no flags Details

Description Hans de Goede 2008-07-25 01:29:18 UTC
After the great work you've guys been doing on r500 support (including 3d yeah!) I've bought myself a Radeon X1950 Pro (RV570) PCI-E card to do some testing for you, giving something back that way.

Today I've updated to the latest xf86-video-ati git and did a standard build of that (on a fully up2date Fedora development system, using xorg-x11-server-Xorg-1.4.99.905-2.20080701).

This fixes 2 of the 3 issues I ways, once more good work!

The only remaining (2d related) issue I have now is that whenever I try to play a video in mplayer (format doesn't seem to matter) I get a window full of noise and for each frame the following error:
X11 error: BadAlloc (insufficient resources for operation)

I can use around this by telling mplayer not to use xvideo. I'm not sure if this can be reproduced with other software then mplayer, as many software already contains a workaround for this (capturing the X11 error and falling back to non XVideo use) due to the long standing bug 2772.

I for example myself wrote the catch this error and fallback to software video stretching code for SDL, to work around a similar long standing error with the i8xx driver.

I would be more then happy to try any patches, or even to take a stab at fixing this myself, provided I'm giving some directions of the likely (low level) cause.
Comment 1 Michel Dänzer 2008-07-25 01:57:00 UTC
Please attach the full xorg.conf and Xorg.0.log files.

E.g. this is expected with XAA when using a compositing manager.
Comment 2 Hans de Goede 2008-07-25 02:12:20 UTC
Created attachment 17883 [details]
xorg.conf
Comment 3 Hans de Goede 2008-07-25 02:16:22 UTC
Created attachment 17884 [details]
xorg.log

I'm not using a composite manager, I do see in the xorg.log that xorg is defaulting the XAA, I thought it would use EXA by default on my card, let me check what happens if I switch to EXA.
Comment 4 Hans de Goede 2008-07-25 02:23:31 UTC
Switching to EXA indeed fixes this!
Comment 5 Michel Dänzer 2008-07-25 02:27:16 UTC
It's not possible to fix this in general with XAA unfortunately.
Comment 6 Hans de Goede 2008-07-25 03:44:24 UTC
Ok, well EXA is the future right? Does anyone know why EXA isn't the default with the r5xx in the radeon driver, I thought it was supposed to be?
Comment 7 Alex Deucher 2008-07-25 06:24:20 UTC
(In reply to comment #6)
> Ok, well EXA is the future right? Does anyone know why EXA isn't the default
> with the r5xx in the radeon driver, I thought it was supposed to be?
> 

EXA needs newer xservers for optimal performance due to relatively recent improvements in the exa core.  It will be the default eventually.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.