On 11/18/2011 05:19 PM, Eric Anholt wrote:
> On Thu, 17 Nov 2011 19:58:54 -0800, Chad Versace
> <chad.vers...@linux.intel.com> wrote:
>> To do so, we must resolve all buffers on entering a glBegin/glEnd block.
>> For the detailed explanation, see the Doxygen comments in this patch.
>>
>> Signed-off-by: Chad Versace <chad.vers...@linux.intel.com>
>> ---
>> src/mesa/drivers/dri/i965/brw_context.c | 73
>> +++++++++++++++++++++++++++++++
>> 1 files changed, 73 insertions(+), 0 deletions(-)
>>
>> diff --git a/src/mesa/drivers/dri/i965/brw_context.c
>> b/src/mesa/drivers/dri/i965/brw_context.c
>> index 9b506a6..4d51e62 100644
>> --- a/src/mesa/drivers/dri/i965/brw_context.c
>> +++ b/src/mesa/drivers/dri/i965/brw_context.c
>> @@ -33,11 +33,23 @@
>> #include "main/imports.h"
>> #include "main/macros.h"
>> #include "main/simple_list.h"
>> +
>> +#include "vbo/vbo_context.h"
>> +
>> #include "brw_context.h"
>> #include "brw_defines.h"
>> #include "brw_draw.h"
>> #include "brw_state.h"
>> +
>> +#include "gen6_hiz.h"
>> +
>> +#include "intel_fbo.h"
>> +#include "intel_mipmap_tree.h"
>> +#include "intel_regions.h"
>> #include "intel_span.h"
>> +#include "intel_tex.h"
>> +#include "intel_tex_obj.h"
>> +
>> #include "tnl/t_pipeline.h"
>> #include "glsl/ralloc.h"
>>
>> @@ -45,12 +57,73 @@
>> * Mesa's Driver Functions
>> ***************************************/
>>
>> +/**
>> + * \brief Prepare for entry into glBegin/glEnd block.
>> + *
>> + * Resolve all buffers before entering a glBegin/glEnd block. This is
>> + * necessary to prevent recursive calls to FLUSH_VERTICES.
>> + *
>> + * Details
>> + * -------
>> + * When vertices are queued during a glBegin/glEnd block, those vertices
>> must
>> + * be drawn before any rendering state changes. To enusure this, Mesa calls
>
> "ensure"
>
>> + * FLUSH_VERTICES as a prehook to such state changes. Therefore,
>> + * FLUSH_VERTICES itself cannot change rendering state without falling into
>> a
>> + * recursive trap.
>> + *
>> + * This precludes meta-ops, namely buffer resolves, from occuring while any
>> + * vertices are queued. To prevent that situation, we resolve all buffers on
>> + * entering a glBegin/glEnd
>> + *
>> + * \see brwCleanupExecEnd()
>> + */
>> +static void brwPrepareExecBegin(struct gl_context *ctx)
>> +{
>> + struct brw_context *brw = brw_context(ctx);
>> + struct intel_context *intel = &brw->intel;
>> + struct intel_renderbuffer *draw_irb;
>> + struct intel_renderbuffer *read_irb;
>> + struct intel_texture_object *tex_obj;
>> +
>> + if (!intel->has_hiz) {
>> + /* The context uses no feature that requires buffer resolves. */
>> + return;
>> + }
>> +
>> + /* Resolve each enabled texture. */
>> + for (int i = 0; i < ctx->Const.MaxTextureImageUnits; i++) {
>> + if (!ctx->Texture.Unit[i]._ReallyEnabled)
>> + continue;
>> + tex_obj = intel_texture_object(ctx->Texture.Unit[i]._Current);
>> + if (!tex_obj || !tex_obj->mt)
>> + continue;
>> + intel_miptree_all_slices_resolve_hiz(intel, tex_obj->mt);
>> + intel_miptree_all_slices_resolve_depth(intel, tex_obj->mt);
>> + }
>> +
>> + /* Resolve each attached depth buffer. */
>> + draw_irb = intel_get_renderbuffer(ctx->DrawBuffer, BUFFER_DEPTH);
>> + read_irb = intel_get_renderbuffer(ctx->ReadBuffer, BUFFER_DEPTH);
>> +
>> + if (draw_irb) {
>> + intel_renderbuffer_resolve_hiz(intel, draw_irb);
>> + intel_renderbuffer_resolve_depth(intel, draw_irb);
>> + }
>> +
>> + if (read_irb != draw_irb && read_irb) {
>> + intel_renderbuffer_resolve_hiz(intel, read_irb);
>> + intel_renderbuffer_resolve_depth(intel, read_irb);
>> + }
>
> I find it odd that this is doing a larger set of resolves than the
> brw_predraw_resolve_buffers in the next patch. Actually, it seems like
> this ought to be just brw_predraw_resolve_buffers, since you're trying
> to just get that function's work done before getting any begin/end
> vertices queued up, right?
Shortly after posting the patch series, I was troubled by this function too.
After thinking about it, I agree with you here: we should do the same resolves
as done by brw_predraw_resolve_buffers(). We shouldn't actually call that
function,
however, because it mucks with vbo_bind_arrays().
This should fix glean/fbo, and drop HiZ's regression count to 0 :)
v2 will be sent soon.
----
Chad Versace
chad.vers...@linux.intel.com
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
