On Fri, Sep 03, 2004 at 01:11:54AM -0400, Michel Dänzer wrote:
Hi Michel,
> > Well... however they are working, they're grown-up enough to deal with the
> > evolution of our codebase one way or another. Unless they actually make some
> > comment I don't think we need to try and guess what might or might not be
> > 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
> permits.
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 <[EMAIL PROTECTED]> and CC me at [EMAIL PROTECTED]
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..
2.4.18-17.7
2.4.18-17.8
2.4.20-8
2.4.20-8bigmem
2.4.20-8smp
2.4.20-28.8
2.4.20-28-8.bigmem
2.4.20-28.8-smp
2.4.20-28.9
2.4.20-28.9-bigmem
2.4.20-28.9smp
All of these kernels have known security problems, which were subsequently
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-legacy
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 requires'.
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
heartbeat.
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, NVIDIA, ATI)
the only ones who seem to actually document workarounds and such is Matrox.
There are some clues in the ATI driver too (amusingly, including Matrox workarounds)
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 independance
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.
Dave
-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idP47&alloc_id808&op=click
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
