I tried to install a Radeon 8500 on a system with an nForce-based
motherboard but I couldn't direct rendering to work because agpgart
failed to load:
Linux agpgart interface v0.99 (c) Jeff Hartmann
agpgart: Maximum main memory to use for agp memory: 816M
agpgart: unsupported bridge
agpgart: no
> btw what about now?
Much, much better. I have a few more comments though . ;)
1. For the mailing list info, there is a link to the old Geocrawler
archives. I think that should probably be removed because SF.net has their
own archives now and they also include the content from the old Geocr
> > I would also recommend that you work together with Nick Leippe.
>
> Just a quick note to say that I'm still here and happy to help.
> My modified version is up for grabs to pick and choose from still at
> http://lfm.sourceforge.net/dritest/
Sorry I managed to miss a whole bunch of posts, read
> > I think it is much too early for this kind of criticism. While the
> > updated website is far from perfect and finished, I definetely think it
> > is a clear improvement with respect to the former version.
>
> I don't see how it is too early for criticism. Liam has indicated
> several time
> > I would say that Effecting a full scale 'all in one go' transition is
> > VERY hard. I would suggest letting Liam make the poage official, and
> > continue refining the layout.
>
> I don't see how a transition in one go is very hard at all. The DRI
> website is fairly small, all you have to
cement
Driver provided WriteBitmap replacement
Driver provided NonTEGlyphRenderer replacement
(II) (null)(0): Acceleration enabled
Fatal server error:
Caught signal 11. Server aborting
**
With the 20020926 official snapshot, the last line is the "Silken mouse"
message.
Am Freitag, 27. September 2002 03:20 schrieb Andy Dustman:
> On Thu, 2002-09-26 at 19:22, José Fonseca wrote:
> > AFAIK the announced breakeage concerned C++ only.
>
> Well, there is some c++ code in libnurbs, and so apparently libGLU.so.
> However it appears that wouldn't affect the DRI snapshots
On Thu, 2002-09-26 at 19:22, José Fonseca wrote:
> AFAIK the announced breakeage concerned C++ only.
Well, there is some c++ code in libnurbs, and so apparently libGLU.so.
However it appears that wouldn't affect the DRI snapshots.
> RedHat does indeed provides a compat-gcc package. I'll see wh
On Thu, 2002-09-26 at 03:40, Charl P. Botha wrote:
> serious note, have you tried replacing your libxaa.a yet to eliminate
> the possibility of that signal 11 that we've been seeing with the last
> few snapshots? You could also try a snapshot of today or later, because
> Michel has fixed the XAA
On Wed, Sep 25, 2002 at 10:32:32PM -0400, Andy Dustman wrote:
>On Tue, 2002-09-24 at 09:25, José Fonseca wrote:
>
>> I've updated my workstation to the RedHat Linux 7.3.94 beta, which has
>> gcc 3.2. So now forward the snapshots will be built with this version.
>> AFAIK this shouldn't pose any pro
Michel Dänzer wrote:
> On Don, 2002-09-26 at 22:23, Ian Romanick wrote:
>
>>Attached is a patch to fix the
>>
>>drmRadeonCmdBuffer: -22
>>
>>problem in the SW TCL path (used on Radeon VE & M6 cards) in the Radeon
>>driver. It turns out that not every place in the code was using the right
>>pack
On Don, 2002-09-26 at 22:23, Ian Romanick wrote:
> Attached is a patch to fix the
>
> drmRadeonCmdBuffer: -22
>
> problem in the SW TCL path (used on Radeon VE & M6 cards) in the Radeon
> driver. It turns out that not every place in the code was using the right
> packet sizes. I believe that
Attached is a patch to fix the
drmRadeonCmdBuffer: -22
problem in the SW TCL path (used on Radeon VE & M6 cards) in the Radeon
driver. It turns out that not every place in the code was using the right
packet sizes. I believe that this was the only missed place. I have tested
with with a Q3 d
On Don, 2002-09-26 at 18:17, Keith Whitwell wrote:
> Michel Dänzer wrote:
> >
> > Something else I've been thinking about is that relying on the
> > swi_emitted and swi_received counters being in sync is pretty fragile.
> > It might be better to use a scratch register instead.
>
> Yes, it could
On Thu, Sep 26, 2002 at 05:38:03PM +0200, Michel Dänzer wrote:
> That does get rid of the slowness, thanks. This begs the question: does
> it use multitexturing for anything except lightmaps? :) It does seem to
> look nicer...
I don't want to be a pedant, but often I can't resist. "Begging the
q
Michel Dänzer wrote:
> On Don, 2002-09-26 at 10:24, Eric Anholt wrote:
>
>>On Thu, 2002-09-26 at 00:58, Eric Anholt wrote:
>>
>>>CVSROOT: /cvsroot/dri
>>>Module name: xc
>>>Repository: xc/xc/lib/GL/mesa/src/drv/r200/
>>>Changes by: anholt@usw-pr-cvs1. 02/09/26 00:58:14
>>>
>>>Log messag
On Don, 2002-09-26 at 10:24, Eric Anholt wrote:
> On Thu, 2002-09-26 at 00:58, Eric Anholt wrote:
> > CVSROOT:/cvsroot/dri
> > Module name:xc
> > Repository: xc/xc/lib/GL/mesa/src/drv/r200/
> > Changes by: anholt@usw-pr-cvs1. 02/09/26 00:58:14
> >
> > Log message:
> > R200 sync-
On Don, 2002-09-26 at 17:30, Bobakitoo wrote:
> > > I've been wondering for some time why at least the Quake 2 engine is
> > > very slow with multitexturing enabled, i.e. with
> > >
> > > set gl_ext_multitexture "1"
> > >
> > > in ~/.quake2/baseq2/config.cfg, it crawls on stuff like explosions.
> > I've been wondering for some time why at least the Quake 2 engine is
> > very slow with multitexturing enabled, i.e. with
> >
> > set gl_ext_multitexture "1"
> >
> > in ~/.quake2/baseq2/config.cfg, it crawls on stuff like explosions.
> > Change that to 0 and it's snappy.
> >
> > Do people s
On Thu, Sep 26, 2002 at 11:04:36AM -0400, Bobakitoo wrote:
> > > I've been wondering for some time why at least the Quake 2 engine is
> > > very slow with multitexturing enabled, i.e. with
> > >
> > > set gl_ext_multitexture "1"
> > >
> > > in ~/.quake2/baseq2/config.cfg, it crawls on stuff like
Ian Romanick wrote:
> On Thu, Sep 26, 2002 at 03:00:02AM +0200, Michel Dänzer wrote:
>
>
>>I've been wondering for some time why at least the Quake 2 engine is
>>very slow with multitexturing enabled, i.e. with
>>
>>set gl_ext_multitexture "1"
>>
>>in ~/.quake2/baseq2/config.cfg, it crawls on st
On Thu, Sep 26, 2002 at 03:00:02AM +0200, Michel Dänzer wrote:
> I've been wondering for some time why at least the Quake 2 engine is
> very slow with multitexturing enabled, i.e. with
>
> set gl_ext_multitexture "1"
>
> in ~/.quake2/baseq2/config.cfg, it crawls on stuff like explosions.
> Chan
On Don, 2002-09-26 at 02:22, Dieter Nützel wrote:
>
> Any glue about the stuttering with UT?
usleeps? Again, IRQs are currently disabled in the r200 driver...
--
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member / CS student, Free Soft
Eric Anholt wrote:
> On Thu, 2002-09-26 at 00:58, Eric Anholt wrote:
>
>>CVSROOT: /cvsroot/dri
>>Module name: xc
>>Repository: xc/xc/lib/GL/mesa/src/drv/r200/
>>Changes by: anholt@usw-pr-cvs1. 02/09/26 00:58:14
>>
>>Log message:
>> R200 sync-to-vblank support (set LIBGL_THROTTLE_RE
On Thu, 2002-09-26 at 00:58, Eric Anholt wrote:
> CVSROOT: /cvsroot/dri
> Module name: xc
> Repository: xc/xc/lib/GL/mesa/src/drv/r200/
> Changes by: anholt@usw-pr-cvs1. 02/09/26 00:58:14
>
> Log message:
> R200 sync-to-vblank support (set LIBGL_THROTTLE_REFRESH=1)
Okay, that con
On Thu, 2002-09-26 at 04:32, Andy Dustman wrote:
> On Tue, 2002-09-24 at 09:25, José Fonseca wrote:
> > I've updated my workstation to the RedHat Linux 7.3.94 beta, which has
> > gcc 3.2. So now forward the snapshots will be built with this version.
>
> If the kernel modules were the only issue,
26 matches
Mail list logo
