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 w
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 changes
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 cu
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
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
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 changes.
I'm not sure if the XFr
As I recall KDE preloads libGL for some reason. that might have
something to do with it.
Alex
--- Michel Dänzer <[EMAIL PROTECTED]> wrote:
> 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 driv
On Thu, Oct 16, 2003 at 01:42:41PM -0700, Alex Deucher wrote:
> I just noticed this app today:
>
> http://meld.sourceforge.net/index.html
>
> Looks pretty nice.
Another merge tool I've been using for long time (and that I mention her
for completeness)is http://xxdiff.sf.net/ . It's not so visua
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
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 drive
Keith Whitwell 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? Could this be
related to the changes with GLX_NV_vertex_array_range,
GLX_MESA_agp_offset, G
On Wed, 15 Oct 2003 16:26:33 -0700
Eric Anholt <[EMAIL PROTECTED]> wrote:
> 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, xmlc
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 SF.net
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
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 uploade
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 Da
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 swi
--- 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 brought up).
> Notably, I'm not using pci_ids.h
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
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,
On Thu, 2003-10-16 at 19:00, Keith Whitwell wrote:
> 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
> > d
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
> > h
--- 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 c
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 y
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 imple
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.
-
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 ab
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?
>
--- 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 th
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:
> >>
>
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
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 version of july?
I wonder if it could be related to r
Roland Scheidegger wrote:
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 qu
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
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
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 drive
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,
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
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_
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 text
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
41 matches
Mail list logo
