Bug 28003 - [r300g] Compiz fails to start using gallium on rv350.
Summary: [r300g] Compiz fails to start using gallium on rv350.
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/r300 (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-05-06 13:27 UTC by Scott Moreau
Modified: 2010-05-09 20:31 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
compiz output (3.14 KB, application/octet-stream)
2010-05-06 19:43 UTC, Scott Moreau
Details
work around the assertion failure (1.59 KB, patch)
2010-05-07 03:11 UTC, Chia-I Wu
Details | Splinter Review

Description Scott Moreau 2010-05-06 13:27:41 UTC
Compiz will only start with GALLIUM_ABORT_ON_ASSERT=0 or it crashes. I bisected and on current master 7ed2f953c0b109d35ddb4c58effb18bd0fac4592 the message is:

r300: Implementation error: Format mismatch in r300_surface_copy
    : src: b8g8r8a8_unorm dst: b8g8r8x8_unorm
r300_blit.c:134:r300_surface_copy: Assertion `0' failed.
debug_get_bool_option: GALLIUM_ABORT_ON_ASSERT = TRUE

while with the first bad commit found 968bf9634ec03e61441834603f13f0c914bbb0ce the message is:

r300_blit.c:136:r300_surface_copy: Assertion `dst->texture->format == src->texture->format' failed.
debug_get_bool_option: GALLIUM_ABORT_ON_ASSERT = TRUE

This last good commit is: 821abff8c03031603111abc17dabe7cfa28a31e1

I will provide any further requested information.
Comment 1 Marek Olšák 2010-05-06 15:24:58 UTC
This is a state tracker bug. We shouldn't get two different formats in surface_copy.

Could you please give me a backtrace?
Comment 2 Scott Moreau 2010-05-06 19:43:42 UTC
Created attachment 35476 [details]
compiz output
Comment 3 Michel Dänzer 2010-05-07 00:49:58 UTC
(In reply to comment #1)
> This is a state tracker bug. We shouldn't get two different formats in
> surface_copy.

Indeed. There should never be a need for copies for texture-from-pixmap anyway, should probably use a sampler view.
Comment 4 Chia-I Wu 2010-05-07 01:53:20 UTC
(In reply to comment #3)
> Indeed. There should never be a need for copies for texture-from-pixmap anyway,
> should probably use a sampler view.
The assertion failure is hit when using an RGBA pixmap as an RGB texture.  It was discussed here

  http://www.mail-archive.com/mesa3d-dev@lists.sourceforge.net/msg12992.html

and using a sampler view should be the correct fix to my knowledge.

I might not be able to find the time to work on it anytime soon.  If no one volunteers, setting GLX_BIND_TO_TEXTURE_RGB_EXT to GLX_FALSE for RGBA visuals should be a valid workaround, if compiz does check the attribute.
Comment 5 Michel Dänzer 2010-05-07 02:18:21 UTC
(In reply to comment #4)
> I might not be able to find the time to work on it anytime soon.

FWIW I think it's a regression of one of your EGL reworks though.

> If no one volunteers, setting GLX_BIND_TO_TEXTURE_RGB_EXT to GLX_FALSE for RGBA
> visuals should be a valid workaround, if compiz does check the attribute.

I suspect that would take about the same amount of work, and I wouldn't consider it very useful (not sure if compiz/kwin/... could even handle it).
Comment 6 Chia-I Wu 2010-05-07 03:11:11 UTC
Created attachment 35484 [details] [review]
work around the assertion failure

Does this patch help?  It effectively reverts 968bf9634ec03e61441834603f13f0c914bbb0ce by ignoring internal_format in st/mesa.  It is better than reverting the commit in that the workaround is closer to the bug (both in st/mesa).
Comment 7 Chia-I Wu 2010-05-07 03:19:48 UTC
(In reply to comment #5)
> (In reply to comment #4)
> > I might not be able to find the time to work on it anytime soon.
> 
> FWIW I think it's a regression of one of your EGL reworks though.
> 
> > If no one volunteers, setting GLX_BIND_TO_TEXTURE_RGB_EXT to GLX_FALSE for RGBA
> > visuals should be a valid workaround, if compiz does check the attribute.
> 
> I suspect that would take about the same amount of work, and I wouldn't
> consider it very useful (not sure if compiz/kwin/... could even handle it).
Ok, I've created a patch to work around the bug triggered by 968bf963.  It restores the old (and wrong) behavior, but with comments.  Could you or Scott help me verify the patch?
Comment 8 Chia-I Wu 2010-05-07 03:23:55 UTC
(In reply to comment #7)
> Ok, I've created a patch to work around the bug triggered by 968bf963.  It
> restores the old (and wrong) behavior, but with comments.  Could you or Scott
                    ^^^^^^^^^
I meant, "wrong, but better than the assertion failure".  I am sorry to introduce the regression in the first place.
> help me verify the patch?
Comment 9 Scott Moreau 2010-05-08 17:24:56 UTC
(In reply to comment #8)
> (In reply to comment #7)
> > Ok, I've created a patch to work around the bug triggered by 968bf963.  It
> > restores the old (and wrong) behavior, but with comments.  Could you or Scott
>                     ^^^^^^^^^
> I meant, "wrong, but better than the assertion failure".  I am sorry to
> introduce the regression in the first place.
> > help me verify the patch?

Thanks for everyones replies. I applied the patch against latest master and it works around the issue. I enabled ccsm>Workarounds>Force Sync Between X and GLX because of redraw/refresh issues using firefox but still having problems with it though compiz works without any warnings or errors.
Comment 10 Chia-I Wu 2010-05-09 20:31:04 UTC
Thanks for testing.  I've committed the patch and am closing the bug.  Feel free to open a new bug if you have other issues.


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.