[Dri-devel] Re: Strange messages
Hi Michel! Friday 04, at 12:29:26 AM you wrote: > > > > Yes, of course. Seeking this found another problem - darkplaces after hard > > playing (intro demo) lockups X - program exited abnormally with > > drmRadeonIrqWait: -4 message. > > -4 is -EINTR, i.e. the system call was interrupted by a signal. It > shouldn't abort on that, please try the attached patch. Thanks, this patch is solved the problem. -- WBR, Konstantin chat with ==>ICQ: 109916175 Lepikhov,speak to ==>JID: [EMAIL PROTECTED] aka L.A. Kostis write to ==>mailto:[EMAIL PROTECTED] ...The information is like the bank...(c) EC8OR --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Snaps for gcc<3, glibc-2.2
> "Andy" == Andy Dustman <[EMAIL PROTECTED]> writes: Andy> Which is it, then: Snapshots or no snapshots? The current snapshots (for Andy> linux-i386) don't work unless you have Red Hat 8.0 and/or glibc-2.3; I'm Andy> not even sure that they work on that platform. Broken snapshots are Andy> worse than no snapshots at all (you can't download something that isn't Andy> going to work if it isn't there). Well, I _do_ have gcc3.2 (gentoo-1.4) and at least radeon-20021002 does not work for me. The display gets black, monitor loses signal and I can't switch back to the console (it stays balck). But I can reboot with C-M-del. I remember this problem was already here. But I don't remmeber a solution (anonyone?). Bye, Adam -- I considered atheism but there weren't enough holidays. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] New snapshots available - please test (Was: Snaps for gcc<3, glibc-2.2)
On Thu, Oct 03, 2002 at 05:02:44PM -0600, Jens Owen wrote: >José Fonseca wrote: > >>Anyway, I already have the minimum chroot environment setup. I just >>need >>to test it with a few snapshots, and arrange so that everything can be >>automated from a cronjob again. Ok. I've just finished building a set of snapshots from the HEAD with this chroot environment. They are available from the usual place with a build tag of *-20021004-linux.i386.tar.bz2 . As said before these snapshots were made in a chroot environment, based on Gentoo Linux 1.2, with gcc-2.95.3, glib-2.2.5, and xfree-4.2.0. > >Your awesome! Thanks for your effort on these snapshots. It's nothing much, really. I've been using Gentoo Linux on my laptop for quite a while and I've always proceeded this way, i.e., by making a chroot environment where I install everything I need (from source which takes several days) and then move everything to the root and reboot. This way I can keep working during the process. The Gentoo Linux installation documentation pretty much describes all the process very nicely. The trickiest part that I still have to solve is doing this from crontab without opening a security hole on my machine - chroot requires root priveledges but I can't download, compile and _run_ code from the internet as root. My plan is to put it on root's cron job but call 'su' to become a regular user. This assuming, of course, that these snapshots are indeed the promised holly graal. Please test. José Fonseca --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Snaps for gcc<3, glibc-2.2
On Fre, 2002-10-04 at 10:59, Adam Duck wrote: > > "Andy" == Andy Dustman <[EMAIL PROTECTED]> writes: > > Andy> Which is it, then: Snapshots or no snapshots? The current snapshots (for > Andy> linux-i386) don't work unless you have Red Hat 8.0 and/or glibc-2.3; I'm > Andy> not even sure that they work on that platform. Broken snapshots are > Andy> worse than no snapshots at all (you can't download something that isn't > Andy> going to work if it isn't there). > > Well, I _do_ have gcc3.2 (gentoo-1.4) and at least radeon-20021002 > does not work for me. The display gets black, monitor loses signal and > I can't switch back to the console (it stays balck). But I can reboot > with C-M-del. I remember this problem was already here. But I don't > remmeber a solution (anonyone?). There have been several problems, one being IRQs. Please post the relevant parts of the server log etc. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] New snapshots available - please test (Was: Snapsfor gcc<3, glibc-2.2)
[...snip...] > > This assuming, of course, that these snapshots are indeed the promised > holly graal. Please test. > seem to work fine for my system (i tried the r200-package, on debian unstable, gcc is 2.95.4 on my system) nice work > José Fonseca > --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] New snapshots available - please test (Was: Snapsfor gcc<3, glibc-2.2)
On Fre, 2002-10-04 at 14:10, Stefan Lange wrote: > [...snip...] > > > > This assuming, of course, that these snapshots are indeed the promised > > holly graal. Please test. > > > > seem to work fine for my system > (i tried the r200-package, on debian unstable, gcc is 2.95.4 on my system) > nice work Yes, but BTW, for Debian users there's deb http://penguinppc.org/~daenzer/debian/dri-trunk/./ Not daily snapshots, but... -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Strange messages
On Fre, 2002-10-04 at 10:03, Konstantin Lepikhov wrote: > > Friday 04, at 12:29:26 AM you wrote: > > > > > > > > > Yes, of course. Seeking this found another problem - darkplaces after hard > > > playing (intro demo) lockups X - program exited abnormally with > > > drmRadeonIrqWait: -4 message. > > > > -4 is -EINTR, i.e. the system call was interrupted by a signal. It > > shouldn't abort on that, please try the attached patch. > Thanks, this patch is solved the problem. Great, I've fixed this in the radeon and r200 drivers now. Thanks for testing. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Patch to enable 3rd TMU on R100
On Fri, Sep 27, 2002 at 07:53:22PM +0100, Keith Whitwell wrote:
> One option is to have the kernel actually do the fixup of the buffers when
> they are submitted by the client, so the driver never knows really where it's
> textures are, but talks about them via. some indirection.
I've been looking into this to assess the difficulty of such an
implementation. The back patching would be done in radeon_emit_state /
radeon_emit_packets, yes?
In radeon_emit_packets you have some code like:
if ( packet is RADEON_PP_TXFILTER_? or R200_PP_TXOFFSET_? )
{
texture_id = data[ offset_of_texture_id ];
address = address of texture_id;
if ( address is not in texturable memory )
{
address = get space for texture;
copy_texture( from user memory to address );
}
data[ offset_of_texture_id ] = address of texture_id;
}
Is that basically what you had in mind? There would be similar code in
radeon_emit_state.
Ignoring issues of SGIS_generate_mipmaps or glCopyPixels for a moment, a
system like this would need some sort of fencing. Basically, reference
counting for packets that set a texture. When a texture is bound to a
texture unit, increment the counter. When another texture is bound, put a
command in the stream to trigger an interrupt. When the interrupt is
received, decrement the counter. If the counter is zero, then the texture
is not in use and can be taken out of memory.
This would also allow proper synchronization of glTexSubImage?D.
This also raises the question of NV_fence. If we go down this path, we will
have already implemented most of the infrastructure for NV_fence. Should we
go the final mile and export it?
--
Smile! http://antwrp.gsfc.nasa.gov/apod/ap990315.html
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Rage 10-04-2002 build causes 'vertical hold' problem with mplayerXv mode
I tested this build with glxinfo and glxgears, both of which worked just fine. In fact, gears seemed to perform slightly faster than in previous releases. However, when I tried to us mplayer in Xv mode, my screen behaved like the vertical hold had gone crazy. I'm on 2.4.19 using a Rage Mobility 8M card on a Dell Inspiron 4000 laptop. Please let me know if there's any testing I can perform. Jay signature.asc Description: This is a digitally signed message part
Re: [Dri-devel] Re: XAA versioning?
I checked out latest CVS earlier and compiled it, it seems to work fine now. - Chad On 1 Oct 2002, Michel [ISO-8859-1] Dänzer wrote: > On Mon, 2002-09-30 at 02:18, Chad Page wrote: > > > > Nope, dosen't work with that - I still have to comment out the > > call in RADEONResetVideo. Appears to be a failure within the sync function > > itself. > > Hmm, I changed RADEONWaitForIdleMMIO() to info->accel->Sync() because > the former doesn't necessarily have the desired effect if the CP is > running. I guess that could be reverted if RADEONWaitForIdleCP() > crashes, I'm curious why though; can you dig a little further? > > > -- > Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer > XFree86 and DRI project member / CS student, Free Software enthusiast > > > > --- > This sf.net email is sponsored by: DEDICATED SERVERS only $89! > Linux or FreeBSD, FREE setup, FAST network. Get your own server > today at http://www.ServePath.com/indexfm.htm > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel > --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: XAA versioning?
On Sam, 2002-10-05 at 01:29, Chad Page wrote: > > I checked out latest CVS earlier and compiled it, it seems to work > fine now. Yes, I tracked this down together with Kevin Puetz. Glad to hear the fix works for you as well. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Rage 10-04-2002 build causes 'vertical hold'problem with mplayer Xv mode
On Sam, 2002-10-05 at 00:42, Jay Phelps wrote:
> I tested this build with glxinfo and glxgears, both of which worked just
> fine. In fact, gears seemed to perform slightly faster than in previous
> releases.
>
> However, when I tried to us mplayer in Xv mode, my screen behaved like
> the vertical hold had gone crazy.
>
> I'm on 2.4.19 using a Rage Mobility 8M card on a Dell Inspiron 4000
> laptop.
Man, a 'Rage Mobility' could be anything from a Mach64 to a Radeon. :)
Anyway, from the problem I guess it's a Rage128? I just committed a
patch that makes the feature which causes instabilities an option
("DMAForXv") which defaults to off. In the meantime, Option
"XaaNoPixmapCache" or a similar option is supposed to work around the
problem.
--
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member / CS student, Free Software enthusiast
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Am Mittwoch, 2. Oktober 2002 09:58 schrieb Keith Whitwell: > > I definitely running this on my dual Athlon with latest ACPI for 2.4.19 > > and irq's routing enabled, I think. > > > > With "procinfo -f" I see ~980 irq/sec during "gears". > > > > Same with r200 code from yesterday. But it was much faster. > > I think I may have fixed your problem (thanks to Felix), can you try again? I think you have. 2.4.19-ck5 (O(1) + -AA + preemption) gears: ~2380 fps System load ~25-26% But Q3A get best (~136 fps) only with "setenv R200_NO_USLEEPS 1". -Dieter --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
On Sat, 5 Oct 2002 03:50:38 +0200 Dieter Nützel <[EMAIL PROTECTED]> wrote: > Am Mittwoch, 2. Oktober 2002 09:58 schrieb Keith Whitwell: > > > I definitely running this on my dual Athlon with latest ACPI for 2.4.19 > > > and irq's routing enabled, I think. > > > > > > With "procinfo -f" I see ~980 irq/sec during "gears". > > > > > > Same with r200 code from yesterday. But it was much faster. > > > > I think I may have fixed your problem (thanks to Felix), can you try again? > > I think you have. > > 2.4.19-ck5 (O(1) + -AA + preemption) > > gears: > ~2380 fps > System load ~25-26% > > But Q3A get best (~136 fps) only with "setenv R200_NO_USLEEPS 1". Stefan Lange reported that Quake3 gives him max 50FPS which sounds like a usleep limit. I saw that usleep is used in several places in r200_ioctl.c. I'm afraid that my change in r200Clear may be causing trouble. I could actually reproduce the 50FPS limit on my Radeon7500 by changing radeonClear to behave like r200Clear (set RADEON_MAX_CLEAR to 1 and put in a usleep instead of busy waiting). With RADEON_MAX_CLEAR == 2 everything seems fine. But maybe it wouldn't hurt increasing the limit a bit further, just to be sure. 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:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
> > But Q3A get best (~136 fps) only with "setenv R200_NO_USLEEPS 1". > > Stefan Lange reported that Quake3 gives him max 50FPS which sounds like > a usleep limit. I saw that usleep is used in several places in > r200_ioctl.c. I'm afraid that my change in r200Clear may be causing > trouble. > > I could actually reproduce the 50FPS limit on my Radeon7500 by changing > radeonClear to behave like r200Clear (set RADEON_MAX_CLEAR to 1 and put > in a usleep instead of busy waiting). With RADEON_MAX_CLEAR == 2 > everything seems fine. But maybe it wouldn't hurt increasing the limit a > bit further, just to be sure. I've noticed in q3a, that if I'm following someone, it'll often (but not always) stick at 50fps. If I free fly, I see 2, and often 3's in the third fps column (if I look at the floor, I can get 4's, and occasionly 5's) this is with a radeon 8500 and AMD 2000XP+ (no enviromental variables set) --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] r200: UT and Q3A Intro (Cinematics) stuttering SOLVED
Short form tonight 'cause I'm somewhat tired and angry about X server hang during my tests so that I have to kill KMail (KDE 3.1 beta2) with my long one...;-( Kernel 2.5.40 (-mcp3/-ac3) did the trick. No more stuttering during UT 436 (numbers to come). Mesa/demos> ut& [1] 10759 Mesa/demos> r200CreateScreen bad type 0x0 for device fcntl: Invalid argument fcntl: Invalid argument [1]Fertigut Same with Q3A Intro (video and sound) and all the other Cinematics. For clarification: I have Q3A 1.31 so that I have to use "timedemo 1/demo four" for all my tests. Latest message from Q3A: r200Finish: drmRadeonIrqWait: -16 I think it's because I have latest DRI CVS but don't have the latest DRM kernel stuff for 2.5.40 because of compilation errors. 2.5.40+ should be updated as soon as possible to reach the deadline for the feature freeze around the 20th October (Halloweeen). The -file strukture have changed somewhat with 2.5. make -f Makefile.linux make[10]: Entering directory `/tmp/INSTALL/SOURCE/dri-trunk/xc/xc/programs/Xserver/hw/xfree 86/os-support/linux/drm/kernel' === KERNEL HEADERS IN /lib/modules/2.5.40-ac3/build/include === SMP=1 MODULES=1 MODVERSIONS=1 AGP=1 === Compiling for machine i686 === WARNING === WARNING Use 2.4.x kernels ONLY ! === WARNING cc -O2 -Wall -Wwrite-strings -Wpointer-arith -Wcast-align -Wstrict-prototypes -Wnested-externs -Wpointer-arith -D__KERNEL__ -DMODULE -fomit-frame-pointer -DCONFIG_AGP -DCONFIG_AGP_MODULE -DCONFIG_DRM_SIS -D__SMP__ -DMODVERSIONS -include /lib/modules/2.5.40-ac3/build/include/linux/modversions.h -DEXPORT_SYMTAB -I/lib/modules/2.5.40-ac3/build/include -c gamma_drv.c -o gamma_drv.o In file included from /lib/modules/2.5.40-ac3/build/include/linux/irq.h:19, from /lib/modules/2.5.40-ac3/build/include/asm/hardirq.h:6, from /lib/modules/2.5.40-ac3/build/include/linux/interrupt.h:25, from /lib/modules/2.5.40-ac3/build/include/asm/highmem.h:24, from /lib/modules/2.5.40-ac3/build/include/linux/highmem.h:12, from /lib/modules/2.5.40-ac3/build/include/linux/pagemap.h:10, from drmP.h:56, from gamma_drv.c:34: /lib/modules/2.5.40-ac3/build/include/asm/irq.h:16: irq_vectors.h: Datei oder Verzeichnis nicht gefunden make[10]: *** [gamma_drv.o] Error 1 cc -O2 -Wall -Wwrite-strings -Wpointer-arith -Wcast-align -Wstrict-prototypes -Wnested-externs -Wpointer-arith -D__KERNEL__ -DMODULE -fomit-frame-pointer -DCONFIG_AGP -DCONFIG_AGP_MODULE -DCONFIG_DRM_SIS -D__SMP__ -DMODVERSIONS -include /lib/modules/2.5.40-ac3/build/include/linux/modversions.h -DEXPORT_SYMTAB -I/lib/modules/2.5.40-ac3/build/include -c radeon_drv.c -o radeon_drv.o In file included from /lib/modules/2.5.40-ac3/build/include/linux/irq.h:19, from /lib/modules/2.5.40-ac3/build/include/asm/hardirq.h:6, from /lib/modules/2.5.40-ac3/build/include/linux/interrupt.h:25, from /lib/modules/2.5.40-ac3/build/include/asm/highmem.h:24, from /lib/modules/2.5.40-ac3/build/include/linux/highmem.h:12, from /lib/modules/2.5.40-ac3/build/include/linux/pagemap.h:10, from drmP.h:56, from radeon_drv.c:32: /lib/modules/2.5.40-ac3/build/include/asm/irq.h:16: irq_vectors.h: Datei oder Verzeichnis nicht gefunden make[10]: *** [radeon_drv.o] Error 1 Same for all DRM modules. Some more problems: VTK/bin> ./TaskParallelism r200CreateScreen r200CreateScreen r200_makeX86Normal3fv/197 CVAL 0 OFFSET 14 VAL 41bd1040 r200_makeX86Normal3fv/198 CVAL 4 OFFSET 20 VAL 41bd1044 r200_makeX86Normal3fv/199 CVAL 8 OFFSET 25 VAL 41bd1048 r200_makeX86Normal3fv done drmCommandWrite: -22 drmRadeonCmdBuffer: -22 Speicherschutzverletzung VTK/bin> ./TaskParallelismWithPorts r200CreateScreen r200_makeX86Normal3fv/197 CVAL 0 OFFSET 14 VAL 41bd1040 r200_makeX86Normal3fv/198 CVAL 4 OFFSET 20 VAL 41bd1044 r200_makeX86Normal3fv/199 CVAL 8 OFFSET 25 VAL 41bd1048 r200_makeX86Normal3fv done VTK/bin> ./vtk /opt/VTK/Local/sphere-bench.tcl-2.1 & [1] 10704 VTK/bin> r200CreateScreen [1]Speicherschutzverletzung ./vtk /opt/VTK/Local/sphere-bench.tcl-2.1 (core dumped) [snip] Loaded symbols for /usr/lib/gconv/ISO8859-15.so Reading symbols from /usr/X11R6/lib/modules/dri/r200_dri.so...done. Loaded symbols for /usr/X11R6/lib/modules/dri/r200_dri.so #0 0x40c88617 in Tcl_HashStats () from /usr/lib/libtcl8.3.so (gdb) bt #0 0x40c88617 in Tcl_HashStats () from /usr/lib/libtcl8.3.so #1 0x416d69e5 in vtkTclGetPointerFromObject () from /opt/VTK/V4.0/VTK/lib/libvtkCommonTCL.so #2 0x416d5995 in vtkTclGenericDeleteObject () from /opt/VTK/V4.0/VTK/lib/libvtkCommonTCL.so #3 0x40c636c7 in Tcl_DeleteCommandFromToken () from /usr/lib/libtcl8.3.so #4 0x40c63656 in Tcl_DeleteCommand () from /usr/lib/libtcl8.3.so #5 0x416d58e1 in vtkTclDeleteObjectFromHash () from /opt/VTK/V4.0/VTK/li
[Dri-devel] unsubscribing from list
Hi all, since we now have a new website and a new webmaster I will be unsubscribing from dri-devel. I would like to congratulate Liam on a job well done. At the same time I would like to apologize for my lack of involvement until recently. Had I gotten a little more involved from earlier on, the new site would have probably been ready much sooner. It was fun being a part of this project and definitely very interesting to follow some of the threads on this mailing list. I wish everyone and the project the best of luck in the future. Cheers, - Frank --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
