2009/4/28 Stefan Dösinger stefan@codeweavers.com:
I think this is getting pretty rediculous. I think we should either just always print the infolog, or give the infolog its own debug channel and make this a WARN.
Am Dienstag, 28. April 2009 17:24:55 schrieb Henri Verbeet:
2009/4/28 Stefan Dösinger stefan@codeweavers.com:
I think this is getting pretty rediculous. I think we should either just always print the infolog, or give the infolog its own debug channel and make this a WARN.
I disagree. Having genuine warnings visible in the FIXME log has been pretty helpful to me a few times. Warnings are more helpful than errors because if there's a compile error the ERR channel gets flooded with GL errors anyway.
If we hide them per default, it means we have to ask for more logs on bugreports, and filter the log somehow anyway. If we make all the spam visible it makes the whole default fixme output useless. I certainly want to keep GLSL errors in the fixme channel and filter out known spam.
2009/4/28 Stefan Dösinger stefan@codeweavers.com:
Am Dienstag, 28. April 2009 17:24:55 schrieb Henri Verbeet:
I think this is getting pretty rediculous. I think we should either just always print the infolog, or give the infolog its own debug channel and make this a WARN.
I disagree. Having genuine warnings visible in the FIXME log has been pretty helpful to me a few times. Warnings are more helpful than errors because if there's a compile error the ERR channel gets flooded with GL errors anyway.
If we hide them per default, it means we have to ask for more logs on bugreports, and filter the log somehow anyway. If we make all the spam visible it makes the whole default fixme output useless. I certainly want to keep GLSL errors in the fixme channel and filter out known spam.
Having useful warnings is useful, of course. However, it's really up to the driver to provide useful infolog messages. I'm sure you remember I had doubts about filtering the infolog when this was first added, and this patch just takes it to a whole new level by parsing the infolog and adding multiple versions of the same message each time we add another extension. The way to fix this really is to convince driver developers to generate useful infolog output. Also, note that if you want the "mismatched access semantics" warning to go away, you should fix the actual problem, not add the message to the spam list.
Am Dienstag, 28. April 2009 20:09:32 schrieb Henri Verbeet:
Having useful warnings is useful, of course. However, it's really up to the driver to provide useful infolog messages. I'm sure you remember I had doubts about filtering the infolog when this was first added, and this patch just takes it to a whole new level by parsing the infolog
The other positive side effect of the \n parsing is that we don't send a big string to dbgstr_a, but write proper lines for each line the driver sends us, which makes the errors actually readable in a normal log. There are also some users who considered the extension-unsupported spam an actual error which led to confusion in bug reports and forums because it was prominently visible output.
But anyway, I don't want to start a big fight over a debug function. If you're unhappy with the patch I can keep it in my tree or put it into the wiki and be happy with it.
-
Henri Verbeet -
Stefan Dösinger