On Thu, 2004-02-12 at 08:26, Michel Dänzer wrote:
> On Thu, 2004-02-12 at 03:21, Hod McWuff wrote:
> > On Wed, 2004-02-11 at 19:03, Michel Dänzer wrote:
> > > On Thu, 2004-02-12 at 00:26, Hod McWuff wrote:
> > > > On Wed, 2004-02-11 at 17:28, Michel Dänzer wrote:
> >
> > By the way, is there an index of CVS tags by date? Or should I just try
> > to pull something by a date near when the first Gatos commits were made?
>
> I usually look up this kind of stuff in something like the cvs log
> output.
I'm a bit rusty on CVS. I went lazy and started poring through the CVS
web interface. Do you refer to the ChangeLog you get automatically sent
to when doing a cvs commit?
> dev_priv->fb_location is basically the same, and it's already added to
> the relevant variables instead of everywhere they're used.
OK, that one gets knocked out, unless there are subtle differences
between dev_priv->fb_location and dev_priv->fb_offset... my testing
suggests that if there is, it's irrelevant.
> > and doing some bit masking.
>
> You mean getting the values into shape for the MC_{FB,AGP}_LOCATION
> registers? Taking the above into consideration, they're doing the same.
That one's definitely knocked out then.
> > There's also the spot in radeon_cp where it appears to write a couple of
> > new initializations to the card. You're sure those are superfluous?
>
> Might not hurt to add those, but the 2D driver needs to set them up
> correctly anyway, in particular for when it's not using the DRM.
This being the last major difference, I'm hoping it does it...
> > > > > The DRM and 3D driver in current DRI CVS should theoretically be able to
> > > > > work with their 2D driver. Its aperture setup may have to be changed
> > > > > slightly though.
> > > >
> > > > The one in 2.6.2 works with 2D (after faking the version number)
> > >
> > > Faking the version number is obviously a bad idea. The GATOS 2D driver
> >
> > The Gatos 3D driver won't even try to work unless the DRM version number
> > is 1.100.0 or better.
>
> Look, the 1.100.0 was a failed attempt to express the incompatibility,
> but it didn't prevent non-GATOS 3D drivers from locking up the machine,
> for example.
Right, but if I don't change the version number in the kernel driver,
the userspace driver won't even -try- to use it. I'm just trying to
trick the Gatos userspace into accepting the DRI DRM. It would probably
be more correct to patch the Gatos userspace to only require 1.10.0 or
better, but I hadn't gotten into that yet.
The DRI radeon 1.10.0 radeon DRM *DOES* work with the Gatos 2D driver.
It's 3D I'm wrestling with, and even that feels like it's pretty damn
close.
>
> Again, the cause for the incompatibility has been removed in the 1.10.0
> DRM, so it...
Removed from the kernel space module, so now I have to get the userspace
side of the Gatos version to cope with the official DRI kernel module,
correct?
>
> > > should work with the 1.10.0 radeon DRM with the changes described above.
> >
> > Those changes are exactly what I'm trying to isolate and port to the
> > current CVS DRM.
As noted, I've been focusing on kernel. I started a preliminary dig into
the userspace side last night. Still playing with it. It looks complex.
>
> I mean the changes I have been describing for the GATOS 2D driver.
Oh OK. If I use the 1.10.0 radeon DRM without any changes, the Gatos
userspace side fails immediately and falls back to indirect rendering
gracefully. Once I change the version number, it connects successfully
and 2D works just fine in all cases, as does video features. It might be
subjective but it even feels a little snappier on startup. It's only 3D
that has trouble.
The radeon 1.9.0 that's in 2.6.2 causes the expected lockup if I change
the version to 1.100.0. With the version unmolested, I believe it denies
the connection. I think I do remember an even older one that locked up
despite any version numbers.
> I think it makes no sense to merge stuff with the vanilla tree when
> there's more up to date code in the 2.6 maintainer's tree, but maybe
> that's just me...
I've had better luck using the vanilla kernel for testing 3rd party
kernel code. Less likely to run into a fresh bug that screws the system
up in unrelated ways.
> > As an aside though, perhaps a unified source is a good idea.
>
> That's what the DRM in DRI CVS is, unless I misunderstand you.
I mean the DRI-issued DRM should be published verbatim to both the 2.6
and 2.4 kernels. That may or may not be political fire, but it would
ensure that absolutely all bug reports regarding the DRM come back to
the same place that new development happens. As things stand, many
bugfixes (usually arch-related) seem to only be represented in the
various kernel maintainers' copies.
> PS: If you're going to keep posting to dri-devel, please subscribe...
> otherwise, I or another list admin have to manually approve your posts.
Sorry... done.
Incidentally, I recompiled xfree last night (Gentoo jumped to 4.3.0-r4)
and thus regained access to the non-Gatos userspace code. All non-Gatos
functions perform great, except for those complex GL apps (tuxracer and
tuxracer-demo) that, after a second or so, start spewing messages about
texture problems and get unusably slow. I'll reinstall the working
driver and capture you an error message later today...
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id56&alloc_id438&op=click
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
