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
First of all, congratulations for the new drivers for ATI Mach64 and
for the support of more and more video cards, even older ones...
Still, I could not successfully use DRM and 3D acceleration on my
AGP-disabled 4MB Mach64 card, using the Debian-package
xserver-xfree86-dri-mach64. Even in the
On Mit, 2003-02-05 at 17:50, Albert Cohen wrote:
(II) ATI(0): [drm] drmSetBusid failed (7, PCI:0:5:0), Permission denied
(EE) ATI(0): [dri] DRIScreenInit Failed
This has been discussed several times here: you need to make sure the
DRM is built with the same compiler as the kernel.
--
Adam K Kirchhoff wrote:
FYI,
With the latest patch to UT2003 (2186), and drivers from the
texmem branch as of this morning (for a Radeon 8500), ut2003 segfaults:
Backtrace:
[ 1] ./Core.so [0x409f635a]
[ 2] /lib/libpthread.so.0 [0x40d7275a]
[ 3] /lib/libc.so.6 [0x40b9f898]
[ 4]
Keith Whitwell wrote:
The other bug report I've had is triggered in similar circumstances, but
goes into an infinite loop inside DRI_VALIDATE_DRAWABLE_INFO(), as a
magic stamp value never gets updated because the X protocol message
never succeeds -- but it doesn't segfault.
I've got a patch
Ian Romanick wrote:
Keith Whitwell wrote:
The other bug report I've had is triggered in similar circumstances,
but goes into an infinite loop inside DRI_VALIDATE_DRAWABLE_INFO(), as
a magic stamp value never gets updated because the X protocol message
never succeeds -- but it doesn't
Keith Whitwell wrote:
Ian Romanick wrote:
Keith Whitwell wrote:
The other bug report I've had is triggered in similar circumstances,
but goes into an infinite loop inside DRI_VALIDATE_DRAWABLE_INFO(),
as a magic stamp value never gets updated because the X protocol
message never succeeds
Ian, now that you've merged in the software support for combine3 from the
Mesa trunk, I'm trying to get it working in hardware on R100 with texmem
(impatient as I am ;) ). I don't have Radeon docs, so I'm guessing about
the registers. I'm attaching a patch of what I've got. My assumptions
are
There are now two patches, one from Egbert Eich (who reported the problem). I
haven't had time to look at his as it changes some deep, dark, dri stuff that
I wasn't ever involved with, but looks sane nonetheless. His avoids the error
reply from the X server, whereas mine copes with it
On Wed, 5 Feb 2003, Ian Romanick wrote:
Adam K Kirchhoff wrote:
FYI,
With the latest patch to UT2003 (2186), and drivers from the
texmem branch as of this morning (for a Radeon 8500), ut2003 segfaults:
Backtrace:
[ 1] ./Core.so [0x409f635a]
[ 2] /lib/libpthread.so.0
On Wed, 5 Feb 2003, Keith Whitwell wrote:
Ian Romanick wrote:
Keith Whitwell wrote:
The other bug report I've had is triggered in similar circumstances,
but goes into an infinite loop inside DRI_VALIDATE_DRAWABLE_INFO(), as
a magic stamp value never gets updated because the X
Leif Delgass wrote:
On Wed, 5 Feb 2003, Keith Whitwell wrote:
Ian Romanick wrote:
Keith Whitwell wrote:
The other bug report I've had is triggered in similar circumstances,
but goes into an infinite loop inside DRI_VALIDATE_DRAWABLE_INFO(), as
a magic stamp value never gets updated
Keith Whitwell wrote:
Leif Delgass wrote:
On Wed, 5 Feb 2003, Keith Whitwell wrote:
Ian Romanick wrote:
Keith Whitwell wrote:
The other bug report I've had is triggered in similar
circumstances, but goes into an infinite loop inside
DRI_VALIDATE_DRAWABLE_INFO(), as a magic stamp value
Will all this stuff about context teardown fix the problem I'm having
with my glut based program that always gives me
X Error of failed request: BadValue (integer parameter out of range for
operation)
Major opcode of failed request: 144 (XFree86-DRI)
Minor opcode of failed request: 9 ()
I just last night downloaded the newest CVS from
dri.sourceforge.net.. and tried compiling it..
it went smoothly.. no errors.. *BUT*.. none of the
kernel modules were created.. for *any* of the video drivers listed in the
host.def file..
Any ideas?
-- John S. Chalice
#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,
Leif Delgass wrote:
Ian, now that you've merged in the software support for combine3 from the
Mesa trunk, I'm trying to get it working in hardware on R100 with texmem
(impatient as I am ;) ). I don't have Radeon docs, so I'm guessing about
the registers. I'm attaching a patch of what I've got.
Steven Paul Lilly wrote:
Will all this stuff about context teardown fix the problem I'm having
with my glut based program that always gives me
X Error of failed request: BadValue (integer parameter out of range for
operation)
Major opcode of failed request: 144 (XFree86-DRI)
Minor opcode
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
Ian, now that you've merged in the software support for combine3 from the
Mesa trunk, I'm trying to get it working in hardware on R100 with texmem
(impatient as I am ;) ).
Where do I find at least a short explanation on the effect this patch should
show to me (to the user) ? The only
Good advice! It looks like a double free in __driUtilUpdateDrawableInfo
when freeing pdp-pClipRects. But at that point not only has pClipRects
been freed, so has pdp! This happens (in the original code) with
__driGarbageCollectDrawables being called before the driver's
DestroyContext and the
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?
Regards,
Felix
On Wed, 5 Feb 2003 12:04:45 +0100
Felix Kühling [EMAIL PROTECTED] wrote:
On Wed, 5 Feb 2003, Ian Romanick wrote:
Leif Delgass wrote:
Ian, now that you've merged in the software support for combine3 from the
Mesa trunk, I'm trying to get it working in hardware on R100 with texmem
(impatient as I am ;) ). I don't have Radeon docs, so I'm guessing about
the
On Tue, Feb 04, 2003 at 09:51:30PM -0500, Leif Delgass wrote:
On Wed, 5 Feb 2003, Arkadi Shishlov wrote:
What do you mean by aren't fully compliant? Final A = Fragment A or
Final A = Texture A? It looks like Fragment A..
Yes, I think that's right. As an example, there's a texture in the
I posted this on the XFree86 list, but was refered here instead.
I'm getting ready to rebuild my system from scratch and am pondering which
card to put into it.
1) a 3DLabs GVX1 AGP card. This works fine in 2D but the 3D support is still
pending. I would prefer to work with this card as I'm
Hello all,
So there's this really great game from Garagegames called
MarbleBlast, which they've ported to Linux. Game requires TNT2 and higher
or Radeon 8500 and higher. It plays just fine on my Radeon 8500 using the
ATI FireGL drivers, but segfaults when trying to use the opensource
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
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
You need to continue past this exception to get to the segfault. This is
just Mesa testing for SSE.
On Wed, 5 Feb 2003, Adam K Kirchhoff wrote:
Hello all,
So there's this really great game from Garagegames called
MarbleBlast, which they've ported to Linux. Game requires TNT2 and
Martin Spott wrote:
Ian, now that you've merged in the software support for combine3 from the
Mesa trunk, I'm trying to get it working in hardware on R100 with texmem
(impatient as I am ;) ).
Where do I find at least a short explanation on the effect this patch should
show to me (to the user) ?
Adam K Kirchhoff wrote:
Hello all,
So there's this really great game from Garagegames called
MarbleBlast, which they've ported to Linux. Game requires TNT2 and higher
or Radeon 8500 and higher. It plays just fine on my Radeon 8500 using the
ATI FireGL drivers, but segfaults when trying to use
Adam K Kirchhoff wrote:
So there's this really great game from Garagegames called
MarbleBlast, which they've ported to Linux. Game requires TNT2 and higher
or Radeon 8500 and higher. It plays just fine on my Radeon 8500 using the
ATI FireGL drivers, but segfaults when trying to use the
Program received signal SIGFPE, Arithmetic exception.
[Switching to Thread 16384 (LWP 2053)]
0x40c9fa70 in _mesa_test_os_sse_exception_support () from
This is expected, just press 'c' to continue. Look at the name of the
function -- it's deliberately trying to raise an exception.
On Wed, 2003-02-05 at 22:58, Adam K Kirchhoff wrote:
Hello all,
So there's this really great game from Garagegames called
MarbleBlast, which they've ported to Linux. Game requires TNT2 and higher
or Radeon 8500 and higher. It plays just fine on my Radeon 8500 using the
ATI FireGL
I grepped for this and didn't find it, but in Mesa there is
Const.MaxArrayLockSize which defaults to 3000 (wasn't that the count in
the last backtrace?). There's nowhere in the radeon or r200 driver that
refer to MaxArrayLockSize.
-Leif
On Wed, 5 Feb 2003, Keith Whitwell wrote:
Felix Kühling
On Wed, 5 Feb 2003, Ian Romanick wrote:
Adam K Kirchhoff wrote:
So there's this really great game from Garagegames called
MarbleBlast, which they've ported to Linux. Game requires TNT2 and higher
or Radeon 8500 and higher. It plays just fine on my Radeon 8500 using the
ATI FireGL
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
That would be easy enough to verify with oprofile. Just take a profile
with and without the patch. In order to get profile data on the GL
driver, do this:
oprofpp -l /usr/X11R6/lib/modules/dri/radeon_dri.so
Thanks for the explanation.
If there's anything else I can do to support your
John S. Chalice wrote:
I just last night downloaded the newest CVS from dri.sourceforge.net..
and tried compiling it..
it went smoothly.. no errors.. *BUT*.. none of the kernel modules were
created.. for *any* of the video drivers listed in the host.def file..
Any ideas?
well, you can
On Wed, Feb 05, 2003 at 10:53:20PM +, John Gay wrote:
I posted this on the XFree86 list, but was refered here instead.
I'm getting ready to rebuild my system from scratch and am pondering which
card to put into it.
1) a 3DLabs GVX1 AGP card. This works fine in 2D but the 3D support is
On Thu, 6 Feb 2003 00:44:12 +0200
Arkadi Shishlov [EMAIL PROTECTED] wrote:
Now I think it is texture alpha. Quite pointless to have RGBA texture
without ability to use it alpha channel.
http://idea.hosting.lv/a/tmp/quakeforge-mach64-blend.jpg
Hows Quakeforge comming, btw - it'd be nice to
On Sun, 26 Jan 2003, qqq wrote:
I have the same problems
I use the dri trunk Xfree86 4.2.99 radeon 1.8.0
games too.
I was using XFree in versions 4.2, 4.2.1, cvs and from DRI, the effect
is the same.
Maybe it is a chipset related problem, I have VIA Apollo pro, and what about you?
Felix Kühling wrote:
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
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).
On Wed, 5 Feb 2003, Keith Whitwell wrote:
Felix Kühling wrote:
On
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
I'll second this. In some of the screenhacks from xscreensaver 4.06,
there is flickering when they are displayed on the root window (as you
would normally play them as screensavers). With a quick check, I notice
this behavior in superquadrics, atlantis, moebius, queens, and pulsar
(there are
On Thu, 6 Feb 2003, Felix Kühling wrote:
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
On Mit, 2003-02-05 at 21:30, [EMAIL PROTECTED] wrote:
I'll second this. In some of the screenhacks from xscreensaver 4.06,
there is flickering when they are displayed on the root window (as you
would normally play them as screensavers).
They don't actually render to the root window when you
*NEW-Special Package Deal!*
2003 McAfee Version 7.0 Software Suite - Home Edition-
THE NAME THAT MEANS SECURITY FOR YOUR PC COMPUTER.
Do not leave your PC open for a virus that could destroy your data.
McAfee VirusScan is the #1 software used by Corporate Businesses to
protect PCs against virus
Leif Delgass 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).
Hmm. Do you have an r200? I wonder whats up
cd programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/
make -f Makefile.linux MODULE.o
I would just add that if you're using a kernel that uses a better source
directory naming scheme (e.g. 2.4.19 unpacks to linux-2.4.19 whereas
2.4.18 unpacks to just linux), you'll want to use the
On Wed, 5 Feb 2003, Keith Whitwell wrote:
Leif Delgass 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).
52 matches
Mail list logo
