On Sat, 30 Nov 2002 19:52:50 +
José Fonseca [EMAIL PROTECTED] wrote:
On Sat, Nov 30, 2002 at 08:04:55PM +0100, Felix Kühling wrote:
[snip]
Vertex formats are the real problem. Driver functions are called
directly from the GL application and modify the driver state bypassing
Hi,
while I was trying to understand the vtxfmt mesa code and poking around
with gdb I noticed that the neutral vtxfmt wrapper gets restored quite
often. I tracked it to radeonFlushVertices where
_mesa_install_exec_vtxfmt( ctx, rmesa-vb.vtxfmt ) is called if the
FLUSH_UPDATE_CURRENT flag is set.
On Sat, 30 Nov 2002 23:32:06 +0100
Felix Kühling [EMAIL PROTECTED] wrote:
Hi,
while I was trying to understand the vtxfmt mesa code and poking around
with gdb I noticed that the neutral vtxfmt wrapper gets restored quite
often. I tracked it to radeonFlushVertices where
Hi,
my digging is starting to pay off ;)
I had reported that weird problem, that the global ambient light is not
correct using hardware TCL if I specify anything other than 1.0 as alpha
component. Now I found out that the trigger for this problem is actually
to specify the default of (0.2, 0.2,
.
It is enough the copy a context only once, when it moves from the main
thread to a free thread.
I think this task is not trivial but feasible. It would allow SMP
systems to benefit from the inherent parallelism in the rendering
process.
Regards,
Felix
On Thu, 28 Nov 2002 20:59:08 +0100
Felix
On Fri, 29 Nov 2002 11:15:19 +
José Fonseca [EMAIL PROTECTED] wrote:
On Fri, Nov 29, 2002 at 10:19:52AM +0100, Felix Kühling wrote:
Hi,
I got pretty excited about this idea and spent some more thought on it.
I'm going to share my insights in this mail. Any comments are
appreciated
On Fri, 29 Nov 2002 11:15:19 +
José Fonseca [EMAIL PROTECTED] wrote:
On Fri, Nov 29, 2002 at 10:19:52AM +0100, Felix Kühling wrote:
[snip]
I think that one thing that must be thought is whether the parallelism
should be in the pipeline stages or in the pipeline data, i.e., if we
should
On Fri, 29 Nov 2002 13:20:45 +
José Fonseca [EMAIL PROTECTED] wrote:
[snip]
Let'me ilustrate with an example. Image you have 1000 polygons to
process (i.e., transform, clip, build vertex buffers, and render). If
you have a SMP computer with 4 processors you can make use of
parallelism
On Fri, 29 Nov 2002 07:55:52 -0700
Brian Paul [EMAIL PROTECTED] wrote:
Felix Kühling wrote:
My approach was basically inspired by the fact that there is something
in mesa that is called pipeline. So I thought, why not implement it
like a real pipeline. If we really want to parallelize
On Fri, 29 Nov 2002 19:02:14 +0100
Dieter Nützel [EMAIL PROTECTED] wrote:
But if it works correctly with RADEON_TCL_FORCE_DISABLE that indicates
that the Mesa code is correct.
How is it called for the r200?
RADEON_TCL_FORCE_DISABLE / R200_TCL_FORCE_DISABLE both didn't work.
R200_NO_TCL.
On Fri, 29 Nov 2002 22:46:08 +
Ian Molton [EMAIL PROTECTED] wrote:
On Fri, 29 Nov 2002 14:54:30 +0100
Felix Kühling [EMAIL PROTECTED] wrote:
When the red polygons are
to be run through the pipeline and the blue ones aren't finished yet
What if the red ones are transparent
On Wed, 27 Nov 2002 09:44:52 +0100
Felix Kühling [EMAIL PROTECTED] wrote:
On Tue, 26 Nov 2002 22:04:59 +
Keith Whitwell [EMAIL PROTECTED] wrote:
Felix Kühling wrote:
Hi,
clipping of lines at the edges of the viewing volume doesn't seem to
work. The problem occurs both
Hi,
I came across the mesa pipeline a couple of times now, reading the mesa
sources. It struck me that all the pipeline stages are actually executed
sequentially. Does anyone who is more involved think it would be
worthwile to process several vertex buffers at a time in parallel
pipeline stages
On Tue, 26 Nov 2002 22:04:59 +
Keith Whitwell [EMAIL PROTECTED] wrote:
Felix Kühling wrote:
Hi,
clipping of lines at the edges of the viewing volume doesn't seem to
work. The problem occurs both with RADEON_TCL_FORCE_DISABLE and with
LIBGL_ALWAYS_INDIRECT. If I use a glOrtho (-1.0
Hi,
the circuit demo segfaults with direct and indirect rendering. It could
be a bug in circuit, but I didn't ever see this before the Mesa 5.0
merge. My xscreensaver version is 4.05.
With direct rendering it always occurs after about 45 seconds if I run
it with -delay 0 on my Radeon 7500. This
Never mind. I tracked it down, it's not a Mesa or DRI error. In fact it
was fixed in the new upstream version 4.06. The strange backtrace is
because a function overwrites its own return address with 0.
Regards,
Felix
On Wed, 27 Nov 2002 10:55:45 +0100
Felix Kühling [EMAIL PROTECTED] wrote
Hi,
clipping of lines at the edges of the viewing volume doesn't seem to
work. The problem occurs both with RADEON_TCL_FORCE_DISABLE and with
LIBGL_ALWAYS_INDIRECT. If I use a glOrtho (-1.0, 1.0, -1.0, 1.0, -1.0,
1.0) projection this works:
glBegin(GL_LINES);
glColor3f(1.0, 0.0, 0.0);
On Sun, 24 Nov 2002 22:20:26 +
[EMAIL PROTECTED] wrote:
In the past few months I've been noticing 2 problems with my A7M266-D
(dual athlon) computer (2 processors installed) with its ATI Radeon
7500 gfx card:
1) Whenever I try to burn CD's at x20 it falls over very quickly
(about
Hi Ingo,
I think I read something about problems with the module loader some
weeks ago on dri-devel. Bad things happen when the same module is loaded
twice. In your config this happens with GLcore which is automatically
(re)loaded by the glx module. Do you still get segfaults if you remove
the
On Fri, 15 Nov 2002 08:00:27 -0700
Brian Paul [EMAIL PROTECTED] wrote:
Felix Kühling wrote:
[...]
There's a bug in your program. The GL light position is a homogeneous
coordinate (4 components) but you're only providing 3 components:
GLfloat lightpos[3] = {0.0, 10.0, 0.0
Hi,
I made a small programme to illustrate the TCL/SW lighting differences.
It displays a square consisting of 10x10 quads which is lit by one
lightsource. The distance between the lightsource and the square is
changed periodically. With TCL this has the desired effect, with
software lighting it
Hi all,
not too long ago I read on this list that you have to be extra careful
about using floating point in the kernel. Is the same true for MMX? If
so, would it be dangerous to compile a kernel module with -march=athlon?
AFAIK gcc-3.2 generates MMX instructions if the target CPU supports
them.
On Sun, 10 Nov 2002 11:26:25 -0800 (PST)
Linus Torvalds [EMAIL PROTECTED] wrote:
On Sun, 10 Nov 2002, Felix Kühling wrote:
not too long ago I read on this list that you have to be extra careful
about using floating point in the kernel. Is the same true for MMX? If
so, would
On 04 Nov 2002 15:33:37 +0100
Christophe Saout [EMAIL PROTECTED] wrote:
Am Mon, 2002-11-04 um 07.51 schrieb [EMAIL PROTECTED]:
i'm using a kernel 2.4.20-pre11 with a radeon module compiled from CVS. I have a
radeon 8500 LE (r200 QL), and every time i want to switch from X to VT, i've got
On Tue, 29 Oct 2002 13:23:22 +
Keith Whitwell [EMAIL PROTECTED] wrote:
Felix,
I've cleaned up the WaitForFrameCompletion function a bit committed. The
logic is slightly different, but a lot easier to read/understand, I think.
Ok, I just think that the name rmesa-irqsEmitted is now a
On Tue, 29 Oct 2002 14:09:56 +
Keith Whitwell [EMAIL PROTECTED] wrote:
Felix Kühling wrote:
On Tue, 29 Oct 2002 13:23:22 +
Keith Whitwell [EMAIL PROTECTED] wrote:
Felix,
I've cleaned up the WaitForFrameCompletion function a bit committed. The
logic is slightly different
On Mon, 28 Oct 2002 13:08:15 +
Keith Whitwell [EMAIL PROTECTED] wrote:
Felix Kühling wrote:
[snip]
Felix, do you have versions of these that apply cleanly to the trunk? R200
in particular.
I suppose the applied cleanly two weeks ago ;) New versions are attached.
Keiht
Felix
Hi,
I had my Xserver running for about 24 hours straight and noticed that it
was using about 220M virtual memory. Even after closing all clients and
logging out the memory usage didn't drop significantly. After I killed
and restarted gdm it uses only about 90M. Does this indicate a memory
leak in
On Fri, 25 Oct 2002 23:38:41 +0100
Ian Molton [EMAIL PROTECTED] wrote:
On Fri, 25 Oct 2002 10:34:35 -0700
Ian Romanick [EMAIL PROTECTED] wrote:
Time step 1:
cut
Er. surely you would render lkike this
1: Display 0 Render 1
2: Display 0.n Render 2
Now, if still displaying
On Sun, 27 Oct 2002 16:00:16 +0100
Felix Kühling [EMAIL PROTECTED] wrote:
Hi,
I had my Xserver running for about 24 hours straight and noticed that it
was using about 220M virtual memory. Even after closing all clients and
logging out the memory usage didn't drop significantly. After I
On Thu, 24 Oct 2002 06:24:28 -0700
Ian Romanick [EMAIL PROTECTED] wrote:
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
On Fri, 25 Oct 2002 23:44:21 +0200
Dieter Nützel [EMAIL PROTECTED] wrote:
Am Montag, 14. Oktober 2002 22:36 schrieb Felix Kühling:
Hi,
here is a new set of frame throttling patches for the radeon and r200
drivers. It implements a second chance strategy to avoid ping-ponging
between
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
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,
Hi,
after upgrading to the merged XFree89 4.2.99.2 XFree86.0.log contains
this:
(**) RADEON(0): Display dimensions: (315, 236) mm
(**) RADEON(0): DPI set to (154, 154)
xdpyinfo still shows the correct 92 DPI:
dimensions:1152x864 pixels (317x238 millimeters)
resolution:92x92 dots per
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:
(**) RADEON(0): Display dimensions: (315, 236) mm
(**) RADEON(0
On Wed, 23 Oct 2002 00:37:47 +0200
Malte Cornils [EMAIL PROTECTED] wrote:
Hi,
I'm having a visual problem with an application (NWN under Wine) - it works
fine with LIBGL_ALWAYS_INDIRECT=true but displays the problem (some textures
flicker and show wrong colours) with hardware-accelerated
Hi,
as a conclusion from the gcc-3.2 problems thread a week ago, here is a
patch that fixes inconsistent type aliasing in the radeon and r200
drivers. Can someone with CVS access commit this please?
Best regards,
Felix
__\|/_____ ___ ___
__Tschüß___\_6
Hi,
here is a new set of frame throttling patches for the radeon and r200
drivers. It implements a second chance strategy to avoid ping-ponging
between busy waiting and IRQ waiting with very high frame rates.
Best regards,
Felix
__\|/_____ ___ ___
On Sun, 13 Oct 2002 09:34:17 +0100
José Fonseca [EMAIL PROTECTED] wrote:
Felix,
On Sun, Oct 13, 2002 at 02:47:18AM +0200, Felix Kühling wrote:
More results:
I get the same strange behaviour when I compile with -march=pentium2. I
could narrow it down to lib/GL/mesa/src/drv/radeon
Hello,
I've looked into my gcc-3.2 problem again and found out that gcc-3.2
with -march=athlon produces the problem I described in every detail in a
previos mail (wirebox example).
What made this so tedious to find (the problem was appearing and
disappearing arbitrarily) is an inconsistency in
with gcc 3.2)
Afaik I didn't use -march=athlon:
#define DefaultGcc2i386Opt -O2
#define MesaUse3DNow YES
This is a Radeon 64MB VIVO on a 760MP / SMP Athlon machine.
--AHI
At 12 October, 2002 Felix Kühling wrote:
[snip]
Regards,
Felix
Date: Sat, 12 Oct 2002 13:19:02 -0700
From: Allen H. Ibara [EMAIL PROTECTED]
To: Felix Kühling [EMAIL PROTECTED]
Subject: Re: [Dri-devel] gcc-3.2 problem and Makefile inconsistency
I was referring to another problem. I described it in a mail with
subject Strange effects with Radeon7500 last
is that some other part of the radeon driver or Mesa makes assumptions
about the MMX state which are not true when compiling with
-march=athlon.
I tried disabling MesaUse3DNow and MesaUseMMX in host.def, but that
didn't help.
Regards,
Felix
On Sat, 12 Oct 2002 18:57:45 +0200
Felix Kühling [EMAIL
On 11 Oct 2002 18:15:08 +0200
Michel Dänzer [EMAIL PROTECTED] wrote:
I was looking into the lighting issues Felix reported with the
xscreensaver pulsar hack (when running it with the -light option). One
side of the planes looks good, the other one is black, so I thought it
might be related
On Fri, 11 Oct 2002 18:00:18 +0100
Keith Whitwell [EMAIL PROTECTED] wrote:
Felix Kühling wrote:
On 11 Oct 2002 18:15:08 +0200
Michel Dänzer [EMAIL PROTECTED] wrote:
I was looking into the lighting issues Felix reported with the
xscreensaver pulsar hack (when running
Hi Keith,
I attached a new r100 waiting patch against the latest trunk. I assume
that you have the most up-to-date r200 waiting code in your tree. I
added EAGAIN to conditions handled gracefully. But I couldn't find any
situation in which the DRM_RADEON_IRQ_WAIT ioctl returns -EAGAIN (using
grep
On Tue, 08 Oct 2002 13:34:47 +0100
Keith Whitwell [EMAIL PROTECTED] wrote:
Felix Kühling wrote:
Hi Keith,
I attached a new r100 waiting patch against the latest trunk. I assume
that you have the most up-to-date r200 waiting code in your tree. I
added EAGAIN to conditions handled
On Tue, 8 Oct 2002 11:29:44 +0300
Ilia Zadorozhko [EMAIL PROTECTED] wrote:
Hi people,
Help me please getting DRI to work.
I've installed latest (rage128-20021008-linux.i386.tar.bz2) versions of DRI.
Function drmSetBusid requires some kind of permission, which I can't
understand.
Hi,
I can't make any cvs updates or checkouts. It hangs up with messages
like this one:
cvs server: [12:29:45] waiting for anoncvs_dri's lock in /cvsroot/dri/xc/xc/lib/GLw
If I understand the numbers correctly then there is a lock which is over
12 hours old. That's a bit confusing, I completed
Hello,
I wanted to learn more about OpenGL during the weekend and started
reading the OpenGL Programming Guide. The first example I tried
(Example 3.1 Transformed Cube) displayed only a black window with hw
accel but worked fine with LIBGL_ALWAYS_INDIRECT=1.
I made some modifications to the
On Mon, 7 Oct 2002 21:14:16 +0200
Felix Kühling [EMAIL PROTECTED] wrote:
Hello,
I wanted to learn more about OpenGL during the weekend and started
reading the OpenGL Programming Guide. The first example I tried
(Example 3.1 Transformed Cube) displayed only a black window with hw
accel
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
Hi all,
D S and I discovered that Mandrake 9.0 includes Gatos code in their
Xserver. I think this is the reason for the problems Mandrake 9.0 users
are experiencing with binary snapshots. Up to now the only solution
seems to be to compile DRI yourself. A suitable custom binary snapshot
(if
On 03 Oct 2002 11:01:57 +0200
Michel Dänzer [EMAIL PROTECTED] wrote:
On Don, 2002-10-03 at 01:52, thork wrote:
about the aperture thing, he told me those 8Mb where from system memory
not from the video card memory, I found this thing in the log:
(--) RADEON(0): VideoRAM: 65536 kByte
I happened to be be looking for information about this a few days ago
and could recover the address from my history:
http://www.winischhofer.net/linuxsis630.shtml
It contains very detailed information about latest driver development.
Sorry, 2D only.
On Tue, 1 Oct 2002 13:26:59 +0100
José
On Tue, 01 Oct 2002 11:59:31 +0100
Keith Whitwell [EMAIL PROTECTED] wrote:
Felix Kühling wrote:
Hi r200'ers,
here is the improved frame throttling for r200. It compiles on my
system. Time for testing ...
I still get a lot of busy waiting with this patch. I assume the behaviour
Keith,
you got the condition for waiting for an interrupt wrong.
r200_ioctl.c, line 330
...
/* if there was a previous frame, wait for its IRQ */
- if (iw-irq_seq != -1 sarea-last_frame r200GetLastFrame( rmesa ) ) {
+ if (iw-irq_seq != -1 r200GetLastFrame( rmesa )
Hi everybody,
I just remembered that I had similar symptoms to the ones frequently
described on the dri-users list lately (screen goes to power saving
mode, system locked). It was after the cvs update that introduced
interrupt controlled frame throttling.
I noticed that my BIOS assigned IRQ 10
Hi r200'ers,
here is the improved frame throttling for r200. It compiles on my
system. Time for testing ...
Best regards,
Felix
__\|/_____ ___ ___
__Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___
_Felix___\Ä/\ \_\ \_\
Keith,
I implemented the smart waiting scheme we discussed yesterday. Just to
get the purpose of the whole thing straight again: it is to minimize the
amount of busy waiting as well as the number of lost IRQs. In that case
the attached patch does a pretty good job.
The simple cases are when
On 29 Sep 2002 01:58:16 +0200
Michel Dänzer [EMAIL PROTECTED] wrote:
On Sam, 2002-09-28 at 19:59, Felix Kühling wrote:
On Sat, 28 Sep 2002 18:02:08 +0100
José Fonseca [EMAIL PROTECTED] wrote:
I just uploaded a set of binary snapshots built from the CVS head
using RedHat's compat
On Sun, 29 Sep 2002 22:47:47 +0200
Felix Kühling [EMAIL PROTECTED] wrote:
On Sun, 29 Sep 2002 13:22:44 -0700
Keith Whitwell [EMAIL PROTECTED] wrote:
CVSROOT:/cvsroot/dri
Module name:xc
Repository: xc/xc/lib/GL/mesa/src/drv/radeon/
Changes by: keithw@usw-pr-cvs1. 02/09
On Sun, 29 Sep 2002 13:22:44 -0700
Keith Whitwell [EMAIL PROTECTED] wrote:
CVSROOT: /cvsroot/dri
Module name: xc
Repository: xc/xc/lib/GL/mesa/src/drv/radeon/
Changes by: keithw@usw-pr-cvs1. 02/09/29 13:22:44
Log message:
irqwait patch from felix
Modified files:
On Sun, 29 Sep 2002 23:25:03 +0200
Dieter Nützel [EMAIL PROTECTED] wrote:
Am Sonntag, 29. September 2002 22:57 schrieb Felix Kühling:
On Sun, 29 Sep 2002 22:47:47 +0200
Felix Kühling [EMAIL PROTECTED] wrote:
On Sun, 29 Sep 2002 13:22:44 -0700
Keith Whitwell [EMAIL PROTECTED
On Sun, 29 Sep 2002 22:37:36 +0100
Keith Whitwell [EMAIL PROTECTED] wrote:
Felix Kühling wrote:
On Sun, 29 Sep 2002 23:25:03 +0200
Dieter Nützel [EMAIL PROTECTED] wrote:
[snip]
Is r100/r200 a completely different thing?
If not why not a patch against both?
Then the testing audience
Hello,
Modifying the frame throttling code in r200_ioctl.c I removed
R200_MAX_OUTSTANDING which is no longer needed there. It is, however,
still used in r200Clear:
if ( rmesa-sarea-last_clear - clear = R200_MAX_OUTSTANDING+1 ) {
break;
}
The corresponding radeonClear uses
Hi,
I was able to reduce CPU usage of applications which use glFinish by
emitting and waiting for an IRQ in radeonFinish before
radeonWaitForIdle. I'm not sure whether radeonWaitForIdle is still
needed after waiting for the IRQ, but keeping it does at least not hurt.
The patch is attached.
One
On Sat, 28 Sep 2002 16:31:56 +0100
Keith Whitwell [EMAIL PROTECTED] wrote:
[snip]
Using a static variable doesn't cut it -- that should go into the
radeonContext struct in radeon_context.h.
Beyond that, it would be *nice* if the irq never happened unless we thought
that we were in danger
On Sat, 28 Sep 2002 21:36:43 +0200
Dieter Nützel [EMAIL PROTECTED] wrote:
Am Samstag, 28. September 2002 21:20 schrieb Felix Kühling:
On Sat, 28 Sep 2002 17:28:01 +0100
Keith Whitwell [EMAIL PROTECTED] wrote:
Felix Kühling wrote:
[snip]
Ok, I think it can be done. However, we
at 10:09:44PM +0200, Felix Kühling wrote:
On Sun, 14 Jul 2002 19:59:08 +0100
José Fonseca [EMAIL PROTECTED] wrote:
[...]
reproduce it (by the look of its webpages, TORCS seems a nice way to
spend sometime ;-). I'll also redo the other extra safety check that
was failing before on my
:17:01 viking kernel: [drm]SRC_CNTL = 0x0f00
Jul 15 13:17:01 viking kernel: [drm:mach64_do_dma_idle] *ERROR* mach64_do_dma_idle
failed BM_GUI_TABLE=0x0051c000 tail: 4
On Mon, 15 Jul 2002 13:16:37 +0200
Felix Kühling [EMAIL PROTECTED] wrote:
Hi José,
I got a similar error
Oops, forgot to copy this one to the list...
Begin forwarded message:
Date: Mon, 15 Jul 2002 15:09:17 +0200
From: Felix Kühling [EMAIL PROTECTED]
To: José Fonseca [EMAIL PROTECTED]
Subject: Re: [Dri-devel] Mach64: Error flushing vertex buffer: return = -11
On Mon, 15 Jul 2002 12:56:33 +0100
I saw a similar problem in torcs. First I thought it was just a problem
with too little z-buffer accuracy. But when you look closely you see
that the polygon is too bright.
http://www.dd.chalmers.se/~kuhlfeli/torcsbug.jpg
On Mon, 15 Jul 2002 19:08:29 -0400 (EDT)
Leif Delgass [EMAIL PROTECTED]
On Sun, 14 Jul 2002 19:59:08 +0100
José Fonseca [EMAIL PROTECTED] wrote:
On Sat, Jul 13, 2002 at 08:12:26PM -0400, Leif Delgass wrote:
On Sat, 13 Jul 2002, Leif Delgass wrote:
On Sun, 14 Jul 2002, José Fonseca wrote:
But the fact remains that the reads from GUI_STAT aren't
Hi,
I tried another game: Torcs. Occasionally (about once in 1 or 2 hours)
it crashes with Error flushing vertex buffer: return = -11. This is
the corresponding kernel log:
Jul 13 23:04:30 viking kernel: [drm:mach64_freelist_get] *ERROR* Empty ring with
non-idle engine!
Jul 13 23:04:30 viking
On Thu, 11 Jul 2002 16:44:50 -0400 (EDT)
Leif Delgass [EMAIL PROTECTED] wrote:
On Thu, 11 Jul 2002, Allen Barnett wrote:
On Wednesday 10 July 2002 07:59 pm, Leif Delgass wrote:
On Thu, 11 Jul 2002, José Fonseca wrote:
Allen, thanks for the detailed report of the problems. It's gonna
Hi,
just updated after reading José's mail about the MACH64_NATIVE_VTXMFT
and tried running some apps. q3demo and quake2 crashed with multi
textures enabled:
q3demo.x86: mach64_tris.c:518: mach64_draw_triangle: Assertion `vb == vbchk' failed.
I found the problem in the COPY_VERTEX macro. The
Hi,
I just read Davids mail about bzflag performance on mach64. Incidentally
last night I tried bzflag for the first time on mach64 and it froze the
X server reproducibly (tried it twice) just after starting bzflag. By
now I found out that it's related to switching the screen resoultion.
Without
On Mon, 8 Jul 2002 14:42:52 -0400 (EDT)
Leif Delgass [EMAIL PROTECTED] wrote:
On Mon, 8 Jul 2002, Leif Delgass wrote:
On Mon, 8 Jul 2002, Felix Kühling wrote:
On Mon, 8 Jul 2002 10:52:11 -0400 (EDT)
Leif Delgass [EMAIL PROTECTED] wrote:
On Mon, 8 Jul 2002, José Fonseca
On Thu, 4 Jul 2002 17:19:23 +0100
Tim Smith [EMAIL PROTECTED] wrote:
(on my system glxgears behaves quite oddly with pageflipping enabled even
with only one; it has brief periods of seeming to animate slowly backwards,
but shows no significant change in framerate - it is the only app that
On Sun, 30 Jun 2002 15:06:34 -0400 (EDT)
Leif Delgass [EMAIL PROTECTED] wrote:
On Sun, 30 Jun 2002, Alan Hourihane wrote:
On Sun, Jun 30, 2002 at 12:39:30 +0200, Felix Kühling wrote:
Hi mach64 folks,
after several weeks of extreme busyness/absence I am back now and
testing
Hi mach64 folks,
after several weeks of extreme busyness/absence I am back now and
testing the mach64-0-0-4 and 0-0-5 branches again (still the best I can
do :( ). It's great that you got 2D accel working. However, there is
still one problem.
Moving a GL window caused the X-server to segfault
current
config :)
Regards,
Felix
On Sat, 1 Jun 2002 22:02:14 -0400 (EDT)
Leif Delgass [EMAIL PROTECTED] wrote:
On 31 May 2002, Michel Dänzer wrote:
On Fri, 2002-05-31 at 02:30, Felix Kühling wrote:
I reported lockups shortly after starting the Xserver with a gcc 3.0
compiled drm
On Sun, 2 Jun 2002 13:48:02 -0400 (EDT)
Leif Delgass [EMAIL PROTECTED] wrote:
[...]
I had a closer look at this. I get a lockup when I run the Xserver
without DRI after switching from a 2D accelerated XFree86 4.1 server to
the text console. If DRI is loaded there is no problem. If I start
On 31 May 2002 23:20:19 +0200
Michel Dänzer [EMAIL PROTECTED] wrote:
On Fri, 2002-05-31 at 02:30, Felix Kühling wrote:
I reported lockups shortly after starting the Xserver with a gcc 3.0
compiled drm module that triggered the strange permission problem. Now I
tested it without
with the SiS 6326 either. Can someone confirm this?
Best regards,
Felix Kühling
On Wed, 29 May 2002 13:01:30 GMT
[EMAIL PROTECTED] wrote:
Hi!
Kernel having problem when compiling: 2.4.17.
glibc 2.1.2
gcc 2.95.3
hardware=AMD K6 II 450 MHz, SIS 6326 Display (VGA)
card supporting AGP 2x PCI 2.1
On 30 May 2002 00:25:08 +0100
Sergey V. Udaltsov [EMAIL PROTECTED] wrote:
Again and again I take snapshots, again Permission denied even for
root. What could this be? Can it be related to gcc 3.1 I use to build
the kernel module in the snapshot? Really strange situation to me...
Regards,
On Fri, 24 May 2002 18:18:51 +0200
Alexander Stohr [EMAIL PROTECTED] wrote:
Good fix Felix.
I do hate local function prototypes.
Its just bad coding style and laziness.
Further it shows a critical lack of
knowledge for the header file organisation.
In this case there aren't even any
the useless local redeclaration of
swap. This allows inlining the swap function in both 2.95 and 3.0.4.
Note I checked all this in the assembler output. I'm just not sure
whether the problem should be regarded a g++ bug or not.
The patch is attached.
Regards,
Felix Kühling
On Thu, 23 May 2002 23:05:32 +0100
José Fonseca [EMAIL PROTECTED] wrote:
On 2002.05.23 22:37 Leif Delgass wrote:
I've committed code to read BM_GUI_TABLE to reclaim processed buffers and
[...]
Monday the 20th but after Saturday the 18th, could you test to see if
this
happens? I'm not
On Sat, 18 May 2002 11:30:28 -0400 (EDT)
Leif Delgass [EMAIL PROTECTED] wrote:
Did you have a 2D accelerated server running on another vt? The DDX saves
and restores its register state on mode switches, so it could be a problem
with the FIFO depth or pattern registers being changed. Try
On Sat, 18 May 2002 15:56:00 +0100
José Fonseca [EMAIL PROTECTED] wrote:
Nice report ;-)
Thanks :)
Try with xfree-gdb (http://www.dawa.demon.co.uk/xfree-gdb/) to see if you
have better luck.
Yep, that gave better results. Since I have only one computer here and
the display turns black I
On Sat, 18 May 2002 18:26:52 +0100
José Fonseca [EMAIL PROTECTED] wrote:
I also have to start using another X server in a sep window cause having
to log out everytime I want to test is a PITA.
I'm not sure whether I get this correctly. Anyway, I have my 2D Xserver
running on vt7 and start
Hi,
I just tested the latest version and it seems to work so far. But Leif
didn't activate any real new stuff yet, right? However, the behaviour
after switching vt and back has changed. glxgears starts, the window
stays black for a second and disappears. In the xterm I get the
following message:
On Fri, 3 May 2002 04:01:42 -0400 (EDT)
Leif Delgass [EMAIL PROTECTED] wrote:
I wanted to give you an update on my progress since I sent the first patch
of my merge. None of this is checked in yet, btw. I added the necessary
initialization to atidri.c, based on the glint/gamma driver, and
On 02 May 2002 23:19:10 +0100
Sergey V. Udaltsov [EMAIL PROTECTED] wrote:
BTW, it was mentioned it was easy to enable 2D acceleration back. Is it
true? Can it be done in snapshots (by checking this illustrious
pATI-directRenderingEnabled). So people could use snapshot drivers in
everyday
Hi,
I tried DMA on the mach64-0-0-4-branch now. All the gl application seem
to work fine. But after switching to another console and back (without
running a gl app at the same time:) the gl app's window is just black
after starting it, full CPU load in the kernel and the X-server reacts
very
On Tue, 30 Apr 2002 18:25:03 -0400 (EDT)
Leif Delgass [EMAIL PROTECTED] wrote:
On Tue, 30 Apr 2002, José Fonseca wrote:
On 2002.04.30 13:41 Felix Kühling wrote:
Hi,
I tried DMA on the mach64-0-0-4-branch now. All the gl application seem
to work fine. But after switching
Hi,
I cvs updated mach64-0-0-4-branch last night and recompiled (previous
update was on sunday). Right after starting glxgears the screen switched
off (like with xset dpms force off) and the machine hung. The sysrq keys
didn't work.
Maybe Peter Anderson's problems are not PowerPC specific?
701 - 800 of 815 matches
Mail list logo
