On Sat, Dec 12, 2009 at 8:03 PM, Keith Whitwell <kei...@vmware.com> wrote:
> Maarten,
>
> Interesting. There are reasons this might be happening indeed, but first can
> I ask a couple of silly questions...
>
> - Is your bug only on one particular gallium driver, or does eg. softpipe
> show the same symptoms?
> - What about non-gallium drivers? eg. Mesa swrast?
That's not silly at all. I could not get softpipe to work (glxinfo:
symbol lookup error: /ts/git/mesa-softpipe/lib/libGL.so.1: undefined
symbol: glAreTexturesResidentEXT), i did get swrast to work. And this
didn't have the problem.
>
> Keith
> ________________________________________
> From: Maarten Maathuis [madman2...@gmail.com]
> Sent: Friday, December 11, 2009 4:41 PM
> To: Keith Whitwell
> Cc: mesa3d-dev@lists.sourceforge.net
> Subject: Re: [Mesa3d-dev] [gallium] what is wrong when i need FLUSH_CURRENT
> in st_teximage_flush_before_map()
>
> On Tue, Dec 8, 2009 at 7:21 PM, Maarten Maathuis <madman2...@gmail.com> wrote:
>> It was TexSubImage, and i added FLUSH_CURRENT after
>> ASSERT_OUTSIDE_BEGIN_END_AND_FLUSH and it seems to fix the issue. The
>> difference between the two is that one triggers on NeedFlush &
>> FLUSH_UPDATE_CURRENT and the other on NeedFlush &
>> FLUSH_STORED_VERTICES. Any idea what the problem is?
>>
>> Maarten.
>>
>> On Tue, Dec 8, 2009 at 3:36 PM, Keith Whitwell <kei...@vmware.com> wrote:
>>> On Fri, 2009-12-04 at 13:51 -0800, Maarten Maathuis wrote:
>>>> I recently noticed a regression in the nv50 gallium driver, with a few
>>>> hours of bisecting i figured out i need FLUSH_CURRENT called
>>>> unconditionally in st_teximage_flush_before_map(). Otherwise in
>>>> warzone2100 several small textures (glyphs) go missing. Does this make
>>>> any sense or perhaps provide a hint as to the real problem. One other
>>>> person has tried and could not reproduce this issue. I've tried doing
>>>> a 100 msec wait instead and gpu flush (FLUSH_FRAME to be precise) +
>>>> 100 msec wait. Neither work, which leads me to believe something is
>>>> still stuck in the state tracker.
>>>
>>> Maarten,
>>>
>>> FLUSH_CURRENT really just flushes internal Mesa state, rather than doing
>>> anything to the GPU or driver. In particular it will:
>>>
>>> - Make sure the VBO module issues any pending draw commands
>>> - Asks the VBO module to update ctx->Current.Attrib[]
>>> - Similarly for ctx->Light.MatAttrib[]
>>> - And provokes the unmapping of the in-progress immediate VBO.
>>>
>>> Most of this is also done by ASSERT_OUTSIDE_BEGIN_END_AND_FLUSH(), which
>>> is being called at the top of _mesa_TexImage2D().
>>>
>>> So it's a surprise that calling FLUSH_CURRENT has any effect, as it
>>> really just updates a few mesa internal values once ASSERT_OUTSIDE...()
>>> has been called.
>>>
>>> What would happen if you lifted your FLUSH_CURRENT up into the highest
>>> mesa function on the callstack?
>>>
>>> Keith
>>>
>>>
>>
>
> This is the smallest change i could find that would work.
>
> diff --git a/src/mesa/vbo/vbo_exec_api.c b/src/mesa/vbo/vbo_exec_api.c
> index f0a7eea..f45761e 100644
> --- a/src/mesa/vbo/vbo_exec_api.c
> +++ b/src/mesa/vbo/vbo_exec_api.c
> @@ -370,6 +370,8 @@ do {
> \
> if (N>3) dest[3] = V3; \
> } \
> \
> + exec->ctx->Driver.NeedFlush |= FLUSH_STORED_VERTICES; \
> + \
> if ((A) == 0) { \
> GLuint i; \
> \
> @@ -377,7 +379,6 @@ do {
> \
> exec->vtx.buffer_ptr[i] = exec->vtx.vertex[i]; \
> \
> exec->vtx.buffer_ptr += exec->vtx.vertex_size; \
> - exec->ctx->Driver.NeedFlush |= FLUSH_STORED_VERTICES; \
> \
> if (++exec->vtx.vert_count >= exec->vtx.max_vert) \
> vbo_exec_vtx_wrap( exec ); \
>
------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
