Created attachment 92611 [details] dmesg from journalctl running kmscube on kernel (for version and config see the attached) VT i get scrambled graphics. hardware is ATI OLAND (see the attached for more detail) you can get kmscube here: https://github.com/robclark/kmscube.git
Created attachment 92613 [details] drm msg in kernel
Created attachment 92614 [details] hwinfo --gfxcard --reallyall
Created attachment 92615 [details] lspci -k (VGA and audio part)
Created attachment 92616 [details] radeon-ucode version
Created attachment 92617 [details] kconfig
This is probably because the Gallium textures which end up being scanned out are created without the PIPE_BIND_SCANOUT flag set, so they end up with a tiling mode which is not supported by the display engine. I can reproduce similar issues with weston, especially when making apps fullscreen, and I can work around it in the radeonsi driver by always creating textures as if the PIPE_BIND_SCANOUT flag was set.
@Michel, any idea how to fix that? The scanout buffers are created via gbm and this falls back to mesa dri->image->createImage() with __DRI_IMAGE_SCANOUT set. So I guess the radeonsi driver uses wrong tiling for such buffers? The DRM device node is stored in dri->screen so the driver should be able to query all required context information, right? Could you tell me at which point exactly you added the PIPE_BIND_SCANOUT flag? I can try adding some ctx-queries there so we set it correctly if used for DRM scanout. In case this flag is needed during pipe-creation, not at buffer-alloc time, we should probably set this flag unconditionally for gbm created pipes. Just thinking out loud.. I have no idea how the radeon hw really works..
(In reply to comment #7) > Could you tell me at which point exactly you added the PIPE_BIND_SCANOUT > flag? I didn't. I modified src/gallium/drivers/radeon/r600_texture.c:r600_surface_init() to set RADEON_SURF_SCANOUT regardless of PIPE_BIND_SCANOUT. As that worked around the problem, I assumed that PIPE_BIND_SCANOUT wasn't set when it should be. Right now though, I'm not able to reproduce the weston problem even with an unpatched radeonsi. Not sure what changed...
(In reply to comment #8) > (In reply to comment #7) > > Could you tell me at which point exactly you added the PIPE_BIND_SCANOUT > > flag? > > I didn't. I modified > src/gallium/drivers/radeon/r600_texture.c:r600_surface_init() to set > RADEON_SURF_SCANOUT regardless of PIPE_BIND_SCANOUT. As that worked around > the problem, I assumed that PIPE_BIND_SCANOUT wasn't set when it should be. > > > Right now though, I'm not able to reproduce the weston problem even with an > unpatched radeonsi. Not sure what changed... I fixed Wayland/Weston with this patch: http://cgit.freedesktop.org/mesa/mesa/commit/?id=0b37737cc3e7042bffb7c8a0e6a5c822bb806977
(In reply to comment #9) > I fixed Wayland/Weston with this patch: > > http://cgit.freedesktop.org/mesa/mesa/commit/?id=0b37737cc3e7042bffb7c8a0e6a5c822bb806977 I had that fix when I reproduced the problem last week.
Also for oland, make sure your kernel has this patch: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/radeon/atombios_crtc.c?id=227ae10f17a5f2fd1307b7e582b603ef7bbb7e97
*** This bug has been marked as a duplicate of bug 71488 ***
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.