[Mesa-dev] [PATCH] mesa: detect inefficient buffer use and report through debug output

Brian Paul brianp at vmware.com
Wed Dec 9 14:23:00 PST 2015


On 12/09/2015 11:43 AM, Ilia Mirkin wrote:
> On Mon, Dec 7, 2015 at 8:42 PM, Brian Paul <brianp at vmware.com> wrote:
>> When a buffer is created with GL_STATIC_DRAW, its contents should not
>> be changed frequently.  But that's exactly what one application I'm
>> debugging does.  This patch adds code to try to detect inefficient
>> buffer use in a couple places.  The GL_ARB_debug_output mechanism is
>> used to report the issue.
>>
>> NVIDIA's driver detects these sort of things too.
>>
>> Other types of inefficient buffer use could also be detected in the
>> future.
>> ---
>>   src/mesa/main/bufferobj.c | 55 +++++++++++++++++++++++++++++++++++++++++++++++
>>   src/mesa/main/mtypes.h    |  4 ++++
>>   2 files changed, 59 insertions(+)
>>
>> diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
>> index f985982..6bc1b5e 100644
>> --- a/src/mesa/main/bufferobj.c
>> +++ b/src/mesa/main/bufferobj.c
>> @@ -51,6 +51,34 @@
>>
>>
>>   /**
>> + * We count the number of buffer modification calls to check for
>> + * inefficient buffer use.  This is the number of such calls before we
>> + * issue a warning.
>> + */
>> +#define BUFFER_WARNING_CALL_COUNT 4
>> +
>> +
>> +/**
>> + * Helper to warn of possible performance issues, such as frequently
>> + * updating a buffer created with GL_STATIC_DRAW.
>> + */
>> +static void
>> +buffer_usage_warning(struct gl_context *ctx, const char *fmt, ...)
>> +{
>> +   va_list args;
>> +   GLuint msg_id = 0;
>
> This needs to be wrapped in a macro, with a 'static' id (at each macro
> invocation), otherwise a fresh id will get generated each time this is
> called, which is presumably not desirable. Same as what I did with
> pipe_debug_message/_pipe_debug_message.

Is the macro required, or can I just pass a pointer to a static GLuint 
from each call site?  I took a quick stab at the macro but I'm having 
trouble with the varargs stuff.

-Brian



More information about the mesa-dev mailing list