Created attachment 92240
Text with errors
Recently I'm noticing somewhat more 'weird' behavior - it might be
related to my temporal usage of night releases of Mozilla (since rawhide
version got somewhat broken)
What is weird in this image is - the text was badly rendered AND it
remained visible
I've not yet tested patch from comment 165 - but with regards to Firefox
and Cairo - I'm also seeing errors in i.e. pidgin - where status icons
looks occasionally damaged.
And my rawhide has these related packages:
cairo-1.13.1-0.1.git337ab1f.fc21.x86_64
ok - while doing a very quick light check - at least on Firefox input
window I do not observe any rendering bugs (which have been pretty
simple to reach before).
(Lenovo T61 + git + patch from comment 168)
Thought the performance decrease is noticeable and also the setting for
MAX_FLUSH...
Update after some new commits:
4c7b183fd21b461f9f18662c3b9d9732b6bef13d + Always patch - now gives me
broken text lines in Thunderbird window.
And it's now enough just to move the mouse over text and the text is
changing and actually never renders correctly some letters.
Checking back
Ok - seem(In reply to comment #170)
Created attachment 92288 [details]
bug
f23ab963c4f4ada2051588dfc85264aa2798dbf7 + that patch and I'm seeing
corruption. Using google-chrome and letters in url bar or window title bar
sometimes get corrupted and then get fixed.
Also seeing the problem
(In reply to comment #160)
Typical, it appeared stable through my firefox testing, but if you try
reverting b7565a26401e283df94b68019e8093f8104428f4, I expect the corruptions
to disappear again.
Yep - correct revert of this commit make MAX_VERTEX 1 again producing
correct rendering - even
(In reply to comment #160)
Typical, it appeared stable through my firefox testing, but if you try
reverting b7565a26401e283df94b68019e8093f8104428f4, I expect the corruptions
to disappear again.
Yep - correct revert of this commit make MAX_VERTEX 1 again producing
correct rendering - even
I think nice illustration could be - that while before with MAX 9 it
seemed like i.e. gnome-terminal running top was not really rendering
broken characters - it now seems to show a lot of messed characters.
On the other hand - MAX 1 seems to be now more fluent then before - so
except for some
(In reply to comment #153)
(In reply to comment #145)
Created attachment 91383 [details]
gedit in openbox with 2.99.907 GM45 SNA
I am finding that GM45 SNA seems unusable with 2.99.907 - git bisect pointed
to the bad commit as:
9289e2c56b7f0cc78c5123691ad96611f0e04bed is the first
Created attachment 91613
Grabbed snapshot with patch from comment 157
As could be seen - yes - with little effort I'm able to capture broken
characters with given patch compiled in.
The only needed thing is to start to edit the dialog in the Firefox and
start to add/remove random characters over
bad news - now I'm in fact able to spot badly rendered characters in
Firefox also with MAX 1
So something went wrong
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to xserver-xorg-video-intel in Ubuntu.
I think I've a sort of positive message here
at least on my T61 - now using upstream git commit
8f340f90f4b2f269d6308d0bd31fbc2a5f579608
I'm no longer observing corruptions while scrolling Firefox pages.
So some recent commit is probably behind this change.
Before I've used 14 days older commit
(In reply to comment #78)
No hope to solve this and many, many other bugs on gen4 - here and in mesa.
I suggest to buy new laptop because it doesn't have any sense. Some time ago
I also thought that it has. Now I have Intel Ivybridge and Nvidia through
Bumblebee and both runs almost perfect
(In reply to comment #74)
I think I've a sort of positive message here
at least on my T61 - now using upstream git commit
8f340f90f4b2f269d6308d0bd31fbc2a5f579608
I'm no longer observing corruptions while scrolling Firefox pages.
So some recent commit is probably behind this change.
(In reply to comment #92)
Removed an older hack and had to reduce the max further. Bah, humbugs.
OK, this time I'm definitely not able to reproduce the issue so far.
Maybe it will some extra time - hard to say now - but before it has took me
just minutes to get the issue visible.
intel_gpu_top
From what I'm experiencing after driver rebuild - I'd have said - now
it's actually much simpler to trigger that flickering/high GPU usage.
So unless the patch is missing something - than limitation to 16 doesn't
help here on T61.
--
You received this bug notification because you are a member
And with 12 - flickering starts to appear as well.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to xserver-xorg-video-intel in Ubuntu.
https://bugs.launchpad.net/bugs/1098489
Title:
[gen4] Corruption in Chrome omni bar results using
I'm doing some experiments with MAX_FLUSH_VERTICES.
When set to 64 - even gnome-terminal starts so show weird pixels in some
cases.
Now I'm just playing with value 12 (gives ~2.1Mchars/s) and I'm hunting
for visual problems.
--
You received this bug notification because you are a member of
(In reply to comment #96)
(In reply to comment #93)
The bad part is - while before I've been getting 3.7Mchar/s in x11perf
-aa10text - now it's like 1.3Mchar/s so significantly slower.
That's the sacrifice, we have to stop sending commands to the GPU and wait
for it complete those in
Well I should wait a while before posting a comment about magic value 6.
I'm now observing flickering with value 6 as well.
So yeah - it's more or less time related - and it takes more or less
time until the problem becomes visible.
Also is there explanation with the max value 64 starts to
(In reply to comment #107)
The quick answer is that if ever see it with MAX_FLUSH_VERTICES set to 1,
then it is a different issue. Please do be aware that all current kernels
since 3.7 do have a coherency issue, the fix will not arrive before 3.10.1
(outside of drm-intel trees).
Could you
I've been looking at drm-intel-next-queued/drm-intel-fixes - there are
quite a few patches - but also a lot of reverts recently - so I'm
pretty much confused what is actually the solution for gma965 in T61.
--
You received this bug notification because you are a member of Desktop
Packages,
Well I could add here output of some tests:
i.e.:
$ ./render-composite-solid
Opened connection to :0 for testing.
Testing setting of single pixels (root): passed [1 iterations x 4096]
Testing area sets (root): passed [1 iterations x 4096]
Testing area fills (root): passed [1 iterations x 4096]
Well here is just another one -
$ ./basic-copyarea
Opened connection to :0 for testing.
Testing setting of single pixels (root): passed [1 iterations x 4096]
Testing area sets (root): passed [1 iterations x 4096]
Testing area fills (root, using pixmap source): passed [1 iterations x 4096]
Testing
Hmm - after doing some more experiments - the high load on GPU seems
to be pretty much the thing which make the problem visible.
Another interesting thing is - it's usually enough to just 'reload' the
very same page in Firefox and the load goes down to ~1% and everything
is ok.
Also the kernel
Created attachment 82127
Scroll with intel_gpu_top
I've captured video when problem appears and when doesn't
(Attaching only frame)
Using some past kernel 3.10 b2c311075db578f1433d9b303698491bfa21279a
(as of now - current vanilla)
Using current xf86 tree 5aaab9ea0310d48bb1a1ca20308d1c9721a9de3f
Created attachment 82118
Video capture showing flicker on firefox scroll
I've captured at 25FPS some example how the pictures are flickering when
i.e. Firefox windows is being scrolled up/down. In most cases, the
pictures is visible normally when scrolling stops, but in rare case the
picture
Created attachment 82128
Scroll with intel_gpu_top and no problems
Quite the same system - except the problem was not visible (restarted X
session).
As could be seen - now during scrolling the GPU has been basically unloaded.
Nothing else the Firefox scroll has been basically done.
I should
(In reply to comment #84)
Yes, that is characteristic of this bug. The internal vertex/texture
coordinates that are being passed along the GPU pipeline become corrupt (it
looks like we overflow a small ring buffer). The only effective approach
If it would be plain 'overflow' - than I'd be
I think nice illustration could be - that while before with MAX 9 it
seemed like i.e. gnome-terminal running top was not really rendering
broken characters - it now seems to show a lot of messed characters.
On the other hand - MAX 1 seems to be now more fluent then before - so
except for some
(In reply to comment #153)
(In reply to comment #145)
Created attachment 91383 [details]
gedit in openbox with 2.99.907 GM45 SNA
I am finding that GM45 SNA seems unusable with 2.99.907 - git bisect pointed
to the bad commit as:
9289e2c56b7f0cc78c5123691ad96611f0e04bed is the first
Maybe this bug could be more easily tracked down when the amount of
vertices is actually much higher - since in this case it seems to crash
almost immediatelly.
I understand there is some 'maximum queue' size GPU could handle - but
the engine should be able to track size of all commands and not
Just to add some more comment on MAX_FLUSH_VERTICES - when set to valu
96 - it gives the highest throughput on x11perf -aa10text 3.7MChar/s -
using any higher value doesn't make any different (so the max seems to
be somewhere between 64-96]
Also when this 3.7MChar is rendered - the parallel
(In reply to comment #99)
(In reply to comment #97)
(In reply to comment #96)
(In reply to comment #93)
The bad part is - while before I've been getting 3.7Mchar/s in x11perf
-aa10text - now it's like 1.3Mchar/s so significantly slower.
But as I said before - if that would be
Well I'm curious how this explains this - I've taken current git -
changed the value to '44' - and I'm typing this text. I could see a lot of
errors during text typing - but these errors seems to be somehow limited only
to certain regions of shown text.
It's not destroyed everywhere - only in
It could be probably worth to mention - that when I'm flipping between
Firefox tabs I could have scrolling tabs without any issue (and low GPU
usage), while flipping to other tabs and scrolling in them increases GPU
to high levels and visual problems are present.
So in the moment the problem
(In reply to comment #105)
Created attachment 82227 [details]
Snapshot on the issue on characters
Yep - that's exactly what I easily observe with gnome-terminal when I increase
max triangles from recent Chris patches to 64 - this is present almost all the
time. And it's very occasional
bad news - now I'm in fact able to spot badly rendered characters in
Firefox also with MAX 1
So something went wrong
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to xserver-xorg-video-intel in Ubuntu.
Maybe this bug could be more easily tracked down when the amount of
vertices is actually much higher - since in this case it seems to crash
almost immediatelly.
I understand there is some 'maximum queue' size GPU could handle - but
the engine should be able to track size of all commands and not
Well I'm curious how this explains this - I've taken current git -
changed the value to '44' - and I'm typing this text. I could see a lot of
errors during text typing - but these errors seems to be somehow limited only
to certain regions of shown text.
It's not destroyed everywhere - only in
(In reply to comment #136)
The issue that the VUE (which is a memory slot used by the GPU for a vertex
entry) are reused by a second thread before the first thread is complete,
causing the first thread to generate invalid texture coordinates and corrupt
rendering. That is a hardware read-write
Just to add some more comment on MAX_FLUSH_VERTICES - when set to valu
96 - it gives the highest throughput on x11perf -aa10text 3.7MChar/s -
using any higher value doesn't make any different (so the max seems to
be somewhere between 64-96]
Also when this 3.7MChar is rendered - the parallel
Well here is just another one -
$ ./basic-copyarea
Opened connection to :0 for testing.
Testing setting of single pixels (root): passed [1 iterations x 4096]
Testing area sets (root): passed [1 iterations x 4096]
Testing area fills (root, using pixmap source): passed [1 iterations x 4096]
Testing
Well I could add here output of some tests:
i.e.:
$ ./render-composite-solid
Opened connection to :0 for testing.
Testing setting of single pixels (root): passed [1 iterations x 4096]
Testing area sets (root): passed [1 iterations x 4096]
Testing area fills (root): passed [1 iterations x 4096]
I've been looking at drm-intel-next-queued/drm-intel-fixes - there are
quite a few patches - but also a lot of reverts recently - so I'm
pretty much confused what is actually the solution for gma965 in T61.
--
You received this bug notification because you are a member of Desktop
Packages,
Created attachment 82118
Video capture showing flicker on firefox scroll
I've captured at 25FPS some example how the pictures are flickering when
i.e. Firefox windows is being scrolled up/down. In most cases, the
pictures is visible normally when scrolling stops, but in rare case the
picture
Created attachment 82127
Scroll with intel_gpu_top
I've captured video when problem appears and when doesn't
(Attaching only frame)
Using some past kernel 3.10 b2c311075db578f1433d9b303698491bfa21279a
(as of now - current vanilla)
Using current xf86 tree 5aaab9ea0310d48bb1a1ca20308d1c9721a9de3f
(In reply to comment #84)
Yes, that is characteristic of this bug. The internal vertex/texture
coordinates that are being passed along the GPU pipeline become corrupt (it
looks like we overflow a small ring buffer). The only effective approach
If it would be plain 'overflow' - than I'd be
It could be probably worth to mention - that when I'm flipping between
Firefox tabs I could have scrolling tabs without any issue (and low GPU
usage), while flipping to other tabs and scrolling in them increases GPU
to high levels and visual problems are present.
So in the moment the problem
(In reply to comment #96)
(In reply to comment #93)
The bad part is - while before I've been getting 3.7Mchar/s in x11perf
-aa10text - now it's like 1.3Mchar/s so significantly slower.
That's the sacrifice, we have to stop sending commands to the GPU and wait
for it complete those in
From what I'm experiencing after driver rebuild - I'd have said - now
it's actually much simpler to trigger that flickering/high GPU usage.
So unless the patch is missing something - than limitation to 16 doesn't
help here on T61.
--
You received this bug notification because you are a member
(In reply to comment #92)
Removed an older hack and had to reduce the max further. Bah, humbugs.
OK, this time I'm definitely not able to reproduce the issue so far.
Maybe it will some extra time - hard to say now - but before it has took me
just minutes to get the issue visible.
intel_gpu_top
Created attachment 82128
Scroll with intel_gpu_top and no problems
Quite the same system - except the problem was not visible (restarted X
session).
As could be seen - now during scrolling the GPU has been basically unloaded.
Nothing else the Firefox scroll has been basically done.
I should
Hmm - after doing some more experiments - the high load on GPU seems
to be pretty much the thing which make the problem visible.
Another interesting thing is - it's usually enough to just 'reload' the
very same page in Firefox and the load goes down to ~1% and everything
is ok.
Also the kernel
(In reply to comment #99)
(In reply to comment #97)
(In reply to comment #96)
(In reply to comment #93)
The bad part is - while before I've been getting 3.7Mchar/s in x11perf
-aa10text - now it's like 1.3Mchar/s so significantly slower.
But as I said before - if that would be
And with 12 - flickering starts to appear as well.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to xserver-xorg-video-intel in Ubuntu.
https://bugs.launchpad.net/bugs/1098334
Title:
[gen4 sna] Font corruption in Chromium tab bar
(In reply to comment #105)
Created attachment 82227 [details]
Snapshot on the issue on characters
Yep - that's exactly what I easily observe with gnome-terminal when I increase
max triangles from recent Chris patches to 64 - this is present almost all the
time. And it's very occasional
I'm doing some experiments with MAX_FLUSH_VERTICES.
When set to 64 - even gnome-terminal starts so show weird pixels in some
cases.
Now I'm just playing with value 12 (gives ~2.1Mchars/s) and I'm hunting
for visual problems.
--
You received this bug notification because you are a member of
(In reply to comment #107)
The quick answer is that if ever see it with MAX_FLUSH_VERTICES set to 1,
then it is a different issue. Please do be aware that all current kernels
since 3.7 do have a coherency issue, the fix will not arrive before 3.10.1
(outside of drm-intel trees).
Could you
Well I should wait a while before posting a comment about magic value 6.
I'm now observing flickering with value 6 as well.
So yeah - it's more or less time related - and it takes more or less
time until the problem becomes visible.
Also is there explanation with the max value 64 starts to
(In reply to comment #78)
No hope to solve this and many, many other bugs on gen4 - here and in mesa.
I suggest to buy new laptop because it doesn't have any sense. Some time ago
I also thought that it has. Now I have Intel Ivybridge and Nvidia through
Bumblebee and both runs almost perfect
(In reply to comment #74)
I think I've a sort of positive message here
at least on my T61 - now using upstream git commit
8f340f90f4b2f269d6308d0bd31fbc2a5f579608
I'm no longer observing corruptions while scrolling Firefox pages.
So some recent commit is probably behind this change.
I think I've a sort of positive message here
at least on my T61 - now using upstream git commit
8f340f90f4b2f269d6308d0bd31fbc2a5f579608
I'm no longer observing corruptions while scrolling Firefox pages.
So some recent commit is probably behind this change.
Before I've used 14 days older commit
63 matches
Mail list logo
