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
On Fri, 2002-09-27 at 04:25, Andy Dustman wrote:
Still getting the same problem with the r200. Interestingly, the amount
of memory used for textures has gone up recently, from about 93 MB to
113 MB. Most obvious feature of this is what looks like a NULL pointer
reference at the end. Also
Title: RE: [Dri-devel] nForce and AGPGART
Can you please send the outputs of
`lspci -v -xxx` to the list?
-Original Message-
From: Rene Sepulveda [mailto:[EMAIL PROTECTED]]
Sent: Friday, September 27, 2002 08:27
To: [EMAIL PROTECTED]
Subject: [Dri-devel] nForce and AGPGART
Am Freitag, 27. September 2002 08:26 schrieb Rene Sepulveda:
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
Am Freitag, 27. September 2002 06:19 schrieb Frank Worsley:
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
Michel Dänzer wrote:
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
Hi,
The r200 dri drivers are working fine on my system but I noticed
something strange in my logs:
(**) RADEON(0): Using AGP 4x mode
(II) RADEON(0): AGP Fast Write disabled by default
My bios says that AGP Fast Write is enabled.
Is there an issue with AGP Fast Write and the r200?
I couldn't
Stephane Chauveau wrote:
Hi,
The r200 dri drivers are working fine on my system but I noticed
something strange in my logs:
(**) RADEON(0): Using AGP 4x mode
(II) RADEON(0): AGP Fast Write disabled by default
My bios says that AGP Fast Write is enabled.
Is there an issue with AGP
On Fre, 2002-09-27 at 16:47, Keith Whitwell wrote:
Michel Dänzer wrote:
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
It's a big hack to be doing this. I'd really like to know why this happens,
So would I. I suspect it's a workaround for some problem, it worked fine
here without. (as I said on IRC yesterday: but then I have sane hardware
:)
but in the mean time I'm ok to see it go in.
Okay,
Alexander Stohr wrote:
Can you please send the outputs of
`lspci -v -xxx` to the list?
Sure.
00:00.0 Host bridge: nVidia Corporation nForce CPU bridge (rev b2)
Flags: bus master, 66Mhz, fast devsel, latency 0
Memory at e000 (32-bit, prefetchable) [size=256M]
Capabilities:
On Thu, Sep 26, 2002 at 04:51:37PM +0100, Keith Whitwell wrote:
Ian Romanick wrote:
On Thu, Sep 26, 2002 at 07:20:58AM +0100, Keith Whitwell wrote:
I guess my problem is, should values other than [GL_TEXTURE0, GL_TEXTURE0 +
MAX_TEXTURE_UNITS] ever get this far in the pipeline?
This
On Fri, 2002-09-27 at 17:01, Michel Dänzer wrote:
Yep, but I guess you have to worry about then going to sleep *after* the
interrupt has arrived, if there is a delay in getting the scratch write across
the bus, compared to the irq, which should be instantaneous.
Is that really an
On Fri, 2002-09-27 at 13:51, Dieter Nützel wrote:
Is it true that the nForce is unsupported by agpgart
Yes.
News to me that it is
Have a close look at LKML and watch out for some posts from Alan Cox about
nForce. I think I remember he had something going.
We have IDE (in the newest tree)
Right. Here's my updated suggestion. Leave the '3' in the patch, but
expand the 'vertex' array in radeon_vb from 15 elements to 17. That will
prevent code like
glMultiTexCoord2fv( GL_TEXTURE3, foo );
Yes, that works for this path. The other you have to look at is where the
Charlie == Charlie Grosvenor [EMAIL PROTECTED] writes:
Charlie I am thinking of purchasing a Maya AP Radeon 8500 Deluxe 64MB DDR AGP RP
Charlie VO DVI, what do people think of this card? What is the status of the
Charlie open source drivers? How good are they? Is the dual head
Ian Romanick wrote:
A lot of this stuff is inherently device independent with some device
dependent direction (i.e., *ChooseTextureFormat), but it hasn't been
implemented that way. As a reference point, my previous work removed
somewhere around 450 lines of code from the MGA driver (~5%). The
On Fri, Sep 27, 2002 at 07:53:22PM +0100, Keith Whitwell wrote:
from overwriting normalptr and floatcolorptr. :) In actuality, should this
be expanded anyway? How was the value 15 arrived at?
Yes, you need a bigger maximum for the extra texture coord.
Okay. It should be changed to 19,
On 27 Sep 2002 18:46:20 +0200
Michel Dänzer [EMAIL PROTECTED] wrote:
(BTW it would have been a pain in the neck for him to debug this without
reinit)
I agree !
OK, I see it now.
It's a big hack to be doing this. I'd really like to know why this happens,
So would I. I suspect
On Thu, Sep 26, 2002 at 03:00:02AM +0200, Michel Dnzer wrote:
I've been wondering for some time why at least the Quake 2 engine is
very slow with multitexturing enabled, i.e. with
I am using mutlitexturing in my own application, tested on my Voodoo3 but also
on Radeon VE, Riva Vanta, or GF. No
On Fre, 2002-09-27 at 18:51, Keith Whitwell wrote:
It's a big hack to be doing this.
BTW it also seems to work for him without writing to GEN_INT_CNTL all
the time, i.e. only acknowledging the bits in GEN_INT_STATUS. Would that
make it slightly less hackish? :)
I'd really like to know
On Fre, 2002-09-27 at 22:42, Keith Whitwell wrote:
Michel Dänzer wrote:
On Fre, 2002-09-27 at 18:51, Keith Whitwell wrote:
It's a big hack to be doing this.
BTW it also seems to work for him without writing to GEN_INT_CNTL all
the time, i.e. only acknowledging the bits in
This adds support for 16K and 64K system page sizes.
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
#
This cleans up the GART/DRM interface (in a backwards-compatible
way) and gets rid of the bogus assumption that GATT_entry ~0xfff
is a physical address.
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU
Every snapshot since 9/20/2002 seems to have the same problem. I know
it was supposed to have been resolved the 25th, but perhaps it's not
an easy fix.
There is a warning message about xaa versions but no errors in the x
log. X then segfaults after silken mouse is enabled. Again with no
details
25 matches
Mail list logo
