[ltp] Latest Radeon driver info

Dax Kelson linux-thinkpad@linux-thinkpad.org
Sat, 26 Jun 2004 13:15:31 -0600


--=-hnyDHR7BijxWZPkoMCFl
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Sat, 2004-06-26 at 15:42 +0100, Hamie wrote:

> Hmm... I have an r50p (FireGL-T2) with 1600x1200 LCD, and would really=20
> like to have my cake & eat it too... i.e. 3d accel AND the ability to=20
> suspend my laptop (The ATI drivers are fast, but won't suspend for me,=20
> and corrupt the display when switching between VGA text console & X) and=20
> the X.Org radeon is very stable, but certainly isn't as fast as the ATI=20
> for 3d work (Although with 2d, I think X.Org might be faster=20
> [subjectively only, no measurements].
>=20
> Is 3d being worked on for the FireGL-T2 (Rv350?) at all? Is the lack of=20
> it due to lack of ATI info (Grr!) or lack of time, lack of developers=20
> with rv350's?

Open source 3D *is* being worked on for the Radeon R3xx, the going is
very slow though since ATI has only tricked out the smallest amount of
information. See:

http://volodya-project.sourceforge.net/R300.php

The main person working on it is Vladimir Dergachev, and in early May he
said:

-----------------

One small correction - with ATI help, since I have some sample hardware
from them and some docs. In particular, I know which CP packets were
removed in R300 and I am reasonably sure no new ones were added. So this
is good.

The bad thing is that majority of 3d register descriptions are missing
from the docs.

Another good thing is that from looking at ATI's website and reading
some books I get the impression that R300 is different from R200 in that
it is more general-purpose (docs claim ability to apply any 4x4
matrices) so it might be possible to get to the level of functionality
where we can process vertex data with colors and ignore T&L part.

Hmm.. I don't think the above paragraph was very clear: in R200 to
perform an operation one has to write particular values in 3d registers
- so there are several registers for clipping, etc.

I am hoping that on R300 one simply sends streams of numbers via CP
packets and the hardware performs the operations, similar to a DSP.
(Harvard architecture, if I remember this right). This would be real
nice as it would imply that we do not need to know registers that first
appeared in R300 (or that changed format from R200).

Well, we'll see what happens.

                       Vladimir Dergachev

------------------------------

If you want to follow it more closely, or help out, go check out:

http://dri.sf.net/

Dax Kelson
Guru Labs

--=-hnyDHR7BijxWZPkoMCFl
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA3ctTESq34TbtkiIRAmLSAKC+sPpcz6N+yoScR+F/vcjMd3s4SgCfaE7v
SuRidbhsut6vKjy6yGh4GzU=
=D/ch
-----END PGP SIGNATURE-----

--=-hnyDHR7BijxWZPkoMCFl--