Bug 2516

Some more digging found this is not only related to texture borders, other
rasterization fallbacks suffer from that as well (easily tested with texenv,
just changed one of the texture wrap modes to GL_CLAMP_TO_BORDER which causes a
rast fallback). Summary changed accordingly.
It reaches the r200Fallback path just fine, and then strangely later dies in
_tnl_run_pipeline called from r200WrapRunPipeline.

Simply calling UNLOCK_HARDWARE in r200SpanRenderStart was all that was needed to
get this locally debuggable.

That said, I have no idea what is going on...
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 988616000 (LWP 8096)]
_tnl_build_vertices (ctx=0x8060990, start=0, end=0, newinputs=0) at
tnl/t_vertex.c:1379
1379             a[j].inputstride = vptr->stride;
(gdb) bt
#0  _tnl_build_vertices (ctx=0x8060990, start=0, end=0, newinputs=0)
    at tnl/t_vertex.c:1379
#1  0x3afb4fe3 in run_render (ctx=0x8060990, stage=0x0) at tnl/t_vb_render.c:296
#2  0x3afa5fde in _tnl_run_pipeline (ctx=0x8060990) at tnl/t_pipeline.c:159
#3  0x3af2a92f in r200WrapRunPipeline (ctx=0x8060990) at r200_state.c:2316
#4  0x3afc340a in _tnl_flush_vtx (ctx=0x8060990) at tnl/t_vtx_exec.c:282
#5  0x3afbe8a8 in _tnl_FlushVertices (ctx=0x8060990, flags=1) at tnl/t_vtx_api.c:838
#6  0x3af3ca4c in r200FlushVertices (ctx=0x8060990, flags=1) at r200_swtcl.c:906
#7  0x3af8d6af in _mesa_TexImage2D (target=3553, level=0, internalFormat=6407,
    width=258, height=258, border=1, format=6407, type=5121, pixels=0x41180008)
    at main/teximage.c:2096
#8  0x08049321 in MeasureDownloadRate () at texdown.c:163
#9  0x080495b2 in Display () at texdown.c:256
#10 0x3aaeafa1 in fghcbDisplayWindow () from /usr/lib/libglut.so.3
#11 0x3aaee36a in fgEnumWindows () from /usr/lib/libglut.so.3
#12 0x3aaeb2ef in glutMainLoopEvent () from /usr/lib/libglut.so.3
#13 0x3aaebbf5 in glutMainLoop () from /usr/lib/libglut.so.3
#14 0x0804999c in main (argc=1, argv=0xaffff1c4) at texdown.c:384

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

Some more debugging info (still from texdown):
(gdb) print count
$13 = 3
(gdb) print ((TNLcontext *)ctx->swtnl_context)->clipspace->attr[0]
$14 = {attrib = 0, format = 6, vertoffset = 0, vertattrsize = 16,
  inputptr = 0x8207b90 "", inputstride = 16, insert = 0x3b0d0db0,
  emit = 0x3afeb3a0 <insert_4f_3>, extract = 0x3afec7d0 <extract_4f_viewport>,
  vp = 0x808cd90}
(gdb) print ((TNLcontext *)ctx->swtnl_context)->clipspace->attr[1]
$15 = {attrib = 3, format = 15, vertoffset = 144, vertattrsize = 4,
  inputptr = 0x80614ec "", inputstride = 0, insert = 0x3b0d0eac,
  emit = 0x3afeb910 <insert_4ub_4f_rgba_3>,
  extract = 0x3afec990 <extract_4chan_4f_rgba>, vp = 0x808cd90}
(gdb) print ((TNLcontext *)ctx->swtnl_context)->clipspace->attr[2]
$16 = {attrib = 8, format = 3, vertoffset = 16, vertattrsize = 16,
  inputptr = 0x81f2954 "", inputstride = 16, insert = 0x3b0d0d5c,
  emit = 0x3afeb4b0 <insert_2f_2>, extract = 0x3afec8a0 <extract_4f>, vp =
0x808cd90}
(gdb) print VB->AttribPtr
$17 = {0x0, 0x81f69ec, 0x81f6a08, 0x81f6a24, 0x81f6a40, 0x81f6a5c, 0x81f6a78,
  0x81f6a94, 0x81f6ab0, 0x81f6acc, 0x81f6ae8, 0x81f6b04, 0x81f6b20, 0x81f6b3c,
  0x81f6b58, 0x81f6b74, 0x81f6b90, 0x81f6bac, 0x81f6bc8, 0x81f6be4, 0x81f6c00,
  0x81f6c1c, 0x81f6c38, 0x81f6c54, 0x81f6c70, 0x81f6c8c, 0x81f6ca8, 0x81f6cc4,
  0x81f6ce0, 0x0, 0x0}

