On 04/12/15 23:08, Ilia Mirkin wrote:
On Fri, Dec 4, 2015 at 6:00 PM, Jose Fonseca <[email protected]> wrote:
On 04/12/15 22:45, Ilia Mirkin wrote:
On Fri, Dec 4, 2015 at 5:40 PM, Jose Fonseca <[email protected]> wrote:
On 04/12/15 20:04, Ilia Mirkin wrote:
On Fri, Dec 4, 2015 at 3:01 PM, Brian Paul <[email protected]> wrote:
On 12/04/2015 12:46 PM, Ilia Mirkin wrote:
On Fri, Dec 4, 2015 at 2:42 PM, Brian Paul <[email protected]> wrote:
+ if (templ->poly_smooth && svga->debug.callback.debug_message) {
+ /* note: we always need a % something in the message string */
Why? Did I mess something up?
If I write it without the dummy %s I get:
In file included from
../../../../src/gallium/auxiliary/util/u_inlines.h:36:0,
from svga_pipe_rasterizer.c:29:
svga_pipe_rasterizer.c: In function 'svga_create_rasterizer_state':
../../../../src/gallium/auxiliary/util/u_debug.h:273:40: error:
expected
expression before ')' token
fmt, __VA_ARGS__); \
^
svga_pipe_rasterizer.c:357:7: note: in expansion of macro
'pipe_debug_message'
pipe_debug_message(&svga->debug.callback, CONFORMANCE,
^
Hmmmm... so that'd be a "yes" to me messing it up :) I'll have a look
to see if there's something simple I can do here. Off-hand it feels
like it should be #__VA_ARGS__? Been a while since I looked at the
specifics of all this.
BTW, right now this callback is only set for debug contexts. Perhaps
that was not an ideal decision... just an FYI though.
apitrace creates a debug context so that's the main thing for me right
now.
But it might be nice if setting MESA_DEBUG would cause the debug/info
messages to be printed to stderr for those apps that don't use
GL_ARB_debug_output.
Yeah, we should probably also throw in Enable/Disable hooks into
st/mesa that flip it on/off when flipping GL_DEBUG_OUTPUT (or whatever
the enum is).
BTW, note that apitrace cuts messages off after 100 of them which is
pretty annoying -- I opened an issue at
https://github.com/apitrace/apitrace/issues/395 a while back.
Not just "100", but 100 *per ID*.
Which is very different.
Why is it so annoying? A patch for an option is welcome anyway BTW.
Right, but but an ID is a message. So let's say the message is
"falling back to XYZ", why would you only want to know the first 100
times? Or let's say the message is "shader compiles to XYZ
instructions" -- again, why the first 100 times? In fact, *given* that
you enable these messages, I don't see why it would ever be desirable
to limit them.
Isn't it obvious?
OpenGL applications are repetitive by nature. You're bound to have the same
error over and over again.
Futhermore, some IHVs have messages so frequent that completely overwel
everything else.
So, when you take a trace of an arbitrary app, and replay e.g., on NVIDIA,
you'll get lots and performance hints. Nevertheless, you'll want to be able
to spot rare and more important issues among all that. limiting to a fix
number, e.g., 100, means that after a while, they all silence, so that any
new issue will stand out.
Soemthing that happens all the time is invariably interesting.
I doubt we're going to change each others' mind on this.
I'm not trying to change your mind. You said you couldn't see any reason
to ever limit, and I gave you an example otherwise.
> I've
contemplated throwing prints into mesa, but haven't been sufficiently
motivated to worry about it.
Like you say, GL applications tend to be repetitive, but they tend to
have a "startup" phase, and a "do repetitive thing" phase. If the
message gets triggered > 100x during the startup phase, I don't get to
see it when I'm actually interested in the results.
Yes, I agree there might be situations where you might want to see all.
That's why I already agreed to have the apitrace option to cofigure an
arbitraryly/infinite limit.
But it's OK, with Matt's run from shader-db, it all works, which was
the primary motivation for piping this thing through to gallium.
Super.
Jose
_______________________________________________
mesa-dev mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
