Bug 73946

Summary: scanout broken on radeon SI (OLAND)
Product: Mesa Reporter: Sgt. Garcia <darwinskernel>
Component: Mesa coreAssignee: mesa-dev
Status: RESOLVED DUPLICATE QA Contact:
Severity: normal    
Priority: medium CC: darwinskernel, dh.herrmann
Version: git   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments: dmesg from journalctl
drm msg in kernel
hwinfo --gfxcard --reallyall
lspci -k (VGA and audio part)
radeon-ucode version
kconfig

Description Sgt. Garcia 2014-01-22 20:38:46 UTC
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
Comment 1 Sgt. Garcia 2014-01-22 20:39:30 UTC
Created attachment 92613 [details]
drm msg in kernel
Comment 2 Sgt. Garcia 2014-01-22 20:40:06 UTC
Created attachment 92614 [details]
hwinfo --gfxcard --reallyall
Comment 3 Sgt. Garcia 2014-01-22 20:40:41 UTC
Created attachment 92615 [details]
lspci -k (VGA and audio part)
Comment 4 Sgt. Garcia 2014-01-22 20:41:03 UTC
Created attachment 92616 [details]
radeon-ucode version
Comment 5 Sgt. Garcia 2014-01-22 20:46:02 UTC
Created attachment 92617 [details]
kconfig
Comment 6 Michel Dänzer 2014-01-23 07:28:47 UTC
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.
Comment 7 David Herrmann 2014-01-23 08:00:35 UTC
@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..
Comment 8 Michel Dänzer 2014-01-27 03:55:51 UTC
(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...
Comment 9 Marek Olšák 2014-01-27 11:07:07 UTC
(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
Comment 10 Michel Dänzer 2014-01-28 02:38:11 UTC
(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.
Comment 12 Alex Deucher 2014-02-17 19:25:39 UTC

*** 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.