Created attachment 27291 [details]
glxinfo -l

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.

BTW, you can resolve bugs yourself. :)

Mass version move, cvs -> git

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)

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

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

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.

*** Bug 22575 has been marked as a duplicate of this bug. ***

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

Black window in spectex demo still here, with 2.6.35

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

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

This could be fixed in mesa master and 7.9 branch:
http://lists.freedesktop.org/archives/mesa-dev/2010-October/003492.html

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

Created attachment 39559 [details]
screenshot of corruption

 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:(.

 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 :)?

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?

 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.

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

*** Bug 25883 has been marked as a duplicate of this bug. ***

*** Bug 39285 has been marked as a duplicate of this bug. ***