Bug 39209 - [bisected] Wrong display after "prefer native texture formats when possible" commit - part2
Summary: [bisected] Wrong display after "prefer native texture formats when possible" ...
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Mesa core (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: mesa-dev
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-07-13 15:33 UTC by Victor Tseng
Modified: 2011-07-20 14:49 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
window only repaint on resize (2.00 MB, image/png)
2011-07-13 15:34 UTC, Victor Tseng
Details
window only redraw part of itself on maximize (233.91 KB, image/png)
2011-07-13 15:35 UTC, Victor Tseng
Details
Patch (1.08 KB, patch)
2011-07-13 17:40 UTC, Stephane Marchesin
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Victor Tseng 2011-07-13 15:33:32 UTC
After I update to the latest mesa git (85e1fa55066783d2748993810708dee6db7a4993) I found out the some programs (`cairo-dock -o` and gnome-terminal) start not to paint itself.

After some time bisecting, I found the commit which caused the problem is 1a339b6c71ebab6e1a64f05b2e133022d3bbcd15.

A google search #38602 and #38610 indicates 1f544cc58794cffe5d5cac5a83efde91154f1b7d fixes this, but not my case.

Everything was good with 98ce1373e47d05d7150933c391fdeddbc897a3cd.
With 1a339b6c71ebab6e1a64f05b2e133022d3bbcd15, X goes to CPU 100% after cairo-dock started.
With 1f544cc58794cffe5d5cac5a83efde91154f1b7d, X starts to work again, but cairo-dock is not rendering anything (click on the "invisible" icon brings up program, though), and gnome-terminal doesn't render anything in its console part (see attachment).
Going all the way to the latest commit (85e1fa55066783d2748993810708dee6db7a4993) does not help.

I'm on a ATI Mobility Radeon HD 4530 512MB with git-sources-3.0-rc7:
# lspci -nn | grep VGA
02:00.0 VGA compatible controller [0300]: ATI Technologies Inc M92 [Mobility Radeon HD 4500/5100 Series] [1002:9553]
# uname -r
3.0.0-rc7-palatis

xorg-server is 1.10.3 (as shown in `X -version`).
libdrm is at commit 8d055890d90c3d92647e3d8b98d32630ef87c2c8.
xf86-video-ati is at commit e8d0d437957b15252dfad775796a3949ed50dbcf.

However, another computer with a HD 3300 doesn't have the problem, everything was great with this card:
# lspci -nn | grep VGA
01:05.0 VGA compatible controller [0300]: ATI Technologies Inc Radeon HD 3300 Graphics [1002:9614]
Comment 1 Victor Tseng 2011-07-13 15:34:57 UTC
Created attachment 49064 [details]
window only repaint on resize
Comment 2 Victor Tseng 2011-07-13 15:35:47 UTC
Created attachment 49065 [details]
window only redraw part of itself on maximize
Comment 3 Stephane Marchesin 2011-07-13 17:40:39 UTC
Created attachment 49066 [details] [review]
Patch

Does the attached patch help?
Comment 4 Victor Tseng 2011-07-14 04:15:54 UTC
(In reply to comment #3)
> Created an attachment (id=49066) [details]
> Patch
> 
> Does the attached patch help?

nope it doesn't.
Comment 5 Victor Tseng 2011-07-14 04:21:28 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > Created an attachment (id=49066) [details] [details]
> > Patch
> > 
> > Does the attached patch help?
> 
> nope it doesn't.

btw, there's no src/gallium/drivers/r600/eg_state_inlines.h in my tree (mesa master).
I found that r600_translate_colorformat() is in evergreen_state.c and comment the stuff there.

If I switch to a non-composite window manager (emerald -> metacity) then the windows (both cairo-dock and gnome-terminal) starts to render correctly.
Comment 6 Henri Verbeet 2011-07-14 04:31:35 UTC
I think that's a r700 card, so changing evergreen_state.c probably won't do much.
Comment 7 Victor Tseng 2011-07-14 05:04:44 UTC
Okay, I found it DOES impact my Radeon HD 3300, too.

If I turn on "Loose Binding" option in fusion-icon, both computer have the same problem (not properly rendering itself).
If I turn that option off, both computer starts to render correctly (with commit 7e2827fad95071e04e382be0117c654445764c52).
I previously had "Loose Binding" off on the HD3300 and didn't realize that.

I think this is another problem instead of colorformat.

==========

I added some debug output in st_choose_format() (st_format.c).
With 98ce1373e47d05d7150933c391fdeddbc897a3cd it does print something:
st_choose_format(): return PIPE_FORMAT = 1
st_choose_format(): return PIPE_FORMAT = 19
most of them are 1.

But with commits after that, it doesn't print anything.
I think it's not taking that path anymore.
Comment 8 Victor Tseng 2011-07-15 13:26:44 UTC
(In reply to comment #6)
> I think that's a r700 card, so changing evergreen_state.c probably won't do
> much.

thx for pointing this out.

this time I patched the function "r600_translate_colorformat()" in file "r600_state.c".
and it's all working again now.

and I found the buggy pipe_format is 67 (PIPE_FORMAT_R8G8B8A8_UNORM).
Comment 9 Emil Velikov 2011-07-20 11:08:40 UTC
Hi Victor

Can you please test the latest mesa/master

A patch that should resolve your issue has been pushed [1]

Cheers
Emil

[1] http://cgit.freedesktop.org/mesa/mesa/commit/?id=d84791a72b33f96fab54ff2399e8053c50205454
Comment 10 Victor Tseng 2011-07-20 14:49:19 UTC
commit d84791a72b33f96fab54ff2399e8053c50205454 does address this bug.


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.