Getting Xv to work with radeon driver and r500 card

[TechMage89]

I've tried using Xv with the newly-compatable radeon driver and my x1600. There appear to be two problems: It's glacially slow (I assume a drm problem which will eventually be resolved,) and the color is wrong.

The first issue is probably beyond my ability (as a fairly novice programmer) to fix, but I may be able to help with the second. It appears from the look of the image that the card is trying to scanout what looks like YUV as RGB. The odd thing is that the correctly sized part of the image (which is obviously the luma component) is green, which means somehow the luma component is being interpreted as green. I'm guessing there is a register for setting color format that has changed with the r500 and needs to be added to the driver.

However, after taking a look at both the radeon driver source and the ATI docs that have been released, I'm rather unenlightened. I wonder if anyone familiar with the radeon driver could point me to the right place to start looking for the color format setup for overlays. Once I can find that, I might be able to to start deciphering how things work and possibly identify the problem.

I admit I'm coming at this from a position of ignorance, as I have little programming experience, but I am interested in driver development and would like to start learning a bit about it. I figure this problem seems to be relatively simple and shouldn't be to difficult to solve.

Edit: Since posting the above, I have looked further into the registers involved in the overlay. I believe that the released ATI docs are not complete in this regard, but I can find no matching register addresses between the ati docs and radeon_reg.h that have to do with overlays. How then does the overlay work at all?

[CrystalCowboy]

I also experienced a problem with XVideo on the radeon driver. The image was a lime and lavendar combo, and the image was stretched 2X in the horizontal direction. Is this what you are seeing?

The problem affected only UYVY decoding, other formats were unaffected. I was able to work-around the problem by swapping every pair of bytes and decoding as YUY2.

You don't mention anything about versions. My problem showed up in Fedora 5. The
xorg-x11-drv-ati-6.5.7.3-4 package was OK, then xorg-x11-drv-ati-6.5.8.0-1 was broken. The problem persisted in Fedora 6, which was driver version xorg-x11-drv-ati-6.6.3-1.fc6. Just this week I updated to Fedora 8 and the bug is fixed; driver xorg-x11-drv-ati-6.7.195-3.fc8.

[TechMage89]

I'm talking specifically about the overlay on r500 cards. There aren't any packaged versions with Atombios support, so my version is the latest git with the AtomBios branch.

I probably should check to see how it handles different input formats. I would still like to know how the overlay works at all though, because the registers documented in the ATI docs aren't even defined in the Radeon driver.

[bridgman]

I don't think we have released all the overlay documentation yet. We were planning to do video stuff *after* 3d although there does seem to be a lot more interest in video than we initially expected. Is the video interest mostly from "everything being on YouTube these days" or are we talking about actual movie playback, tv watching etc ?

Maybe it's time for another survey

I doubt the radeon devs have spent any time at all on overlay support yet. The main change from 4xx to 5xx was that some of the older video processing hardware built into the overlay was replaced with shader code. Using shaders gives us more flexibility and the potential for higher video quality but it also means a lot more driver work.

I think the original poster's theory is correct, that the app is feeding in one video format and expecting the overlay hardware to do the colour space conversion... which it doesn't do any more. Right now overlay and video support is on the list for *after* we get 3d info out to the developers -- I think that's still the right sequence, do you all agree ?

[Uchikoma]

"Actual" videos in various sizes, shapes, and forms ^^; I use mplayer for the majority of my video watching. Overlay is Xv.

Various res' including HD res videos. Card is an ATI x1800, or on my laptop, a mobility x1400.

[ivanovic]

Working Xv is a *must have* for me. I am using TVTime (yes, it is already ancient) and it does rely on this very feature. This is IMO currently the best and easiest program to "just watch" analog TV.

So personally for me having this work is more important than the 3D part since I would just switch over for some hours to the proprietary driver for gaming anyway.

Though probably the whole stuff on 3D acceleration takes more work than Xv, so it is better to have those specs and code examples earlier since it needs more time to have it working.

Of course I would feel best if all the specs would be released at once (and before new years eve). But probably sanitizing the specs really takes a whole lot of time, so any progress on that front is really welcome. Looks like it could be a *great* future for all the AMD/ATI users out there due to the heavy effords regarding open drivers.

[TechMage89]

Overlay is more important to me right now than 3d. 3d would be nice, but for now, if I need it, the fglrx driver can do it. It can't do Xv, at least not for me. The way I understand it, the cards through r500 ought to have mostly functioning 2d engines. I believe I heard that the everything-is-3d approach didn't start until r600. I do want to be able to watch DVDs and such on my computer, though, and Xshm is painfully slow.

The doc release does contain some registers relating to the overlay, but I'm not sure if it's complete or not. I'm more puzzled by the fact that even the D1OVL_ENABLE register is not used in the Radeon driver. Obviously the radeon driver produces something for an overlay, so why does it? I'm going to test out the overlay using different color spaces when I get the chance. Maybe if I use it with RGB video, it works properly.

If that is the case, it appears the released docs specify that the overlay can be set to ACrYCb format, so it might be possible to rejuggle say YUV video into a format it can handle and still get a measure of improvement over Xshm.

However, these two lines in the specs are puzzling:
ACrYCb 2101010 or ARGB 2101010
CbACrA or BGRA 1010102

Those are pixel formats. To what do they refer? These are both supposed to be 32 bit formats that the overlay can be set to.

[bridgman]

The way I understand it, the cards through r500 ought to have mostly functioning 2d engines. I believe I heard that the everything-is-3d approach didn't start until r600.

The transition to everything-in-3d happened in two stages -- video processing in 5xx, 2d acceleration in 6xx.

The doc release does contain some registers relating to the overlay, but I'm not sure if it's complete or not.

I would be surprised if it were complete, since we didn't even look at it (I was too busy trying to figure out what happened to LVTMA and I2C ), but it's possible.

I'm more puzzled by the fact that even the D1OVL_ENABLE register is not used in the Radeon driver. Obviously the radeon driver produces something for an overlay, so why does it? I'm going to test out the overlay using different color spaces when I get the chance. Maybe if I use it with RGB video, it works properly.

Might just be HW defaults or the BIOS code, not sure. I'll ask the devs whether they have looked at 5xx overlay -- I kinda doubt it

However, these two lines in the specs are puzzling:

ACrYCb 2101010 or ARGB 2101010
CbACrA or BGRA 1010102

Those are pixel formats. To what do they refer? These are both supposed to be 32 bit formats that the overlay can be set to.

Those are the 10-bit video modes -- rather than 8 bits for each component and 8 bits for alpha it uses 10 bits for each component and two bits for alpha.

[CrystalCowboy]

Is the video interest mostly from "everything being on YouTube these days" or are we talking about actual movie playback, tv watching etc ?

In my case, it's scientific research. We need to display streaming video from a digital camera. The camera provides teh stream in UYVY-oncoded form.

[libv]

In my case, it's scientific research. We need to display streaming video from a digital camera. The camera provides teh stream in UYVY-oncoded form.

The new overlay hardware is no longer able to display this directly.