Radeon Driver Gets Reworked Textured Video

[agd5f]

yeah, like John said, no image adjustments for r1xx. However, r1xx can now process planar formats directly rather than swizzling them to packed first, so you should see lower cpu utilization for planar formats.

[duby229]

yeah, like John said, no image adjustments for r1xx. However, r1xx can now process planar formats directly rather than swizzling them to packed first, so you should see lower cpu utilization for planar formats.

OK, just for clarification (and the sanity of my mind) what does "swizzling them to packed" mean?

Oh and thanks for taking the time.

[bridgman]

Packed video formats have all the colour components together in the same buffer, while planar formats have the video components split into two or three different buffers, usually 1 buffer for Y (luminance) then either a buffer for each of Cb and Cr or one buffer containing Cb and Cr interleaved together.

Packed formats are easier for the hardware to process (since one memory read gets you a complete pixel) but planar formats are a better fit for the most common kinds of data compression used with video (eg having only 1/4 as many colour samples as luminance samples).

I believe the previous shader code required packed format, so the CPU had to re-arrange the pixels before feeding to the GPU, while the new shader code can directly read from the 2 or 3 different buffers and combine the components in the shader.

[duby229]

OK, so it means converting a planar format to a packed format for the shaders to process?

[agd5f]

OK, so it means converting a planar format to a packed format for the shaders to process?

For more information on YUV formats see:
http://www.fourcc.org/

The r1xx-r5xx texture hardware can do YUV->RGB conversion natively, however, the conversion is from packed YUV to RGB. Prior to these commits were were using this feature for textured video on r1xx-r5xx chips. So if the native YUV pixel format was planar YUV, we previously had to convert to packed YUV in software before doing the colorspace conversion.

r2xx and newer chips have pixel shaders where we can do the YUV to RGB conversion using a shader. Doing it in a shader allows us to define the YUV->RGB algorithm and thus we can tweak things like brightness and contrast. It also allows us to process planar and packed YUV formats directly without the need to convert to packed. So for r2xx-r7xx we do the YUV->RGB conversion in a shader. r6xx and r7xx have no native YUV->RGB conversion in the texture blocks, so our only choice is to use a shader.

Back to r1xx; the r1xx texture combiners don't have the flexibility of later pixel shaders, so it's not possible to do the YUV->RGB conversion in a shader. However, r1xx chips have a built in support for planar formats in the texture blocks, we were just not taking advantage of it previously. With the latest changes, it is now used, so you should see lower CPU utilization when playing back planar formats since there is no longer a need to convert to packed.

[audi100quattro]

Is there any way textured video will work beyond the 2048th pixel on my R300 dual monitor setup? I'm using the latest git 2d driver and things seem stable..

[agd5f]

Is there any way textured video will work beyond the 2048th pixel on my R300 dual monitor setup? I'm using the latest git 2d driver and things seem stable..

It should work up to 2560 pixels as long as the source material is <= 2048 pixels, but it won't work beyond that until the xserver is updated to split up the root pixmap into separate per-crtc buffers rather than using one big one for the entire desktop. See ajax' shatter proposal.

[whatever]

I'm using a Radeon 9700 on ubuntu 9.04 and just compiled the latest xf86-video-ati driver from git. The new driver makes the whole system freeze after some seconds of using/accessing the new textured video adapter. It happened with tvtime, mplayer and even when only gxvattr was running (no video playing).
A downgrade back to 6.12.1 "solved" the problem.

Another problem that bothers me:
tvtime's overscan feature seems to be using some special xv-stuff. With overlay it works fine, but with the "old" textured-video adapter it is completely unusable (garbage added on top of picture, no cropping on the left side). With the new one it is slightly better (no cropping on top, no cropping on left side, but no garbage either). Are there any chances this will be fixed someday? Of course the freezing thing is more important to fix atm.

[agd5f]

I'm using a Radeon 9700 on ubuntu 9.04 and just compiled the latest xf86-video-ati driver from git. The new driver makes the whole system freeze after some seconds of using/accessing the new textured video adapter. It happened with tvtime, mplayer and even when only gxvattr was running (no video playing).
A downgrade back to 6.12.1 "solved" the problem.

Another problem that bothers me:
tvtime's overscan feature seems to be using some special xv-stuff. With overlay it works fine, but with the "old" textured-video adapter it is completely unusable (garbage added on top of picture, no cropping on the left side). With the new one it is slightly better (no cropping on top, no cropping on left side, but no garbage either). Are there any chances this will be fixed someday? Of course the freezing thing is more important to fix atm.

Can you try again with the latest tex vid commit I just made (b6febf7368d3df3f1d3fee6a87aa71c54e77cdcc)? If you are still having problems, can you git bisect to find the problematic commit?

[whatever]

Both issues have disappeared in the current version. Thank You!