So, the first pointer (for attrib 0 (position)) is the NULL pointer leading to
the segfault, the other ones (attrib 3 (color0), attrib 8 (tex0)) look rather
reasonable (?). Unfortunately I'm no tnl wizard...

Some more debugging showed the problem:
When a rasterization fallback is hit, _tnl_need_projected_coords must be set to
true. This indeed happens, however r200ChooseVertexState will get called later
and this may set (depending on current vertex format) this to false again. When
this is set to false this will cause VB->NdcPtr to be NULL (in t_vb_vertex.c,
run_vertex_stage) which will in turn cause the VB->AttribPtr[VERT_ATTRIB_POS] to
be NULL too (ss_context.c, _swsetup_RenderStart) --> boom.

Created attachment 2067 [details] [review]
possible fix for rasterization fallbacks

this patch fixes the segfaults (tested with gl-117 and texdown), however I'm
not sure if it actually is really correct. I can't quite follow the command
flow of the tnl pipeline, what should and what actually is executed, validated
and what not is hard to understand. Someone with a more thourough understanding
of the tnl pipeline care to comment?

Sorry Roland, 
 
but your fix isn't enough. 
Play around with 's', 'f' and 'b'. 
 
progs/demos> GL_VENDOR = Tungsten Graphics, Inc. 
GL_VERSION = 1.3 Mesa 6.3 
GL_RENDERER = Mesa DRI R200 20041207 AGP 4x x86/MMX+/3DNow!+/SSE TCL 
w*h=65536  count=655  time=3.000000 
w*h=66564  count=617  time=3.002000 
w*h=66564  count=684  time=3.001000 
w*h=66564  count=984  time=3.001000 
w*h=66564  count=675  time=3.003000 
DRM_RADEON_TEXTURE: return = -14 
   offset=0xe9e00000 
   image width=258 height=130 
    blit width=258 height=131 data=0x4506f200 
 
[1]    Exitcode 1                        ./texdown 
 

(In reply to comment #7)
> but your fix isn't enough. 
> Play around with 's', 'f' and 'b'. 
> DRM_RADEON_TEXTURE: return = -14 
>    offset=0xe9e00000 
>    image width=258 height=130 
>     blit width=258 height=131 data=0x4506f200 
I'll look at it, but I'm pretty sure this is a different problem (though related
to the texture border raster fallback). When analyzing the segfaults I already
noticed that the driver will attempt to upload textures with borders which will
always cause a fallback to the gpu anyway, and wondered if it's actually safe to
do that. Looks like that's not the case...

I can reproduce a similar backtrace on radeon and r200 using neverball, which is
doing a rasterization fallback beacuse I'm running at 16bpp (no stencil).

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1214635360 (LWP 1346)]
0xb70559a6 in update_input_ptrs (ctx=0x0, start=0) at tnl/t_vertex.c:386
386           a[j].inputptr = ((GLubyte *)vptr->data) + start * vptr->stride;
(gdb) bt
#0  0xb70559a6 in update_input_ptrs (ctx=0x0, start=0) at tnl/t_vertex.c:386
#1  0xb7055a52 in _tnl_build_vertices (ctx=0x8110180, start=0, end=0,
newinputs=4294967295)
    at tnl/t_vertex.c:408
#2  0xb704a066 in run_render (ctx=0x8110180, stage=0x830d314) at
tnl/t_vb_render.c:295
#3  0xb70410b5 in _tnl_run_pipeline (ctx=0x8110180) at tnl/t_pipeline.c:159
#4  0xb6fba915 in r200WrapRunPipeline (ctx=0x8110180) at r200_state.c:2316
#5  0xb704640c in _tnl_playback_vertex_list (ctx=0x8110180, data=0x85e5198)
    at tnl/t_save_playback.c:209
#6  0xb6feccb3 in execute_list (ctx=0x8110180, list=135332224) at main/dlist.c:5679
#7  0xb6fef760 in _mesa_CallList (list=80) at main/dlist.c:6747
#8  0xb703a9e2 in neutral_CallList (i=0) at vtxfmt_tmp.h:301

(In reply to comment #9)
> I can reproduce a similar backtrace on radeon and r200 using neverball
I'll commit the fix if you don't come up with a better one, the radeon driver is
only affected since it was converted to t_vertex.

I was just noting the ability to reproduce, not saying something either way
about the patch.  I haven't looked into the patch.

Patch committed to CVS.  Thanks!

Mass version move, cvs -> git