From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Dave Jones <davej@redhat.com>
Cc: Ian Romanick <idr@us.ibm.com>, Jon Smirl <jonsmirl@yahoo.com>,
lkml <linux-kernel@vger.kernel.org>,
Dave Airlie <airlied@linux.ie>,
"DRI developer's list" <dri-devel@lists.sourceforge.net>
Subject: Re: DRM code reorganization
Date: Mon, 02 Aug 2004 19:16:59 +0100 [thread overview]
Message-ID: <1091470615.857.3.camel@localhost.localdomain> (raw)
In-Reply-To: <20040802185746.GA12724@redhat.com>
On Llu, 2004-08-02 at 19:57, Dave Jones wrote:
> > The problem is that each driver has different needs based on hardware
> > functionality.
>
> How does this differ from any other subsystem that supports
> cards with features that may not be present in another model ?
> Other subsystems have dealt with this problem without the need
> to introduce horrors like the abstractions in DRM.
The abstractions are one big mistake IMHO. But in context their origin
is easy to understand. The original goal was to support a lot of
platforms and to minimise code writing. The Mesa layer uses this kind of
templating a lot and for the 3D client side code its a real win.
Someone I think took them a stage too far and into a place that it
didn't work out.
The memory manager is a bit more complex, a lot of drivers do have
different needs for memory management and some of it has to be client
side. Its also a really really hot path when doing direct render.
> > AFAIK, the only drivers that have any sort of in-kernel memory manager
> > are the radeon (only used by the R200 driver) and i830.
>
> ISTR SiS has some memory management code too, though I've not looked
> too closely at that for a long time.
SiS and VIA do as well. Both of them overdo the kernel side work and it
hurts performance however.
Alan
next prev parent reply other threads:[~2004-08-02 19:19 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-02 15:53 DRM code reorganization Jon Smirl
2004-08-02 18:02 ` Ian Romanick
2004-08-02 18:27 ` Keith Whitwell
2004-08-02 18:57 ` Dave Jones
2004-08-02 18:16 ` Alan Cox [this message]
2004-08-02 20:11 ` Ian Romanick
2004-08-02 20:42 ` Jon Smirl
2004-08-02 21:09 ` Dave Jones
2004-08-02 21:51 ` Michel Dänzer
2004-08-02 23:09 ` Jon Smirl
2004-08-02 23:24 ` Alan Cox
2004-08-02 20:45 ` Dave Jones
2004-08-02 23:53 ` Ian Romanick
2004-08-03 7:52 ` Keith Whitwell
2004-08-03 16:28 ` Ian Romanick
2004-08-03 16:49 ` Keith Whitwell
2004-08-03 0:06 ` Dave Airlie
2004-08-03 6:13 ` Eric Anholt
2004-08-02 23:48 ` Dave Airlie
2004-08-02 23:26 ` Alan Cox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1091470615.857.3.camel@localhost.localdomain \
--to=alan@lxorguk.ukuu.org.uk \
--cc=airlied@linux.ie \
--cc=davej@redhat.com \
--cc=dri-devel@lists.sourceforge.net \
--cc=idr@us.ibm.com \
--cc=jonsmirl@yahoo.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.