Arch Linux

--enable-texture-float enable floating-point textures and renderbuffers
[default=disabled]

Do you have any further background on the gain and drawbacks?

I have some concerns: http://www.phoronix.com/scan.php?page=news_item&px=OTMzMg

"The source code to implement ARB_texture_float extension is included and can be toggled on at compile time only by those who purchased a license from SGI, or are in a country where the patent does not apply."

Well, how about unigine that doesn't even work without it.

Thus including every game that's based on it.
Don't know for the drawbacks.

You haven't made any effort to answer the question of why SGI's patent on floating point textures should be taken any more seriously than the MPEG LA's patent on H.264 video.

1. It's not enabled by default and so against the Arch rules.
2. If we want to enable it though we need to make sure it gives useful features and no drawbacks.

Any other distribution around enabling it so we won't be on our own? I don't want to be faced to regressions nobody else can confirm. What are the gains if we enable it, guess some games will need it, anything else?
How many user will need it? What's so hard to use abs in this case(it's already prepared in the PKGBUILD)?

all points are invalid Andy.

logically is not enabled by default because is patented and is not available in other distributions because mesa 7.11 is not released.

i asked clutter/gnome-shell developers about this and they don't use it.

Connor Behan (connorbehan) and Andreas Radke (AndyRTR)
I did but i will do it again. Any opengl game/app that uses opengl floating point WON'T work without --enable-texture-float. So to be more specific. Games based on the (now hot and awesome) Unigine engine won't work. Playing games through wine won't work without it enabled. You probably won't need it from everyday accelerated desktop usage (or do you? not sure) but for those that want to use the gallium drivers instead of the binary blobs amd/nvidia blobs will NEED to have this option enabled.

Andreas Radke (AndyRTR) about point 2. I don't know. I'm not a galium dev, my knowledge doesn't go in that deep. This stuff will be in mesa 7.11 so i also don't know if any other distribution is gonna enable it by default. I'm guessing a few will but all popular distributions likely won't since they are (put bluntly) afraid...

Ionut Biru (wonder) like everyone is using gnome huh. I'm not! Though i don't know if KDE uses it..

Andy, I think 1. is quite untrue. Patches are one thing but configure flags are quite another. Within two seconds I was able to find a counter-example. Pidgin defaults to --enable-gnutls but the Arch PKGBUILD for it specifies --disable-gnutls. Libdrm also disables vwmgfx-api and nouveau-api by default but Arch enables both.

2. I think sounds more reasonable. Though this configure flag has the potential to help a lot of gamers (and they should be content to use abs *for now*), I agree that it would help to see how it affects users of other distros so we can be better informed. For this I suggest waiting until mesa 7.11 has been out for a few months instead of setting this to "Won't Implement" right away.

Is the problem lack of testers? I have two video cards I can try this on and I already know one of them shows no sign of trouble with --enable-texture-float. And I live in Canada so for the moment, it's legal for me to build with that flag.

Andy, for point 1. I think it's just mean of you to even consider it! To bust your idea completely here are the compile flags used by xorg-server that are by default _NOT_ set thus in your reasoning it "violates arch rules"... C'MON!

--enable-ipv6
--enable-dri
--enable-dmx
--enable-xvfb
--enable-xnest
--enable-composite
--enable-xcsecurity
--enable-xorg
--enable-xephyr
--enable-glx-tls
--enable-kdrive
--enable-install-setuid
--enable-config-udev
--disable-config-dbus
--enable-record
--disable-xfbdev
--disable-xfake
--disable-static
--sysconfdir=/etc/X11
--localstatedir=/var
--with-xkb-path=/usr/share/X11/xkb
--with-xkb-output=/var/lib/xkb
--with-fontrootdir=/usr/share/fonts

And know that nearly every package has --prefix=/usr in it which is, according to your "reasoning", also not "following arch rules".
Now i ask you. Please don't post such bugus reasons. I get on edge if you do that (like you see in this post).

Note: even the pacman package itself is than not following the arch rules!

Mark... the getting on edge is understandable but most of those extensions would in fact build even if xorg-server were configured with no explicit flags so it is not quite the same thing.

Conner, you smartass :p I made my point and there are a LOT of other examples (pacman, xbmc, mplayer, mplayer-vaapi, glibc which includes some patches as well! ....)
I made my point. Back on topic with real reasons please.