Created attachment 38465 [details]
Output from civ4 with RADEON_DEBUG=swtcl

I have the same problem running civ4 via wine on my RC410.  I've bisected this bug and the first bad commit is eb430b0e948caf02b9f4095d0e1435880073c2aa

weird I'm having trouble reproducing this on real r300 using RADEON_NO_TCL=1

Niels can you give me an exact OSG example to run?

blender 2.4 seems fine here.

I can reproduce this bug with the game nexuiz (http://alientrap.org/nexuiz/).  This is on an RV515 with RADEON_NO_TCL=1.  The game crashes right right before the main menu loads.

The problem is:

- r300_render_allocate_vertices allocates a vertex buffer.
- Draw stores vertices in the buffer.
- r300_render_draw_arrays is called.
- r300_prepare_for_rendering is called and inside that function, assume the command stream is full and must be flushed. r300_flush calls r300_draw_flush_vbuf, which releases the vertex buffer.
- r300_prepare_for_rendering begins to emit states.
- r300_emit_aos_swtcl is called, which crashes due to the buffer having been deleted.

The commit 0392e48867c27f2aa445c5c9b35f4a52ecef2f2d in Mesa fixes the regressions I was able to reproduce.

I have split r300_prepare_for_rendering into 2 parts:
- r300_reserve_cs_dwords, which is called before r300_render_allocate_vertices
- r300_emit_states, which is called instead of r300_prepare_for_rendering

Please test.

nexuiz works now, but I am still having problems running civ4 with wine.   Using mesa from git, commit fd7f70af4897e4e31b11562eb1c473f0ee00fce5 I get this assertion failure:

r300_render.c:973:r300_render_draw_elements: Assertion `6 + (short_count+1)/2 <= (cs_copy->ndw - cs_copy->cdw)' failed.


With commit 0b9eb5c9bb03e5134d9a41786178100109e80c5a wine segfaults.  Here is the backtrace:

Backtrace:
=>0 0x7cf4b24f radeon_bo_get_tiling+0xf() in libdrm_radeon.so.1 (0x0033edc4)
  1 0x7d0759de radeon_drm_bufmgr_get_tiling+0x4d(ws=0x3, _buf=0x300091fc, microtiled=0x1, macrotiled=(nil)) [/home/steltho/mesa/src/gallium/winsys/radeon/drm/radeon_drm_
buffer.c:379] in r300_dri.so (0x0033edc4)
  2 0x00000000 (0x7c04f798)
  3 0x7d074460 in r300_dri.so (+0x11345f) (0x7d074670)
  4 0x8b182474 (0x891cec83)
0x7cf4b24f radeon_bo_get_tiling+0xf in libdrm_radeon.so.1: movl 0x0(%edx),%edx

The crash in radeon_bo_get_tiling has been fixed by commit 09ef8e9283f17. I'll look into the assertion failure.

Created attachment 38727 [details] [review]
possible fix

Could you please test this patch?

(In reply to comment #8)
> Created an attachment (id=38727) [details]
> possible fix
> 
> Could you please test this patch?

This patch causes the game to freeze (no more assertion failure) and outputs the following errors:
Mesa: User error: GL_INVALID_OPERATION in glGetUniformfv(program)
Mesa: 2105 similar GL_INVALID_OPERATION errors
Mesa: User error: GL_INVALID_OPERATION in glUseProgram(program 17 not linked)
Mesa: User error: GL_INVALID_OPERATION in glGetUniformfv(program)
Mesa: 19 similar GL_INVALID_OPERATION errors
Mesa: User error: GL_INVALID_OPERATION in glUseProgram(program 17 not linked)
Mesa: User error: GL_INVALID_OPERATION in glUseProgram(program 17 not linked)


I've seen errors like this before, so they might not be directly related to this bug.

We have 2 options for 7.9. Either I'll commit this patch but I must be sure there are no regressions, or I'll revert all swtcl fixes and the Dave's commit (in 7.9, not in master), and will get to it later when I have some time.

I'll do some additional testing here later.

(In reply to comment #8)
> Created an attachment (id=38727) [details]
> possible fix
> 
> Could you please test this patch?

I upgraded from 2.6.34 to 2.6.35 and applied this patch and now civ4 doesn't crash.  I tested 2.6.35 without this patch and I still saw the assertion failure, so your patch fixed the assertion failure and upgrading to 2.6.35 fixed the lockup.

OK, I've pushed the patch and additional testing here shows no other regression. Closing..