--Signature_Mon__6_Jun_2005_02_13_48_-0400_/k1pQqp83rxw=wBf
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Hello,

> You can surely split and change the DRM code I provided you with, but
> I wish you good luck maintaining it, because the current form has the
> advantage of being shared code between Linux, FreeBSD and us. That's
> why I would only dare to add hooks for VGA or a radeonfb-like thingie.
> While you can refacture the driver and split it, it's going to be a
> bit harder to stay in sync with the official DRM distribution.

True, we'd end up with our own drm code. On the other hand we'd be less
x86-dependent and it would be easier to add support for new graphics
devices. On the other hand - there's already plenty of BSD- or
Linux-specific code, the kernel modules don't share a lot as far as I
can tell.

> As to shared code, that's a bit difficult because of all the defines,
> most of the code starts to look different if you have e.g. a card that
> supports scatter-gathering, or one that supports using a GART, etc.

Yes, that's why I want to move this stuff into the display drivers.

> This is card specific, and while you could maybe implement runtime
> checks you should bear in mind that this will reduce the performance
> of your rendering driver.

Not when card-specific code sits in card-specific drivers.

> The purpose of DRM is direct rendering - taking a shortcut from
> graphical applications to the graphics card's rendering engine.

Yes.

> It's surely possible to do the split you're suggesting, but either you
> end up still having most of the code specific to the graphics card, or
> you may experience a loss of performance.=20

I don't see the loss of performance - when the display drivers handle
the card-specific stuff there isn't much of a loss, we'd probe the
hardware ( happens anyway ), do some additional setup for the drm and
that's it - but you're the one who knows the drm code, I'm just checking
options ;)

> Either way you're going to get out of sync with the codebase.

Ok, how mature is the drm API? Is it likely to change dramatically any
time soon?

> On the other hand, we're nerds, and we might not care about the
> codebase at all. It's up to you. I'm only suggesting here.

Hmm, let's try something else. I'll just ask a bunch of questions -
maybe we'll find some common ground.
How likely is the drm API to change any time soon? I mean the ioctl()s,
defines and so on.
Is the current drm code really platform-independent? How much work would
it be to get the radeon module to work on - say - macppc? Or sparc64?
What I'm getting at is - what do you think would be easier to maintain -
the current drm code with support for i386, macppc and sparc64 frobbed
into it, with the prospect of adding more platforms, or a (partial)
re-implementation in NetBSD-style?=20
If the API keeps changing then it's of course pretty pointless to come
up with our own implementation. If it doesn't we may be better off with
a nice, modular one that's likely to Just Work(tm) on different
platforms.

just 2 more cents
Michael

--Signature_Mon__6_Jun_2005_02_13_48_-0400_/k1pQqp83rxw=wBf
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (NetBSD)

iQEVAwUBQqPpncpnzkX8Yg2nAQKuBQf/eCr40g6fmmFR1J7k3PODn1GJ2juBAEQM
Ybq798VzvkzmUmdbBwiOLZFXmxJgSQoj7PJcONkPDg1FhJjqO4czn3V9AL5XDC+h
fUyPCLUc2vpid8nEK7XxJfSKlu3XQ3h+KplkKSCzrj0s9TEUttQub9BzYa03V2Y2
dX6ikJ4ADUP/eH7Ok1jqqzrxP5POZfJZ2HPpVuLC3zv/zoBqLncyST6/VRheUUOf
DVA6gV1GJig6R8mJEnciLC6lzJsOAL5YGFWLCDM77lQ6Yb1KddsCjxxEJze0MH7H
BNf0wWXPYP29AlzkvrO6JJxYUxvPo70eKPcShsuY5JANk2l5pSXiXQ==
=T/Q8
-----END PGP SIGNATURE-----

--Signature_Mon__6_Jun_2005_02_13_48_-0400_/k1pQqp83rxw=wBf--