Ville Syrj?l? [EMAIL PROTECTED] wrote:
On Wed, Oct 15, 2003 at 03:48:38PM -0700, Alex Deucher wrote:
there's also this driver:
http://www.instmath.rwth-aachen.de:8000/linux/G450-PCI/
I'm not sure how the G4/550 and G200 differ in regard to PCI vs. AGP...
AFAIK G450 PCI cards have an
Ville Syrjälä wrote:
My previous comment on irc about anisotropic filtering needing two mip
levels was crap. Fortunately I've since managed to figure out the real
details.
The good news is that G550 doesn't have any problems with anisotropic
filtering.
The bad news is that G4x0 chips need both
Alex Deucher [EMAIL PROTECTED] wrote:
I can switch back to the old order in the mean time, however, I'm not
sure if it is any more or less reliable than the current code. both
work fine on my hardware.
I just rebuilt the stuff with a CVS checkout from one hour before now.
When I do _not_
Yeah, I've noticed that as well. If I only comment out the lines
regarding MergedFB, it still assumes I want to use MergedFB. I need to
explicity tell it not to.
Adam
On 16 Oct 2003, Martin Spott wrote:
Alex Deucher [EMAIL PROTECTED] wrote:
I can switch back to the old order in the mean
On Thu, 2003-10-16 at 03:08, Jon Smirl wrote:
Same patch again with Matrox PCI IDs fixed and a linux-2.4 port. The patches
are almost identical. Both against current bitkeeper source.
Can people in the know please check the PCI IDs for the other hardware? I'm
fairly sure Radeon, Rage128, and
On Thu, 2003-10-16 at 03:49, Roland Scheidegger wrote:
And to get this fully on-topic, is there a specific reason why the dri
driver is quite a bit slower (up to 50% in some subtests) in
SpecViewPerf compared to the cvs version of july?
I wonder if it could be related to recent 2D driver
On Thu, Oct 16, 2003 at 12:51:20PM +0200, Michel Dänzer wrote:
On Thu, 2003-10-16 at 03:49, Roland Scheidegger wrote:
And to get this fully on-topic, is there a specific reason why the dri
driver is quite a bit slower (up to 50% in some subtests) in
SpecViewPerf compared to the cvs
On Thu, 2003-10-16 at 08:36, Alex Deucher wrote:
Log message:
Clean up of the mode validation code for MergedFB.
Does it behave the same as pre-MergedFB by default now?
Also enable MergedFB autoconfig which will automatically set the virtual
desktop size and/or metamodes if you
Michel Dnzer wrote:
On Thu, 2003-10-16 at 03:49, Roland Scheidegger wrote:
And to get this fully on-topic, is there a specific reason why the dri
driver is quite a bit slower (up to 50% in some subtests) in
SpecViewPerf compared to the cvs version of july?
I wonder if it could be related to
On Thu, 2003-10-16 at 00:13, Eric Anholt wrote:
Seems like we need a set-understood-version ioctl. What I'm imagining
is an ioctl that takes in a DRM interface version and/or card-specific
DRM interface version. It can then adjust its response to other ioctls
appropriately. It would
Would he be interested in contributing his work back? or maybe
explaining how/if he got it working?
Alex
--- Martin Spott [EMAIL PROTECTED] wrote:
Ville Syrj?l? [EMAIL PROTECTED] wrote:
On Wed, Oct 15, 2003 at 03:48:38PM -0700, Alex Deucher wrote:
there's also this driver:
--- Michel D�nzer [EMAIL PROTECTED] wrote:
On Thu, 2003-10-16 at 08:36, Alex Deucher wrote:
Log message:
Clean up of the mode validation code for MergedFB.
Does it behave the same as pre-MergedFB by default now?
I haven't put back the old clone code, although the code that's there
On Thu, 2003-10-16 at 15:41, Alex Deucher wrote:
--- Michel Dnzer [EMAIL PROTECTED] wrote:
On Thu, 2003-10-16 at 08:36, Alex Deucher wrote:
Log message:
Clean up of the mode validation code for MergedFB.
Does it behave the same as pre-MergedFB by default now?
I haven't put
On Thu, Oct 16, 2003 at 06:30:53AM -0700, Alex Deucher wrote:
Would he be interested in contributing his work back? or maybe
explaining how/if he got it working?
I'll ask him - he moved to southern Germany earlier this year,
Martin.
--
Unix _IS_ user friendly - it's just selective
Alex Deucher [EMAIL PROTECTED] wrote:
Would he be interested in contributing his work back? or maybe
explaining how/if he got it working?
Sorry, currently he's forced to finish his dissertation. He says you
might have to wait at least a month until he'll be able to deal with
that,
Martin.
--
IIRC, the radeon driver still uses AGP writeback. This doesn't work
reliably on my system and I disabled it in my local tree. Some people
(including myself) have been thinking about an efficient algorithm to
detect unreliable writeback, but AFAICT nobody came up with anything yet
(at least no
Felix Kühling wrote:
IIRC, the radeon driver still uses AGP writeback. This doesn't work
reliably on my system and I disabled it in my local tree. Some people
(including myself) have been thinking about an efficient algorithm to
detect unreliable writeback, but AFAICT nobody came up with anything
--- Michel Dänzer [EMAIL PROTECTED] wrote:
On Thu, 2003-10-16 at 03:08, Jon Smirl wrote:
[...] a linux-2.4 port. The patches are almost identical.
For DRI CVS we need a single patch which works everywhere, see
drm_os_linux.h for examples how this is handled for other stuff.
The code
On Thu, Oct 16, 2003 at 09:29:36AM +0100, Keith Whitwell wrote:
Now I need to change the ddx driver to tell the 3D driver if the chipset
is a G550. But this causes some compatibility problems. The 3D driver
doesn't have a version number so the ddx doesn't know if the 3D driver can
handle
On Wed, 2003-10-15 at 18:08, Jon Smirl wrote:
Same patch again with Matrox PCI IDs fixed and a linux-2.4 port. The patches
are almost identical. Both against current bitkeeper source.
Can people in the know please check the PCI IDs for the other hardware? I'm
fairly sure Radeon, Rage128, and
no worries... I was just curious.
--- Martin Spott [EMAIL PROTECTED] wrote:
Alex Deucher [EMAIL PROTECTED] wrote:
Would he be interested in contributing his work back? or maybe
explaining how/if he got it working?
Sorry, currently he's forced to finish his dissertation. He says you
might
On Tue, Oct 14, 2003 at 09:22:33PM -0700, Jon Smirl wrote:
--- Alex Deucher [EMAIL PROTECTED] wrote:
As I recall, no. As it is now, only a single instance of Xfree86 can
use the DRI. I think it might be possible by adapting the resume code
to reinitialize state and agp on a VT switch,
On Thu, 2003-10-16 at 12:41, Jon Smirl wrote:
--- Eric Anholt [EMAIL PROTECTED] wrote:
I'm still working on cleaning the PCI ID stuff up to be portable, which
I'll commit as soon as I test (I'm trying to get a multihead setup going
to see if there are problems with that as Michel Daenzer
Before I go grepping through the tree, where would I find this code (in
the DRM, DRI, or 2D)? Also is it for r100 or r200 or both? is there a
r200_cp_dispatch_clear()?
thanks,
Alex
--- Michel Dänzer [EMAIL PROTECTED] wrote:
On Tue, 2003-10-14 at 06:44, Alex Deucher wrote:
I've uploaded
I just noticed this app today:
http://meld.sourceforge.net/index.html
Looks pretty nice.
Alex
__
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
---
This
I'm curious if Tungsten Graphics has made any attempts to get basic 3D
specs from ATI for the R300 line of cards? While is certainly great that
ATI is showing a commitment to writing their own 3D drivers for linux,
there are still other operating systems (and users who insist on open
source
On Thu, 2003-10-16 at 23:17, Roland Scheidegger wrote:
btw why exactly isn't it possible to hot-swap (when xfree86 is running)
the dri driver (r200_dri.so)? This kinda works, but kwm, kicker
kwhatever insists on crashing shortly afterwards :-(
Weird, when you do what exactly? I've never
On Thu, Oct 16, 2003 at 05:42:15PM -0400, Adam K Kirchhoff wrote:
I'm curious if Tungsten Graphics has made any attempts to get basic 3D
specs from ATI for the R300 line of cards? While is certainly great that
ATI is showing a commitment to writing their own 3D drivers for linux,
there are
Keith Whitwell wrote:
Alex Deucher wrote:
As I recall KDE preloads libGL for some reason. that might have
something to do with it.
If you make sure that the old driver.so file is removed, not
overwritten, there shouldn't be any problem, as existing open
filehandles won't then see any
On Thu, 2003-10-16 at 03:08, Jon Smirl wrote:
[...] a linux-2.4 port. The patches are almost identical.
For DRI CVS we need a single patch which works everywhere, see
drm_os_linux.h for examples how this is handled for other stuff.
What about the other points I raised?
Anyway, it seems Eric
On Thu, 2003-10-16 at 19:12, Dave Jones wrote:
On Thu, Oct 16, 2003 at 04:46:44PM -0400, John Dennis wrote:
Does anybody know for the proprietary drivers (supplied by ATI and
Nvidia) which pieces they replace and which pieces they expect to be
there? The reason I'm asking is to
On Thu, Oct 16, 2003 at 04:46:44PM -0400, John Dennis wrote:
Does anybody know for the proprietary drivers (supplied by ATI and
Nvidia) which pieces they replace and which pieces they expect to be
there? The reason I'm asking is to understand the consequences of
changing an API. I'm
For DRI to work correctly there are several independent pieces that all
have to be in sync.
* XFree86 server which loads drm modules (via xfree86 driver module)
* The drm kernel module
* The agpgart kernel module
Does anybody know for the proprietary drivers (supplied by ATI and
Nvidia) which
33 matches
Mail list logo
