git sources from Dec04 on: Mesa, Xorg-server, xf86-video-ati; using -9999 packages from x11 and ixit(mesa) gentoo overlays on Sabayon. 

DRI3 enabled, Modesetting DDX, acceleration glamor
Desktop compositing enabled; kwin5; vsync with 'full screen redraw'. I found no difference in other modes. 
Hardware Acceleration enabled in chrome by default; disabling causes 2d tearing in all aspects of chrome use regardless, and massive cpu usage for h264 decoding as expected.

3d rendering works well, on-par performancewise with radeon ddx in DRI3
2d rendering works well, similarly on-par. 

Video playback with Netflix however, starts off a chain of events ending in a very weird effect of historical frame skipping back about a second, then skipping forward again. 

Playback on primary display works well, for a time. Dragging window via alt-mouse to the other display immediately starts a stuttering effect felt xserver wide.

The video playback drops to perhaps 1 frame every 3-4 seconds; at the point that the frame updates, a 'back in time' aspect was realized in kwin to repaint instances of every x-client window occurring 1-3 seconds in the past. 

Typing in hexchat for example would be a series of:

start typing and entering text at about 50wpm. 
see 14 characters vanish
see no updates for a second
see new text, typing normally for a short while
see last 10 chars vanish, at a newer point in time than the last vanishing segment; likely timed with the point-in-time that the video frame updated last, but this is just a theory not proven without taking a 60fps video and looking very closely. I can take one soon if you'd like. 

Switching to DRI2 does not make a good difference; infact, immediately after loading Chrome the same stuttering effect occurs, with moderately lesser effect, maybe one skip every couple seconds, lasting a very short while, instead of the massive second-long judders when playing back a video. 

The only "winning" combination so far, for latency in frame output (as detailed by the kwin fps meter effect) Radeon DDX; DRI3; Full scene repaints in Kwin for vsync;  until tearfree has page flipping, its not going to work well enough for fluid desktop use. It also doesn't sync any in-window 2d drawing like kwin full-screen redraw. 

Of other note, Chrome does appear to drop out of HW decode into CPU decode at regular points, which causes a noticeable increase in frame latency spikes, and corresponding CPU usage. This causes video stutter, whereas full HW decode is nearly liquid smooth, perhaps 1 jitter in the course of 5-10 seconds down to 30 fps and then right back to 60fps and smooth for another 5-10 seconds. This is acceptable to me, although not 100% ideal.  I don't know if its related and likely should be a different bugreport against Chrome.

Please let me know what further information you would like. 

Mike