1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
|
# ATI Mach64
## Status
**Warning!** linux-core was [[dropped|http://cgit.freedesktop.org/mesa/drm/commit/?id=9dd3613073aa2491cef440725fdfa0cf1e8f1a42]] from freedesktop drm git repo with mach64 module inside, and module doesn't appear in mainstream kernel, as of 17-09-2010. You can try to build it from external sources, provided by your distribution, but mainstream situation is not good.
---
DRI support for mach64 has been moved to the DRI and Mesa trunks. This means DRI works on any recent distribution as of 2007.
On Linux systems, the DRM module is not included in official kernels. At least Mandriva 2007 systems come with a patch to include the Mach64 DRM, but it has been dropped for 2008 release. (Please can someone indicate where is mach64 drm gone?)
All mach64 chips with a triangle setup engine are supported. This includes the 3D Rage Pro, 3D Rage LT Pro, 3D Rage XL, 3D Rage XC, and 3D Rage Mobility. Cards without a triangle setup engine cannot be supported; this includes VT chips, 3D Rage, 3D Rage II/II+/IIc, and 3D Rage LT.
[[LeifDelgass|LeifDelgass]] has a page describing the status of the old mach64 branch [[here|http://www.retinalburn.net/linux/dri_status.html]]. He also has a [[page|http://www.retinalburn.net/linux/test_results.html]] has links with the results of OpenGL conformance and performance tests on the mach64 branch.
### How do I build the mach64 branch?
Follow the instructions on the Building page. Mach64 is now on the DRI trunk.
Build instructions for older branches are in [[LeifDelgass|LeifDelgass]]' [[Compiling the mach64 branch of DRI mini-HOWTO|http://www.retinalburn.net/linux/dri_HOWTO.html]] .
### Why isn't Mach64 built by default?
The reason the Mach64 driver isn't built by default yet is due to lack of proper security. At the moment, despite the fact that the client submitted buffers are checked and copied, a malicious client can change the buffer contents after the check/copy because _all_ buffers are mapped on client space. Therefore security can be compromised by using the Mach64 bus mastering abilities to read/write from/to system memory.
Things that need to be done:
* Provide a mechanism to allocate private DMA buffers which aren't mapped into the clients. The current DRM DMA buffer API is both arcane and incomplete in this this aspect. A new API is being worked, and is useable if these private DMA buffers are allocated by the DRM instead of the DDX. I'm merging into Mach64 branch as I speak, so this point can be considered done.
* Allocate and manage the private DMA buffers from above in Mach64 DRM. See [[http://sourceforge.net/mailarchive/forum.php?thread_id=1925221&forum_id=7177|http://sourceforge.net/mailarchive/forum.php?thread_id=1925221&forum_id=7177]] for a more detailed description of what to do. Besides having to basically write a new/separate buffer management code we also need to integrate it with the existing one. The reason we need to keep the current buffer management code is that plain texture/bitmap data is of no security concern and needs to be dispatched as fast as possible, which means no copying into private buffers.
There are more things were the Mach64 driver needs a little work but the items above are the ones preventing it to be merged into the DRI trunk, and upstream.
* -- [[JoseFonseca|JoseFonseca]]
As an update, the driver is waiting for some changes I'm preparing for the DRM common code that will allow the managament of several DMA buffers pools.
I can't really give a timeframe to driver completion - my laptop went dead several months ago and it's no longer something that affects me directly. Still I'm commited to finish it as my time permits it.
* -- [[JoseFonseca|JoseFonseca]]
### Latest status
Posted on the dri-users list Dec 8, 2007: (doesn't show up in the archive for some reason)
* _The work to get Mach64 secure was already done by George ([[https://bugs.freedesktop.org/show_bug.cgi?id=6242|https://bugs.freedesktop.org/show_bug.cgi?id=6242]]). Dave Airlie had concerns with the blits, but I reviewed the code with him I found it to be secure (basically we don't let the client touch dma buffers -- it's not the most efficient way for blits, but is is simple as it doesn't imply maintaining two sets of buffers, one private another public). Now I've cleaned up the code a bit (especially eliminating some macros) and commented more, to make it easier to understand and maintain. Hopefully it will be merged soon. José_
## Specifications
Several DRI developers got specifications from ATI under individual NDA.
The driver from the UtahGLX project can also be used as a guide.
## Resources
---
[[CategoryHardwareChipset|CategoryHardwareChipset]]
|
