Bug 22576 - [KMS] mesa demo spectex broken on rv280
[KMS] mesa demo spectex broken on rv280
Status: RESOLVED FIXED
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/r200
git
x86 (IA32) Linux (All)
: medium normal
Assigned To: Default DRI bug account
:
: 22575 25883 39285 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-07-01 02:58 UTC by Andrew Randrianasulu
Modified: 2012-12-18 20:43 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
glxinfo -l (10.25 KB, text/plain)
2009-07-01 03:00 UTC, Andrew Randrianasulu
Details
Wrong patch (897 bytes, patch)
2010-09-13 11:45 UTC, Andrew Randrianasulu
Details | Splinter Review
RADEON_DEBUG=state ./spectex (24.04 KB, text/plain)
2010-09-13 11:50 UTC, Andrew Randrianasulu
Details
screenshot of corruption (8.95 KB, image/jpeg)
2010-10-19 22:43 UTC, Andrew Randrianasulu
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Randrianasulu 2009-07-01 02:58:16 UTC
same setup as in bug 22575:

hardware:

01:00.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200 SE]
(rev 01) (prog-if 00 [VGA controller])

with upstream Linux kernel commit 5a4f13fad1ab5bd08dea78fc55321e429d83cddf
drm master branch commit de1ed01214874dcdd6116ff2587c8710d6ed4d2d
mesa master commit  5e6b593d35156a0068dc0eb3e55dec086f1cadd3
xf86-video-ati kms-support branch commit
ac61e56c4c7b26d105c0441b446ed339e8355658
xserver master commit  84662e40c3d4141ebb298a1ad714f75056a4ab74

progs/demos/spectex gives me only completely black window. With any mode, selectable from right-click menu.
Comment 1 Andrew Randrianasulu 2009-07-01 03:00:24 UTC
Created attachment 27291 [details]
glxinfo -l
Comment 2 Andrew Randrianasulu 2009-07-14 16:34:02 UTC
Spectex demo works with mesa master, commit 681ede8836746735fbb904edf89b076343507a8b (radeon: fix unsigned vs signed comparison in stencil code.)

may be this bug just duplicate #22746? I can't remember  if i has compositor on or off in initial testing.
Comment 3 Michel Dänzer 2009-07-15 04:47:21 UTC
BTW, you can resolve bugs yourself. :)
Comment 4 ajax at nwnk dot net 2009-08-24 12:32:42 UTC
Mass version move, cvs -> git
Comment 5 Andrew Randrianasulu 2010-04-11 10:05:33 UTC
Sorry guys, after some additional testing i found new pattern for triggering this bug.

mesa
commit 821abff8c03031603111abc17dabe7cfa28a31e1
Author: Zack Rusin <zackr@vmware.com>
Date:   Wed Apr 7 17:46:55 2010 -0400
    draw llvm: highly reduce the compilation times for draw llvm

libdrm
commit c1c8bbf80b1f734e23996bf805dc78f32ebaf56f
Author: Ben Skeggs <bskeggs@redhat.com>
Date:   Fri Mar 19 10:20:09 2010 +1000
    nouveau: fix annoying compiler warning


xf86-video-ati
commit eb5665688ef9b52f03f61546351d0848cab54740
Author: Alex Deucher <alexdeucher@gmail.com>
Date:   Thu Apr 8 00:31:52 2010 -0400
    radeon: don't setup Xv on rn50


1. First try kernel 2.6.32 and  this stack _in UMS mode_, run glxgears (important).
2. reboot into D.R.T. kernel (2.6.34-rc3)
3. load radeon (in my config  i have KMS enabled by default).
4. observe perfect spectex demo
5. power off machine.
6. wait  few mins.
7. Power on machine, boot 2.6.34-rc3, rc4
8. load radeon (it will defaulted into KMS)
9. startx
10. observe black screen/horizontal black bars in mesa/progs/demos/spectex
11. Verify what this effect survived warm reboots.
12. repeat "fix" described in 1, but reboot machine machine instead of powering it off.
13. Observe same persistence ("fix" survived warm reboots)
Comment 6 Andrew Randrianasulu 2010-04-19 22:51:34 UTC
Guess i can mark bug 22575 ( [KMS] mesa demo projtex broken on rv280 ) as duplicate of this, because  projtex works after same " run UMS/glxgears first" fix?

