Calling glDrawArrays without having a shader set fails on my Radeon Mobility 9000. This can be reproduced in many games, for example Extreme Tuxracer. The game crashes when loading a track. Sometimes the game crashes, sometimes the X server crashes. The problem also occurs with other programs like Wine. Using immediate mode glBegin()/glEnd() drawing works.
The crash occurs with and without using GL vertex buffer objects.
I managed to get a backtrace from a DirectX sample running in Wine:
wine: Unhandled page fault on read access to 0x0000001c at address 0x7dd560a1 (t hread 0009), starting debugger...
Unhandled exception: page fault on read access to 0x0000001c in 32-bit code (0x7dd560a1).
CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b
EIP:7dd560a1 ESP:00414248 EBP:00414280 EFLAGS:00210202( - 00 - -RI1)
EAX:00003a1c EBX:7df4eff4 ECX:000005b8 EDX:00000000
0x00414248: 00000000 c020645e 0000000e 001088e1
0x00414258: 00000003 00004000 b7ded7bf 00000000
0x00414268: 7cd921a0 00001d0e 7dd5604b 7df4eff4
0x00414278: 7cb3f4f0 000044a0 004142b0 7dd72347
0x00414288: 7c88af90 088e1000 00000001 0000000b
0x00414298: 7cd66928 00000000 7dd7231b 7df4eff4
=>0 0x7dd560a1 r200FlushElts+0x61(ctx=0x7c88af90) [/usr/local/include/drm/radeon_bo.h:153] in r200_dri.so (0x00414280)
1 0x7dd72347 radeonAllocDmaRegion+0x37(rmesa=<register ESI not in topmost frame>, pbo=0x7cb3f8f4, poffset=0x7cb3f8f8, bytes=<register EDI not in topmost frame>, alignment=32) [/home/stefan/src/mesa/src/mesa/drivers/dri/r200/radeon_dma.c:222] in r200_dri.so (0x004142b0)
2 0x7dd7256c rcommon_emit_vector+0x11c(ctx=0x7c88af90, aos=<register ESI not in topmost frame>, data=, size=3, stride=24, count=1464) [/home/stefan/src/mesa/src/mesa/drivers/dri/r200/radeon_dma.c:146] in r200_dri.so (0x004142f0)
3 0x7dd64923 r200EmitArrays+0x283(ctx=0x7c88af90, vimap_rev="") [/home/stefan/src/mesa/src/mesa/drivers/dri/r200/r200_maos_arrays.c:203] in r200_dri.so (0x00414370)
4 0x7dd5ad2a r200_run_tcl_render+0x16a(ctx=0x7c88af90, stage=0x7caf00dc) [/home/stefan/src/mesa/src/mesa/drivers/dri/r200/r200_tcl.c:487] in r200_dri.so (0x004143c0)
5 0x7de1689f _tnl_run_pipeline+0x13f(ctx=0x7c88af90) [/home/stefan/src/mesa/src/mesa/tnl/t_pipeline.c:158] in r200_dri.so (0x00414400)
6 0x7dd4e6c8 r200WrapRunPipeline+0x78(ctx=<register ESI not in topmost frame>) [/home/stefan/src/mesa/src/mesa/drivers/dri/r200/r200_state.c:2445] in r200_dri.so (0x00414420)
7 0x7de16d10 _tnl_draw_prims+0x330(ctx=0x7c88af90, arrays=0x414c80, prim=0x414db8, nr_prims=1, ib=0x414d00, min_index=0, max_index=1463) [/home/stefan/src/mesa/src/mesa/tnl/t_draw.c:355] in r200_dri.so (0x00414550)
8 0x7dec7755 flush+0x55(copy=<register ESI not in topmost frame>) [/home/stefan/src/mesa/src/mesa/vbo/vbo_split_copy.c:166] in r200_dri.so (0x00414580)
9 0x7dec7fde vbo_split_copy+0x60e(ctx=0x7c88af90, arrays=0x7cade60c, prim=0x415118, nr_prims=1, ib=0x415108, draw=0x7de169e0, limits=0x415040) [/home/stefan/src/mesa/src/mesa/vbo/vbo_split_copy.c:497] in r200_dri.so (0x00414f50)
10 0x7dec75d2 vbo_split_prims+0xc2(ctx=0x7c88af90, arrays=0x7cade60c, prim=0x415118, nr_prims=1, ib=<register ESI not in topmost frame>, min_index=0, max_index=<register EDI not in topmost frame>, draw=0x7de169e0, limits=0x415040) [/home/stefan/src/mesa/src/mesa/vbo/vbo_split.c:130] in r200_dri.so (0x00414fa0)
11 0x7de16df6 _tnl_draw_prims+0x416(ctx=0x7c88af90, arrays=0x7cade60c, prim=0x415118, nr_prims=1, ib=0x415108, min_index=0, max_index=4459) [/home/stefan/src/mesa/src/mesa/tnl/t_draw.c:436] in r200_dri.so (0x004150d0)
12 0x7de0e473 vbo_exec_DrawRangeElements+0x123(mode=4, start=0, end=4459, count=<register EDI not in topmost frame>, type=5123, indices=) [/home/stefan/src/mesa/src/mesa/vbo/vbo_exec_array.c:416] in r200_dri.so (0x00415130)
13 0x7de0e752 vbo_exec_DrawElements+0x112(mode=4, count=10860, type=5123, indices=<register EDI not in topmost frame>) [/home/stefan/src/mesa/src/mesa/vbo/vbo_exec_array.c:449] in r200_dri.so (0x00415170)
14 0x7de04a14 neutral_DrawElements+0xa4(mode=4, count=10860, type=5123, indices=) [/home/stefan/src/mesa/src/mesa/main/vtxfmt_tmp.h:336] in r200_dri.so (0x004151a0)
15 0x7e8c596f drawPrimitive+0xb1f(iface=0x133938, PrimitiveType=4, NumPrimitives=3620, StartVertexIndex=0, numberOfVertices=4460, StartIdx=0, idxSize=2, idxData=(nil), minIndex=0) [/home/stefan/src/wine/linux/dlls/wined3d/../../../dlls/wined3d/drawprim.c:266] in wined3d (0x004154b0)
16 0x7e89d550 IWineD3DDeviceImpl_DrawIndexedPrimitive+0xf0(iface=0x133938, PrimitiveType=WINED3DPT_TRIANGLELIST, minIndex=0, NumVertices=4460, startIndex=0, primCount=3620) [/home/stefan/src/wine/linux/dlls/wined3d/../../../dlls/wined3d/device.c:5171] in wined3d (0x00415520)
17 0x7e980a36 IDirect3DDevice8Impl_DrawIndexedPrimitive+0x96(iface=<register ESI not in topmost frame>, PrimitiveType=D3DPT_TRIANGLELIST, MinVertexIndex=0, NumVertices=4460, startIndex=0, primCount=3620) [/home/stefan/src/wine/linux/dlls/d3d8/../../../dlls/d3d8/device.c:1446] in d3d8 (0x00415550)
18 0x0101c17c in text3d (+0x1c17c) (0x00415580)
19 0x0100c01a in text3d (+0xc01a) (0x004155e0)
20 0x010361d8 in text3d (+0x361d8) (0x00415608)
21 0x01037221 in text3d (+0x37221) (0x0041563c)
22 0x0100c33b in text3d (+0xc33b) (0x0043fde0)
23 0x0100c7b8 in text3d (+0xc7b8) (0x0043ff08)
24 0x7b8761e7 start_process+0xc7(arg=(nil)) [/home/stefan/src/wine/linux/dlls/kernel32/../../../dlls/kernel32/process.c:904] in kernel32 (0x0043ffe8)
25 0xb7e97c37 wine_switch_to_stack+0x17() in libwine.so.1 (0x00000000)
0x7dd560a1 r200FlushElts+0x61 [/usr/local/include/drm/radeon_bo.h:153] in r200_dri.so: movl 0x1c(%edx),%eax
153 return bo->bom->funcs->bo_unmap(bo);
Created attachment 25354 [details]
Software versions used:
Mesa: 55db6ce537f1fd9acf205400202abfcc3908d6c3 (radeon-rewrite HEAD)
libdrm: 1edb70f1b909d06f1c0ee7c9c794aec99454e488 (modesetting-gem HEAD)
Xorg server 1.6.1
For testing purposes I hacked radeonCreateScreen2 in radeon_screen.c to enable vertex programs. With a vertex program set the draw call runs without crashing, but many programs I tried produce incorrect results. I guess that's why they're still disabled.
Could you attach full backtrace output from gdb (please compile mesa with -O0 option)?
I don't own any r200 card, but I will try my best.
One more thing, is it reproducible on master mesa branch?
Created attachment 25387 [details]
A backtrace with mesa compiled with -O0 -g. The game used here was Extreme Tuxracer.
I'll see if it is reproducible on the master branch. Do I have to switch the branches of libdrm and the kernel as well, or does the master branch also work with the kernel module and libdrm from the modesetting / radeon rewrite branch?
(In reply to comment #6)
> I'll see if it is reproducible on the master branch. Do I have to switch the
> branches of libdrm and the kernel as well, or does the master branch also work
> with the kernel module and libdrm from the modesetting / radeon rewrite branch?
No, you don't have to change anything just make sure that kernel based mode-setting is disabled during boot up.
No, the bug is not reproducible in Mesa master. etracer and Wine work. However, etracer is slow(about 5 fps, used to be > 150 in earlier driver versions).
On some tracks(but not all), it writes this repeatadely(every frame it seems):
[driAllocateTexture:635] unable to allocate texture
Wine runs ok with Mesa master it seems - at least the DirectX 8 samples do. They're all I have installed at the moment.
One other thing I noticed in the radeon-rewrite branch: A number of extensions are gone(GL_ATI_fragment_shader, GL_ARB_vertex_program, cube textures). Is this just not implemented yet, or a bug as well?
(In reply to comment #8)
> No, the bug is not reproducible in Mesa master. etracer and Wine work. However,
> etracer is slow(about 5 fps, used to be > 150 in earlier driver versions).
> On some tracks(but not all), it writes this repeatadely(every frame it seems):
> [driAllocateTexture:635] unable to allocate texture
> Wine runs ok with Mesa master it seems - at least the DirectX 8 samples do.
> They're all I have installed at the moment.
> One other thing I noticed in the radeon-rewrite branch: A number of extensions
> are gone(GL_ATI_fragment_shader, GL_ARB_vertex_program, cube textures). Is this
> just not implemented yet, or a bug as well?
I think that's just an issue with the dri2 initialization. radeonCreateScreen2 doesn't set the drmSupportsXXX flags as does radeonCreateScreen (depending on drm version). I think just setting these flags should fix this.
> I think that's just an issue with the dri2 initialization.
> radeonCreateScreen2 doesn't set the drmSupportsXXX flags as does
> radeonCreateScreen (depending on> drm version). I think just
> setting these flags should fix this.
I tried that, and indeed the extensions show up. Many shaders don't work properly though. Then again, this driver is still under development. Do you want me to file bugs for those issues?
(In reply to comment #10)
> > I think that's just an issue with the dri2 initialization.
> > radeonCreateScreen2 doesn't set the drmSupportsXXX flags as does
> > radeonCreateScreen (depending on> drm version). I think just
> > setting these flags should fix this.
> I tried that, and indeed the extensions show up. Many shaders don't work
> properly though. Then again, this driver is still under development. Do you
> want me to file bugs for those issues?
I'm not too familiar yet with radeon-rewrite, but I don't think those flags are not set on purpose, hence these are indeed unexpected bugs.
okay I've flicked on all the flags for the DRI2 paths, hopefully that fixes some of the issues.
The extensions are back now, but the glDrawArrays crash is still there. There are issues with the extensions, but I'll file separate bugs for them to prevent this bug from getting more off-topic.
Could you run the failing app with RADEON_DEBUG=allmsg and post the output?
This does not produce any output. It seems that the debug block in radeon_screen.c only applies to the r300 driver(#elif RADEON_COMMON && defined(RADEON_COMMON_FOR_R300))
ok, I copied the debug declarations into the r200 ifdef block and un-ifdefed the initialization of the debug stuff in the screen init function. This produces a little debug output, but nothing related to the crash. I'll attach it in a file.
Created attachment 25475 [details]
Note that the
%%% etracer warning: Attempt to bind to Texture unloaded texture: `b-herring_run_icon'
Is written before the main menu shows up and is even written with a working driver. So it is not related to the crash.
Created attachment 25479 [details] [review]
Could you try this patch?
No, it makes the issue worse unfortunately: Now every app seems to crash, including glxgears. I am currently recompiling Mesa, I'll get you a backtrace in a few minutes.
Created attachment 25514 [details]
Backtrace of glxgears with patch 25479("proposed patch")
Created attachment 25596 [details] [review]
make sure bo is not null
What about this one?
Created attachment 25604 [details]
Screenshot of etracer with patch 25596
This patch fixes the crash.
However, now there are drawing bugs in the game, as seen in the screenshot. random geometry pops up, and randomly geometry disappears. My intuition says that they're follow-up bugs, not caused by this patch. Should I file new bugs?
There's another size mismatch uncovered by this patch:
CS section end at (r200_cmdbuf.c,r200EmitVertexAOS,254)
CS section size missmatch start at (r200_cmdbuf.c,r200EmitVertexAOS,249) 5 vs 7
I'll note that in the size mismatch bug as well
Another update: etracer works, but the DX8 sdk samples now reliably crash the X server. I don't know if the game and X server crashes are related though. Is there any log I can get you?
Closing this bug, i believe a13e96359baaa0331561f86ef6487feba6540464 fix all array drawing issue there was, at least i don't have any anymore here. Note that there is an issue with stencil and i am looking into it. Reopen if this commit doesn't fix the bug for you.
Yep, I think this can be closed. I filed a separate bug for the X server crashes.
The DolphinVS vertex shader sample works properly now as well, at least for the vertex part(The clear color is incorrect and there's depth buffer garbage it seems, as in many other apps, but I think both issues are know already)