On Fri, Sep 03, 2004 at 01:11:54AM -0400, Michel D=E4nzer wrote:
> > Well... however they are working, they're grown-up enough to deal w=
> > evolution of our codebase one way or another. Unless they actually =
> > comment I don't think we need to try and guess what might or might n=
> > convenient for them.
> I'd agree on that.
> As some of you know already, I have a fulltime job at ATI's Linux team
> now. I'll continue being active in the DRI and X communities as time
Congrats, hope you'll do some good things there.
> If you have any development related questions or suggestions
> about the proprietary ATI drivers, please don't hesitate to contact my
> manager Matthew Tippett <mtippett@...> and CC me at mdanzer@...=
I'd really like to see the day arrive when third party vendors don't
have to ship their own agpgart implementations at all.
I've heard three possible reasons in the past explaining the reasoning
behind why vendors feel the need to ship their own :-
1. 'We want to support every kernel out there, and old kernels
dont have an up to date agpgart driver'.
This is totally bogus IMO, as end users should be *encouraged* to be
running something recent anyway.
Take for example ATi's current driver. It has binary modules for the
following Red Hat kernels..
All of these kernels have known security problems, which were subsequentl=
fixed in later errata kernels. (The final for Red Hat 7 & 8 was
2.4.20-24.7/8 I believe. Encouraging use of 2.4.18 is a *bad* idea.
These users really need to be upgrading.
Likewise, RHL9's final errata kernel was at 2.4.20-30.9 (The Fedora-legac=
project has also since released a 2.4.20-35.9 I believe).
Encouraging the use of ancient kernels with known problems isn't going
to do the name of Linux as a secure operating system any favours.
2. 'The in-kernel AGPGART doesn't have all the features our driver requir=
Newsflash: I take patches.
Sifting through the ATI mashed-up agpgart is quite painful, as there are
so many changes in there ifdef'd to hell and back that its hard to see
whats really needed and what isn't. So, lets talk. Tell me what you need
from the kernel GART driver. If it makes sense, I'll merge patches in a
3. "Our binary part has workarounds for various chipset/card combinations
that we'd rather weren't public"
Great, so having users who use the in-kernel gart scratch their heads
when cards lock-up for no reason, and then think 'ati sucks, I'm only
buying nvidia from now on' is better than being open and explaining
incompatibilities ? We all know hardware isn't perfect.
Lets work around it, and move on, rather than hide these secrets away.
From what I gather the bulk of these workarounds are of the form
'fast writes dont work in this mode' etc, which really is trivial stuff
given the negligable benchmarking difference these seem to make anyway.
Of the three binary vendor drivers I've looked at (Matrox Parhelia, NVIDI=
the only ones who seem to actually document workarounds and such is Matro=
There are some clues in the ATI driver too (amusingly, including Matrox w=
but I'd really like to see these written cleanly, without ifdefs, and
with an explanation as to what the hell is going on, so we know why
we're poking random bits of config space for 'compatability reasons'.
Finally, pushing all these little bits back upstream is going to make
*your* lives easier too. You'll no longer have to worry about this huge
chunk of code, and making it work everywhere. You'll gain further indepen=
against what kernel your driver is running against. Your users won't
have to worry about whether agpgart is built-in or modular.
(This is a real pain for Fedora/RHEL users, as we make it built-in
so that things like the amd64 IOMMU, and framebuffers that use agp
mappings work correctly).
What do I get out of this ? A smaller inbox from users mailing me
that 'I used the ati driver, and agpgart blew up, its your fault'.
Or at least, if I do continue to get those mails and agpgart blows up,
it's more likely it *will* be my fault.