Looking at Tegra2

Obviously, when you've reverse engineered Nvidia desktop GPUs and written a driver for those, you're always interested in knowing how new chip models look at the hardware level. And when an embedded variant like Tegra2 comes up it's logical to wonder how different from the mainline desktop GPUs it is (ok, it's only logical for guys like me, but whatever).

Well, it happens that Tegra2 has a bunch of interesting differences when compared to its desktop big brother (at least judging by the first reverse engineering I did of it).

The first and obvious weird design is that the nvrm module can be either a user space daemon or a kernel module now. Aside from the weird design this results in, a user space daemon makes reverse engineering easier which is a bonus for me.

Second, it seems like the beast only uses PIO objects (yes, like those which were last used on the Riva128 in 1997). There is no command fifo like on the desktop variant. The fifo machinery seen on desktop cards probably requires too many transistors and juice to function.

Third, all hardware GLES2 state registers can be read back, which means that you don't need to store the state twice in memory and in the hardware, but only in the hardware. It seems like this can be a big saving in driver size/complexity when implementing the glGet() functions and friends. «What is the current size of the viewport? Let me look at the hardware, one second» might sound strange at first, but makes sense in memory-limited environments.

So do I plan to make an open source Tegra2 driver? Not in the foreseeable future, I'm doing this just out of curiosity. But if you want to look at the findings to make your own driver, I've put up a git tree with the stuff online:
http://cgit.freedesktop.org/~marcheu/tegra/