On my rv670 AGP card it seems that commit 1a7db3fc2a0277d724d60d028064d8ef75019c28 stops the -retro xorg background from being drawn. Doesn't seem to affect anything else. Looks like what I see is whatever is in memory - which made git bisect tricky as it appeared to work OK after a good test, a complete power down was needed to make the bug reappear. Reverting commits backwards on r6xx-r7xx-support branch came up with the above as the culprit.
Can you attach your xorg log and config?
Created attachment 23475 [details] [review] Xorg.0.log
Created attachment 23476 [details] [review] xorg.conf
Do either of the following options help? Option "EXANoUploadToScreen" "TRUE" Option "EXANoDownloadFromScreen" "TRUE"
(In reply to comment #4) > Option "EXANoUploadToScreen" "TRUE" This fixes it.
Let's try the PCIE gart instead of AGP. Remove the EXA options and add this: Option "BusType" "PCIE"
(In reply to comment #6) > Let's try the PCIE gart instead of AGP. Remove the EXA options and add this: > Option "BusType" "PCIE" > Yes this fixes it. It also fixed the glitching I get that was discussed on #radeon yesterday. I notice the drm patch that fixed it for me got reverted so I double checked I was upto date on xf86-video-radeon but still get pauses without that patch.
I've disabled gart transfers on r6xx/r7xx AGP cards: c0e2513ab128ddd5be0ed626d9e31777a98983ef
(In reply to comment #8) > I've disabled gart transfers on r6xx/r7xx AGP cards: > c0e2513ab128ddd5be0ed626d9e31777a98983ef > This fixes it for ati, but the similar patch for radeonhd does not fix the same issue with that driver. It also fixes a CPU usage problem (oprofile shows native_read_tsc) with xv/x11 video that I was going to report - I don't know if people with PCIE cards will still see this.
(In reply to comment #9) > > This fixes it for ati, but the similar patch for radeonhd does not fix the same > issue with that driver. > fixed now.
(In reply to comment #10) > (In reply to comment #9) > > > > This fixes it for ati, but the similar patch for radeonhd does not fix the same > > issue with that driver. > > > > fixed now. > Not quite - DFS issues and x11 CPU usage are now fixed, but the xorg -retro background still does not render properly. It's not the same as it was. What happens now is I can reveal the correct background by moving an xterm around. Option "ExaOptimizeMigration" "off" fixes it, but is really slow.
(In reply to comment #11) > Not quite - DFS issues and x11 CPU usage are now fixed, but the xorg -retro > background still does not render properly. > > It's not the same as it was. What happens now is I can reveal the correct > background by moving an xterm around. > > Option "ExaOptimizeMigration" "off" fixes it, [...] Weird - the root weave pattern should get migrated to VRAM in one go regardless of this option... Can you get a screenshot of the corrupted background?
Created attachment 24197 [details] incorrect xorg background
(In reply to comment #12) > (In reply to comment #11) > > Option "ExaOptimizeMigration" "off" fixes it, [...] > > Weird - the root weave pattern should get migrated to VRAM in one go regardless > of this option... > > Can you get a screenshot of the corrupted background? > You are right, I've been hit by sods law, that does not fix it, I've now found that the bug doesn't always happen upon restarting X. I've just done loads of startx - quit - startx ...... and here's what I see * = good. *xxxxxxxx*x*xxxx*x*xxxx*xx*xxxx*xxxx*xxxxxx* screenshot attached.
This looks like it's still most likely a coherency problem between the pattern data getting copied to VRAM and it then being used for filling the background.
(In reply to comment #14) > I've now found > that the bug doesn't always happen upon restarting X. In light of this I've just retested the ati driver by many restarts of X and it's 100% OK - so it does seem to be just a radeonhd issue.
(In reply to comment #16) > (In reply to comment #14) > > I've now found > > that the bug doesn't always happen upon restarting X. > > In light of this I've just retested the ati driver by many restarts of X and > it's 100% OK - so it does seem to be just a radeonhd issue. Ignore that - it seems that ati is only working @ 1024x768 which is the res I normally use and have been testing both drivers at. I started at a different res tonight and the corruption is there - behaving exactly as radeonhd does.
(In reply to comment #17) > Ignore that - it seems that ati is only working @ 1024x768 which is the res I > normally use and have been testing both drivers at. Option "BusType" "PCIE" Still (appears to) fix it.
Just before I replaced my AGP card last month I couldn't reproduce this with ati, so closing. It still happened with radeonhd, but as it's finished I guess there's no point reassigning.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.