Slightly OT, but here's an article comparing XiG Summit, dri cvs and the
ATI driver on a radeon 9000pro.
http://homepage.hispeed.ch/rscheidegger/atilinux_oct03/ati_linux_comp_oct03.html
And to get this fully on-topic, is there a specific reason why the dri
driver is quite a bit slower (up to 50%
On Wed, 2003-10-15 at 16:15, Felix Kühling wrote:
> On Wed, 15 Oct 2003 21:53:17 +0200
> Michel Dänzer <[EMAIL PROTECTED]> wrote:
>
> > On Wed, 2003-10-15 at 18:50, Felix Kühling wrote:
> > >
> > > Oops, xmlconfig.o gets linked into all drivers, even those that don't
> > > use it. BTW, the same i
On Wed, 15 Oct 2003 21:53:17 +0200
Michel Dänzer <[EMAIL PROTECTED]> wrote:
> On Wed, 2003-10-15 at 18:50, Felix Kühling wrote:
> >
> > Oops, xmlconfig.o gets linked into all drivers, even those that don't
> > use it. BTW, the same is true for all object files in
> > xc/lib/GL/mesa/src/drv/common
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 AGP-PCI bridge on the card which could do
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...
Alex
--- Ville_Syrjälä <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 15, 2003 at 02:40:07PM -0700, Jon Smirl wrote:
> > Has any one checked the PC
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 texture units to pull i
On Thu, 2003-10-16 at 00:11, Felix Kühling wrote:
> This should make life easier for developers. You'll get annoying
> warnings though. For my conscience: it is still a lot better than the
> old scheme as the values from the environment are properly checked and
> converted before use. :)
Yes, I th
On Wed, Oct 15, 2003 at 02:40:07PM -0700, Jon Smirl wrote:
> Has any one checked the PC IDs in each driver? For example I'm not sure that
> all of the cards I added to the MGA driver are 3D capable.
The driver only supports G200/G400/G550. Remove the rest.
I'm not sure about the G200 PCI entry. T
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter your comments there.
http://bugs.xfree86.org/show_bug.cgi?id=314
--- Additional Comments From [EMAIL PROTECTED] 2003-15-10 18:17 ---
I just wanted to add m
On Wed, 2003-10-15 at 14:57, Jon Smirl wrote:
> --- Eric Anholt <[EMAIL PROTECTED]> wrote:
> > If the Linux drivers go to probing PCI IDs, could it also start creating
> > /dev/dri/cardXs which are associated with a specific piece of hardware?
> > The get/set unique thing is a problem, though. It
This should make life easier for developers. You'll get annoying
warnings though. For my conscience: it is still a lot better than the
old scheme as the values from the environment are properly checked and
converted before use. :)
Regards,
Felix
On Wed, 15 Oct 2003 15:02:58 -0700
Felix Kuehling
--- Eric Anholt <[EMAIL PROTECTED]> wrote:
> If the Linux drivers go to probing PCI IDs, could it also start creating
> /dev/dri/cardXs which are associated with a specific piece of hardware?
> The get/set unique thing is a problem, though. It seems to me that we
> ought to have /dev/dri/cardX st
On Wed, 2003-10-15 at 12:01, Jon Smirl wrote:
> --- Alexander Stohr <[EMAIL PROTECTED]> wrote:
> > One thing to ask you: there is always those secondary PCI ID
> > on the current Radeon designs. Do you see some chance to get
> > rid of irritating logfile messages that concern those 2nd ID.
> >
> T
Has any one checked the PC IDs in each driver? For example I'm not sure that
all of the cards I added to the MGA driver are 3D capable. I went through the
Xfree source trying to figure out an accurate list but sometime it wasn't
obvious.
=
Jon Smirl
[EMAIL PROTECTED]
--- Michel D�nzer <[EMAIL PROTECTED]> wrote:
> On Wed, 2003-10-15 at 22:58, Alex Deucher wrote:
> > --- Michel Dnzer <[EMAIL PROTECTED]> wrote:
> > > On Wed, 2003-10-15 at 22:12, Alex Deucher wrote:
> > > > perhaps for the time being I can set mergedfb to default to
> "false"
> > >
> > > That's
On Wed, 2003-10-15 at 14:40, Jon Smirl wrote:
> Has any one checked the PC IDs in each driver? For example I'm not sure that
> all of the cards I added to the MGA driver are 3D capable. I went through the
> Xfree source trying to figure out an accurate list but sometime it wasn't
> obvious.
I've g
--- Michel Dänzer <[EMAIL PROTECTED]> wrote:
> On Wed, 2003-10-15 at 22:58, Linus Torvalds wrote:
> > On Wed, 15 Oct 2003, Michel Dänzer wrote:
> > > On Wed, 2003-10-15 at 21:01, Jon Smirl wrote:
> > >
> > > > This new scheme allows the entire PCI probing stage of xfree to be
> eliminated.
> > >
On Wed, 2003-10-15 at 22:58, Alex Deucher wrote:
> --- Michel Dnzer <[EMAIL PROTECTED]> wrote:
> > On Wed, 2003-10-15 at 22:12, Alex Deucher wrote:
> > > perhaps for the time being I can set mergedfb to default to "false"
> >
> > That's probably a good idea, but then it should default to clone mod
On Wed, 2003-10-15 at 22:58, Linus Torvalds wrote:
> On Wed, 15 Oct 2003, Michel Dänzer wrote:
> > On Wed, 2003-10-15 at 21:01, Jon Smirl wrote:
> >
> > > This new scheme allows the entire PCI probing stage of xfree to be eliminated.
> >
> > I'll believe it when the relevant XFree86 developers ag
[ Following up to myself ]
On Wed, 15 Oct 2003, Linus Torvalds wrote:
>
> Yes, XF86 may need to have some legacy module for backwards compatibility.
> But thinking that X should try to probe on its own is just silly.
This is also relevant to 2D, since more and more graphics cards really
shou
--- Michel D�nzer <[EMAIL PROTECTED]> wrote:
> On Wed, 2003-10-15 at 22:12, Alex Deucher wrote:
> > perhaps for the time being I can set mergedfb to default to "false"
>
> That's probably a good idea, but then it should default to clone mode
> as
> pre-MergedFB. Driving both heads with a single
On Wed, 15 Oct 2003, Michel Dänzer wrote:
> On Wed, 2003-10-15 at 21:01, Jon Smirl wrote:
>
> > This new scheme allows the entire PCI probing stage of xfree to be eliminated.
>
> I'll believe it when the relevant XFree86 developers agree with you. :)
If they don't, they are clueless.
There's n
On Wed, 2003-10-15 at 22:12, Alex Deucher wrote:
> perhaps for the time being I can set mergedfb to default to "false"
That's probably a good idea, but then it should default to clone mode as
pre-MergedFB. Driving both heads with a single CRTC is nasty.
--
Earthling Michel Dänzer \ Debian (p
On Wed, 2003-10-15 at 21:01, Jon Smirl wrote:
>
> Now assuming no xconfig file...
> xfree loads, opens the first DRM device, and gets SUGGESTED_UNIQUE.
> That will tell Xfree what video hardware to use.
> Modes are all determined by the EDID/hardware exchange.
> This should be enough to get xfree
Alan, that's the CLE266/via driver, right? the savage driver is still
barely touched as far as I know. there was some talk of shelving the
old savage_1-0-0 branch and starting a new one on savage_1-0-1 since
the old one needed so many changes to get synced up to the trunk.
Alex
--- Alan Cox <[E
On Mer, 2003-10-15 at 21:07, Alex Deucher wrote:
> the 3D drvier needs to be updated to mesa 5.x. Not much work has been
> done on it and I think there are some issues with the 2D driver.
> There's no way it will make it into 4.4.0. the current code is on a
> branch in DRI cvs. If you are inter
On Wed, 2003-10-15 at 19:12, Jon Smirl wrote:
> The attached patch adds a new DRM IOCTL: DRM_IOCTL_GET_SUGGESTED_UNIQUE. It
> works by hooking into the OS PCI device detection at module load time. Each DRM
> driver now contains the PCI IDs of all the cards that it supports. The OS then
> matches th
perhaps for the time being I can set mergedfb to default to "false"
rather than the "true" clone mode it does now.
that should prevent the mergedfb code paths from being taken and those
that want to try it can simply turn it on.
I don't think anyone has had a problem with it turned off. speak up i
the 3D drvier needs to be updated to mesa 5.x. Not much work has been
done on it and I think there are some issues with the 2D driver.
There's no way it will make it into 4.4.0. the current code is on a
branch in DRI cvs. If you are interested in helping, please do.
Alex
--- Tim Roberts <[EMA
On Wed, 2003-10-15 at 18:50, Felix Kühling wrote:
>
> Oops, xmlconfig.o gets linked into all drivers, even those that don't
> use it. BTW, the same is true for all object files in
> xc/lib/GL/mesa/src/drv/common. How should files in the common directory
> be handled that are not used by all driver
--- Alexander Stohr <[EMAIL PROTECTED]> wrote:
> One thing to ask you: there is always those secondary PCI ID
> on the current Radeon designs. Do you see some chance to get
> rid of irritating logfile messages that concern those 2nd ID.
>
The new code allows a different way of initializing XFree.
John,
i gave your code a short review and found nothing worth a note.
In other words, if there is a problem at all
then i've overlooked that due to the speed i browsed it.
One thing to ask you: there is always those secondary PCI ID
on the current Radeon designs. Do you see some chance to get
ri
Alex Deucher wrote:
That's fine with me. we can revert back to xfree86 CVS for the trunk
and I can move to a branch. I wouldn't have put it on the trunk if I
had know the mode stuff was cause so much trouble, but then again, it's
been working fine for me and those who initially tested it, so I ne
Sounds good. I may play around with it when I get a chance. Any other
thoughts on what it might be if not clears?
Alex
--- Michel D�nzer <[EMAIL PROTECTED]> wrote:
> On Tue, 2003-10-14 at 06:44, Alex Deucher wrote:
> > I've uploaded some screenshots as an example:
> > http://www.botchco.com/
That's fine with me. we can revert back to xfree86 CVS for the trunk
and I can move to a branch. I wouldn't have put it on the trunk if I
had know the mode stuff was cause so much trouble, but then again, it's
been working fine for me and those who initially tested it, so I need
to more testers t
It's still emulating the old clone mode. it just uses the mergefb
clone mode rather than the old clone mode since there were just about
the same code-wise. Clone mode was on by default in the old radeon
driver, so the mergedfb equivalent is on by default in mergedfb. the
reason for the default t
On Wed, 15 Oct 2003, Jon Smirl wrote:
>
> If you are familar with the hardware please check that I got the PCI ID lists
> right.
Please fix the fact that modern PCI is _not_ enumerated with just "bus,
slot, function". A lot of machines are starting to have a "domain number",
which allows fro mu
I'll take a look at it if I get some free time this week.
Alex
--- Adam K Kirchhoff <[EMAIL PROTECTED]> wrote:
>
> Hey guys,
>
> That did it. I moved libint10.a out of the way on my linux
> installation, and now X is failing to start just as it did under
> FreeBSD
> (while validating mod
On Wed, 15 Oct 2003 14:39:41 +0200
Ronald Baljeu <[EMAIL PROTECTED]> wrote:
> Hi,
>
> The current DRI drivers for i810 fail to work (both cvs source, and
> snapshot). It looks like another expat problem.
>
> This is what I get when running glxinfo:
>
> # export LIBGL_DEBUG=verbose
> # glxinfo
>
On Wed, 2003-10-15 at 23:00, Michel D01nzer wrote:
> So the r128 driver in current CVS still seems to be broken.
Yeah, I think so. And I hope our dear developers can manage to locate
and fix this bug.
--
Luo Chong <[EMAIL PROTECTED]>
---
On Wed, 2003-10-15 at 16:48, happyluo79 wrote:
> Sorry about the non-wrapping lines.
> I removed xlibmesa-dri and xlibmesa-gl, and then installed
> xlibmesa-gl1-dri-trunk from
> deb http://people.debian.org/~daenzer/dri-trunk-sid/./
> but the problem persists.
So the r128 driver in cur
On Wed, 2003-10-15 at 16:56, Jon Smirl wrote:
> --- "Charl P. Botha" <[EMAIL PROTECTED]> wrote:
> > My first attempt at resume for the radeon resulted in the reinit hack
> > (which Michel has since turned into a fantastic piece of work). This
> > releases all resources at VT switch away and re-i
--- "Charl P. Botha" <[EMAIL PROTECTED]> wrote:
> My first attempt at resume for the radeon resulted in the reinit hack
> (which Michel has since turned into a fantastic piece of work). This
> releases all resources at VT switch away and re-initialises them at VT
> switch-to. With the reinit p
On Tue, 2003-10-14 at 06:44, Alex Deucher wrote:
> I've uploaded some screenshots as an example:
> http://www.botchco.com/alex/2048-error/
>
> the new version of xscreensaver displays a separate instance on each
> head of a xinerama desktop. so in this case only the context running up
> again the
Michel Dänzer wrote:
On Tue, 2003-10-14 at 21:58, Alex Deucher wrote:
The reason mergedfb is enabled by default is to emulate the clone
behavior in the old driver. perhaps this should be changed in the
future?
In the mean time, I may switch back to validating the modes on crtc2
before crtc1. th
On Tue, 2003-10-14 at 21:58, Alex Deucher wrote:
>
> The reason mergedfb is enabled by default is to emulate the clone
> behavior in the old driver. perhaps this should be changed in the
> future?
>
> In the mean time, I may switch back to validating the modes on crtc2
> before crtc1. that was
On Wed, 2003-10-15 at 13:03, happyluo79 wrote:
> Recently I upgraded xfree86 from 4.2.1 to 4.3.0-0pre1v3 (I use debian
> sid). I found that tecplot (I use tecplot 9.2, which takes advantage
> of OpenGL to accelerate 3D rendering.) can no longer render 3D graphics
> properly. For example, choosin
Recently I upgraded xfree86 from 4.2.1 to 4.3.0-0pre1v3 (I use debian sid). I found
that tecplot (I use tecplot 9.2, which takes advantage of OpenGL to accelerate 3D
rendering.) can no longer render 3D graphics properly. For example, choosing "contour"
in 3D graphics has no effect at all. This d
Hey guys,
That did it. I moved libint10.a out of the way on my linux
installation, and now X is failing to start just as it did under FreeBSD
(while validating modes on the second head).
So, in theory, you should be able to reproduce the problem really
easily, Alex, by moving th
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, however, I may be wrong.
Am I right in thinking t
50 matches
Mail list logo