Menu
▾
▴
mesa3d-dev
|
From: <ran...@gm...> - 2010-03-05 16:25:32
|
It segfaults right after start ....
#0 0x00000000 in ?? ()
No symbol table info available.
#1 0xb701b037 in _tnl_render_quad_strip_verts (ctx=0x88dba88, start=0,
count=42, flags=56) at tnl/t_vb_rendertmp.h:431
j = 3
tnl = <value optimized out>
QuadFunc = (const tnl_quad_func) 0
stipple = 0 '\0'
#2 0xb701c2cd in run_render (ctx=0x88dba88, stage=0x892edd8)
at tnl/t_vb_render.c:320
prim = <value optimized out>
start = 0
length = <value optimized out>
i = 0
tnl = (TNLcontext *) 0x892ebc8
tab = (tnl_render_func *) 0xb71821a0
pass = 0
__PRETTY_FUNCTION__ = "run_render"
#3 0xb7010467 in _tnl_run_pipeline (ctx=0x88dba88) at tnl/t_pipeline.c:153
tnl = (TNLcontext *) 0x892ec88
__tmp = 895
i = 8
#4 0xb701133e in _tnl_draw_prims (ctx=0x88dba88, arrays=0x891ce94,
prim=0x891b968, nr_prims=2, ib=0x0, min_index=0, max_index=83)
at tnl/t_draw.c:478
this_nr_prims = <value optimized out>
bo = {0xb7180bb4, 0x88dba88, 0x30, 0xbf9e0928, 0xb6f73ddc, 0x80000000,
0x1, 0x8c28218, 0xb6f700de, 0x8c1afd8, 0x0, 0x2, 0x40, 0x88dba88, 0x88f2718,
0xbf9e0968, 0xb6f701f7, 0x88dba88, 0x400000, 0xbf9e0968, 0xb6f7017e,
0x88dba88, 0x400000, 0xb769b50c, 0xb717fa80, 0xb769b65c, 0x88d0544,
0x60121df, 0xb7180bb4, 0x88dba88, 0x0, 0xbf9e09c8, 0xb6fdf83e}
nr_bo = 0
max_basevertex = <value optimized out>
i = <value optimized out>
__PRETTY_FUNCTION__ = "_tnl_draw_prims"
#5 0xb70116a9 in _tnl_vbo_draw_prims (ctx=0x88dba88, arrays=0x891ce94,
prim=0x891b968, nr_prims=2, ib=0x0, index_bounds_valid=1 '\001',
min_index=0, max_index=83) at tnl/t_draw.c:384
No locals.
#6 0xb7007913 in vbo_exec_vtx_flush (exec=0x891b838, unmap=1 '\001')
at vbo/vbo_exec_draw.c:384
ctx = (GLcontext *) 0x88dba88
#7 0xb70050ee in vbo_exec_FlushVertices_internal (ctx=0x88dba88,
unmap=136 '\210') at vbo/vbo_exec_api.c:872
exec = (struct vbo_exec_context *) 0x891b838
#8 0xb700518b in vbo_exec_FlushVertices (ctx=0x88dba88, flags=1)
at vbo/vbo_exec_api.c:906
No locals.
#9 0xb6fd49bc in _mesa_PopMatrix () at main/matrix.c:285
stack = (struct gl_matrix_stack *) 0x88dbfb4
#10 0x08049d89 in DrawCrankshaft (eng=0x8073f60) at engine.c:511
phiStep = 120
phi = -90
i = 0
z = 0.400000006
#11 0x0804b4b7 in Draw () at engine.c:528
rot = {{0.457617939, -0.388804674, 0.799635649, 0}, {-0.00557587016,
0.898054183, 0.439849645, 0}, {-0.889131725, -0.205741853, 0.408797771,
0}, {0, 0, 0, 1}}
#12 0xb771a537 in processWindowWorkList (window=0x88c9ba8) at
glut_event.c:1307
workMask = 4
__PRETTY_FUNCTION__ = "processWindowWorkList"
#13 0xb771b519 in glutMainLoop () at glut_event.c:1358
No locals.
#14 0x0804ae39 in main (argc=1, argv=0xbf9e0f54) at engine.c:1340
No locals.
|
|
From: Jesse B. <jb...@vi...> - 2010-03-05 16:55:12
|
make realclean and configure and make again.
On Fri, 5 Mar 2010 19:24:13 +0000
ran...@gm... wrote:
> It segfaults right after start ....
>
> #0 0x00000000 in ?? ()
> No symbol table info available.
> #1 0xb701b037 in _tnl_render_quad_strip_verts (ctx=0x88dba88, start=0,
> count=42, flags=56) at tnl/t_vb_rendertmp.h:431
> j = 3
> tnl = <value optimized out>
> QuadFunc = (const tnl_quad_func) 0
> stipple = 0 '\0'
> #2 0xb701c2cd in run_render (ctx=0x88dba88, stage=0x892edd8)
> at tnl/t_vb_render.c:320
> prim = <value optimized out>
> start = 0
> length = <value optimized out>
> i = 0
> tnl = (TNLcontext *) 0x892ebc8
> tab = (tnl_render_func *) 0xb71821a0
> pass = 0
> __PRETTY_FUNCTION__ = "run_render"
> #3 0xb7010467 in _tnl_run_pipeline (ctx=0x88dba88) at tnl/t_pipeline.c:153
> tnl = (TNLcontext *) 0x892ec88
> __tmp = 895
> i = 8
> #4 0xb701133e in _tnl_draw_prims (ctx=0x88dba88, arrays=0x891ce94,
> prim=0x891b968, nr_prims=2, ib=0x0, min_index=0, max_index=83)
> at tnl/t_draw.c:478
> this_nr_prims = <value optimized out>
> bo = {0xb7180bb4, 0x88dba88, 0x30, 0xbf9e0928, 0xb6f73ddc, 0x80000000,
> 0x1, 0x8c28218, 0xb6f700de, 0x8c1afd8, 0x0, 0x2, 0x40, 0x88dba88, 0x88f2718,
> 0xbf9e0968, 0xb6f701f7, 0x88dba88, 0x400000, 0xbf9e0968, 0xb6f7017e,
> 0x88dba88, 0x400000, 0xb769b50c, 0xb717fa80, 0xb769b65c, 0x88d0544,
> 0x60121df, 0xb7180bb4, 0x88dba88, 0x0, 0xbf9e09c8, 0xb6fdf83e}
> nr_bo = 0
> max_basevertex = <value optimized out>
> i = <value optimized out>
> __PRETTY_FUNCTION__ = "_tnl_draw_prims"
> #5 0xb70116a9 in _tnl_vbo_draw_prims (ctx=0x88dba88, arrays=0x891ce94,
> prim=0x891b968, nr_prims=2, ib=0x0, index_bounds_valid=1 '\001',
> min_index=0, max_index=83) at tnl/t_draw.c:384
> No locals.
> #6 0xb7007913 in vbo_exec_vtx_flush (exec=0x891b838, unmap=1 '\001')
> at vbo/vbo_exec_draw.c:384
> ctx = (GLcontext *) 0x88dba88
> #7 0xb70050ee in vbo_exec_FlushVertices_internal (ctx=0x88dba88,
> unmap=136 '\210') at vbo/vbo_exec_api.c:872
> exec = (struct vbo_exec_context *) 0x891b838
> #8 0xb700518b in vbo_exec_FlushVertices (ctx=0x88dba88, flags=1)
> at vbo/vbo_exec_api.c:906
> No locals.
> #9 0xb6fd49bc in _mesa_PopMatrix () at main/matrix.c:285
> stack = (struct gl_matrix_stack *) 0x88dbfb4
> #10 0x08049d89 in DrawCrankshaft (eng=0x8073f60) at engine.c:511
> phiStep = 120
> phi = -90
> i = 0
> z = 0.400000006
> #11 0x0804b4b7 in Draw () at engine.c:528
> rot = {{0.457617939, -0.388804674, 0.799635649, 0}, {-0.00557587016,
> 0.898054183, 0.439849645, 0}, {-0.889131725, -0.205741853, 0.408797771,
> 0}, {0, 0, 0, 1}}
> #12 0xb771a537 in processWindowWorkList (window=0x88c9ba8) at
> glut_event.c:1307
> workMask = 4
> __PRETTY_FUNCTION__ = "processWindowWorkList"
> #13 0xb771b519 in glutMainLoop () at glut_event.c:1358
> No locals.
> #14 0x0804ae39 in main (argc=1, argv=0xbf9e0f54) at engine.c:1340
> No locals.
--
Jesse Barnes, Intel Open Source Technology Center
|
|
From: <ran...@gm...> - 2010-03-05 23:00:47
|
В сообщении от Friday 05 March 2010 16:55:20 Jesse Barnes написал(а):
> make realclean and configure and make again.
Removing all new functions and reverting to mainstream mesa works OK, even
without realclean ... So, it is purely my fault, as coder. But what exactly I
forgot? Init current_primitive = -1 on context creation? State management in
nouveau changed since first dri1 attempt ....
As far as i understand this code - you plug in not just fev line functions
but two big function tables, filled with many functions (pointers at
functions). This way one can plug in much more optimized (for different
OpenGL cases) render functions, if hw permits this. So, you plug inly
one "Chooser" function into mesa's TNL module, and keep current primitive
type somewhere in your context data .....
Ideally, various fixups (like polygonOffset) will be layred on top of this,
making nv04.render.c a bit hard for reading ...
Thanks Jesse and Francisco for your time, you spended reading my mails and
trying to figure out what was my fault ....
>
> On Fri, 5 Mar 2010 19:24:13 +0000
>
> ran...@gm... wrote:
> > It segfaults right after start ....
> >
> > #0 0x00000000 in ?? ()
> > No symbol table info available.
> > #1 0xb701b037 in _tnl_render_quad_strip_verts (ctx=0x88dba88, start=0,
> > count=42, flags=56) at tnl/t_vb_rendertmp.h:431
> > j = 3
> > tnl = <value optimized out>
> > QuadFunc = (const tnl_quad_func) 0
> > stipple = 0 '\0'
> > #2 0xb701c2cd in run_render (ctx=0x88dba88, stage=0x892edd8)
> > at tnl/t_vb_render.c:320
> > prim = <value optimized out>
> > start = 0
> > length = <value optimized out>
> > i = 0
> > tnl = (TNLcontext *) 0x892ebc8
> > tab = (tnl_render_func *) 0xb71821a0
> > pass = 0
> > __PRETTY_FUNCTION__ = "run_render"
> > #3 0xb7010467 in _tnl_run_pipeline (ctx=0x88dba88) at
> > tnl/t_pipeline.c:153 tnl = (TNLcontext *) 0x892ec88
> > __tmp = 895
> > i = 8
> > #4 0xb701133e in _tnl_draw_prims (ctx=0x88dba88, arrays=0x891ce94,
> > prim=0x891b968, nr_prims=2, ib=0x0, min_index=0, max_index=83)
> > at tnl/t_draw.c:478
> > this_nr_prims = <value optimized out>
> > bo = {0xb7180bb4, 0x88dba88, 0x30, 0xbf9e0928, 0xb6f73ddc,
> > 0x80000000, 0x1, 0x8c28218, 0xb6f700de, 0x8c1afd8, 0x0, 0x2, 0x40,
> > 0x88dba88, 0x88f2718, 0xbf9e0968, 0xb6f701f7, 0x88dba88, 0x400000,
> > 0xbf9e0968, 0xb6f7017e, 0x88dba88, 0x400000, 0xb769b50c, 0xb717fa80,
> > 0xb769b65c, 0x88d0544, 0x60121df, 0xb7180bb4, 0x88dba88, 0x0, 0xbf9e09c8,
> > 0xb6fdf83e} nr_bo = 0
> > max_basevertex = <value optimized out>
> > i = <value optimized out>
> > __PRETTY_FUNCTION__ = "_tnl_draw_prims"
> > #5 0xb70116a9 in _tnl_vbo_draw_prims (ctx=0x88dba88, arrays=0x891ce94,
> > prim=0x891b968, nr_prims=2, ib=0x0, index_bounds_valid=1 '\001',
> > min_index=0, max_index=83) at tnl/t_draw.c:384
> > No locals.
> > #6 0xb7007913 in vbo_exec_vtx_flush (exec=0x891b838, unmap=1 '\001')
> > at vbo/vbo_exec_draw.c:384
> > ctx = (GLcontext *) 0x88dba88
> > #7 0xb70050ee in vbo_exec_FlushVertices_internal (ctx=0x88dba88,
> > unmap=136 '\210') at vbo/vbo_exec_api.c:872
> > exec = (struct vbo_exec_context *) 0x891b838
> > #8 0xb700518b in vbo_exec_FlushVertices (ctx=0x88dba88, flags=1)
> > at vbo/vbo_exec_api.c:906
> > No locals.
> > #9 0xb6fd49bc in _mesa_PopMatrix () at main/matrix.c:285
> > stack = (struct gl_matrix_stack *) 0x88dbfb4
> > #10 0x08049d89 in DrawCrankshaft (eng=0x8073f60) at engine.c:511
> > phiStep = 120
> > phi = -90
> > i = 0
> > z = 0.400000006
> > #11 0x0804b4b7 in Draw () at engine.c:528
> > rot = {{0.457617939, -0.388804674, 0.799635649, 0},
> > {-0.00557587016, 0.898054183, 0.439849645, 0}, {-0.889131725,
> > -0.205741853, 0.408797771, 0}, {0, 0, 0, 1}}
> > #12 0xb771a537 in processWindowWorkList (window=0x88c9ba8) at
> > glut_event.c:1307
> > workMask = 4
> > __PRETTY_FUNCTION__ = "processWindowWorkList"
> > #13 0xb771b519 in glutMainLoop () at glut_event.c:1358
> > No locals.
> > #14 0x0804ae39 in main (argc=1, argv=0xbf9e0f54) at engine.c:1340
> > No locals.
|
|
From: Stephane M. <ste...@gm...> - 2010-03-05 23:49:12
|
2010/3/5 <ran...@gm...>: > В сообщении от Friday 05 March 2010 16:55:20 Jesse Barnes написал(а): >> make realclean and configure and make again. > > > Removing all new functions and reverting to mainstream mesa works OK, even > without realclean ... So, it is purely my fault, as coder. But what exactly I > forgot? Init current_primitive = -1 on context creation? State management in > nouveau changed since first dri1 attempt .... > > As far as i understand this code - you plug in not just fev line functions > but two big function tables, filled with many functions (pointers at > functions). This way one can plug in much more optimized (for different > OpenGL cases) render functions, if hw permits this. So, you plug inly > one "Chooser" function into mesa's TNL module, and keep current primitive > type somewhere in your context data ..... > > Ideally, various fixups (like polygonOffset) will be layred on top of this, > making nv04.render.c a bit hard for reading ... > > Thanks Jesse and Francisco for your time, you spended reading my mails and > trying to figure out what was my fault .... > As discussed on irc, and for posterity: 00:35 < marcheu> you have a 16 or 8 (with multitexture) vertex cache 00:35 < marcheu> these number you see (0xFEDCBA) are not magic 00:35 < marcheu> these are the index of the vertices we want to emit 00:36 < marcheu> so FEDCBA emits vertices 15,14,13,12,11 and 10 00:36 < marcheu> but that means you have to actually place data at these locations 00:37 < marcheu> which means that if you want to do a single-pass emission you have to place the first vertex at spot 10 00:37 < marcheu> so basically the layout of the nv4 3D object is like that: 00:37 < marcheu> - vertex 0 00:37 < marcheu> - vertex 1 00:37 < marcheu> ... 00:37 < marcheu> - vertex 15 00:38 < marcheu> - vertex indices that we want fired 00:38 < marcheu> so if you want to do a 1-swoop submission, you have to start from 10 or so 00:38 < marcheu> that also means you _place_ vertex data at the right spot. right now you place it at 0 00:39 < marcheu> also you reserve one too little places on the fifo (6 instead of 7 on line 206) 00:39 < marcheu> becuase you need one spot for the FEDCBA 00:39 < marcheu> so you need 3 things: 00:39 < marcheu> - start emitting at the right place, which probably means an extra argument to BEGIN_PRIMITIVE to tell which place 00:40 < marcheu> - increase the size of the BEGIN_PRIMITIVE 00:40 < marcheu> - that was only two things :) Stephane |
|
From: <ran...@gm...> - 2010-03-06 21:46:19
|
В сообщении от Friday 05 March 2010 23:49:03 Stephane Marchesin написал(а):
> 2010/3/5 <ran...@gm...>:
> > В сообщении от Friday 05 March 2010 16:55:20 Jesse Barnes написал(а):
> >> make realclean and configure and make again.
> >
> > Removing all new functions and reverting to mainstream mesa works OK,
> > even without realclean ... So, it is purely my fault, as coder. But what
> > exactly I forgot? Init current_primitive = -1 on context creation? State
> > management in nouveau changed since first dri1 attempt ....
> >
> > As far as i understand this code - you plug in not just fev line
> > functions but two big function tables, filled with many functions
> > (pointers at functions). This way one can plug in much more optimized
> > (for different OpenGL cases) render functions, if hw permits this. So,
> > you plug inly one "Chooser" function into mesa's TNL module, and keep
> > current primitive type somewhere in your context data .....
> >
> > Ideally, various fixups (like polygonOffset) will be layred on top of
> > this, making nv04.render.c a bit hard for reading ...
> >
> > Thanks Jesse and Francisco for your time, you spended reading my mails
> > and trying to figure out what was my fault ....
>
> As discussed on irc, and for posterity:
>
> 00:35 < marcheu> you have a 16 or 8 (with multitexture) vertex cache
> 00:35 < marcheu> these number you see (0xFEDCBA) are not magic
> 00:35 < marcheu> these are the index of the vertices we want to emit
> 00:36 < marcheu> so FEDCBA emits vertices 15,14,13,12,11 and 10
> 00:36 < marcheu> but that means you have to actually place data at
> these locations
> 00:37 < marcheu> which means that if you want to do a single-pass
> emission you have to place the first vertex at spot 10
> 00:37 < marcheu> so basically the layout of the nv4 3D object is like that:
> 00:37 < marcheu> - vertex 0
> 00:37 < marcheu> - vertex 1
> 00:37 < marcheu> ...
> 00:37 < marcheu> - vertex 15
> 00:38 < marcheu> - vertex indices that we want fired
> 00:38 < marcheu> so if you want to do a 1-swoop submission, you have
> to start from 10 or so
> 00:38 < marcheu> that also means you _place_ vertex data at the right
> spot. right now you place it at 0
> 00:39 < marcheu> also you reserve one too little places on the fifo (6
> instead of 7 on line 206)
> 00:39 < marcheu> becuase you need one spot for the FEDCBA
> 00:39 < marcheu> so you need 3 things:
> 00:39 < marcheu> - start emitting at the right place, which probably
> means an extra argument to BEGIN_PRIMITIVE to tell which place
> 00:40 < marcheu> - increase the size of the BEGIN_PRIMITIVE
> 00:40 < marcheu> - that was only two things :)
>
> Stephane
New patch is here, tested with trivial/tri, DANGEROUS, may lock up your
machine hard with anything else!
Strange thing about code - in function swtnl_render_triangles_verts it was
going on and on, causing segfault, until i added
if (count == 3)
{
swtnl_triangle(ctx, i+0,i+1,i+2);
return;
}
Was found under gdb
=======
swtnl_render_triangles_verts (ctx=0x950ca88, start=0, count=3, flags=52)
at nv04_render.c:285
285 for(i=start;i<count-5;i+=6)
(gdb) print i
$1 = 18
=======
Please, someone, enlight me on this small C secret, what was wrong in this
for() ?
|
|
From: Mike K. <mik...@gm...> - 2010-03-07 20:15:21
|
2010/3/6 <ran...@gm...>:
> В сообщении от Friday 05 March 2010 23:49:03 Stephane Marchesin написал(а):
>> 2010/3/5 <ran...@gm...>:
>> > В сообщении от Friday 05 March 2010 16:55:20 Jesse Barnes написал(а):
>> >> make realclean and configure and make again.
>> >
>> > Removing all new functions and reverting to mainstream mesa works OK,
>> > even without realclean ... So, it is purely my fault, as coder. But what
>> > exactly I forgot? Init current_primitive = -1 on context creation? State
>> > management in nouveau changed since first dri1 attempt ....
>> >
>> > As far as i understand this code - you plug in not just fev line
>> > functions but two big function tables, filled with many functions
>> > (pointers at functions). This way one can plug in much more optimized
>> > (for different OpenGL cases) render functions, if hw permits this. So,
>> > you plug inly one "Chooser" function into mesa's TNL module, and keep
>> > current primitive type somewhere in your context data .....
>> >
>> > Ideally, various fixups (like polygonOffset) will be layred on top of
>> > this, making nv04.render.c a bit hard for reading ...
>> >
>> > Thanks Jesse and Francisco for your time, you spended reading my mails
>> > and trying to figure out what was my fault ....
>>
>> As discussed on irc, and for posterity:
>>
>> 00:35 < marcheu> you have a 16 or 8 (with multitexture) vertex cache
>> 00:35 < marcheu> these number you see (0xFEDCBA) are not magic
>> 00:35 < marcheu> these are the index of the vertices we want to emit
>> 00:36 < marcheu> so FEDCBA emits vertices 15,14,13,12,11 and 10
>> 00:36 < marcheu> but that means you have to actually place data at
>> these locations
>> 00:37 < marcheu> which means that if you want to do a single-pass
>> emission you have to place the first vertex at spot 10
>> 00:37 < marcheu> so basically the layout of the nv4 3D object is like that:
>> 00:37 < marcheu> - vertex 0
>> 00:37 < marcheu> - vertex 1
>> 00:37 < marcheu> ...
>> 00:37 < marcheu> - vertex 15
>> 00:38 < marcheu> - vertex indices that we want fired
>> 00:38 < marcheu> so if you want to do a 1-swoop submission, you have
>> to start from 10 or so
>> 00:38 < marcheu> that also means you _place_ vertex data at the right
>> spot. right now you place it at 0
>> 00:39 < marcheu> also you reserve one too little places on the fifo (6
>> instead of 7 on line 206)
>> 00:39 < marcheu> becuase you need one spot for the FEDCBA
>> 00:39 < marcheu> so you need 3 things:
>> 00:39 < marcheu> - start emitting at the right place, which probably
>> means an extra argument to BEGIN_PRIMITIVE to tell which place
>> 00:40 < marcheu> - increase the size of the BEGIN_PRIMITIVE
>> 00:40 < marcheu> - that was only two things :)
>>
>> Stephane
>
> New patch is here, tested with trivial/tri, DANGEROUS, may lock up your
> machine hard with anything else!
>
> Strange thing about code - in function swtnl_render_triangles_verts it was
> going on and on, causing segfault, until i added
>
> if (count == 3)
> {
> swtnl_triangle(ctx, i+0,i+1,i+2);
> return;
> }
>
>
> Was found under gdb
>
> =======
>
> swtnl_render_triangles_verts (ctx=0x950ca88, start=0, count=3, flags=52)
> at nv04_render.c:285
> 285 for(i=start;i<count-5;i+=6)
> (gdb) print i
> $1 = 18
>
> =======
>
> Please, someone, enlight me on this small C secret, what was wrong in this
> for() ?
>
count is GLuint, i.e. unsigned. If count < 5, count-5 ~ around 4
billion due to overflow. Changing the check to i+5 < count should make
it work.
Mike.
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X