Slashdot Mirror
Matrox to fund DRI Development
SuperN wrote in to let us know that Matrox will be contracting Precision Insight to develop a DRI driver for the G400 and G200 chipsets, for use in XFree86. There's more information available, as well as a press release. Once Precision Insight is finished developing the driver, the source is to be released with the rest of XFree86, so it looks to be good vibes all around.
Now, if Matrox would only release the warp specifications so that we could make secure direct rendering without a performance hit.
Some background:
The G200 and G400 has the ability to read and write to buffers in primary memory. This is a great feature, but if misused you can easily crash your computer or with a little more work do things like read and write kernel memory. Therefore we only allow root to do direct rendering in Utah GLX.
Thanks to Matrox' donation of the warp microcode we can now send a list of vertices to the card instead of having to manually calculating things like delta x and delta y values. (This is usually called triangle setup.) This was a great performance boast and also a key to more security since you cannot embed register writes in such a list of vertices.
Still, every time you want to change the current texture or change your current blending mode you will need to write to a register. And since the G200/G400 doesn't distinguish between a register write to change your blending mode and a register write that initiates a blit that will zero out the first 6 MB of framebuffer memory you a normal user cannot be allowed to write such data directly to the card. [1]
You can work around this by sending a buffer with some sort of bytecode to the kernel and let it do some sanity checks on it before sending it to the card. Thankfully the vertex lists cannot contain hidden register writes. [2].
This does not come without a performance penalty though.
What we could do if we had warp specifications is to write microcode that would take a buffer that not only contained vertex data but also information about all mode changes that was safe. Stuff like buffer allocation would still have to be done by the kernel or the X server, but you wouldn't have to do that very often.
I am not totally unreasonable, even though I would love to write some microcode myself I would be satisfied if Matrox provided microcode with this kind of functionality.
Still, this is a problem that will probably disappear in a couple of graphics card generations once multiuser systems is more common.
[1] Actually, the data isn't written directly to the card in any case if you are using DMA to transfer the commands from the host to the card. This is a key to high performance graphics in combination with the G200/G400.
[2] You can upset the card by writing improper values to the vertex list with the current microcode, you shouldn't be able to do more than a DOS attack with it though. The kernel or X server could probably detect this and restore the state of the card if this is tried as well. (I don't know if this is possible, but I think this is the case.)
The decision is even more of a cinch given the excellent quality of their hardware. This is not a situation where you have to choose between the best hardware and the best open source drivers. Matrox has them both. The G400 MAX has the highest output bandwidth of any card of which I am aware, and it produces a nice crisp image on even the biggest monitors. Besides that, it makes a passable 3D accellerator for games.
For me the decision was easy. I traded in my Millenium II for a Millenium G400 MAX last week and I have been very happy since.
-jwb