Warning
Unable to process data:
multipart/mixed;boundary="=_NextPart_000_00D1_78B76A5D.C6120A44"
left
over - think IBM logo with interspersed black lines, repeated, etc..
Like reusing older uncleared memory. But it does show the xor'd lines +
no erase.
btw, glxgears shows 55 FPS with DRI, 40 FPS without. Occasional black flash
/stutter + drop in frame rate. 640x480 root, depth 15, no 2d ac
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
>
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
--- 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 barrier
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 = DR
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 curren
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
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 initi
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 th
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
> t
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 2
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 p
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 w
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 think this is in the clear ioctl. I
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 scre
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.
> >>
On Monday 08 Jul 2002 12:49 am, Michel Dänzer scribed numinously:"
> On Tue, 2002-07-02 at 00:32, Tim Smith wrote:
> > Here it is. It'll need cleaning up if it works, but it'll do as a test.
>
> Took me quite some fiddling to get it working here, but that's mostly
> due to the non-standard and not
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
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 think this is in the clear ioctl. I already ran into this and fixed it
> in my local tree. It
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
[...]
>
> 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
> 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
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 Read
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
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->readOff
> I just set up a 2nd PC and ssh'd into mine and ran Tribes 2.
> My original post said that the lockups occur within 5 seconds of 3D
> rendering starting. That's not quite correct.
> The lockups occur only after I move the mouse (which moves
> the 3D scene
> around). But anyway ...
> /var/log/X
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
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
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 (trie
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
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
>
>
>>>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
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:
> >>>
> 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, r
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:
>
>
>>Yes. I'm seeing the sam
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 screen
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.
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.
> >
> >
>
> 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-
>
> 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. Mi
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
get
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 fou
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?
> >
> >
> > http:
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 defau
Hi.
Im just writing to ask a couple quick questions...
1) Can the Radeon 7500 use FSAA yet?
2) when is the GATOS code planned for merging?
---
This sf.net email is sponsored by:ThinkGeek
Oh, it's good to be a geek.
http://thinkgeek.com/sf
__
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
>>>
>>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 true, depending on particular state changes between passes.
On Mon, Jul 08, 2002 at 01:35:11AM -0400, Leif Delgass wrote:
>On Mon, 8 Jul 2002, Leif Delgass wrote:
[...]
>
>I should clarify: the texture mem available is currently determined by the
>max resolution configured and the AGP size (if it's an AGP card, of
>course), but you'll get better framerates
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
Warning
Unable to process data:
multipart/mixed;boundary="=_NextPart_000_00E0_33D22B1E.C2213E80"
--- 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(
52 matches
Mail list logo
