Hmm, so if this is driver-specific, what driver interactions are
provoked by adding the FLUSH_CURRENT?
How does your driver know that anything different has happened
with/without this change?
Keith
On Wed, 2009-12-16 at 12:32 -0800, Maarten Maathuis wrote:
> With the help of scons i actually managed to build a softpipe and came
> to the conclusion this is working fine too. This is really odd.
>
> Maarten.
>
> On Wed, Dec 16, 2009 at 8:01 PM, Maarten Maathuis <madman2...@gmail.com>
> wrote:
> > did a realclean and got softpipe to build, but it still doesn't work.
> >
> > warzone2100: swrast/s_span.c:1477: _swrast_write_rgba_span: Assertion
> > `rb->_BaseFormat == 0x1908 || rb->_BaseFormat == 0x1907' failed.
> >
> > On Wed, Dec 16, 2009 at 7:20 PM, Maarten Maathuis <madman2...@gmail.com>
> > wrote:
> >> On Sat, Dec 12, 2009 at 11:21 PM, Maarten Maathuis <madman2...@gmail.com>
> >> wrote:
> >>> 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 ); \
> >>>>
> >>>
> >>
> >> Any ideas? This time mesa with only softpipe doesn't even build (what
> >> do you use to build softpipe?):
> >>
> >> gcc -I../../include -g -O2 -Wall -Wmissing-prototypes -std=c99
> >> -ffast-math -fno-strict-aliasing -g -fPIC -D_GNU_SOURCE -DPTHREADS
> >> -DDEBUG -DHAVE_POSIX_MEMALIGN -DUSE_XSHM arbfplight.c readtex.o
> >> -L../../lib -lglut -lGLEW -lGLU -lGL -lm -o arbfplight
> >> ../../lib/libGL.so: undefined reference to `gl_dispatch_stub_361'
> >> ../../lib/libGL.so: undefined reference to `gl_dispatch_stub_356'
> >> ../../lib/libGL.so: undefined reference to `gl_dispatch_stub_366'
> >> ../../lib/libGL.so: undefined reference to `glDeleteTexturesEXT'
> >> ../../lib/libGL.so: undefined reference to `glGetColorTableParameterfvEXT'
> >> ../../lib/libGL.so: undefined reference to `gl_dispatch_stub_362'
> >> ../../lib/libGL.so: undefined reference to `gl_dispatch_stub_357'
> >> ../../lib/libGL.so: undefined reference to `glGenTexturesEXT'
> >> ../../lib/libGL.so: undefined reference to `gl_dispatch_stub_363'
> >> ../../lib/libGL.so: undefined reference to `gl_dispatch_stub_358'
> >> ../../lib/libGL.so: undefined reference to `gl_dispatch_stub_364'
> >> ../../lib/libGL.so: undefined reference to `glIsTextureEXT'
> >> ../../lib/libGL.so: undefined reference to `gl_dispatch_stub_359'
> >> ../../lib/libGL.so: undefined reference to `glAreTexturesResidentEXT'
> >> ../../lib/libGL.so: undefined reference to `gl_dispatch_stub_365'
> >> ../../lib/libGL.so: undefined reference to `glGetColorTableEXT'
> >> ../../lib/libGL.so: undefined reference to `glGetColorTableParameterivEXT'
> >>
> >
------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
