R600/r700 kms + 3d dri1/dri2

[Aostrich]

Hi All!
Yesterday I tried to run all recent KMS+DRI2+3D stuff on my HD4870. I took linux-2.6.31-git14, mesa master git, ati ddx master git, and libdrm 2.4.14. In general it was successful, except small "buts"...

The biggest issue I've observed is Xv... It is not tear-free with KMS. There are visible artifacts (some color lines) appear on the video in both, windowed and full-screen modes. Switching Mplayer from full-screen to windowed mode and back removes them, but in a second or two these lines appear again...

3D for me is quite OK (checked with ioqake3), except some artifacts in the bottom and rightmost 1-pixel lines. Probably this is already fixed in mesa.

Are those bugs of my setup or features for now?

[Perry3D]

Hi All!
Yesterday I tried to run all recent KMS+DRI2+3D stuff on my HD4870. I took linux-2.6.31-git14, mesa master git, ati ddx master git, and libdrm 2.4.14. In general it was successful, except small "buts"...

The biggest issue I've observed is Xv... It is not tear-free with KMS. There are visible artifacts (some color lines) appear on the video in both, windowed and full-screen modes. Switching Mplayer from full-screen to windowed mode and back removes them, but in a second or two these lines appear again...

3D for me is quite OK (checked with ioqake3), except some artifacts in the bottom and rightmost 1-pixel lines. Probably this is already fixed in mesa.

Are those bugs of my setup or features for now?

http://bugs.freedesktop.org/show_bug.cgi?id=22007

Maybe this is the right bug for you

[Aostrich]

Perry3D,

Yes, this is exactly the artifacts I see.
Do you also observe the vsync tearing?

[nanonyme]

3D for me is quite OK (checked with ioqake3), except some artifacts in the bottom and rightmost 1-pixel lines. Probably this is already fixed in mesa.

http://cgit.freedesktop.org/mesa/mes...85b8d1231aae63 Sounds similar to the bug this fixed. Try updating and comment again if it persists.

[Aostrich]

Yes, today I saw a lot of commits to Mesa which could fix such off-by-one bugs.
Will update and recheck tonight.

Anyway this bug is not as annoying as tearing in Xv...

[nanonyme]

I know... I just don't have any idea what the problem might be related to there. I don't think I'm getting artefacts with Xv myself, just a horizontal visible line (might count as tearing) in the video every now and then.

[bridgman]

I believe the non-KMS Xv driver accesses hardware directly to avoid tearing; that approach would probably not have been used in the KMS paths since one of the goals is to let X run without direct hardware access. I think there will be a discussion at XDC next week to try and standardize an approach for handling sync-to-vblank in the kernel driver.

Disclaimer - I haven't actually confirmed this by looking at code yet.

[nanonyme]

I believe the non-KMS Xv driver accesses hardware directly to avoid tearing; that approach would probably not have been used in the KMS paths since one of the goals is to let X run without direct hardware access. I think there will be a discussion at XDC next week to try and standardize an approach for handling sync-to-vblank in the kernel driver.

Well, with luck it'd be using the same vsync method as OpenGL in KMS and would Just Work with Alex's upcoming interrupt code. :3 (I'd suspect we won't be that lucky but it's among the main reasons why I don't think I'm going to even search the applicable code section before the interrupts code is done - right next to the fact that vsync probably would be way out of my league )

[lucx]

Hi,

how about some power management with kms?, my pc wyth radeon hd4870 hangs afther one hour or two, and cooler from card is very very hot!!

[agd5f]

The anti-tearing Xv stuff for r6xx/r7xx doesn't work with KMS right now. It needs support in the drm command checker similar to what we did for r1xx-r5xx.