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.
Matrox has done a great 180. They used to have the worst driver support in the industry, even under Windows. Now they're working hard, and they're putting out good Linux support. I think the G200/G400 is the fastest 2d card you can get for XFree86, and their 3d support is getting better fast.
Remember, people. When you buy the videocard, SEND IN THOSE PRODUCT REGISTRATION CARDS! Mark Linux. It's how they know what to support!
People are working on support for TV-Out. Unfortunately this is one of the only portions of Matrox's graphics system they did not make the specs available for.
The problem is, everyone who puts TV-Out technology on their boards signs a contract with Macrovision, Inc (they are the ones who implement the copy protection that prevents you from copying vhs tapes), and the contract forbids specs from being released (because people could then easily override the insecure Macrovision protection and allow vhs tapes to be copied).
There are rumors that Matrox intends to support TV-Out via a binary-only module, but they are only rumors. There hasnt been any official info from Matrox regarding TV-Out on Linux.
________________________________
Is it just me, or do more people get the feeling that the magic 'carmack touch' was applied here?
In the matroxuser.com sniplet it sums up the history of the matrox & linux community relationship, from the first matrox driver in 1992, upto the GLX project, where it -clearly- states the nature and development of carmack's role in the GLX project. And if you would expand this history line with 'the present' it would be this order:
Start of GLX
Carmack messing with GLX
Matrox Funding GLX development.
Now doesnt that make a great coinsidence? Specialy considering the weight carmack's word usualy carries in the OpenGL / Games scene, it wouldnt supprise me to find that he was the final drop for matrox to go ahead.
If this all is true? donno, but if so, kuddles to u carmack for helping this to happen!
-- Chris Chabot
"I dont suffer from insanity, i enjoy every minute of it!"
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