[Dri-devel] Re: radeon7500 + irongate agp chipset: are the problems being workedon?
On Sun, 17 Feb 2002, Andrew Schwerin wrote: I'm running with a Radeon VE and having a similar problem. All apps that use DRI eventually (within 10 minutes, often less than 1 minute) lock up the system. I've got an A7A266. Contrary to the experience of the users, I've had more trouble when I turn the AGP speed down from 4x to 1x, though reducing the aperature size has helped a little. I've now tested Radeon, Radeon 7500 a fair bit with 4.2.0, and am also experiencing this exact same thing. Upon starting up gears, it runs normal for about 2 seconds, then slows down to slower than software rendering instantly for about 3-5 seconds, then speeds up a bit, then goes back to full speed, and stays there. Eventually it crashes X, and sometimes the whole system. Running Chromium also crashes the system at the main screen. Running random GL screensavers crash also. In some cases, after the initial crash, the system is still running. I ssh in, and can kill X, etc.. all processes are in S state at that time. No log files show anything suspicious. Killing X and restarting it always leads to full system lockup requiring a hard reset. I cant get any OpenGL applications to run for long without locking up the X server and/or kernel. I'm using our rawhide 2.4.17-0.16 kernel rebuilt for i586 UP on a K6-3 300Mhz CPU. I haven't yet tried to debug things further, but am willing to test any kernel/X patches out. -- -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc.Phone: (705)949-2136 http://www.redhat.com ftp://people.redhat.com/mharris Red Hat XFree86 mailing list: [EMAIL PROTECTED] General open IRC discussion:#xfree86 on irc.openprojects.net -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Unreal
On Thu, Feb 21, 2002 at 04:53:04AM +, Keith Whitwell wrote: That sounds like a bug in the quake physics model - some silly feedback between the integration time step and the display subsystem... I'm suprised... I can only speak about the quake 1/quakeworld source (I haven't studied the quake2 code enough yet), but it's actually nothing that complex. In fact, it's the opposit. quake doesn't do the integeration properly at all. It just adds the gravity acceleration to the velocity then the velocity to the location. I'm not sure if t squared shows up in the physics code or not (it looks like it does, but indirectly), but the 1/2 for the 1/2at**2 doesn't. Basicly, a projectile (player, grenade) has a piece-wise linear trajectory that doesn't touch the correct parabola except at the start point. Quake: the universe where G depends on how fast you can blink your eyes. Bill -- Leave others their otherness. -- Aratak ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Matrox G550?
Gday, Ian Romanick wrote: Since the G550 is, basically, just a slightly enhanced G400/G450, it is supported by the DRI, right? If so, then does anyone have any information about the partial TL support in the G550? Now that we've got some TL support for the Radeon, it might be nice to look at this card, too. I suppose it's probably the classic problem, though: those that have the required docs won't share. I have a g450. I have been asking via the matrox forums and directly to their support, about either adding some extra functionality to their code or at least releasing some info about the cards so it can get done. Basically I get the standard reply, ...currently not supported. not likely to in the future Maybe if we can approach them on mass via a petition or something, something may happen. The extra features the cards are capable of would be very much appreciated by a lot of people I suspect.(better OpenGL support, TV-out ..etc) I am currently using their latest code and my experiences with the card are mixed. 2-d, dual-head, dvd are great but 3-d stuff leaves a lot to be desired. I have to disable or at best select low quality features just to get a stable platform. If you go for the advanced OpenGLfeatures I regularly get hard lockups requiring a reboot :-( Sorry I can't point you to some info on them, I don't think there is any out there yet. At least none that I could find. btw. I get around 835 fps on a g450/32mb, 1Ghz PIII smp machine. regards darryl ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Unreal
Bill Currie wrote: I can only speak about the quake 1/quakeworld source (I haven't studied the quake2 code enough yet), but it's actually nothing that complex. In fact, it's the opposit. quake doesn't do the integeration properly at all. It just adds the gravity acceleration to the velocity then the velocity to the location. I'm not sure if t squared shows up in the physics code or not (it looks like it does, but indirectly), but the 1/2 for the 1/2at**2 doesn't. Basicly, a projectile (player, grenade) has a piece-wise linear trajectory that doesn't touch the correct parabola except at the start point. Quake: the universe where G depends on how fast you can blink your eyes. I'm pretty sure Dave was talking about Quake3 ;-) He certainly plays it enough... -- Gareth ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: radeon7500 + irongate agp chipset: are theproblems being worked on?
Hehe. I feel mildly sheepish. My system wasn't locking hard. Only the keyboard, mouse and video card were locking. I was able to connect over the network to my machine in order to shut it down safely last time it locked up. It still hoses the Radeon VE card and the keyboard, but that's better than I thought. -Andy On Thu, 2002-02-21 at 01:41, Mike A. Harris wrote: On Sun, 17 Feb 2002, Andrew Schwerin wrote: I'm running with a Radeon VE and having a similar problem. All apps that use DRI eventually (within 10 minutes, often less than 1 minute) lock up the system. I've got an A7A266. Contrary to the experience of the users, I've had more trouble when I turn the AGP speed down from 4x to 1x, though reducing the aperature size has helped a little. I've now tested Radeon, Radeon 7500 a fair bit with 4.2.0, and am also experiencing this exact same thing. Upon starting up gears, it runs normal for about 2 seconds, then slows down to slower than software rendering instantly for about 3-5 seconds, then speeds up a bit, then goes back to full speed, and stays there. Eventually it crashes X, and sometimes the whole system. Running Chromium also crashes the system at the main screen. Running random GL screensavers crash also. In some cases, after the initial crash, the system is still running. I ssh in, and can kill X, etc.. all processes are in S state at that time. No log files show anything suspicious. Killing X and restarting it always leads to full system lockup requiring a hard reset. I cant get any OpenGL applications to run for long without locking up the X server and/or kernel. I'm using our rawhide 2.4.17-0.16 kernel rebuilt for i586 UP on a K6-3 300Mhz CPU. I haven't yet tried to debug things further, but am willing to test any kernel/X patches out. -- -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc.Phone: (705)949-2136 http://www.redhat.com ftp://people.redhat.com/mharris Red Hat XFree86 mailing list: [EMAIL PROTECTED] General open IRC discussion:#xfree86 on irc.openprojects.net -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Matrox G550?
On Wed, 20 Feb 2002, Keith Whitwell wrote: Since the G550 is, basically, just a slightly enhanced G400/G450, it is supported by the DRI, right? If so, then does anyone have any information about the partial TL support in the G550? Now that we've got some TL support for the Radeon, it might be nice to look at this card, too. I don't have any information about it, in fact I've never had access to one of the cards to test or verify that the driver works on it. However, if you can get doco, it should be reasonably easy to add transformation support (I don't think the card does lighting???). I suppose it's probably the classic problem, though: those that have the required docs won't share. I don't know of anyone who does have docs. You may have good luck contacting Matrox directly. To the best of my knowledge, Matrox no longer releases documentation of their hardware to open source projects and developers. The last documentation that is available I believe is the G400. From what I understand, the documentation contains information on defeating Macrovision. I wonder why they couldn't just remove sensitive information though or redact it out. At least Matrox supports their hardware via in house development patches though. Possibly someone at Matrox would consider writing support for missing features, if not in official capacity, perhaps on their spare time. Not sure if anyone from Matrox reads the list or not, but it might be a good idea to contact Luugi Marsan or Karl Lessard perhaps. Just a thought. TTYL -- -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc.Phone: (705)949-2136 http://www.redhat.com ftp://people.redhat.com/mharris Red Hat XFree86 mailing list: [EMAIL PROTECTED] General open IRC discussion:#xfree86 on irc.openprojects.net -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: radeon7500 + irongate agp chipset: are theproblems being worked on?
On 21 Feb 2002, Andrew Schwerin wrote: Date: 21 Feb 2002 02:55:38 -0800 From: Andrew Schwerin [EMAIL PROTECTED] To: Mike A. Harris [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Content-Type: text/plain Subject: Re: [Dri-devel] Re: radeon7500 + irongate agp chipset: are the problems being worked on? Hehe. I feel mildly sheepish. My system wasn't locking hard. Only the keyboard, mouse and video card were locking. I was able to connect over the network to my machine in order to shut it down safely last time it locked up. It still hoses the Radeon VE card and the keyboard, but that's better than I thought. Yep, I thought it was dead at first too, until I could ssh in. It is completely repeatable though. I tried on 3 different machines now, each with a Radeon 7500, a Radeon 64DDR and a Radeon VE. In all cases using 4.2.0 plus kernel 2.4.17+new DRM. Unstable for me. -- -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc.Phone: (705)949-2136 http://www.redhat.com ftp://people.redhat.com/mharris Red Hat XFree86 mailing list: [EMAIL PROTECTED] General open IRC discussion:#xfree86 on irc.openprojects.net -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [PATCH] Wolfenstein on r128
On Tuesday 19 February 2002 12:33 am, you wrote: Cool. I have Wolfenstien running on my system with Voodoo3 and it seems to work fine. I was afraid this was going to be a really ellusive bug. -Brian I also run Wolfenstein on a Voodoo3 2000 - It works fine at first appears to give good framerates, but if there are many other player models/explosions etc in view it goes as low as 10 fps. It is the same on windows with the wickedgl drivers that now come with them (the MP SP 1.1 demos). Changing the settings doesn't help much. This actually doubly hurts gameplay, as on the beach in multiplayer you end up only sending 10 packets/sec so get higher latency aswell. I assume that since the rate is reasonable on an empty beach It's the models / weapon effects that take the time. Do you think these are processed seperately enough in mesa / the drivers to be optimised / quality reduced in a game specific hack of any sort? Thanks. Andy. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Unreal
David S. Miller wrote: In fact in many versions of quake3 the distance you can jump is determined by what FPS you can achieve. 125FPS is the optimal rate in those cases and it is what everyone uses. now it gets OT but what the heck.. q3 jumping is explained here: http://ucguides.savagehelp.com/Quake3/FAQFPSJumps.html second post, not the one with the pictures -- ralf willenbacher ([EMAIL PROTECTED]) ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: radeon7500 + irongate agp chipset: are theproblems being worked on?
Mike A. Harris wrote: It is completely repeatable though. With gears? I tried on 3 different machines now, each with a Radeon 7500, a Radeon 64DDR and a Radeon VE. In all cases using 4.2.0 plus kernel 2.4.17+new DRM. New DRM being the Radeon DRM from 2.4.17? or XFree86 4.2.0? or dri.sourceforge.net trunk? Have you tried going back to a kernel release from Nov/Dec (when we were testing XF4.2)? Knowing this could help in isolating the problem. Regards, Jens -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [PATCH] Wolfenstein on r128
Andy Furniss wrote: On Tuesday 19 February 2002 12:33 am, you wrote: Cool. I have Wolfenstien running on my system with Voodoo3 and it seems to work fine. I was afraid this was going to be a really ellusive bug. -Brian I also run Wolfenstein on a Voodoo3 2000 - It works fine at first appears to give good framerates, but if there are many other player models/explosions etc in view it goes as low as 10 fps. It is the same on windows with the wickedgl drivers that now come with them (the MP SP 1.1 demos). Changing the settings doesn't help much. This actually doubly hurts gameplay, as on the beach in multiplayer you end up only sending 10 packets/sec so get higher latency aswell. I assume that since the rate is reasonable on an empty beach It's the models / weapon effects that take the time. Do you think these are processed seperately enough in mesa / the drivers to be optimised / quality reduced in a game specific hack of any sort? Maybe. I'd have to do some profiling and analysis of the GL features that wolfenstein is using in order to answer that. I don't have time for either though. -Brian ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Unreal [was: Mach 64 success and problems]
Gareth Hughes wrote: Keith Whitwell wrote: What is the point of sustaining such a frame rate that has no pratical advantage? You do see the partial frames, it seems. The eye seems to do a reasonable job of integrating it all, providing you with a low-latency view of the game world. Hardcore gamers want ~100fps so the game clock is updated enough to allow smooth gameplay. This is particularly important with network-based deathmatch games. That's a bogus argument (though it may be true...) It's a sad state of affairs that people are writing games with such crippled network/physics subsystems that can't operate correctly unless the graphics adaptor has certain characteristics. We could just throw out every second frame they'd be happy save money on new video cards... Keith ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: radeon7500 + irongate agp chipset: are theproblems being worked on?
Mike A. Harris wrote: On 21 Feb 2002, Andrew Schwerin wrote: Date: 21 Feb 2002 02:55:38 -0800 From: Andrew Schwerin [EMAIL PROTECTED] To: Mike A. Harris [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Content-Type: text/plain Subject: Re: [Dri-devel] Re: radeon7500 + irongate agp chipset: are the problems being worked on? Hehe. I feel mildly sheepish. My system wasn't locking hard. Only the keyboard, mouse and video card were locking. I was able to connect over the network to my machine in order to shut it down safely last time it locked up. It still hoses the Radeon VE card and the keyboard, but that's better than I thought. Yep, I thought it was dead at first too, until I could ssh in. It is completely repeatable though. I tried on 3 different machines now, each with a Radeon 7500, a Radeon 64DDR and a Radeon VE. In all cases using 4.2.0 plus kernel 2.4.17+new DRM. Unstable for me. Can you try find a smoking gun? Is it 4.2.0, new drm (which new drm?) or the kernel? Or something else? Keith ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: radeon7500 + irongate agp chipset: are theproblems being worked on?
On Thu, 21 Feb 2002, Keith Whitwell wrote: Hehe. I feel mildly sheepish. My system wasn't locking hard. Only the keyboard, mouse and video card were locking. I was able to connect over the network to my machine in order to shut it down safely last time it locked up. It still hoses the Radeon VE card and the keyboard, but that's better than I thought. Yep, I thought it was dead at first too, until I could ssh in. It is completely repeatable though. I tried on 3 different machines now, each with a Radeon 7500, a Radeon 64DDR and a Radeon VE. In all cases using 4.2.0 plus kernel 2.4.17+new DRM. Unstable for me. Can you try find a smoking gun? Is it 4.2.0, new drm (which new drm?) or the kernel? Or something else? Sorry for not being clear, but I meant 4.2.0 DRM when I said new DRM. I can try it with another kernel also. I'll test it with 2.4.9 and 4.2.0 DRM. I'm using XFree86 4.2.0 in all cases. I'll report back with any new info I find. Thanks Keith, TTYL -- -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc.Phone: (705)949-2136 http://www.redhat.com ftp://people.redhat.com/mharris Red Hat XFree86 mailing list: [EMAIL PROTECTED] General open IRC discussion:#xfree86 on irc.openprojects.net -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: radeon7500 + irongate agp chipset: are theproblems being worked on?
On Thu, 21 Feb 2002, Jens Owen wrote: Date: Thu, 21 Feb 2002 07:39:48 -0700 From: Jens Owen [EMAIL PROTECTED] To: Mike A. Harris [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Subject: Re: [Dri-devel] Re: radeon7500 + irongate agp chipset: are theproblems being worked on? Mike A. Harris wrote: It is completely repeatable though. With gears? With gears it takes a bit of time but it crashes. With Chromium, or numerous xscreensaver GL screensavers, it crashes almost instantly, or within 30 seconds to a minute on my 300Mhz CPU. I tried on 3 different machines now, each with a Radeon 7500, a Radeon 64DDR and a Radeon VE. In all cases using 4.2.0 plus kernel 2.4.17+new DRM. New DRM being the Radeon DRM from 2.4.17? or XFree86 4.2.0? or dri.sourceforge.net trunk? XFree86 4.2.0 DRM code from xf-4_2-branch. The kernel 2.4.17 DRM code is removed, and the 4.2.0 DRM replaces it. Have you tried going back to a kernel release from Nov/Dec (when we were testing XF4.2)? Knowing this could help in isolating the problem. Which kernel? I can test it. -- -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc.Phone: (705)949-2136 http://www.redhat.com ftp://people.redhat.com/mharris Red Hat XFree86 mailing list: [EMAIL PROTECTED] General open IRC discussion:#xfree86 on irc.openprojects.net -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: radeon7500 + irongate agp chipset: are theproblems being worked on?
On Thu, Feb 21, 2002 at 03:47:37PM +, Keith Whitwell wrote: Can you try find a smoking gun? Is it 4.2.0, new drm (which new drm?) or the kernel? Or something else? glean was the only thing (after the materials copying hang and the count j -3 loop fixes) that cause lockups here, still a few glitches (depth buffer with either polygon offset or TINY_VERTEX_FORMAT) but most things ran without problems. I just tried glean against current TCL and it exists with cannot get DMA buffer, so I suspect that whatever bug(s) which lead up to not getting a buffer trigger the hang you took out of the TCL code yesterday? -- Michael. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [PATCH] Small cleanup for drm_fops.h:read()
This is just a small change to the generic read() method in
drm_fops.h to use wait_event_interruptible() rather than the
hand-hacked waiting code that was in there. This is the method
recommended by the second edition of Linux Device Drivers . . .
On a different note, is there any way that this generic code could
be factored out in a less opaque way? The way things stand, the
debugging option prints out a number of function names that don't
exist until the preprocessor has done it's thing - this makes it
impossible to grep for them, and makes the code that much harder to
get into. I was thinking something like the various structs of
methods the VFS uses . . . There are probably gotchas in that, but
the current code really is very hard to get into.
Simon Fowler
Index: programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/drm_fops.h
===
RCS file:
/cvsroot/dri/xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/drm_fops.h,v
retrieving revision 1.7
diff -u -r1.7 drm_fops.h
--- programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/drm_fops.h 27 Jan 2002
20:05:42 - 1.7
+++ programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/drm_fops.h 21 Feb 2002
+17:52:46 -
@@ -125,32 +125,20 @@
int avail;
int send;
int cur;
- DECLARE_WAITQUEUE(wait, current);
DRM_DEBUG(%p, %p\n, dev-buf_rp, dev-buf_wp);
- add_wait_queue(dev-buf_readers, wait);
- set_current_state(TASK_INTERRUPTIBLE);
- while (dev-buf_rp == dev-buf_wp) {
- DRM_DEBUG( sleeping\n);
- if (filp-f_flags O_NONBLOCK) {
- remove_wait_queue(dev-buf_readers, wait);
- set_current_state(TASK_RUNNING);
+ if (dev-buf_rp == dev-buf_wp) {
+ if (filp-f_flags O_NONBLOCK)
return -EAGAIN;
- }
- schedule(); /* wait for dev-buf_readers */
- if (signal_pending(current)) {
+ DRM_DEBUG( sleeping\n);
+ if(wait_event_interruptible(dev-buf_readers, (dev-buf_rp !=
+dev-buf_wp))) {
DRM_DEBUG( interrupted\n);
- remove_wait_queue(dev-buf_readers, wait);
- set_current_state(TASK_RUNNING);
return -ERESTARTSYS;
}
DRM_DEBUG( awake\n);
- set_current_state(TASK_INTERRUPTIBLE);
}
- remove_wait_queue(dev-buf_readers, wait);
- set_current_state(TASK_RUNNING);
-
+
left = (dev-buf_rp + DRM_BSZ - dev-buf_wp) % DRM_BSZ;
avail = DRM_BSZ - left;
send = DRM_MIN(avail, count);
--
PGP public key Id 0x144A991C, or ftp://bg77.anu.edu.au/pub/himi/himi.asc
(crappy) Homepage: http://bg77.anu.edu.au
doe #237 (see http://www.lemuria.org/DeCSS)
My DeCSS mirror: ftp://bg77.anu.edu.au/pub/mirrors/css/
msg03020/pgp0.pgp
Description: PGP signature
[Dri-devel] 2nd libGL(U?) problem
Hi, after the old problem has been solved a new occured. when linking my program to efence following backtrace is able to do: -- #0 scale_internal_ubyte (components=3, widthin=32, heightin=48, datain=0x4af51e00 \026\021\f%\026, widthout=32, heightout=64, dataout=0x4af71800 \026\021\f%\026, element_size=1, ysize=96, group_size=3) at mipmap.c:1473 #1 0x400f7182 in gluBuild2DMipmapLevelsCore (target=3553, internalFormat=3, width=32, height=48, widthPowerOf2=32, heightPowerOf2=64, format=6407, type=5121, userLevel=0, baseLevel=0, maxLevel=6, data=0x4af51e00) at mipmap.c:4127 #2 0x400f7ee3 in gluBuild2DMipmaps (target=3553, internalFormat=3, width=32, height=48, format=6407, type=5121, data=0x4af51e00) at mipmap.c:4560 #3 0x08054503 in S_T_AddData24 (tex=0x48935f68, width=32, height=48, data_x=32, data_y=48, data=0x4af51e00 \026\021\f%\026) at fe/gl/texture.c:369 -- The program crashes with HW-acceleratio AND without (with LIBGL_ALWAYS_INDIRECT tested). Its again a problem in the DRI-lib only, as the program not crashes with other librarys like nVidias. Here is my data: ATI Radeon 7200 XFree 4.2.0 DRI from CVS localhost kernel: [drm] AGP 0.99 on VIA Apollo KT133 @ 0xe600 32MB localhost kernel: [drm] Initialized radeon 1.2.0 20010405 on minor 0 AMD Athlon 1400 MHz, 256 MB RAM Linux Kernel 2.4.16 questions go to my e-mail-adress. cya -- Robin Redeker www:http://www.x-paste.de/ e-mail: [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Unreal [was: Mach 64 success and problems]
On Wed, 20 Feb 2002, Michael Thaler wrote: when I start UT I get the Intro. The Sound is o.k. but the Rendering does not seem to delete old objects correctly. The same objected is displayed at different positions of the screen without deleting the old objects. The lights are just big white or yellow circles. The game menu with the Unreal Tournament logo and the menu is displayed correctly. When I start a practice session the weapon is displayed correctly with all textures, but I cannot see any background textures of the room. This part at least sounds like you don't have the latest CVS. Can you try this: In the source tree: cd xc/xc/lib/GL/mesa/src/drv/mach64 cvs update If you see files being updated, move to the build tree (build/xc/lib/GL) and rebuild the Mesa driver with 'su' and 'make install'. Then try turning multitexturing on in UnrealTournament.ini. There will still be some transparency problems with textures here and there, but you should see the background textures. More or less the only thing I can see are big white or yello circles which are probably lights. When I move arround, the lights get drawn over the screen, but the lights are not deleted at the old positions, so the screen gets more and more filled with white. Sometimes the weapon turns black and you can only see a black shiluette of the weapons. Firing makes the weapon apear again. A strange thing happens when you press ESC and go to the menu screen. Everything is displayed correctly there but when you go back to the game you can still see the menu screen in the background. It is not deleted. You can see big white lights in front of it and you can see the menu screen through the lights. -- Leif Delgass http://www.retinalburn.net ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Branches?
Which branch merges are complete? If the mesa-4-0-branch to trunk merge is complete, is the branch dead? -- Tell that to the Marines! ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Mach64: some programs
Hi all Tried to run the Mach64 dri-enabled driver and ... 1. Openuniverse and celestia - still no textures. I've heard some talks about DMA, thought it is already working. Is not it? I know, without DMA my 8M is not enough for 1280x1024... 2. Counter-strike/wine in OpenGL mode. I see only my pistol - no environment at all:) Also in console, a lot of messages: mach64UploadTexImages: ran into bound texture What does this mean? Is it bad or good? Is it fixable? 3. About the fog. Really, the problem is not in the fog. The fog demo works OK. 4. About signal 11. It seems the problem was about vt. Everything is OK if I run programs from xterm. Cheers, Sergey ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Branches?
On Thu, Feb 21, 2002 at 01:56:01PM -0800, Ian Romanick wrote: Which branch merges are complete? If the mesa-4-0-branch to trunk merge is complete, is the branch dead? Yep. Alan. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Branches?
Ian Romanick wrote: Which branch merges are complete? If the mesa-4-0-branch to trunk merge is complete, is the branch dead? I believe mesa-4-0 is now on the trunk, and is about to be merged into XFree86. Yes, that branch is now dead. Keith ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] trunk: texutil.c compilation error
make[5]: Entering directory `/tmp/INSTALL/SOURCE/dri/xc/xc/lib/GL/mesa/src' rm -f texutil.o gcc -c -O -mcpu=k6 -fomit-frame-pointer -mpreferred-stack-boundary=2 -malign-functions=4 -fschedule-insns2 -fexpensive-optimizations -ansi -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -pipe -I../../../../exports/include -I../../../../exports/include/X11 -I../../../../include/extensions -I../../../../extras/Mesa/src -I../../../../lib/GL/dri -I../../../../extras/Mesa/include -I../../../../lib/GL/include -I../../../.. -I../../../../exports/include -I/usr/X11R6/include -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -DFUNCPROTO=15 -DNARROWPROTO -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API-DMALLOC_0_RETURNS_NULL -DGLXEXT -DXF86DRI -DGLX_DIRECT_RENDERING -DGLX_USE_DLOPEN -DGLX_USE_MESA -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASMtexutil.c In file included from texutil.c:85: ../../../../extras/Mesa/src/texutil_tmp.h: In function `texsubimage2d_pack_rgba_direct': ../../../../extras/Mesa/src/texutil_tmp.h:188: structure has no member named `packing' [-] Thanks, Dieter ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64: some programs
On 2002.02.21 22:08 Sergey V. Udaltsov wrote: Hi all Tried to run the Mach64 dri-enabled driver and ... 1. Openuniverse and celestia - still no textures. I've heard some talks about DMA, thought it is already working. Is not it? I know, without DMA my 8M is not enough for 1280x1024... No, DMA isn't yet done. Frank Earl has most of the work done except for the security, for which a solution has yet to be found. His work is not yet on a CVS branch, although I hope it will be in a near future. 2. Counter-strike/wine in OpenGL mode. I see only my pistol - no environment at all:) This is also an evidence of insufficient memory for textures. You have to decrease the screen resolution and/or reduce the textures details to be able to fit more texture into the onboard memory. This also affects the framerate because the driver fails to cache a decent number of textures in the onboard memory so is constantly needing to upload them which, again, is also very slow since it does that through PIO. AGP/DMA gives a big boost on performance because it gives faster communication with the card and allows to extend the card memory with the main memory. Also in console, a lot of messages: mach64UploadTexImages: ran into bound texture What does this mean? Is it bad or good? Is it fixable? I've been looking into the code and it seems that the driver was trying to free textures to alocate a new one but ran into a texture that was bounded to texture processing unit, so it failed to allocate space for the new texture. So it's basically the same problem. 3. About the fog. Really, the problem is not in the fog. The fog demo works OK. 4. About signal 11. It seems the problem was about vt. Everything is OK if I run programs from xterm. You can't switch VT while running an OpenGL application on mach64 as it is now. Cheers, Sergey Regards, José Fonseca _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] trunk: texutil.c compilation error
Fixed. texutil_tmp.h needed fixing too. Alan. On Fri, Feb 22, 2002 at 12:13:25AM +0100, Dieter Nützel wrote: make[5]: Entering directory `/tmp/INSTALL/SOURCE/dri/xc/xc/lib/GL/mesa/src' rm -f texutil.o gcc -c -O -mcpu=k6 -fomit-frame-pointer -mpreferred-stack-boundary=2 -malign-functions=4 -fschedule-insns2 -fexpensive-optimizations -ansi -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -pipe -I../../../../exports/include -I../../../../exports/include/X11 -I../../../../include/extensions -I../../../../extras/Mesa/src -I../../../../lib/GL/dri -I../../../../extras/Mesa/include -I../../../../lib/GL/include -I../../../.. -I../../../../exports/include -I/usr/X11R6/include -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -DFUNCPROTO=15 -DNARROWPROTO -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API-DMALLOC_0_RETURNS_NULL -DGLXEXT -DXF86DRI -DGLX_DIRECT_RENDERING -DGLX_USE_DLOPEN -DGLX_USE_MESA-DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASMtexutil.c In file included from texutil.c:85: ../../../../extras/Mesa/src/texutil_tmp.h: In function `texsubimage2d_pack_rgba_direct': ../../../../extras/Mesa/src/texutil_tmp.h:188: structure has no member named `packing' [-] Thanks, Dieter ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
