Created attachment 54314 [details] example of misrendered fonts From time to time, there is slight font corruption. However, this is not stricly limited to font rendering but also happens with GUI controls, the web page part of chromium and, for example, the LCD clock panel item in XFCE. This happens with SNA and latest xf86-video-intel from git.
Created attachment 54315 [details] misrendering in chromium
Ho hum. Looks suspiciously like I'm not flushing correctly, can you try reverting 051a18063df075536cb1ac0dc4dfc3c1306ab74e (sna: Implement a VMA cache)?
Not so easy to reproduce - I was expecting chromium to hit the issue very quickly if it was 051a1806. Can you keep your eye out for any patterns in triggering this?
Reverting 051a1806 did not help. Regarding reproducing, triggering the bug is easiest with the xfce terminal and executing something that produces a large amount of text like dmesg a couple of times. For me, the issue in chromium does not happen very often and I have no way of reliably triggering it (it only happend once when writing the bug report). However, once chromium was in the buggy state, scrolling sideways corrupted the web site pretty hard.
Are you sure it is a recent regression? Do you have a feeling when the regression may have occurred? If you could bisect it, that would speed up fixing it very quickly. :) Maybe try going back to b424b10e771b1d3d041efdd2b77f576251364744^.
I just fixed a couple of issues resulting from c295ad8da91e39c8fffa540901097651df5d24b2 (sna: Transfer the whole bo for a replacement XCopyArea) which was causing corrupt rendering in winecfg. It could well be related, so it is also worth testing current master (a02bbd87) as well.
No, master does not fix it. But it seems b424b10e771b1d3d041efdd2b77f576251364744 is indeed working, as I think this is not a very recent regression. So I will try to bisect this issue.
Well, the first bad commit is b424b10e771b1d3d041efdd2b77f576251364744. After reverting that and ece7fc8afeb8eefcf0ad1a054f02e7fac8db6327, I do not encounter the bug anymore.
I went back and rechecked the specs for the pitch restrictions, and it looks like the 16 byte check I added earlier is unnecessary if we can convince the GPU that we are only rendering to a single-stream (i.e. we've completely disabled the depth buffer). So I've undone the earlier patch and tried frobbing the depth write disable earlier during setup in the hope that solves this without breaking again.
Nope, this doesn't help. Instead it hangs my GPU quite easily when switching tabs in chromium.
Created attachment 54319 [details] i915_error_state of after the hang
I've undone the tweaking of the pitch for 915g and 945g, can you check that it is sufficient. I'll definitely look at this again in the future! Meanwhile, I am still puzzled as to how come you are using a 1x1 destination surface, as the code is meant to avoid those because it usually costs a lot more to create and render to such surfaces on the GPU than on the CPU.
The 1x1 destination would appear to be the result of XComposite, one mystery solved.
I believe this is now fixed.
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.