Bug 21513

Summary: radeon-rewrite: r200 glDrawArrays without shaders fails
Product: DRI Reporter: Stefan Dösinger <stefandoesinger>
Component: DRM/RadeonAssignee: Default DRI bug account <dri-devel>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: medium    
Version: DRI git   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
glxinfo output
none
gdb backtrace
none
debug output
none
proposed patch
none
Backtrace of glxgears with patch 25479("proposed patch")
none
make sure bo is not null
none
Screenshot of etracer with patch 25596 none

Description Stefan Dösinger 2009-05-01 14:57:58 UTC
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).
Register dump:
 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
 ESI:00003a1a EDI:7cb3f4f0
Stack dump:
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
Backtrace:

=>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);
Comment 1 Stefan Dösinger 2009-05-01 14:59:14 UTC
Created attachment 25354 [details]
glxinfo output
Comment 2 Stefan Dösinger 2009-05-01 15:03:32 UTC
Software versions used:

Mesa: 55db6ce537f1fd9acf205400202abfcc3908d6c3 (radeon-rewrite HEAD)
libdrm: 1edb70f1b909d06f1c0ee7c9c794aec99454e488 (modesetting-gem HEAD)

DDX-driver:git://anongit.freedesktop.org/~airlied/xf86-video-ati, 1f5861ff6c60862d2beda08f33ee64ae24c1238f

Kernel: ed70a54c74f78f426497654676dda7ac53055d13

Xorg server 1.6.1
Comment 3 Stefan Dösinger 2009-05-01 15:12:02 UTC
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.
Comment 4 Maciej Cencora 2009-05-02 08:48:51 UTC
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?
Comment 5 Stefan Dösinger 2009-05-03 05:07:42 UTC
Created attachment 25387 [details]
gdb backtrace

A backtrace with mesa compiled with -O0 -g. The game used here was Extreme Tuxracer.
Comment 6 Stefan Dösinger 2009-05-03 05:09:28 UTC
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?
Comment 7 Maciej Cencora 2009-05-03 06:30:15 UTC
(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.
Comment 8 Stefan Dösinger 2009-05-03 08:29:28 UTC
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?
Comment 9 Roland Scheidegger 2009-05-04 08:09:53 UTC
(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.
Comment 10 Stefan Dösinger 2009-05-04 10:10:50 UTC
> 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?
Comment 11 Roland Scheidegger 2009-05-04 12:11:19 UTC
(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.
Comment 12 Dave Airlie 2009-05-04 18:57:19 UTC
okay I've flicked on all the flags for the DRI2 paths, hopefully that fixes some of the issues.
Comment 13 Stefan Dösinger 2009-05-05 06:01:29 UTC
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.
Comment 14 Maciej Cencora 2009-05-05 10:57:03 UTC
Could you run the failing app with RADEON_DEBUG=allmsg and post the output?
Comment 15 Stefan Dösinger 2009-05-05 11:15:43 UTC
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))
Comment 16 Stefan Dösinger 2009-05-05 11:20:46 UTC
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.
Comment 17 Stefan Dösinger 2009-05-05 11:21:19 UTC
Created attachment 25475 [details]
debug output
Comment 18 Stefan Dösinger 2009-05-05 11:22:07 UTC
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.
Comment 19 Maciej Cencora 2009-05-05 12:00:42 UTC
Created attachment 25479 [details] [review]
proposed patch

Could you try this patch?
Comment 20 Stefan Dösinger 2009-05-05 14:14:38 UTC
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.
Comment 21 Stefan Dösinger 2009-05-05 14:29:11 UTC
Created attachment 25514 [details]
Backtrace of glxgears with patch 25479("proposed patch")
Comment 22 Maciej Cencora 2009-05-07 08:31:51 UTC
Created attachment 25596 [details] [review]
make sure bo is not null

What about this one?
Comment 23 Stefan Dösinger 2009-05-07 11:09:09 UTC
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
Comment 24 Stefan Dösinger 2009-05-07 11:18:13 UTC
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?
Comment 25 Jerome Glisse 2009-05-20 13:31:02 UTC
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.
Comment 26 Stefan Dösinger 2009-05-20 16:16:34 UTC
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)

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.