While a lot of users are interested in this support, the only response from the original request by Lucas Stach to merge the code branch in question (the branch was written and maintained by Marek Olšák) was from Intel's Eric Anholt and he was in favor of seeing the floating point / render targets support included in Mesa. The discussion on the Mesa development list basically died after that point, with no other messages and no code being merged, although the code is already written and ready.
In pressing for this code to be merged or to at least debate the issue once more of patented OpenGL capabilities within Mesa, Lucas Stach has written another message to the list this morning. Back in the merge floating to master e-mail thread, Lucas has written:
This matter won't go away if we ignore it. We will never get full OpenGL 3.0+ compliance if we don't merge in the floating branch.
Attached you will find a patch against Marek's floating branch to hide the patented extensions behind a configure switch. Please ACK if you think we could merge in floating or give some opinion why you think we couldn't merge.
The attached patch is very simple. When the --enable-patented configure switch is set, the patented code is enabled and GL_ARB_texture_float and GL_ATI_texture_float extensions are exposed.
So far there's no response yet from any of the other developers, but let's see what happens next week when most people are back to working.
It would be really great if there was an update from the Linux Foundation on their Mesa patent research as its certainly a nasty topic and is holding back some of OpenGL 3.x support. For somewhat easier adoption by end-users, at least there is an external S3TC library for Mesa, which was created by Roland Scheidegger and now maintained by Marek Olšák. After all, this open-source library that is critical to the free software Linux desktop is years behind the latest OpenGL 3.x/4.x specification and those wishing to take advantage of this industry graphics specification are limited to using the binary-only AMD/NVIDIA drivers as a result.