agd5f

Today I grabbed Dave’s r500test mesa tree and added a few fixes and the rest of the r5xx PCI ids.  I’ve pushed the code up the mesa tree on the r500-support branch.  So everyone that wants to play with r500 DRI support should go there.  Additionally, we hope to fix up the remaining issues on RS chips (RS4xx and RS6xx).  So what’s left to do:

- Lots of cleanup
- Rasterizer setup needs work
- Fragment shader support for r5xx
- Implement new and exciting features

To test you need a recent version of radeon and drm from git or my drm r345-cleanup branch. radeonhd users can try the experimental radeonhd DRI support here.

 UPDATE: I’ve pushed this to drm master.

The radeon drm did not do the right thing in all cases for r3xx based chips since it was initially reverse engineered.  I’ve gone through and started fixing up the deltas between r1/2xx and r3/4/5xx.  Users with IGP chips should test as well (especially RS4xx XPRESS chips).  If you had an XPRESS chip that used to lock immediately when the DRI was enabled, please test.  Note that some XPRESS chips default to DRI=false for just this reason.  If you have one of these chips, please try this branch and set: Option "DRI" "TRUE" in the device section of your xorg.conf.

The code is on the r345-cleanup branch of my drm tree:

http://gitweb.freedesktop.org/?p=users/agd5f/drm.git;a=summary

I’ve just committed code to hopefully fix some of the remaining issues with RS4xx (XPRESS chips). If you have an XPRESS chip and have problems with dualhead, or display corruption, or DVI, please test the latest code in ati git master!

As some of you have probably heard, I’ve been working on adding full support for EXA composite for R3xx-R5xx cards. Well, as of last night, it lives. R3xx/R4xx support is pretty solid although there are some blend combinations that still need to be debugged. RS690 works, but only after running a 3D app like gears first. R5xx support works on some chips, but not on others, probably along the same lines as textured video. I think both may be related to the number of raster pipes that should be enabled for each chip. I haven’t merged it into master yet, but you can grab it from the r3xx-render branch of xf86-video-ati. To check it out:

git clone git://anongit.freedesktop.org/git/xorg/driver/xf86-video-ati
cd xf86-video-ati
git checkout -b r3xx-render origin/r3xx-render


Update: The new render code has been merged to ati git master.

DCE 3.0 (Display Control Engine version 3.0) is the new display controller in the latest radeons from AMD. This includes the HD3600/HD3400 series cards (RV620/RV635) and the RS780. The analog functionality (DACs) is largely unchanged however the digital portion has been completely revamped to support a variety of digital outputs including DisplayPort. Previous chips generally had fixed function encoder/transmitter blocks (LVTMA is an exception) for specific output types (LVDS or TMDS). On the new chips, there are now multi-purpose digital encoders and transmitters. The encoders and transmitters can be configured to support any digital output type that is required. Support for DCE 3.0 cards is available in both the radeon and radeonhd drivers.

You’ve probably seen that the radeon driver recently got support for textured video. This basically exposes an Xv adapter using the 3D texture engine for rendering. Textured video has some advantages over traditional overlays. These include:

- multiple ports (display more than one video at a time)

- no crtc limitations (videos can span multiple heads)

- works with composite (wobbly videos or rotated screens)

The video pipeline has two basic parts: decoding and rendering. I’ll just cover the rendering as that is what it relevant here. For rendering with Xv you have a decoded buffer of YUV data. In order to display on the screen the data needs to be converted to RGB and scaled to fit the size of the drawable. With an overlay, the overlay hardware does the YUV to RGB conversion and scaling, then the data is “overlaid” with the graphics data during scan out. The converted data is never actually written to a buffer. This is what makes the overlay incompatible with composite.

Using the texture engine, we treat the YUV data as a texture. The radeon texture engine has native support for YUV texture and YUV to RGB conversion. This is what we use. On hardware without YUV textures, the color space conversion can be done with a fragment shader program. Now that we have the YUV data as a texture, we render a quad and apply the texture to it. The texture is scaled based on the size of the quad rendered. All of this happens in radeon_textured_videofuncs.c.

RADEONInit3DEngine() sets up the common state required for 3D operations. Next we set up the texture and the surface info for the destination of the 3D engine. This could be the desktop or an offscreen pixmap. We choose the appropriate texture format based on the YUV format and enable YUV to RGB conversion in the texture engine. On r3xx, r4xx, and r5xx chips we load a small vertex program to setup the vertexes and a small fragment program to load the texture. On older chips the pipeline is fixed so the setup is not as complex. Finally we iterate across the clipping regions of the video and draw the quads for the exposed regions of the video. We send four vertexes, one for each corner of each box in the clipping region. Each vertex consists of four coordinates, two for position (X, Y) and two texture coordinates (S, T). The position defines the location on the destination surface for that vertex. The texture coordinates specify the location within the texture that corresponds to that vertex. Think of a texture as a stamp with a width and a height. When a texture is applied to a primitive, you need to specify what portion of the texture is applied. Textures are considered to have a width and height of 1; as such your S and T coordinates are proportions rather than raw coordinates.

At the end you’ve drawn a video frame using the texture engine.

EXA composite support uses the same principles, only it adds blends (blending texture data with data in the destination buffer — translucent windows) and coordinate transforms (changing the X,Y coordinates of the primitive to transform the object — this is how rotation is done).

I just committed support for textured video on radeon r1xx-r4xx.  r5xx is similar and will be supported soon, once the new fragment shader is sorted out.

Textured video uses the texture engine to display content and perform colorspace conversion.  It’s also composite friendly.

It’s finally here:

http://www.x.org/docs/AMD/R5xx_Acceleration_v1.1.pdf

The reason it took so long to get documentation out for 3D was that we didn’t have a full 3D programming guide available. Part of what I did over the last month or so was to compile this guide from the various information that was available. For those that are familiar with the current r300 3D driver, this guide should answer a lot of questions. If you have any technical development questions that are not answered in the released documentation, please ask at gpudriverdevsupport@amd.com.

Next up is TCORE which we will be releasing soon. TCORE provides sample code for chip initialization, command queue setup, and basic memory management.

xf86-video-ati 6.8.0 is out!  All of the sub-drivers (mach64, r128, and radeon) have been ported to libpciaccess and George cleaned up the ati wrapper so each driver is completely stand-alone now.

Major changes:

- - mach64, r128, radeon ported to libpciaccess
- - massive restructuring of ati wrapper
- - radeon support for r5xx, rs6xx, and r6xx chips using ATOMBIOS
- - return of zaphod mode support
- - radeon support for centered modes using scalers (selectable via output attributes)
- - PAL tv-out fixed on supported chips
- - initial support for render accel on r3xx/r4xx chips (rotation)
- - fix TV option handling
- - Xv RGB fixes
- - XPRESS Xv fixes
- - improve bios/driver interaction on radeon
- - revert back to previous AGP mode behavior
- - lots of bug fixes

I finally added support for “center” mode when using RMX for panel scaling. use xrandr to toggle the rmx mode.

full expansion: xrandr --output LVDS --set scaler full

center mode: xrandr --output LVDS --set scaler center

turn off rmx: xrandr --output LVDS --set scaler off

Applies to DVI too.