Malte Cornils wrote:
On Thu, Oct 24, 2002 at 01:31:14AM +0200, Malte Cornils wrote:
Is there any way I could help in a different way, maybe you could guess
something after looking at a screenshot? If you supply a patch, I promise
I'll test it, of course. With TCL it's way faster :-)
BTW,
On Die, 2002-10-22 at 16:01, Matthieu Bonetti wrote:
Thank you for your concern.
You can get all informtion about logs here:
http://perso.abew.net/radeon/
Hmm, is it any different in depth 24?
--
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI
On Mit, 2002-10-23 at 15:08, Alan Hourihane wrote:
On Wed, Oct 23, 2002 at 02:59:21PM +0200, Michel Dänzer wrote:
On Mit, 2002-10-23 at 01:37, Alan Hourihane wrote:
I'm committing the final part of the merge now. I have build tested
it and it does build fine, although I've not tested
On Thu, Oct 24, 2002 at 01:47:01PM +0200, Michel Dänzer wrote:
That certainly shouldn't be needed for shared entities. Where exactly
was it crashing ?
XAA dereferences pScrn-pScreen to track the state of shared entities.
RADEONScreenInit() calls other radeon driver functions which call
Hi,
I tried all the mesa demos last night. The glutfx demo got a segfault
when exiting. I got this backtrace:
#0 0x402bb980 in XrmMergeDatabases () from /usr/X11R6-DRI/lib/libX11.so.6
#1 0x402bcb28 in XrmQPutStringResource ()
from /usr/X11R6-DRI/lib/libX11.so.6
#2 0x402bcf63 in
It works perfectly fine ! No bugs, no nothing.
Howcome depth 16 is bugged ?
On 24 Oct 2002 13:51:49 +0200
Michel Dänzer [EMAIL PROTECTED] wrote:
On Die, 2002-10-22 at 16:01, Matthieu Bonetti wrote:
Thank you for your concern.
You can get all informtion about logs here:
On Don, 2002-10-24 at 13:52, Alan Hourihane wrote:
On Thu, Oct 24, 2002 at 01:47:01PM +0200, Michel Dänzer wrote:
That certainly shouldn't be needed for shared entities. Where exactly
was it crashing ?
XAA dereferences pScrn-pScreen to track the state of shared entities.
Oops, the cursor bug is still here, but using the software mode is fine with me.
---
This sf.net email is sponsored by: Influence the future
of Java(TM) technology. Join the Java Community
Process(SM) (JCP(SM)) program now.
On Thu, Oct 24, 2002 at 02:00:48PM +0200, Michel Dänzer wrote:
On Don, 2002-10-24 at 13:52, Alan Hourihane wrote:
On Thu, Oct 24, 2002 at 01:47:01PM +0200, Michel Dänzer wrote:
That certainly shouldn't be needed for shared entities. Where exactly
was it crashing ?
XAA
On Thu, Oct 24, 2002 at 02:00:48PM +0200, Michel Dänzer wrote:
On Don, 2002-10-24 at 13:52, Alan Hourihane wrote:
On Thu, Oct 24, 2002 at 01:47:01PM +0200, Michel Dänzer wrote:
That certainly shouldn't be needed for shared entities. Where exactly
was it crashing ?
XAA dereferences
On Thu, Oct 24, 2002 at 01:34:33AM +0200, Felix Kühling wrote:
On Wed, 23 Oct 2002 13:24:32 -0700
Ian Romanick [EMAIL PROTECTED] wrote:
On Wed, Oct 23, 2002 at 09:22:05PM +0200, Felix Kühling wrote:
Hi,
after upgrading to the merged XFree89 4.2.99.2 XFree86.0.log contains
this:
Warning
Unable to process data:
multipart/mixed;boundary==_NextPart_000_00E1_37C22E8A.C0556D86
On Thu, Oct 24, 2002 at 01:53:01PM +0200, Felix Kühling wrote:
Hi,
I tried all the mesa demos last night. The glutfx demo got a segfault
when exiting. I got this backtrace:
[snip]
I checked radeonDestroyContext. It looks suspicious to me that a lot of
the context is destroyed *before* the
On Thu, Oct 24, 2002 at 06:08:37AM -0700, Ian Romanick wrote:
On Thu, Oct 24, 2002 at 01:34:33AM +0200, Felix Kühling wrote:
On Wed, 23 Oct 2002 13:24:32 -0700
Ian Romanick [EMAIL PROTECTED] wrote:
On Wed, Oct 23, 2002 at 09:22:05PM +0200, Felix Kühling wrote:
Hi,
after upgrading
On Thu, Oct 24, 2002 at 09:38:20AM -0400, David Dawes wrote:
On Thu, Oct 24, 2002 at 06:08:37AM -0700, Ian Romanick wrote:
On Thu, Oct 24, 2002 at 01:34:33AM +0200, Felix Kühling wrote:
On Wed, 23 Oct 2002 13:24:32 -0700
Ian Romanick [EMAIL PROTECTED] wrote:
On Wed, Oct 23, 2002 at
On Die, 2002-10-22 at 23:30, Malte Cornils wrote:
On Tue, Oct 22, 2002 at 01:07:24PM +0200, Michel Dänzer wrote:
The gotcha about TREE is that you have to provide the include directory, so
you'd have to use TREE=/home/mcornils/kernel-source-2.4.18/include in this case.
Errm, is this
On Don, 2002-10-24 at 13:53, Felix Kühling wrote:
[ backtrace on glutfx exit omitted ]
I checked radeonDestroyContext. It looks suspicious to me that a lot of
the context is destroyed *before* the RADEON_FIRE_VERTICES macro calls
radeonFlush. I moved RADEON_FIRE_VERTICES before any of the
On Mit, 2002-10-23 at 14:03, Matthieu Bonetti wrote:
It works perfectly fine ! No bugs, no nothing.
Howcome depth 16 is bugged ?
The 7500 and better chips have enough power to handle 32 bpp very well,
so most people probably run depth 24. I'll try to reproduce and
hopefully fix this when I get
Switching lit, unlit, Smooth and Flat in some combinations gave
partially texture corruption.
See the image.
-Dieter
attachment: isosurf.png
Dieter Nützel wrote:
Switching lit, unlit, Smooth and Flat in some combinations gave
partially texture corruption.
See the image.
Texturing is not used in that image.
Looks like the front/back material coefficients are incorrect.
-Brian
Dear list (and especially José),
This is a heads-up regarding post-merge DRI driver snapshots. I tried
building binary snapshots of my resume things yesterday in a post-merge
tree which is why I ran into these issues.
1. It seems the XFree86 module ABI version has been bumped upwards.
This
Am Donnerstag, 24. Oktober 2002 15:59 schrieb Michel Dänzer:
On Die, 2002-10-22 at 23:30, Malte Cornils wrote:
On Tue, Oct 22, 2002 at 01:07:24PM +0200, Michel Dänzer wrote:
The gotcha about TREE is that you have to provide the include
directory, so you'd have to use
Brian wrote:
Dieter Nützel wrote:
Switching lit, unlit, Smooth and Flat in some combinations gave
partially texture corruption.
See the image.
Texturing is not used in that image.
YES, of course.
Stupid me. To many things in parallel...;-)
Looks like the front/back material
http://marc.theaimsgroup.com/?l=linux-kernelm=103548024914815w=2
Cheers,
Dieter
---
This sf.net email is sponsored by: Influence the future
of Java(TM) technology. Join the Java Community
Process(SM) (JCP(SM)) program now.
On Thu, Oct 24, 2002 at 09:10:01AM +0100, Keith Whitwell wrote:
http://studsun1.ira.uka.de/~s_malte/nwn_tcl.png
http://studsun1.ira.uka.de/~s_malte/nwn.png
Hmm. Looks like depth fighting, but that doesn't make much sense as I
wouldn't expect there to be multipass rendering going on here.
On Thu, Oct 24, 2002 at 03:59:35PM +0200, Michel Dänzer wrote:
IMHO the best thing would be to educate users about
/lib/modules/`uname -r`/build .
So, how about a Please put a symbolic link to the location of your kernel
build tree under /lib/modules/`uname -r`/build if that file doesn't yet
On Don, 2002-10-24 at 17:20, Stefan Lange wrote:
I'm currently using cvs-code from the dri-trunk from today. I got
several crashes of the xserver (system was still running stable). Once,
however, I got a complete lockup. Examining the log-files after
rebooting, I found tons of these
Hi!
I'm currently using cvs-code from the dri-trunk from today. I got
several crashes of the xserver (system was still running stable). Once,
however, I got a complete lockup. Examining the log-files after
rebooting, I found tons of these messages:
in XFree86.0.log:
Stefan Lange wrote:
[...]
I attached the complete
server-log, in case that helps.
forgot to add the attachment, as usual...
XFree86.0.log.old.bz2
Description: Binary data
Hi,
after the XFree86 merge LOD_BIAS was broken, as can be clearly seen with
the lodbias mesa demo. Positive bias would have no effect, negative bias
would lead to garbaged textures. Someone must have accidentally changed
the RADEON_LOD_BIAS_MASK. The (one line) patch is attached.
Cheers,
Alan Hourihane wrote:
CVSROOT: /cvsroot/dri
Module name: xc
Repository: xc/xc/extras/ogl-sample/main/gfx/lib/glu/libnurbs/nurbtess/
Changes by: alanh@usw-pr-cvs1. 02/10/24 01:43:56
Log message:
remove duplicate of swap()
Modified files:
Ian Romanick wrote:
I would recommend an audit then a copy, with the DMA buffer being setup as
non-cached, write combining memory (like AGP mapped memory). The reason
being that you don't want to pollute the cache with blocks that are
essentially write-once.
This is dangerous - on SMP (or
On Thu, Oct 24, 2002 at 06:17:49PM +0200, Felix Kühling wrote:
after the XFree86 merge LOD_BIAS was broken, as can be clearly seen with
the lodbias mesa demo. Positive bias would have no effect, negative bias
would lead to garbaged textures. Someone must have accidentally changed
the
dri-trunk/xc diff xc/programs/Xserver/hw/xfree86/scanpci/xf86PciData.c
xc/programs/Xserver/hw/xfree86/scanpci/xf86PciData.c.Dieter
1c1
/* $XFree86: xc/programs/Xserver/hw/xfree86/scanpci/xf86PciData.c,v 1.5
2000/04/05 18:13:58 dawes Exp $ */
---
/* $XFree86:
Hello Keith,
I made a trace with TaskParallelism one of my VTK apps.
-Dieter
TaskParallelism.log.bz2
Description: BZip2 compressed data
I've checked in a bunch of changes to Mesa CVS but haven't yet updated
the DRI mesa-4-1 branch to compensate - so it won't compile. I'll check
in my fixes (plus a new R200 feature) tomorrow.
-Brian
---
This sf.net email is sponsored by:
36 matches
Mail list logo
