Programming the G-series WARP engine

[runderwo]

Does anyone have any information on programming the WARP? Specifically, the layout of registers (as viewed from the WARP) and op codes would be extremely handy. All I can find is the DDK for the microcode which handles DirectX vertex lists. It doesn't go into any detail about how to maintain the existing microcodes or to write a new one.

All I can glean from the DDK is that WARP instructions are 64-bits wide and that a WARP program must be 64-bit aligned in the instruction cache.

[DGhost]

try getting in touch with DevRel. i don't know if they can help you or not, but they are the best source of info.

Any of the few people (if any exist) outside of Matrox who have info on WARP are going to be under NDA.

edit: honestly, i do not remember if Matrox ever chose to make information on WARP available to developers. If my memory serves me correctly, they never did release them - instead they chose to develop their own Linux driver instead.

[runderwo]

The only info I have is what came with the DDK; it gives a general overview of the WARP architecture, WARP register definitions as seen from the device driver, and goes into details on how to send vertex data to the pre-existing microcode. Nothing useful on how to create an own microcode

Any idea who to contact at Matrox? This is a dead product so contacting sales (who tech support always 301 redirects to) seems pointless. But the tech support guys can't make any decisions without consent of their managers, and don't seem willing to relay any requests.

[Goc]

Sounds pretty much like normal Matrox behaviour...

[Greebe]

Any idea who to contact at Matrox? This is a dead product so contacting sales (who tech support always 301 redirects to) seems pointless. But the tech support guys can't make any decisions without consent of their managers, and don't seem willing to relay any requests.

While it may appear tech support doesn't relay this info, the opposite is most likely true. It's the other guys who are afraid of releasing any info that's the problem, even if it's old obsolete tech.

Mind if I ask why you want to mess with the warp engine?

[Ribbit]

If I understood Haig correctly, they're still using the WARP in the Parhelia.

[runderwo]

Mind if I ask why you want to mess with the warp engine?

A couple things are up front right now regarding Matrox's microcode that is part of the XFree86/DRI driver:

1. There is a general purging of firmware and microcode going on right now all over the Linux world and especially in Debian. The problem is that it is software without any form of source code, which is in conflict with the goals of most of the people who are working on such projects. It also arguably causes a license violation when combined with other people's GPL code. The mga microcode is a target, so unless someone (i.e. me) either obtains source for the current microcode, or reverse engineers the instruction set and constructs equivalent source or a new microcode myself, it is doomed to disappear.

2. The security architecture of the driver could be improved greatly, if the microcode were to oversee certain register writes which are safe for unprivileged users who are accessing the DRI device to perform. Right now, every register write must be done through DRM ioctls, each of which involves an expensive context switch. This is done so that the in-kernel DRM driver can perform register writes on behalf of the user to ensure that the user can't do anything funky. If the microcode did these things instead on behalf of the Mesa driver, there would be no context switch or CPU usage involved.

3. The microcode expects DirectX style vertex buffer format as opposed to OpenGL vertex array format. There is a performance loss associated with the conversion.

It is also possible that the WARPs could do other useful things besides triangle setup, but I won't speculate on that at the moment as has been done here in the past.

[Kruzin]

Tech support and sales can't help you.
Your only chance is Developer Relations (devrel).
But I wouldn't hold much hope. They're well known for not even replying if you're not a big-time developer. They don't deal with open-source people as a general rule.

http://www.matrox.com/mga/support/tech_support/emaildevrel_form.cfm

[runderwo]

I think I've filled out that form about a dozen times, every time I had a new potential Matrox-related project. Never received a response.

[runderwo]

Irritatingly, the WARP registers are write-only, which means I can't do any deduction on the instruction set. There are also some registers mentioned in the WARP DDK such as WBRKPTSTS that are not even documented in the G400 databook.

[DGhost]

IIRC, the XFree people had issues getting that information from Matrox the first time around. I believe Matrox never did release the WARP specifications to anyone. Instead they developed their own binary only module that handled the WARP shit and plugged into the current open source driver.

It used to be you could log in and get chip level specifications at least. Unfortunately, it appears that in the last year (apparently after they laid off most of the DevRel staff, and a lot of the driver development team) they removed the devrel portion of the website, instead forcing you to contact them if you wanted information.

that being said, a year ago you might have stood a chance. with the changes that have occured, i would seriously doubt the people in charge will give you that info.

The fact it is set up to handle DirectX vertex buffers is interesting. that would certainly help explain why they always had such great DirectX support and has always had such issues with OpenGL. Especially since it appears the Parhelia reuses a lot of the building blocks that made up the G400.

[runderwo]

Yes, they released a binary only microcode with an accompanying DDK that is responsible for triangle setup in the current DRI driver. Before that, the hardware had no setup capability and was mind numbingly slow as the CPU had to do the setup stage.

The DDK claims they use the same microcode for DirectX, the ICD and the miniGL, at least of the time of its writing. They have probably changed that since then. Also, the WARP(s) in the Parhelia (if they exist) is most likely not only handling a T&L stage but probably had programmable shader functionality tacked onto it too. It probably would have been possible to do a T&L stage on the G550's WARP but too much trouble for Matrox for a card which is not marketed for 3D capabilities. In any case, the current microcode has some mis-features and no source code so it is unmaintainable.

I did verify that the WR* are write-only from the host. That is unfortunate, because observing their changes while single stepping through the microcode might have helped reveal what the op codes are doing. I still have no idea what is the WBRKPTSTS register the DDK is referring to. It is not in the databook nor any of the publicly released code.

http://home.icequake.net/~nemesis/g400/c2warp.c

http://home.icequake.net/~nemesis/g400/ucode_out.gz

http://home.icequake.net/~nemesis/g400/warp_opcodes.h

http://home.icequake.net/~nemesis/g400/warp_hw.h

http://home.icequake.net/~nemesis/g400/warptest.c

[Jon P. Inghram]

Have they ever even said what WARP stands for, or if it is actually an acronym?

[runderwo]

(C) Matrox:

The setup engine or W.A.R.P. (Windows Accelerator Rendering Pre-processor) is a device who pre-process command sent to the graphic engine (the graphic engine being the accelerator itself).

[DGhost]

Thank you for the clarification on the linux/mga issues. It has been so long since I have even touched Linux, and I was never involved in XFree.