Created attachment 45301 [details] Artifacts under Gnome Shell gnome-shell from git clutter-1.6 (git) kernel-2.6.38.2-11.fc15.x86_64 Mesa versions: $ rpm -qa | grep mesa mesa-dri-drivers-dri1-7.11-0.5.20110401.0.fc14.x86_64 mesa-libEGL-7.11-0.5.20110401.0.fc14.x86_64 mesa-dri-llvmcore-7.11-0.5.20110401.0.fc14.x86_64 mesa-libEGL-devel-7.11-0.5.20110401.0.fc14.x86_64 mesa-dri-drivers-7.11-0.5.20110401.0.fc14.x86_64 mesa-libOSMesa-devel-7.11-0.5.20110401.0.fc14.x86_64 mesa-libOSMesa-7.11-0.5.20110401.0.fc14.x86_64 mesa-libGLU-devel-7.11-0.5.20110401.0.fc14.x86_64 mesa-dri-filesystem-7.11-0.5.20110401.0.fc14.x86_64 mesa-libGLES-devel-7.11-0.5.20110401.0.fc14.x86_64 mesa-libGL-7.11-0.5.20110401.0.fc14.x86_64 mesa-libGL-devel-7.11-0.5.20110401.0.fc14.x86_64 mesa-libGLU-7.11-0.5.20110401.0.fc14.x86_64 mesa-libGLES-7.11-0.5.20110401.0.fc14.x86_64 $ lspci 01:05.0 VGA compatible controller: ATI Technologies Inc Radeon Xpress 1250
Are you using r300c or r300g? Please attach the output of glxinfo.
Created attachment 45316 [details] glxinfo
You are using the gallium driver.
Created attachment 45494 [details] glxinfo output Same happens to me, lspci output is: 01:05.0 VGA compatible controller: ATI Technologies Inc Radeon Xpress 1250 hardware is Dell Latitude XT.
Same artifacts here. x1250 (Gallium-Driver) on Samsung R60
Looks like this font issue can be triggered (at least for me) by http://wiki.clutter-project.org/wiki/File:COGLBasicsExample.zip , so the problem might be clutter/cogl-related. Also, relationship with 'font glitches' from https://bugs.freedesktop.org/show_bug.cgi?id=29139 is possible.
It looks like only the very thin characters misrender. Unfortunately, I don't have RS600.
(In reply to comment #7) > It looks like only the very thin characters misrender. I'm not sure whether this is width-related; I see misrenderd also 'S', 'v', '2', and some others, and I believe (but unfortunately I don't have a screenshot) that under some circumstances, the set of affected glyphs changes. > > Unfortunately, I don't have RS600. If it will be of some use, I can test patches, do some basic debugging, or provide remote access to RS600 machine.
Created attachment 46709 [details] [review] R300 texture alignment partial fix As Marek stated, this issue is related to texture alignment. After playing with mesa/src/gallium/drivers/r300/r300_texture_desc.c (see attached patch), I was able to get things rendering properly -- font issue disappeared with setting 'height' alignment of 8bpp textures to '2' and misrendered artifacts on some round edges with 32bpp textures and 'height' alignment to 2. Patch contains only values I needed to fix -- I guess there is some relation between parts of array I've been modifying. Unfortunately, this patch causes, that some (random) of GNOME 3's popup windows are being rendered improperly -- their content looks like portions of other textures (e.g. desktop background, icons, ...; random parts of vram), with no apparent relation to expected content.
RS600/RS690/RS740 require 64 bit texture pitch alignment, perhaps the tile alignment needs some adjustment as well.
*64 byte
I'm sorry, I was talking about tile alignment whole time, the modified function was r300_get_pixel_alignment, which definitely returns "tile" . Sorry for confusion.
After more thorough testing, it seems that r300 driver is not able to correctly create surfaces of certain dimensions; random vram content is shown instead. Also, it doesn't seem to change, despite of application changing contents of its window. I tried some more changes in the alignment table (like multiplying related alignments by two), but it had only negative effect.
Created attachment 46752 [details] [review] little experiment (In reply to comment #13) > After more thorough testing, it seems that r300 driver is not able to correctly > create surfaces of certain dimensions; random vram content is shown instead. Not true. The r300 driver gets it right for all the other GPUs, it's just rs6xx that is broken. Please try the attached patch.
(In reply to comment #14) > Created an attachment (id=46752) [details] > little experiment > > (In reply to comment #13) > > After more thorough testing, it seems that r300 driver is not able to correctly > > create surfaces of certain dimensions; random vram content is shown instead. > > Not true. The r300 driver gets it right for all the other GPUs, it's just rs6xx > that is broken. Sorry, I was generalizing too much; for me it's always in rs600 context. > > Please try the attached patch. I tried this patch; unfortunately it just reverted the old behavior -- problem with certain surface sizes was gone, but problem with texture alignment returned for both 8bpp and 32bpp textures. I did not notice any other differences. If you will have any other ideas/patches, I'll gladly test them; but I can't do much here by myself.
Nope, I've run out of ideas and I don't have the GPU. (Milan, are you near Brno by any chance?)
(In reply to comment #16) > Nope, I've run out of ideas and I don't have the GPU. > > (Milan, are you near Brno by any chance?) I'll contact you by e-mail and we'll see whether we can arrange a meeting.
so any idea?
After testing r300g driver (both with and withoug alignment fix) with different values for ColorTiling option, the results seems to be unaffected -- no matter whether the ColorTiling is enabled or disabled, I still get the original behavior (only affected by patch to alignment table).
The ColorTiling option only affects the buffers allocated by the DDX, which is usually just the window framebuffer. The textures and private framebuffers allocated by r300g are usually tiled regardless of the ColorTiling option. Setting this environment variable disables tiling in r300g: RADEON_DEBUG=notiling It must be set such that the Gnome Shell can see it, of course.
(In reply to comment #20) > Setting this environment variable disables tiling in r300g: > > RADEON_DEBUG=notiling > > It must be set such that the Gnome Shell can see it, of course. I tested gnome-shell with it; when using alignment table patches (Xorg's ColorTiling was always false), there was no change. However, when I reverted to original r300_texture_desc.c, things seem to work more-or-less correctly -- 8bpp textures seem to render fine (there's one case when I'm not sure), however, small 32bpp textures still render incorrectly.
(In reply to comment #21) > I tested gnome-shell with it; when using alignment table patches (Xorg's > ColorTiling was always false), there was no change. However, when I reverted to > original r300_texture_desc.c, things seem to work more-or-less correctly -- > 8bpp textures seem to render fine (there's one case when I'm not sure), > however, small 32bpp textures still render incorrectly. UPDATE: looks like some fonts are not rendered properly either, but I can't justify whether they are rendered into 8bpp or 32bpp textures.
Is it still a issue with current mesa and kernel ?
From the image it seems like the same rendering issue I am having: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/751828 My graphics card is ATI Radeon Xpress 1250 $ glxinfo | grep -i opengl OpenGL vendor string: X.Org R300 Project OpenGL renderer string: Gallium 0.4 on ATI RS600 OpenGL version string: 2.1 Mesa 9.1.1 OpenGL shading language version string: 1.20
Created attachment 78575 [details] Same(?) text rendering issues as original reporter had
Affects me as well, OpenSuse 12.3 - Tumbleweed (kernel 3.7-3.11); for my report and details (Samsung R60, hardly any different from people here) see http://phoronix.com/forums/showthread.php?89174-Radeon-Gnome-3-AMD-Xpress-1250-%28Samsung-R60%29-Driver-Glitches&p=374780 Also see https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/751828 Affects a LOT of people. :((( I dump importance to medium-major, because its really distracting as it corrupts whole working area of gnome 3 / gnome shell (time, calender, system control (settings, power options)) With 3.11 kernel one gets a colorful triangle show, screen is tiled into four flashing triangle stips, after 3-4 seconds they vanish, but the font corruption stays same. This bug might be linked with 35457
Yes, in 35457 in post 37 gnome-shell text corruption is exactly which I experience and is exactly same with screens in this bug. These two are the same critical bug.
This is definite duplicate of 35457 (compare screen attachments) *** This bug has been marked as a duplicate of bug 35457 ***
This is not a duplicate.
Still experiencing this with kernel 3.17-1 and latest Mesa from Manjaro. Experiencing it even in Enlightment e17 (version e19) environiment, when hardware OpenGL compositing is selected. If I select software compositing, then this issue disappears. Also, in KDE 4.14 I get random kernel hardlocks and freezes, I never had. I wonder if this issue is connected.
I have a similar problem My bug reports on other treckers and full information about my hardware: https://bugzilla.gnome.org/show_bug.cgi?id=746160 https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/1434826
*** Bug 89686 has been marked as a duplicate of this bug. ***
I also have affected system and wanted for ages to see it fixed (with or without my help). unfortunately, even if I still can try and load old linux distro where last working fglrx (proprietary driver) was working - I have no idea what to do next - even mmiotrace format apparently changed from 2.6.29 kernel era, and here i fear some more tracing will be needed (and tools for userspace tracing also appear to bitrot or not even properly support this GPU). i tried to appear on #radeon but everyone was busy there (I think this situation will continue more or less due to new bug flow, new hardware, new features, other users and developers also wanting various levels of help). may be setting special 'hackday' for this or other specific bugs will help? if you like the idea - please reply (I tend to read dri-devel and mesa-dev ML). Thanks in advance!
Created attachment 121662 [details] chromium BSU also show this bug using r300g driver from OpenGL version string: 2.1 Mesa 11.1.0-devel (git-8ae8fec), on kernel 4.2.0.
Created attachment 121663 [details] dmesg as you can see this happens also on 32-bit kernel/32 bit userspace
Created attachment 121870 [details] mmiotrace from Catalyst 9.3 kernel 2.6.27.27
*** Bug 92651 has been marked as a duplicate of this bug. ***
Created attachment 122015 [details] chromium BSU log with RADEON_DEBUG=texalloc unfortunately, running with RADEON_DEBUG=notiling gives no visible improvements.
Created attachment 122016 [details] chromium BSU debug log with RADEON_DEBUG=texalloc,notiling
(In reply to Andrew Randrianasulu from comment #38) > unfortunately, running with RADEON_DEBUG=notiling gives no visible > improvements. You have to disable tiling in the ddx as well in the device section of you xorg config: Option "ColorTiling" "false"
Is there any hope that this will ever be fixed by someone? Not even Kodi does work on the laptop - cannot verify if it is the same problem - but the osd while playback video looks the same (striped) way as the menubar of the Unity-desktop...think its the same problem. There is almost nothing we can do with these laptops until someone will fix this!
Confirm that this bug is still present on up to date fedora25 : kernel 4.9.8-201.fc25 mesa 13.0.4 with X11 or wayland (no differences). Only gnome-shell is affected. All others apps are ok. same GPU as others : Extended renderer info (GLX_MESA_query_renderer): Vendor: X.Org R300 Project (0x1002) Device: ATI RS600 (0x7941) Version: 13.0.4 Accelerated: yes Video memory: 256MB Unified memory: no Preferred profile: compat (0x2) Max core profile version: 0.0 Max compat profile version: 2.1 Max GLES1 profile version: 1.1 Max GLES[23] profile version: 2.0 OpenGL vendor string: X.Org R300 Project OpenGL renderer string: Gallium 0.4 on ATI RS600 OpenGL version string: 2.1 Mesa 13.0.4 OpenGL shading language version string: 1.20
Same for Warzone2100 (and others?) on latest Mint Mate with Oibaf ppa, too. Still the same problems.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/333.
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.