Hi,
while I was trying to understand the DMA buffer allocation of the radeon
driver a few months ago I added an assertion at the end of
radeonAllocDmaRegion:
assert (rmesa-dma.current.ptr = rmesa-dma.current.end);
It fails if someone tries to allocate more DMA buffer space than one DMA
#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,
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
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
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
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