P.S.: bisecting kernel right now, hopefully will have bisect result today. But i'll also re-test with current 2.6.34-rc5 kernel (UMS mode) just in case.

Can it be some wrong-initialized register on-card? I mean KMS code write bunch of regs, but at least one of them stuck/not responded to write, and UMS "fix" just unlock this reg ? Just possible scenario, i can be completely wrong here ...
Comment 7 Alex Deucher 2010-04-20 07:11:41 UTC
(In reply to comment #6)

> P.S.: bisecting kernel right now, hopefully will have bisect result today. But
> i'll also re-test with current 2.6.34-rc5 kernel (UMS mode) just in case.
> Can it be some wrong-initialized register on-card? I mean KMS code write bunch
> of regs, but at least one of them stuck/not responded to write, and UMS "fix"
> just unlock this reg ? Just possible scenario, i can be completely wrong here
> ...

It's probably a register that KMS is not setting.  I suspect there is some state that's not getting emitted under KMS that is under UMS.  When you run UMS, it sets the reg to the appropriate value, then things work under KMS.
Comment 8 Andrew Randrianasulu 2010-04-21 17:48:49 UTC
Well, no need for 2.6.32 or something like this, 2.6.34-rc5 (current drm-radeon-testing) works just fine, as "fix" for this bug. 

But UMS itself seems broken, i can't see any OpenGL output  with glxgears, only black window! And killing X with ctrl-alt-bs lock mouse and keyboard, I can only  power-off via  ACPI button. I'll upgrade X + evdev, and if problem still there - will look for  filling/updating  additional bugs about this behavior.
Comment 9 Andrew Randrianasulu 2010-04-21 18:29:56 UTC
*** Bug 22575 has been marked as a duplicate of this bug. ***
Comment 10 Andrew Randrianasulu 2010-04-21 18:38:38 UTC
(In reply to comment #8)
> Well, no need for 2.6.32 or something like this, 2.6.34-rc5 (current
> drm-radeon-testing) works just fine, as "fix" for this bug. 
> 
> But UMS itself seems broken, i can't see any OpenGL output  with glxgears, only
> black window! And killing X with ctrl-alt-bs lock mouse and keyboard, I can
> only  power-off via  ACPI button. I'll upgrade X + evdev, and if problem still
> there - will look for  filling/updating  additional bugs about this behavior.

After upgrading X server and xf86-input-evdev (recompile + install) ctrl-alt-bs works again in UMS. But black gears in UMS mode still here ... looking at other bugs, i'll try to play with various desktop sizes (800x600, etc). Sorry for adding this info here, I was mostly run KMS-only setup and hardly noticed when UMS broke ....
Comment 11 Andrew Randrianasulu 2010-08-08 10:29:20 UTC
Black window in spectex demo still here, with 2.6.35
Comment 12 Andrew Randrianasulu 2010-09-13 11:45:56 UTC
Created attachment 38678 [details] [review]
Wrong patch

After some looking at r200_tcl.c I tried to replace old-style check for specular color  with more modern macro. And was hit by 'spectex: radeon_cs_gem.c:181: cs_gem_write_reloc: Assertion `boi->space_accounted' failed.'
Comment 13 Andrew Randrianasulu 2010-09-13 11:50:05 UTC
Created attachment 38679 [details]
RADEON_DEBUG=state ./spectex

What puzzled me most - even after i reverted my patch and  tried to use another (system-wise installed) version of mesa, even with different demo - same assert hit me again. But after some time at least lodbias demo working again ....
Comment 14 Fabio Pedretti 2010-10-12 01:20:45 UTC
This could be fixed in mesa master and 7.9 branch:
http://lists.freedesktop.org/archives/mesa-dev/2010-October/003492.html
Comment 15 Andrew Randrianasulu 2010-10-19 22:42:16 UTC
(In reply to comment #14)
> This could be fixed in mesa master and 7.9 branch:
> http://lists.freedesktop.org/archives/mesa-dev/2010-October/003492.html

It still broken, but in slightly different way:

sphere has few horizontal black stripes now. I'll add screenshot.
Comment 16 Andrew Randrianasulu 2010-10-19 22:43:28 UTC
Created attachment 39559 [details]
screenshot of corruption
Comment 17 smoki 2012-01-13 06:01:06 UTC
 Bug is here with kernel 3.1.8, xserver 1.10.4 and git from whole stack.
 
 Load UMS and mesa 7.5.2 to fix lighting, reboot into KMS with current mesa
and lighting is fixed... until power off:(.
Comment 18 smoki 2012-12-09 23:11:52 UTC
 I think i've found source of these lighting problems on r200 in this and other bugs. It is just a typo it seems in r200_state_init.c lit_emit()

 OUT_VEC(atom->cmd[LIT_CMD_1], atom->cmd+LIT_CMD_1+1);

 instead of OUT_VEC it needs to be OUT_SCL:

 OUT_SCL(atom->cmd[LIT_CMD_1], atom->cmd+LIT_CMD_1+1);

 And that fixed tcl lighting emit complitely for me on 9250 card, but of course that introduce 2 more dwords which atom complain about:

 CS section size missmatch start at (r200_state_init.c,lit_emit,361) 41 vs 39
 CS section end at (r200_state_init.c,lit_emit,364)

 I've turned off check and it stops :), but don't know how to or where to stop it properly...

 So maybe someone who read this can do that :)?
Comment 19 Alan Swanson 2012-12-10 14:24:17 UTC
This fixes lighting bug 26809 with NWN on my rv250, but R200 untested as yet. To correct the section size mismatch, add the following before the BEGIN_BATCH_NO_AUTOSTATE() line;

  dwords += 2;

Thank you very much for finding this three year old radeon rewrite bug. I assume you discerned this from cmdscl used for LIT_CMD_1 versus cmdvec used for LIT_CMD_0?
Comment 20 smoki 2012-12-10 15:28:18 UTC
 Yeah, i just see that, assume that it must be scl there then compared it with radeon state, there is setup just like that, but with correct vec/scl as i assume, so i changed it like that and that is it - tcl lighting works. Three year old typo - i deserve a medal ;).

 Someone could pushed it in git.
Comment 21 Roland Scheidegger 2012-12-10 16:37:52 UTC
(In reply to comment #18)
>  I think i've found source of these lighting problems on r200 in this and
> other bugs. It is just a typo it seems in r200_state_init.c lit_emit()
> 
>  OUT_VEC(atom->cmd[LIT_CMD_1], atom->cmd+LIT_CMD_1+1);
> 
>  instead of OUT_VEC it needs to be OUT_SCL:
> 
>  OUT_SCL(atom->cmd[LIT_CMD_1], atom->cmd+LIT_CMD_1+1);

Should be fixed by 320d531373e7b0873f5de42f6173b986290f593f, thanks!
FWIW the command emit mechanism looks a bit too complicated it could profit from some refactoring. For instance it is still based on the fake drm_radeon_cmd_header_t structure, the scl vs. scl2 and vec vs. veclinear emits are nothing but crude hacks around limitations in that structure, even though since ums is gone there is absolutely no point in using that struct...
Section size calcs are also somewhat confusing, the sanity code (which was really great back then) is totally unused etc.
Maybe another day...
Comment 22 Alan Swanson 2012-12-18 17:42:10 UTC
*** Bug 25883 has been marked as a duplicate of this bug. ***
Comment 23 smoki 2012-12-18 20:43:27 UTC
*** Bug 39285 has been marked as a duplicate of this bug. ***