Re: Segfault on RTCW with Savage
On Wed, 06 Oct 2004 15:28:21 -0700
Eric Anholt [EMAIL PROTECTED] wrote:
On Wed, 2004-10-06 at 13:09, Felix Kühling wrote:
On Wed, 6 Oct 2004 22:03:40 +0200
Felix Kühling [EMAIL PROTECTED] wrote:
[snip]
You're right. Thanks for catching this. I tried to understand what
force_emit in the i830 driver was for, now I understand. An updated
patch is attached. I'm going to commit that.
Still wrong. Sorry. :-/ I can't just use the index because the vertex
format also depends on the number of texture coordinates which is not
reflected in the index. I could go abuse some more unused texture bits,
but I think I'll come up with my own savage-specific bit field. I should
get some sleep before I trying to fix any more bugs.
Ouch. Indeed. I wonder how expensive tnl_install_attrs is -- might we
want to just always do it?
The attached patch is what I committed. When I looked at the diff I
stumbled over this definition, which looks the same in r128 and i830:
#define EMIT_PAD( N ) \
do {\
imesa-vertex_attrs[imesa-vertex_attr_count].attrib = 0;\
imesa-vertex_attrs[imesa-vertex_attr_count].format = EMIT_PAD; \
imesa-vertex_attrs[imesa-vertex_attr_count].offset = (N); \
imesa-vertex_attr_count++; \
} while (0)
It looks like EMIT_PAD is overloaded here, once as a macro with argument
and once without. I didn't know cpp supports overloading. Is this a
gcc-extension or are we just lucky that it works?
| Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu |
| PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 |
Index: savagetris.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/savage/savagetris.c,v
retrieving revision 1.12
diff -u -r1.12 savagetris.c
--- savagetris.c1 Jul 2004 13:14:06 - 1.12
+++ savagetris.c7 Oct 2004 10:03:36 -
@@ -707,20 +707,43 @@
}
-#define EMIT_ATTR( ATTR, STYLE, SKIP ) \
+#define EMIT_ATTR( ATTR, STYLE, INDEX, SKIP ) \
do { \
imesa-vertex_attrs[imesa-vertex_attr_count].attrib = (ATTR); \
imesa-vertex_attrs[imesa-vertex_attr_count].format = (STYLE); \
imesa-vertex_attr_count++; \
- drawCmd = ~SKIP; \
+ setupIndex |= (INDEX); \
+ drawCmd = ~(SKIP); \
} while (0)
+#define EMIT_PAD( N ) \
+do { \
+ imesa-vertex_attrs[imesa-vertex_attr_count].attrib = 0; \
+ imesa-vertex_attrs[imesa-vertex_attr_count].format = EMIT_PAD;\
+ imesa-vertex_attrs[imesa-vertex_attr_count].offset = (N); \
+ imesa-vertex_attr_count++; \
+} while (0)
+
+#define SAVAGE_EMIT_XYZ 0x0001
+#define SAVAGE_EMIT_W 0x0002
+#define SAVAGE_EMIT_C0 0x0004
+#define SAVAGE_EMIT_C1 0x0008
+#define SAVAGE_EMIT_FOG 0x0010
+#define SAVAGE_EMIT_S0 0x0020
+#define SAVAGE_EMIT_T0 0x0040
+#define SAVAGE_EMIT_ST0 0x0060
+#define SAVAGE_EMIT_S1 0x0080
+#define SAVAGE_EMIT_T1 0x0100
+#define SAVAGE_EMIT_ST1 0x0180
+
+
static void savageRenderStart( GLcontext *ctx )
{
savageContextPtr imesa = SAVAGE_CONTEXT(ctx);
TNLcontext *tnl = TNL_CONTEXT(ctx);
struct vertex_buffer *VB = tnl-vb;
GLuint index = tnl-render_inputs;
+ GLuint setupIndex = SAVAGE_EMIT_XYZ;
GLuint drawCmd = SAVAGE_HW_SKIPFLAGS;
if (imesa-savageScreen-chipset S3_SAVAGE4)
drawCmd = ~SAVAGE_HW_NO_UV1;
@@ -735,18 +758,24 @@
* build up a hardware vertex.
*/
if ((index _TNL_BITS_TEX_ANY) || !(ctx-_TriangleCaps DD_FLATSHADE)) {
- EMIT_ATTR( _TNL_ATTRIB_POS, EMIT_4F_VIEWPORT, SAVAGE_HW_NO_W );
+ EMIT_ATTR( _TNL_ATTRIB_POS, EMIT_4F_VIEWPORT, SAVAGE_EMIT_W, SAVAGE_HW_NO_W );
}
else {
- EMIT_ATTR( _TNL_ATTRIB_POS, EMIT_3F_VIEWPORT, 0 );
+ EMIT_ATTR( _TNL_ATTRIB_POS, EMIT_3F_VIEWPORT, 0, 0 );
}
/* t_context.c always includes a diffuse color */
- EMIT_ATTR( _TNL_ATTRIB_COLOR0, EMIT_4UB_4F_BGRA, SAVAGE_HW_NO_CD );
+ EMIT_ATTR( _TNL_ATTRIB_COLOR0, EMIT_4UB_4F_BGRA, SAVAGE_EMIT_C0, SAVAGE_HW_NO_CD );
if (index (_TNL_BIT_COLOR1|_TNL_BIT_FOG)) {
- EMIT_ATTR( _TNL_ATTRIB_COLOR1, EMIT_3UB_3F_BGR, SAVAGE_HW_NO_CS );
- EMIT_ATTR( _TNL_ATTRIB_FOG, EMIT_1UB_1F, SAVAGE_HW_NO_CS );
+ if ((index _TNL_BIT_COLOR1))
+EMIT_ATTR( _TNL_ATTRIB_COLOR1, EMIT_3UB_3F_BGR, SAVAGE_EMIT_C1,
SAVAGE_HW_NO_CS );
+
Re: Segfault on RTCW with Savage
Felix Kühling wrote:
On Wed, 06 Oct 2004 15:28:21 -0700
Eric Anholt [EMAIL PROTECTED] wrote:
On Wed, 2004-10-06 at 13:09, Felix Kühling wrote:
On Wed, 6 Oct 2004 22:03:40 +0200
Felix Kühling [EMAIL PROTECTED] wrote:
[snip]
You're right. Thanks for catching this. I tried to understand what
force_emit in the i830 driver was for, now I understand. An updated
patch is attached. I'm going to commit that.
Still wrong. Sorry. :-/ I can't just use the index because the vertex
format also depends on the number of texture coordinates which is not
reflected in the index. I could go abuse some more unused texture bits,
but I think I'll come up with my own savage-specific bit field. I should
get some sleep before I trying to fix any more bugs.
Ouch. Indeed. I wonder how expensive tnl_install_attrs is -- might we
want to just always do it?
The attached patch is what I committed. When I looked at the diff I
stumbled over this definition, which looks the same in r128 and i830:
#define EMIT_PAD( N ) \
do {\
imesa-vertex_attrs[imesa-vertex_attr_count].attrib = 0;\
imesa-vertex_attrs[imesa-vertex_attr_count].format = EMIT_PAD; \
imesa-vertex_attrs[imesa-vertex_attr_count].offset = (N); \
imesa-vertex_attr_count++; \
} while (0)
It looks like EMIT_PAD is overloaded here, once as a macro with argument
and once without. I didn't know cpp supports overloading. Is this a
gcc-extension or are we just lucky that it works?
Good catch - even though it works, it would be better to avoid this give the
macro a new name.
Keith
---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Segfault on RTCW with Savage
On Mon, 04 Oct 2004 12:09:09 +0100
Keith Whitwell [EMAIL PROTECTED] wrote:
John,
I'd say the problem is with these lines in savagetris.c:
if (index (_TNL_BIT_COLOR1|_TNL_BIT_FOG)) {
EMIT_ATTR( _TNL_ATTRIB_COLOR1, EMIT_3UB_3F_BGR, SAVAGE_HW_NO_CS );
EMIT_ATTR( _TNL_ATTRIB_FOG, EMIT_1UB_1F, SAVAGE_HW_NO_CS );
}
This is a cut and paste of old code from another driver. Have a look at how
other drivers handle this now to avoid trying to emit FOG when only COLOR1 is
enabled, and vice versa.
Is there a simpler test case than RTCW? I can't reproduce a segfault
with a simple program that draws triangles with diffuse lighting and
Fog. John, can you try if the attached patch fixes it?
Keith
Regards,
Felix
| Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu |
| PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 |
Index: savagetris.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/savage/savagetris.c,v
retrieving revision 1.12
diff -u -r1.12 savagetris.c
--- savagetris.c1 Jul 2004 13:14:06 - 1.12
+++ savagetris.c6 Oct 2004 11:46:34 -
@@ -715,6 +715,15 @@
drawCmd = ~SKIP; \
} while (0)
+#define EMIT_PAD( N ) \
+do { \
+ imesa-vertex_attrs[imesa-vertex_attr_count].attrib = 0; \
+ imesa-vertex_attrs[imesa-vertex_attr_count].format = EMIT_PAD;\
+ imesa-vertex_attrs[imesa-vertex_attr_count].offset = (N); \
+ imesa-vertex_attr_count++; \
+} while (0)
+
+
static void savageRenderStart( GLcontext *ctx )
{
savageContextPtr imesa = SAVAGE_CONTEXT(ctx);
@@ -745,8 +754,14 @@
EMIT_ATTR( _TNL_ATTRIB_COLOR0, EMIT_4UB_4F_BGRA, SAVAGE_HW_NO_CD );
if (index (_TNL_BIT_COLOR1|_TNL_BIT_FOG)) {
- EMIT_ATTR( _TNL_ATTRIB_COLOR1, EMIT_3UB_3F_BGR, SAVAGE_HW_NO_CS );
- EMIT_ATTR( _TNL_ATTRIB_FOG, EMIT_1UB_1F, SAVAGE_HW_NO_CS );
+ if ((index _TNL_BIT_COLOR1))
+EMIT_ATTR( _TNL_ATTRIB_COLOR1, EMIT_3UB_3F_BGR, SAVAGE_HW_NO_CS );
+ else
+EMIT_PAD( 3 );
+ if ((index _TNL_BIT_FOG))
+EMIT_ATTR( _TNL_ATTRIB_FOG, EMIT_1UB_1F, SAVAGE_HW_NO_CS );
+ else
+EMIT_PAD( 1 );
}
if (index _TNL_BIT_TEX(0)) {
Re: Segfault on RTCW with Savage
On Wed, 2004-10-06 at 04:54, Felix Kühling wrote:
On Mon, 04 Oct 2004 12:09:09 +0100
Keith Whitwell [EMAIL PROTECTED] wrote:
John,
I'd say the problem is with these lines in savagetris.c:
if (index (_TNL_BIT_COLOR1|_TNL_BIT_FOG)) {
EMIT_ATTR( _TNL_ATTRIB_COLOR1, EMIT_3UB_3F_BGR, SAVAGE_HW_NO_CS );
EMIT_ATTR( _TNL_ATTRIB_FOG, EMIT_1UB_1F, SAVAGE_HW_NO_CS );
}
This is a cut and paste of old code from another driver. Have a look at how
other drivers handle this now to avoid trying to emit FOG when only COLOR1 is
enabled, and vice versa.
Is there a simpler test case than RTCW? I can't reproduce a segfault
with a simple program that draws triangles with diffuse lighting and
Fog. John, can you try if the attached patch fixes it?
One thing to note is, what happens if you change from, say,
specular-without-fog to specular-with-fog? You won't end up doing the
install_attrs again like you want. For Rage 128, I just stored the
index in the context and checked if that had changed, instead of the
vertex format register's value.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Segfault on RTCW with Savage
On Wed, 06 Oct 2004 10:16:23 -0700
Eric Anholt [EMAIL PROTECTED] wrote:
On Wed, 2004-10-06 at 04:54, Felix Kühling wrote:
On Mon, 04 Oct 2004 12:09:09 +0100
Keith Whitwell [EMAIL PROTECTED] wrote:
John,
I'd say the problem is with these lines in savagetris.c:
if (index (_TNL_BIT_COLOR1|_TNL_BIT_FOG)) {
EMIT_ATTR( _TNL_ATTRIB_COLOR1, EMIT_3UB_3F_BGR, SAVAGE_HW_NO_CS );
EMIT_ATTR( _TNL_ATTRIB_FOG, EMIT_1UB_1F, SAVAGE_HW_NO_CS );
}
This is a cut and paste of old code from another driver. Have a look at how
other drivers handle this now to avoid trying to emit FOG when only COLOR1 is
enabled, and vice versa.
Is there a simpler test case than RTCW? I can't reproduce a segfault
with a simple program that draws triangles with diffuse lighting and
Fog. John, can you try if the attached patch fixes it?
One thing to note is, what happens if you change from, say,
specular-without-fog to specular-with-fog? You won't end up doing the
install_attrs again like you want. For Rage 128, I just stored the
index in the context and checked if that had changed, instead of the
vertex format register's value.
You're right. Thanks for catching this. I tried to understand what
force_emit in the i830 driver was for, now I understand. An updated
patch is attached. I'm going to commit that.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
| Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu |
| PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 |
Index: savagetris.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/savage/savagetris.c,v
retrieving revision 1.12
diff -u -r1.12 savagetris.c
--- savagetris.c1 Jul 2004 13:14:06 - 1.12
+++ savagetris.c6 Oct 2004 19:58:10 -
@@ -715,6 +715,15 @@
drawCmd = ~SKIP; \
} while (0)
+#define EMIT_PAD( N ) \
+do { \
+ imesa-vertex_attrs[imesa-vertex_attr_count].attrib = 0; \
+ imesa-vertex_attrs[imesa-vertex_attr_count].format = EMIT_PAD;\
+ imesa-vertex_attrs[imesa-vertex_attr_count].offset = (N); \
+ imesa-vertex_attr_count++; \
+} while (0)
+
+
static void savageRenderStart( GLcontext *ctx )
{
savageContextPtr imesa = SAVAGE_CONTEXT(ctx);
@@ -736,6 +745,11 @@
*/
if ((index _TNL_BITS_TEX_ANY) || !(ctx-_TriangleCaps DD_FLATSHADE)) {
EMIT_ATTR( _TNL_ATTRIB_POS, EMIT_4F_VIEWPORT, SAVAGE_HW_NO_W );
+ /* We use index below to check if the emit code changed. Since
+ * we're depending on something outside the index here we need
+ * to make sure index reflects the change in the emit
+ * code. Using an otherwise unused bit. */
+ index |= _TNL_BIT_TEX7;
}
else {
EMIT_ATTR( _TNL_ATTRIB_POS, EMIT_3F_VIEWPORT, 0 );
@@ -745,8 +759,14 @@
EMIT_ATTR( _TNL_ATTRIB_COLOR0, EMIT_4UB_4F_BGRA, SAVAGE_HW_NO_CD );
if (index (_TNL_BIT_COLOR1|_TNL_BIT_FOG)) {
- EMIT_ATTR( _TNL_ATTRIB_COLOR1, EMIT_3UB_3F_BGR, SAVAGE_HW_NO_CS );
- EMIT_ATTR( _TNL_ATTRIB_FOG, EMIT_1UB_1F, SAVAGE_HW_NO_CS );
+ if ((index _TNL_BIT_COLOR1))
+EMIT_ATTR( _TNL_ATTRIB_COLOR1, EMIT_3UB_3F_BGR, SAVAGE_HW_NO_CS );
+ else
+EMIT_PAD( 3 );
+ if ((index _TNL_BIT_FOG))
+EMIT_ATTR( _TNL_ATTRIB_FOG, EMIT_1UB_1F, SAVAGE_HW_NO_CS );
+ else
+EMIT_PAD( 1 );
}
if (index _TNL_BIT_TEX(0)) {
@@ -770,19 +790,16 @@
EMIT_ATTR( _TNL_ATTRIB_TEX1, EMIT_1F, SAVAGE_HW_NO_U1 );
}
- /* Only need to change the vertex emit code if there has been a
-* statechange to a new hardware vertex format and also when the
-* vertex format is set for the first time. This is indicated by
-* imesa-vertex_size == 0.
-*/
- if (drawCmd != (imesa-DrawPrimitiveCmd SAVAGE_HW_SKIPFLAGS) ||
- imesa-vertex_size == 0) {
+ /* Need to change the vertex emit code if the SetupIndex changed or
+* is set for the first time (indicated by vertex_size == 0). */
+ if (index != imesa-SetupIndex || imesa-vertex_size == 0) {
imesa-vertex_size =
_tnl_install_attrs( ctx,
imesa-vertex_attrs,
imesa-vertex_attr_count,
imesa-hw_viewport, 0 );
imesa-vertex_size = 2;
+ imesa-SetupIndex = index;
imesa-DrawPrimitiveCmd = drawCmd;
}
@@ -802,7 +819,8 @@
/* Flush the last primitive now, before any state is changed.
* Alternatively state could be emitted in all state-changing
-* functions in savagestate.c. */
+* functions
Re: Segfault on RTCW with Savage
On Wed, 6 Oct 2004 22:03:40 +0200 Felix Kühling [EMAIL PROTECTED] wrote: [snip] You're right. Thanks for catching this. I tried to understand what force_emit in the i830 driver was for, now I understand. An updated patch is attached. I'm going to commit that. Still wrong. Sorry. :-/ I can't just use the index because the vertex format also depends on the number of texture coordinates which is not reflected in the index. I could go abuse some more unused texture bits, but I think I'll come up with my own savage-specific bit field. I should get some sleep before I trying to fix any more bugs. Later, Felix | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Segfault on RTCW with Savage
On Wednesday 06 October 2004 06:54, Felix Kühling wrote:
On Mon, 04 Oct 2004 12:09:09 +0100
Keith Whitwell [EMAIL PROTECTED] wrote:
John,
I'd say the problem is with these lines in savagetris.c:
if (index (_TNL_BIT_COLOR1|_TNL_BIT_FOG)) {
EMIT_ATTR( _TNL_ATTRIB_COLOR1, EMIT_3UB_3F_BGR, SAVAGE_HW_NO_CS );
EMIT_ATTR( _TNL_ATTRIB_FOG, EMIT_1UB_1F, SAVAGE_HW_NO_CS );
}
This is a cut and paste of old code from another driver. Have a look at
how other drivers handle this now to avoid trying to emit FOG when only
COLOR1 is enabled, and vice versa.
Is there a simpler test case than RTCW? I can't reproduce a segfault
with a simple program that draws triangles with diffuse lighting and
Fog. John, can you try if the attached patch fixes it?
Your patch does fix the problem. The checkpoint demo loads and runs without
problems now.
John
---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Segfault on RTCW with Savage
On Wed, 2004-10-06 at 13:09, Felix Kühling wrote: On Wed, 6 Oct 2004 22:03:40 +0200 Felix Kühling [EMAIL PROTECTED] wrote: [snip] You're right. Thanks for catching this. I tried to understand what force_emit in the i830 driver was for, now I understand. An updated patch is attached. I'm going to commit that. Still wrong. Sorry. :-/ I can't just use the index because the vertex format also depends on the number of texture coordinates which is not reflected in the index. I could go abuse some more unused texture bits, but I think I'll come up with my own savage-specific bit field. I should get some sleep before I trying to fix any more bugs. Ouch. Indeed. I wonder how expensive tnl_install_attrs is -- might we want to just always do it? -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Segfault on RTCW with Savage
John,
I'd say the problem is with these lines in savagetris.c:
if (index (_TNL_BIT_COLOR1|_TNL_BIT_FOG)) {
EMIT_ATTR( _TNL_ATTRIB_COLOR1, EMIT_3UB_3F_BGR, SAVAGE_HW_NO_CS );
EMIT_ATTR( _TNL_ATTRIB_FOG, EMIT_1UB_1F, SAVAGE_HW_NO_CS );
}
This is a cut and paste of old code from another driver. Have a look at how
other drivers handle this now to avoid trying to emit FOG when only COLOR1 is
enabled, and vice versa.
Keith
John Lightsey wrote:
On Friday 01 October 2004 04:03, Keith Whitwell wrote:
John Lightsey wrote:
A while back I mentioned on dri-devel that Savage cards will segfault
RTCW while loading the Checkpoint demo.
( http://www.nixnuts.net/benchmarks/current/ ) The problem is in
Mesa/src/mesa/tnl/t_tertex.c around lines 741 and 913.
for (j = 0; j count; j++) {
GLvector4f *vptr = VB-AttribPtr[a[j].attrib];
a[j].inputstride = vptr-stride;
...
}
vptr is null in the middle of the for loop ( j=2 is null j=0, 1, and 3 is
valid.) I have no idea why this is the case, but I've attached a simple
fix which eliminates the problem.
Does anyone see this in other hardware? If it's only the savage driver
causing this, I would say there's probably a bug in the driver somewhere.
What are the values of j, count and a[j] at the time of the crash?
I didn't see the problem with any other hardware, but RTCW refused to run with
r128 and sis 305, the last time I tried.
GDB's output seems a bit confused. After the segfault j=3
VB-AttribPtr[a[j].attrib] is a valid pointer, but vptr is null. It looks
like j is being incremented after the segfault since
VB-AttribPtr[a[2].attrib] is the same bad pointer as vptr.
...snip...
LOADING... graphics
LOADING... maps/mp_destruction.bsp
stitched 0 LoD cracks
...loaded 15194 faces, 48 meshes, 275 trisurfs, 31 flares
Program received signal SIGSEGV, Segmentation fault.
do_emit (ctx=0xa4fa078, start=0, end=4, dest=0x4) at t_vertex.c:916
916 t_vertex.c: No such file or directory.
in t_vertex.c
(gdb) print j
$1 = 3
(gdb) print a[j]
$2 = {attrib = 5, format = 8, vertoffset = 23, vertattrsize = 1, inputptr =
0x0,
inputstride = 0, insert = 0x4653ce48, emit = 0, extract = 0x464dfa70
extract_1ub_1f,
vp = 0xa4f9ef8}
(gdb) print a[j].attrib
$3 = 5
(gdb) print VB-AttribPtr[a[j].attrib]
$4 = (GLvector4f *) 0xb2d3718
(gdb) print a[2]
$5 = {attrib = 4, format = 10, vertoffset = 20, vertattrsize = 3, inputptr =
0x87bfb00 ,
inputstride = 8, insert = 0x4653ce80, emit = 0x464deb20 insert_2f_2,
extract = 0x464dfa30 extract_3ub_3f_bgr, vp = 0xa4f9ef8}
(gdb) print a[2].attrib
$6 = 4
(gdb) print VB-AttribPtr[a[2].attrib]
$7 = (GLvector4f *) 0x0
(gdb) print vptr
$8 = (GLvector4f *) 0x0
(gdb) print vptr-stride
Cannot access memory at address 0xc
(gdb) bt
#0 do_emit (ctx=0xa4fa078, start=0, end=4, dest=0x4) at t_vertex.c:916
#1 0x464d8fb6 in run_render (ctx=0xa4fa078, stage=0x4) at t_vb_render.c:296
#2 0x464c6575 in _tnl_run_pipeline (ctx=0xa4fa078) at t_pipeline.c:159
#3 0x464c4d40 in _tnl_draw_range_elements (ctx=0xa4fa078, mode=1,
max_index=4,
index_count=4, indices=0x4) at t_array_api.c:108
#4 0x464c53be in _tnl_DrawElements (mode=4, count=6, type=5125, indices=0x4)
at t_array_api.c:383
#5 0x080746e0 in ?? ()
(gdb)
Hope that helps.
John
---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Segfault on RTCW with Savage
On Mon, 04 Oct 2004 12:09:09 +0100
Keith Whitwell [EMAIL PROTECTED] wrote:
John,
I'd say the problem is with these lines in savagetris.c:
if (index (_TNL_BIT_COLOR1|_TNL_BIT_FOG)) {
EMIT_ATTR( _TNL_ATTRIB_COLOR1, EMIT_3UB_3F_BGR, SAVAGE_HW_NO_CS );
EMIT_ATTR( _TNL_ATTRIB_FOG, EMIT_1UB_1F, SAVAGE_HW_NO_CS );
}
This is a cut and paste of old code from another driver. Have a look at how
other drivers handle this now to avoid trying to emit FOG when only COLOR1 is
enabled, and vice versa.
Thanks for tracking that down. I'll take a look later.
Keith
| Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu |
| PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 |
---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Segfault on RTCW with Savage
John Lightsey wrote:
A while back I mentioned on dri-devel that Savage cards will segfault RTCW
while loading the Checkpoint demo.
( http://www.nixnuts.net/benchmarks/current/ ) The problem is in
Mesa/src/mesa/tnl/t_tertex.c around lines 741 and 913.
for (j = 0; j count; j++) {
GLvector4f *vptr = VB-AttribPtr[a[j].attrib];
a[j].inputstride = vptr-stride;
...
}
vptr is null in the middle of the for loop ( j=2 is null j=0, 1, and 3 is
valid.) I have no idea why this is the case, but I've attached a simple fix
which eliminates the problem.
Does anyone see this in other hardware? If it's only the savage driver
causing this, I would say there's probably a bug in the driver somewhere.
What are the values of j, count and a[j] at the time of the crash?
Keith
---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Segfault on RTCW with Savage
On Friday 01 October 2004 04:03, Keith Whitwell wrote:
John Lightsey wrote:
A while back I mentioned on dri-devel that Savage cards will segfault
RTCW while loading the Checkpoint demo.
( http://www.nixnuts.net/benchmarks/current/ ) The problem is in
Mesa/src/mesa/tnl/t_tertex.c around lines 741 and 913.
for (j = 0; j count; j++) {
GLvector4f *vptr = VB-AttribPtr[a[j].attrib];
a[j].inputstride = vptr-stride;
...
}
vptr is null in the middle of the for loop ( j=2 is null j=0, 1, and 3 is
valid.) I have no idea why this is the case, but I've attached a simple
fix which eliminates the problem.
Does anyone see this in other hardware? If it's only the savage driver
causing this, I would say there's probably a bug in the driver somewhere.
What are the values of j, count and a[j] at the time of the crash?
I didn't see the problem with any other hardware, but RTCW refused to run with
r128 and sis 305, the last time I tried.
GDB's output seems a bit confused. After the segfault j=3
VB-AttribPtr[a[j].attrib] is a valid pointer, but vptr is null. It looks
like j is being incremented after the segfault since
VB-AttribPtr[a[2].attrib] is the same bad pointer as vptr.
...snip...
LOADING... graphics
LOADING... maps/mp_destruction.bsp
stitched 0 LoD cracks
...loaded 15194 faces, 48 meshes, 275 trisurfs, 31 flares
Program received signal SIGSEGV, Segmentation fault.
do_emit (ctx=0xa4fa078, start=0, end=4, dest=0x4) at t_vertex.c:916
916 t_vertex.c: No such file or directory.
in t_vertex.c
(gdb) print j
$1 = 3
(gdb) print a[j]
$2 = {attrib = 5, format = 8, vertoffset = 23, vertattrsize = 1, inputptr =
0x0,
inputstride = 0, insert = 0x4653ce48, emit = 0, extract = 0x464dfa70
extract_1ub_1f,
vp = 0xa4f9ef8}
(gdb) print a[j].attrib
$3 = 5
(gdb) print VB-AttribPtr[a[j].attrib]
$4 = (GLvector4f *) 0xb2d3718
(gdb) print a[2]
$5 = {attrib = 4, format = 10, vertoffset = 20, vertattrsize = 3, inputptr =
0x87bfb00 ,
inputstride = 8, insert = 0x4653ce80, emit = 0x464deb20 insert_2f_2,
extract = 0x464dfa30 extract_3ub_3f_bgr, vp = 0xa4f9ef8}
(gdb) print a[2].attrib
$6 = 4
(gdb) print VB-AttribPtr[a[2].attrib]
$7 = (GLvector4f *) 0x0
(gdb) print vptr
$8 = (GLvector4f *) 0x0
(gdb) print vptr-stride
Cannot access memory at address 0xc
(gdb) bt
#0 do_emit (ctx=0xa4fa078, start=0, end=4, dest=0x4) at t_vertex.c:916
#1 0x464d8fb6 in run_render (ctx=0xa4fa078, stage=0x4) at t_vb_render.c:296
#2 0x464c6575 in _tnl_run_pipeline (ctx=0xa4fa078) at t_pipeline.c:159
#3 0x464c4d40 in _tnl_draw_range_elements (ctx=0xa4fa078, mode=1,
max_index=4,
index_count=4, indices=0x4) at t_array_api.c:108
#4 0x464c53be in _tnl_DrawElements (mode=4, count=6, type=5125, indices=0x4)
at t_array_api.c:383
#5 0x080746e0 in ?? ()
(gdb)
Hope that helps.
John
---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Segfault on RTCW with Savage
A while back I mentioned on dri-devel that Savage cards will segfault RTCW
while loading the Checkpoint demo.
( http://www.nixnuts.net/benchmarks/current/ ) The problem is in
Mesa/src/mesa/tnl/t_tertex.c around lines 741 and 913.
for (j = 0; j count; j++) {
GLvector4f *vptr = VB-AttribPtr[a[j].attrib];
a[j].inputstride = vptr-stride;
...
}
vptr is null in the middle of the for loop ( j=2 is null j=0, 1, and 3 is
valid.) I have no idea why this is the case, but I've attached a simple fix
which eliminates the problem.
John Lightsey
--- xc/../Mesa/src/mesa/tnl/t_vertex.c.orig 2004-09-30 16:59:08.0 -0500
+++ xc/../Mesa/src/mesa/tnl/t_vertex.c 2004-09-30 16:59:58.0 -0500
@@ -741,9 +741,11 @@
for (j = 0; j count; j++) {
GLvector4f *vptr = VB-AttribPtr[a[j].attrib];
- a[j].inputstride = vptr-stride;
- a[j].inputptr = ((GLubyte *)vptr-data) + start * vptr-stride;
- a[j].emit = a[j].insert[vptr-size - 1];
+ if (vptr) {
+ a[j].inputstride = vptr-stride;
+ a[j].inputptr = ((GLubyte *)vptr-data) + start * vptr-stride;
+ a[j].emit = a[j].insert[vptr-size - 1];
+ }
}
end -= start;
@@ -913,9 +915,11 @@
for (j = 0; j count; j++) {
GLvector4f *vptr = VB-AttribPtr[a[j].attrib];
- a[j].inputstride = vptr-stride;
- a[j].inputptr = ((GLubyte *)vptr-data) + start * vptr-stride;
- a[j].emit = a[j].insert[vptr-size - 1];
+ if (vptr) {
+ a[j].inputstride = vptr-stride;
+ a[j].inputptr = ((GLubyte *)vptr-data) + start * vptr-stride;
+ a[j].emit = a[j].insert[vptr-size - 1];
+ }
}
vtx-emit = 0;
