If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
Can we please document all these various environment variables somewhere? As a driver tester I hate having to dig through the source to find these, and it's not every time that Michael documents which env vars he uses when he posts articles (sometimes he just says "a flag" and doesn't mention which one), and of course they aren't in any of the documentation.
A better way would be to ship a /etc/mesa-debug.conf config file in /etc with a simple var=value format, but only ship and read from that file if mesa is compiled in debug mode (i.e. with debug symbols etc). Might need an option like --enable-debug-conf in configure. Then, ship a default mesa-debug.conf that briefly documents all possible settings but leave them commented out, so the user can easily uncomment and change them as desired.
This method would also remove the need for the user to hack environment variables into the pipeline before starting X, because it seems that you might get strange behavior if some of your mesa-using programs are running with the flags, and some without. Especially e.g. tiling...
It's pretty easy to find these: grep debug_get_bool_option *
Anyway, going to all that trouble for something that's a, likely to disappear once these features are finished and b, only of interest to a very small number of people seems like a waste of time.
Setting up the debug configuration infrastructure would be a one-time investment. Anyone who wants to write a debug option into their code afterwards would still be calling ONE function; it's just that the name of the function would be different from "debug_get_bool_option". Or maybe, heck, we could change the implementation of that function to DO exactly what I've proposed.
Then of course they'd have to write something like this:
#Enable GLSL 1.30 support on Radeon 2xxx or later
in the mesa-debug.conf.example file, but that would take about 3 seconds of a developer's valuable time Can't have that.
why use environment variable and not enable those features by default?
it is patent issue again?
A dev commented here earlier:
Originally posted by arlied
The big items left are:
EXT_transform_feedback needs upstream kernel patch, and it currently locks up on all R700 class hardware.
cayman needs some more work to finish off a few integer opcodes (divide/mod).
Its got 7620/7846 on piglit on my rv635 right now, a few of the remaining issues should be solved by Jerome's tiling work.
Even after the drivers enable GL3 by default, it will still be disabled unless you enable the patented fp texture option - that's true of all the drivers, and it should be the only patented bit required.