Re: [Dri-devel] radeonAllocDmaRegion called with bytes dma buffer size
#12 0x415bb936 in neutral_DrawElements (mode=0, count=0, type=0, indices=0x0) at ../../../../extras/Mesa/src/vtxfmt_tmp.h:369 #13 0x40026f38 in Draw_nString (x=6, y=1078070736, str=0x4144e780 _histogram GL_EXT_packed_pixels GL_EXT_polygon_offset, ' ' repeats 19 times, GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_texture3D, ' ' repeats 17 times, GL_EXT_texture_env_add GL_EXT_texture_env_combine ---Type return to continue, or q return to quit--- ..., count=0) at gl_draw.c:367 #14 0x72676f74 in ?? () if you notice count=0, DRI shouldn't really go any further with a 0 count --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeonAllocDmaRegion called with bytes dma buffer size
a couple of us QF codes are questioning this, looks like gcc optimizations or gdb are interefering cause the way QF handles the vertex array (with error checking), it's impossable for starters for it send a NULL indices pointer, not to mention a 0 count. #9 0x41620115 in _tnl_DrawElements (mode=2823, count=137243856, type=137243856, indices=0x8318ba8) at t_array_api.c:99 #10 0x415bb936 in neutral_DrawElements (mode=0, count=0, type=0, indices=0x0) at ../../../../extras/Mesa/src/vtxfmt_tmp.h:369 #11 0x41680571 in radeon_fallback_DrawElements (mode=0, count=0, type=0, indices=0x0) at ../../../../../../extras/Mesa/src/vtxfmt_tmp.h:369 #12 0x415bb936 in neutral_DrawElements (mode=0, count=0, type=0, indices=0x0) at ../../../../extras/Mesa/src/vtxfmt_tmp.h:369 #13 0x40026f38 in Draw_nString (x=6, y=1078070736, str=0x4144e780 _histogram GL_EXT_packed_pixels GL_EXT_polygon_offset, ' ' repeats 19 times, GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_texture3D, ' ' repeats 17 times, GL_EXT_texture_env_add GL_EXT_texture_env_combine ---Type return to continue, or q return to quit--- ..., count=0) at gl_draw.c:367 #14 0x72676f74 in ?? () --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeonAllocDmaRegion called with bytes dma buffer size
On Thu, 06 Feb 2003 07:46:35 +1000 Chris Ison [EMAIL PROTECTED] wrote: a couple of us QF codes are questioning this, looks like gcc optimizations or gdb are interefering cause the way QF handles the vertex array (with error checking), it's impossable for starters for it send a NULL indices pointer, not to mention a 0 count. Looks like you're right. I recompiled the radeon driver with -O0 and got this: #0 0x40334581 in kill () from /lib/libc.so.6 #1 0x40334394 in raise () from /lib/libc.so.6 #2 0x403358d1 in abort () from /lib/libc.so.6 #3 0x4032edb2 in __assert_fail () from /lib/libc.so.6 #4 0x41654522 in radeonAllocDmaRegion (rmesa=0x8164680, region=0x81670c0, bytes=72000, alignment=3) at radeon_ioctl.c:635 #5 0x4165455e in radeonAllocDmaRegionVerts (rmesa=0x8164680, region=0x81670c0, numverts=3000, vertsize=24, alignment=4) at radeon_ioctl.c:647 #6 0x4165996a in radeonEmitArrays (ctx=0x8167898, inputs=265) at radeon_maos_verts.c:311 #7 0x4167d063 in radeon_run_tcl_render (ctx=0x8167898, stage=0x82e2d38) at radeon_tcl.c:318 #8 0x4162e6b3 in _tnl_run_pipeline (ctx=0x8167898) at t_pipeline.c:154 #9 0x41666a9b in radeonWrapRunPipeline (ctx=0x8167898) at radeon_state.c:2088 #10 0x4161f095 in _tnl_DrawElements (mode=2823, count=3000, type=137243856, indices=0x8318bb8) at t_array_api.c:99 #11 0x415ba8b6 in neutral_DrawElements (mode=0, count=0, type=0, indices=0x0) at ../../../../extras/Mesa/src/vtxfmt_tmp.h:369 #12 0x41685fde in radeon_fallback_DrawElements (mode=7, count=3000, type=5125, indices=0x8318bb8) at ../../../../../../extras/Mesa/src/vtxfmt_tmp.h:369 #13 0x415ba8b6 in neutral_DrawElements (mode=0, count=0, type=0, indices=0x0) at ../../../../extras/Mesa/src/vtxfmt_tmp.h:369 ---Type return to continue, or q return to quit--- #14 0x40026f38 in Draw_nString (x=6, y=1078070736, str=0x4144e780 _histogram GL_EXT_packed_pixels GL_EXT_polygon_offset, ' ' repeats 19 times, GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_texture3D, ' ' repeats 17 times, GL_EXT_texture_env_add GL_EXT_texture_env_combine ..., count=0) at gl_draw.c:367 #15 0x72676f74 in ?? () Cannot access memory at address 0x7369685f There are still a few 0 counts but the source of neutral_DrawElements is in a different directory and is still compiled with -O3. The 3000 looks more sensible. With vertex size 24 this makes 72000 bytes which is more than fits into one 64KB DMA buffer. Felix __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]o__/ \___/ \___/at the same time! --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeonAllocDmaRegion called with bytes dma buffer size
On Wed, 05 Feb 2003 16:25:27 -0700 Keith Whitwell [EMAIL PROTECTED] wrote: Felix Kühling wrote: I attached a patch that fixes the problem. It introduces a new TCL_FALLBACK if there are too many vertices to fit into one DMA buffer. Looks kind of hackish to me. Does anyone have a better idea? Comments? Mesa should respect ctx-Const.MaxArrayVertices, which should be being set in radeon_context.c --- it may be that this code is disabled - can you check that try turning it back on. Found it: radeon_context.c around line 375: /* ctx-Const.MaxArrayLockSize = */ /*MIN2( ctx-Const.MaxArrayLockSize, */ /* RADEON_BUFFER_SIZE / RADEON_MAX_TCL_VERTSIZE ); */ And then there is the definition of RADEON_MAX_TCL_VERTSIZE in radeon_tcl.h which is (4*4). However, I saw vertex_size==24! Maybe the real MAX_TCL_VERTSIZE is even bigger? Felix __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]o__/ \___/ \___/at the same time! --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeonAllocDmaRegion called with bytes dma buffer size
On Wed, 5 Feb 2003 20:17:57 -0500 (EST) Leif Delgass [EMAIL PROTECTED] wrote: Hurrah! ... this fixes the vertex data corruption in the UT2003 opening screen. There's still vertex problems in game (though not quite as much). The remaining problems may be because of cube mapping (I'm testing on R100). I see lots of vertex data corruption with TCL disabled in torcs and in quakeforge. With TCL enabled there is some strange corruption in quakeforge when the console is active. __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]o__/ \___/ \___/at the same time! --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
