Now concerning the perspective correction, consider it as “free” in term of overhead for performance. The interpolator are specific HW unit with a fast multiply by inverse kind of calculation. Basically by shutting down the correction, you do NOT make it faster, you just skip the data path most likely. I would bet they actually have to ADD transistor to support such thing. (or do some tweak at the driver level ? I think it could be possible to mess up with the transform matrix to get this result (see the upper forum link))

Anyway, it is not like software where every new or more operation will cost you time. In HW you do a tradeoff with the transistor count to be able to have more calculation within the same timing bill and perspective correct is already included in this particular case… So I really do not get those specs.

I mean : PS1 level texturing ? 🙂

It was horrible, texturing were swingging around in racing games (think the road). Perspective correction is a huge plus that is already integrated. I do not really see any reason to disable it, even for 2D, it changes nothing to the transistor work/path.

Also I had some ideas where you can use 'flat', but right now I'm thinking if you can just use uniforms…

Perspective correction was not available before because of the cost in software rendering, or that it was poorly understood how to make it cheap in HW for real time.

Nobody would benefit now in 3D to use non perspective (linear) interpolation…

I feel it is like writing software rasterizer in the middle of the 90’s.

I remember trying to find a way to do something similar (but not quite the same) in 2006, so I can easily spot the difference. 🙂

http://www.gamedev.net/topic/419296-skewedsheared-texture-mapping-in-opengl/

I ended up with a solution that used fixed pipeline, by figuring out a way to dynamically calculate the texture transformation matrix for any given input.