[Mesa-dev] Advice for implementing KHR_debug state structs

Timothy Arceri t_arceri at yahoo.com.au
Tue Jul 23 14:42:23 PDT 2013


Hi Brian,

Where can I get a copy of you unfinished work on the GL_KHR_debug extension?

Thanks,
Tim



----- Original Message -----
From: Jose Fonseca <jfonseca at vmware.com>
To: Timothy Arceri <t_arceri at yahoo.com.au>
Cc: mesa-dev at lists.freedesktop.org; Brian Paul <brianp at vmware.com>
Sent: Tuesday, 23 July 2013 11:25 PM
Subject: Re: [Mesa-dev] Advice for implementing KHR_debug state structs

Brian Paul has an early draft [1]. You should start from there.

Jose

[1] http://lists.freedesktop.org/archives/mesa-dev/2013-June/040171.html

----- Original Message -----
> Hi All,
> 
> I've been stalking this list for a while now and I thought I'd finally make
> an attempt to contribute something. I've decided the KHR_debug extension is
> a good place to start as the ARB_debug_output provideds a great starting
> point. However I've hit my first road block.
> 
> 
> I'm ready to setup a struct to hold the state information in mtypes.h for
> this extension but unsure how to continue. The ARBdebug_output extension
> already has a struct gl_debug_state, my question is how should I go about
> implementing one for KHR_debug should I implement a separate struct for each
> extension and duplicate a small amount of code but keep things self
> contained or should I try refactor things to reuse as much code as possible
> and risk tying the code up to tightly? How is this sutuation normally
> handled in Mesa? I guess my question should be seen as a general question of
> how to proceed with the rest of the code also functions, etc, do I aim to
> keep things self contained or is it safe enough to just aim to reduce
> duplication?
> 
> 
> Maybe someone can point me to an example of how other simialar extensions are
> handled?
> 
> Thanks,
> Tim
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 



More information about the mesa-dev mailing list