--- Leif Delgass [EMAIL PROTECTED] wrote:
On Sun, 7 Jul 2002, Brian Paul wrote:
The notion of 'current read buffer' is more complicated than one would
first expect. There are basically two situations in which you need to
read from a color buffer:
1. glRead/CopyPixels() and
Warning
Unable to process data:
multipart/mixed;boundary==_NextPart_000_00E0_33D22B1E.C2213E80
Michel Dänzer wrote:
On Fri, 2002-07-05 at 14:55, Stefan Lange wrote:
on more comment: xv seems to be broken, it only gives me a black overlay
window with mplayer. are there plans to merge with gatos some time?
http://www.keithp.com/~keithp/download/radeon_video.diff makes Xv work
with
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, 2002-07-08 at 06:51, David Willmore wrote:
In X server startup, the drm fails to load. If I exit and try to modprobe
it myself, I get errors about a bunch of AGP symbols not being resolved
Try recompiling the module with (in s3v.h)
__HAVE_AGP set to 0
(I should make this the
On Mon, 2002-07-08 at 10:22, Stefan Lange wrote:
Michel Dänzer wrote:
On Fri, 2002-07-05 at 14:55, Stefan Lange wrote:
on more comment: xv seems to be broken, it only gives me a black overlay
window with mplayer. are there plans to merge with gatos some time?
On Mon, Jul 08, 2002 at 11:55:55AM +0200, Felix Kühling wrote:
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
On Mon, 2002-07-08 at 12:14, Ian Molton wrote:
1) Can the Radeon 7500 use FSAA yet?
Haven't seen anything about that, so I assume no, but I may just have
missed it.
2) when is the GATOS code planned for merging?
Never with the DRI repository directly. Apparently their Mach64 stuff is
The scratch register values need to be read with DRM_READ32(), which
accounts both for endianness and memory barriers. So it would be
u32 done_age = DRM_READ32(dev_priv-scratch[1]);
etc.
Nice work!
I think it's probably worthwhile to commit this now. Michel, if
On Saturday 06 July 2002 20:38, David Willmore wrote:
Well, I've been waiting what seems like forever for a driver
for my laptop and now there is one! What a happy day! One
problem, it's an older Compaq laptop and uses a propriatary
chipset (and AGP bridge) so no AGPGART. *do-oh*
Michel Dänzer wrote:
On Mon, 2002-07-08 at 13:07, Keith Whitwell wrote:
The scratch register values need to be read with DRM_READ32(), which
accounts both for endianness and memory barriers. So it would be
u32 done_age = DRM_READ32(dev_priv-scratch[1]);
etc.
Nice work!
I
On Mon, 2002-07-08 at 07:31, Elladan wrote:
On Sun, Jul 07, 2002 at 09:18:44PM -0600, Brian Paul wrote:
Elladan wrote:
On Fri, Jul 05, 2002 at 08:15:26AM +0100, Keith Whitwell wrote:
Elladan wrote:
Yes. I'm seeing the same thing on my Radeon 7500. See screenshots
here:
Meelis Roos wrote:
$ glxinfo
name of display: localhost:10.0
Xlib: connection to :0.0 refused by server
Xlib: Client is not authorized to connect to Server
display: localhost:10 screen: 0
direct rendering: No
If the display is different from :0.0 (:1.0, remote
display,
On Mon, 2002-07-08 at 13:55, Keith Whitwell wrote:
Michel Dänzer wrote:
On Mon, 2002-07-08 at 07:31, Elladan wrote:
On Sun, Jul 07, 2002 at 09:18:44PM -0600, Brian Paul wrote:
Elladan wrote:
On Fri, Jul 05, 2002 at 08:15:26AM +0100, Keith Whitwell wrote:
Elladan wrote:
Another problem I have with tuxracer is that it's very slow. Used to be
much faster, unfortunately I don't remember if that was with the Mesa 3.4
based driver or with the pre-TCL Mesa 4.0 based one. Neither of the two
environment variables mentioned here helps. Might the output with
Graham Hay wrote:
--- Leif Delgass [EMAIL PROTECTED] wrote:
On Sun, 7 Jul 2002, Brian Paul wrote:
The notion of 'current read buffer' is more complicated than one would
first expect. There are basically two situations in which you need to
read from a color buffer:
1. glRead/CopyPixels()
Michael Schlueter wrote:
Hi,
the lastest cvs version crashes for me with a sig. fault when starting a
gl application. After taking a deeper look into it, it seems to be a
problem with the lastest changes in xc/xc/extras/Mesa/src/context.c (Tue
Jun 18 03:29:39 2002 UTC (2 weeks, 3 days ago)
On Mon, 8 Jul 2002, José Fonseca wrote:
On Mon, Jul 08, 2002 at 11:55:55AM +0200, Felix Kühling wrote:
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
On Mon, 8 Jul 2002, Brian Paul wrote:
Graham Hay wrote:
--- Leif Delgass [EMAIL PROTECTED] wrote:
On Sun, 7 Jul 2002, Brian Paul wrote:
The notion of 'current read buffer' is more complicated than one would
first expect. There are basically two situations in which you need to
read
On Mon, 8 Jul 2002, Brian Paul wrote:
Graham Hay wrote:
--- Leif Delgass [EMAIL PROTECTED] wrote:
On Sun, 7 Jul 2002, Brian Paul wrote:
The notion of 'current read buffer' is more complicated than one would
first expect. There are basically two situations in which you need to
read
Leif Delgass wrote:
On Mon, 8 Jul 2002, Brian Paul wrote:
The driver should assume the second case. swrast-Driver.SetReadBuffer()
will get called for the first case, as needed.
I missed this comment before. If we assume the second case, we'd change
the ReadBuffer (mmesa-readOffset in the
On Mon, Jul 08, 2002 at 10:52:51AM +0100, Keith Whitwell wrote:
This sounds like Z-buffer fighting. If you draw the same triangle twice
with exactly the same vertices you'd expect that the same Z values would
be generated for each fragment. But the OpenGL spec doesn't require that
to be
On Mon, 8 Jul 2002, Leif Delgass wrote:
On Mon, 8 Jul 2002, Brian Paul wrote:
The driver should assume the second case. swrast-Driver.SetReadBuffer()
will get called for the first case, as needed.
I missed this comment before. If we assume the second case, we'd change
the ReadBuffer
[...]
Yes. Keith said he successfully tested it on a 8500, maybe it depends on
the other patch.
OK, i had another look into my problem: I noticed that only
radeon_xv-2002-03-29-19.diff applies cleanly on the r200 branch. the
other patch gives me errors. So I first tried to edit the
Michael Schlueter wrote:
Hi,
the lastest cvs version crashes for me with a sig. fault when starting a
gl application. After taking a deeper look into it, it seems to be a
problem with the lastest changes in xc/xc/extras/Mesa/src/context.c (Tue
Jun 18 03:29:39 2002 UTC (2 weeks, 3 days ago)
Leif Delgass wrote:
On Mon, 8 Jul 2002, Leif Delgass wrote:
On Mon, 8 Jul 2002, Brian Paul wrote:
The driver should assume the second case. swrast-Driver.SetReadBuffer()
will get called for the first case, as needed.
I missed this comment before. If we assume the second case, we'd change
On Mon, 8 Jul 2002, Brian Paul wrote:
Leif Delgass wrote:
On Mon, 8 Jul 2002, Leif Delgass wrote:
On Mon, 8 Jul 2002, Brian Paul wrote:
The driver should assume the second case. swrast-Driver.SetReadBuffer()
will get called for the first case, as needed.
I missed this comment
On Monday 08 Jul 2002 6:31 am, Elladan scribed numinously:
On Sun, Jul 07, 2002 at 09:18:44PM -0600, Brian Paul wrote:
Elladan wrote:
On Fri, Jul 05, 2002 at 08:15:26AM +0100, Keith Whitwell wrote:
Elladan wrote:
Yes. I'm seeing the same thing on my Radeon 7500. See screenshots
here:
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 wrote:
On Mon, Jul 08, 2002 at 11:55:55AM +0200, Felix Kühling wrote:
[...]
I
I've determined what was breaking the binary snapshots DRM: there are several
files in .../linux/drm/kernel which are later symlinked from .../shared/drm/kernel.
The current script first copies the files from the 'shared', and then from
the 'linux', therefore effectively overwritting files with
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 Mon, 2002-07-08 at 21:49, José Fonseca wrote:
I've determined what was breaking the binary snapshots DRM: there are several
files in .../linux/drm/kernel which are later symlinked from .../shared/drm/kernel.
The current script first copies the files from the 'shared', and then from
the
On Monday 08 July 2002 12:58, Michel Dänzer wrote:
On Mon, 2002-07-08 at 12:14, Ian Molton wrote:
1) Can the Radeon 7500 use FSAA yet?
Haven't seen anything about that, so I assume no, but I may just have
missed it.
2) when is the GATOS code planned for merging?
Never with the DRI
Am Mon, 2002-07-08 um 19.51 schrieb Brian Paul:
OK. I checked in the fix for this problem.
The problem was that the mmesa-driDrawable field wasn't getting set
before _mesa_make_current(). One of the things _mesa_make_current()
does is to query the size of newly bound windows to initialize
Hello Keith,
I need some advice. Shouldn't this be included into the current devel DRM
stuff? I can test it on my dual Athlon MP 1900+, 1 GB RAM.
Thanks,
Dieter
-- Forwarded Message --
Subject: Re: Fwd: [Dri-devel] r200: unresolved symbol on SMP/HIGHMEM system
Date:
On Mon, Jul 08, 2002 at 11:16:55PM +0200, Michel Dänzer wrote:
On Mon, 2002-07-08 at 21:49, José Fonseca wrote:
I've determined what was breaking the binary snapshots DRM: there are several
files in .../linux/drm/kernel which are later symlinked from .../shared/drm/kernel.
The current script
On Mon, 2002-07-08 at 20:17, Tim Smith wrote:
On Monday 08 Jul 2002 12:49 am, Michel Dänzer scribed numinously:
The scratch register values need to be read with DRM_READ32(), which
accounts both for endianness and memory barriers. So it would be
u32 done_age =
--- Michel Dänzer [EMAIL PROTECTED] wrote:
On Mon, 2002-07-08 at 20:17, Tim Smith wrote:
On Monday 08 Jul 2002 12:49 am, Michel Dänzer scribed numinously:
The scratch register values need to be read with DRM_READ32(), which
accounts both for endianness and memory barriers. So it
On Mon, 2002-07-08 at 20:58, Michel Dänzer wrote:
2) when is the GATOS code planned for merging?
Never with the DRI repository directly. Apparently their Mach64 stuff is
getting merged into XFree86 for 4.3.0, don't know about the rest. It
should then get into the DRI repository when it's
On Mon, 2002-07-08 at 13:49, José Fonseca wrote:
I could fix the scripts but this wouldn't solve the real problem of
redundant files. So is it safe to delete these deprecated files:
mga.h
mga_dma.c
mga_drm.h
mga_drv.h
mga_state.c
mga_ucode.h
+ drop in frame rate. 640x480 root, depth 15, no 2d accel to test.
Used s3virge-20020708-linux.i386.tar.bz2
4MB s3virge AGP on K6/266.
VGA compatible controller: S3 Inc. ViRGE/GX2 (rev 04) (prog-if 00 [VGA])
Subsystem: Diamond Multimedia Systems Stealth 3D 4000
Cheers,
Graham
Warning
Unable to process data:
multipart/mixed;boundary==_NextPart_000_00D1_78B76A5D.C6120A44
42 matches
Mail list logo
