Ok here's what I came up with, I'm going to commit it soon, though there
really are some ugly hacks in there needed to prevent lockups, (related
to setting/restoring the tcl outputs), maybe someone has any ideas?
The vertex program translation code is pretty taken from the r300
driver, which can be easily seen. I did change it so it more closely
resembles what fglrx outputs on my rv250, though not all changes might
have been necessary.
It really isn't tested much, so far what works is arbvptorus, doom3.
Quake4 in theory too but you need the updated version (bogus vertex
shader code). There are still some bugs in quake4 (and supposedly in
doom3, though at first look I didn't see any), but those are in fact tcl
bugs, not vertex program bugs (doom3/quake4 frequently switch vertex
programs on/off), still related to the texgen tex coord routing.
Programs which use generic attribs (such as arbvpwarpmesh) will fall
back to software tcl, not implemented for simplicty (possible but needs
some more changes, some more arrays to emit etc.).
Large programs (e.g those that require split state atoms, between 64 and
128 instructions, 96-192 parameters) are completely untested.
arb_vertex_program is still disabled by default for now, you still need
to enable it with driconf.
It is also completely untested on r200, I'd really hope this is the same
as far as vertex programs are concerned.
Some timedemo demo1 numbers for doom3, low quality selected but all
advanced options enabled (shadows etc, with the exception of
antialiasing/vsync).
arb renderer, tcl mode 0 (looking plain ugly...): 19 fps
arb renderer, tcl mode 1 (not only ugly, but very wrong...): 23 fps
r200 renderer, tcl mode 0: 9 fps
r200 renderer, tcl mode 0, MESA_EXPERIMENTAL set: 15 fps
r200 renderer, tcl mode 1: 20 fps
Not that fast but at least the vertex programs / advanced renderer don't
slow it down a lot.
Roland
r200vertprogs.tar.gz
Description: Unix tar archive
