Using the GL output option of VLC to play a film (a divx in this case) on an M9 based PPC laptop produce the following: The first frame is displayed with what looks like an incorrect endian (wrong colors), then half of it starts flashing black (a bad triangle) and finally the card completely locks up, a reboot is needed.
It's not an endianness problem, support for YUV textures is broken on RV2xx. It's been disabled in current Mesa CVS. No idea about the lockup, but it may make sense to try Mesa CVS for that as well.
Hrm... it's a HW bug or some problem with the code ? Any chance it ever works ? It seem to work properly with the binary ATI driver on x86 ...
The reason YUV textures don't work is unknown. There seems to be a hw difference between R200 and RV2x0 regarding yuv textures, and nobody knows how (if it's even possible) to make it work on the latter. That said, I'm not 100% convinced that the VLC problem is because of this, does the opengl output plugin actually use YUV textures when it's available (mplayers gl/gl2 output plugin does not)? ATI's binary drivers for x86 do not expose any yuv texture functionality (at least not on my rv250).
Ok, more data. The texture problem is unrelated to the lockup. There is a texture problem when using VLC in GL mode, the colors are wrong (and it's very slow). Unrelated to that, there is a lockup problem when I wake up from sleep that I isolated to beeing caused by radeonfb enabling dynamic clocks on the card. This is the radeonfb version from my latest sleep patches (not yet upstream). It mimmics the dynamic clocks code from X.org, but might actually be enabling _more_ clock PM than the X code since it merges the code in X.org with the previous code I had from ATI, which in some case did set a bit more bits here or there. I'll investigate that issue separately. The symptom is basically one wakeup, 3D activity works for a second or so, and the entire card locks up. CCE-based 2D is fine tho. However, that shows that there is definitely one problem with the X.org dynamic clock code and maybe two: - The dynamic clock stuff is only done on server entry. It should be re-done on "resume" (EnterVT) since that's typically wakeup from sleep, wether it's actually enabling or disabling the dynamic clocks. - I wonder if we should force some more clocks during engine reset/setup, like we used to do even before X had any "workarounds" for dynamic clock issues. Does the reset cycle of every engine part performs properly when dynamic clocks are enabled ?
The YUV texture problem is a HW bug and unfixable, the sleep/wakeup problem is gone.
(In reply to comment #5) > The YUV texture problem is a HW bug and unfixable Do you know that for sure, and if so what chips it affects? The driver currently no longer disables yuv textures even on rv250 due to uncertainty which chips exactly are affected. Also, even if it is definitely broken, we could in theory do some workaround, since the rv250 seems to treat it as "GBR 4:2:2" we could maybe convert textures to this format (still full conversion costs, but same bandwidth needs as ycbcr 4:2:2). Otherwise we really should disable it on affected chips.
the rv250 is broken .. the real r200 and rv280 work fine...
Ok, I'm re-opening for now then. So far, rv250 has the bug for sure. David says rv280 doesn't. I'll verify this here too just in case asap. Somebody has an rv200 to test ?
(In reply to comment #8) > Ok, I'm re-opening for now then. So far, rv250 has the bug for sure. David says > rv280 doesn't. I'll verify this here too just in case asap. Somebody has an > rv200 to test ? I think rv200 should be fine as no one has reported problems on any r100 chips that I can recall.
Created attachment 3595 [details] [review] patch to disable ycbcr textures on rv250 what about the igps? So far r200 and rv280 are said to work, rv250 not. The patch disables yuv textures on rv250 only. It also gets rid of the old r100 pci ids, instead of assuming all ids not listed are some unknown (tcl-capable) r200, it only allows the driver to explicitly initialize on r200 chip ids.
Ok, fixed. I assume the igps work, since they appeared after the rv280 I'd guess they don't have the rv250-specific bug neither.
(In reply to comment #11) > Ok, fixed. I assume the igps work, since they appeared after the rv280 I'd guess > they don't have the rv250-specific bug neither. Most of the IGPs were r100 based anyway. the r200 based ones didn't come around until the r300s were out, IIRC.
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.