Created attachment 91015 [details]
trees are displayed normally in flightgear 2.12.1

trees are displayed normally in flightgear 2.12.1 at startup

Created attachment 91016 [details]
trees disappear in flightgear 2.12.1 after starting the engine

trees disappear in flightgear 2.12.1 after starting the engine or moving the plane or changing the point of view

Can you bisect?

I don't know how to do a bissect, but I will try

I did a bisect with git,

and the culprit seems to be :

59b01ca252bd6706f08cd80a864819d71dfe741c is the first bad commit
commit 59b01ca252bd6706f08cd80a864819d71dfe741c
Author: Fredrik Höglund <fredrik@kde.org>
Date:   Tue Apr 9 20:54:25 2013 +0200

    mesa: Add ARB_vertex_attrib_binding
    
    update_array() and update_array_format() are changed to update the new
    attrib and binding states, and the client arrays become derived state.
    
    Reviewed-by: Eric Anholt <eric@anholt.net>

:040000 040000 e1270491ec1e0f8a98f930a0cf959038a56c4449 d2f6ee337ecbf36f764921474f2c69a67308eafa M      src

you can fin the git log for the bisect in attachment with this message,

the bisect wad doing by setting the first good bissect with the revision 9.2.5 of mesa and the bad bissect with the HEAD revision of mesa mastering ( last revision on git ),

I hope we have enough clues to fix this bug

Created attachment 91114 [details]
git bisect log

the git bisect log,

# first bad commit: [59b01ca252bd6706f08cd80a864819d71dfe741c] mesa: Add ARB_vertex_attrib_binding

does anyone need more informations about this bug ?

because this bug is still here with the new mesa 10.0.2,

I did a bisect, the bug begins with 59b01ca252bd6706f08cd80a864819d71dfe741c commit, I can do another test but I need some help because I'm not a specialist in 3D programming

the problem of missing trees in flightgear is still here in mesa 10.0.3,

but I notice if I type :

"export LIBGL_ALWAYS_SOFTWARE=1" the bug is still here in flightgear, so even with software rendering mode I get the bug,

that means that whatever the graphic card this bug will occur

I believe this is a bug in mesa core, not in a specific driver.

I haven't been able to isolate the code that renders the trees (there are no trees visible anywhere near the airport in the version packaged by debian).

But I have found a number of issues with display lists that affect FlightGear. I have attached patches for those to bug 73504. What they fix specifically is occasional crashes and brief flashes of random geometry. It's possible that the same bugs are also responsible for the missing trees.

If not, can you capture an apitrace that shows the problem?

(In reply to comment #9)
> I believe this is a bug in mesa core, not in a specific driver.
> 
> I haven't been able to isolate the code that renders the trees (there are no
> trees visible anywhere near the airport in the version packaged by debian).
> 

in order to see trees you have to enable "random vegetation" option in "View --> Rendering options",

then at startup you should be able to see some trees around the airport, then you will notice that these trees will randomly disapear when you move the plane or when you change the point of view,

I will try your patches for the bug 73504 and if it is not enough I will record an apitrace

I confirm the bug with mesa master and r600g (AMD CYPRESS).

You can try with this command (on Fedora 19):
/usr/bin/fgfs --fg-root=/usr/share/flightgear --fg-scenery=/usr/share/flightgear/Scenery --airport=KPAO --aircraft=c172p-canvas --enable-random-objects --enable-horizon-effect --enable-enhanced-lighting --enable-ai-models --enable-ai-traffic --disable-real-weather-fetch --enable-clouds3d --geometry=1024x768

Maybe, you should then increase the numbers of trees (set trees density to 10.0 in "View --> Rendering options").

You will see trees in the scene. You then start the engine (stay pushing "S" key) and as soon as the propeller is at full speed (the propeller is differently rendered), the trees will disappears.

They can reappears later during the flight, quite randomly.

I tried the 3 patches from Fredrik Höglund ( bug 73504 ) with the source code of mesa 10.0.3 ( the official source code, not the last git version )

but the bug is still here, the trees are missing when I move the aircraft or when I change the point of view,

I will to try to use apitrace in order to give more clues to Fredrik Höglund,

what we are sure is that a bisect shows that the bug begins with 59b01ca252bd6706f08cd80a864819d71dfe741c commit, and it's a bug in mesa core

here is the apitrace of the bug :

http://demo.ovh.eu/download/4460655c06da77b352f00024805c88ac/fgfs.trace.tar.gz

the bug starts when the engine starts, the trees will disapear

In case it's of any interest, I also see the bug with nouveau/nv50 (nv98 card) by replaying the apitrace -- so yeah, probably a core bug. Or mesa/st.

I tried with flightgear 3.0.0 release candidate,

and the bug is still here, 

I created a bugreport in order to warn the flightgear developpers :

https://code.google.com/p/flightgear-bugs/issues/detail?id=1363

maybe they can find a workaround for flightgear if this bug is difficult to fix in mesa core

Created attachment 93635 [details] [review]
patch

Thanks, but I think I've found the cause of the problem.

Can you confirm that this patch fixes it for you?

(In reply to comment #16)
> Created attachment 93635 [details] [review] [review]
> patch
> 
> Thanks, but I think I've found the cause of the problem.
> 
> Can you confirm that this patch fixes it for you?

FWIW, seems to fix things on nv50 when replaying the trace.

(In reply to comment #16)
> Created attachment 93635 [details] [review] [review]
> patch
> 
> Thanks, but I think I've found the cause of the problem.
> 
> Can you confirm that this patch fixes it for you?

yes your patch solves the bug, thank you very much

(In reply to comment #16)
> Created attachment 93635 [details] [review] [review]
> patch
> 
> Thanks, but I think I've found the cause of the problem.
> 
> Can you confirm that this patch fixes it for you?

Yes it works (r600g).

(In reply to comment #18)
> (In reply to comment #16)
> > Can you confirm that this patch fixes it for you?
> 
> yes your patch solves the bug, thank you very much

No problem - the apitrace helped.

Comment on attachment 93635 [details] [review]
patch

Review of attachment 93635 [details] [review]:
-----------------------------------------------------------------

There are a couple other fields of gl_vertex_array_object that aren't copied in that function... like IndexBufferObj.  I assume that EverBound should be true before and after and Label should also be the same, so those shouldn't need to be copied in or out.

(In reply to comment #21)
> Comment on attachment 93635 [details] [review] [review]
> patch
> 
> Review of attachment 93635 [details] [review] [review]:
> -----------------------------------------------------------------
> 
> There are a couple other fields of gl_vertex_array_object that aren't copied
> in that function... like IndexBufferObj.  I assume that EverBound should be
> true before and after and Label should also be the same, so those shouldn't
> need to be copied in or out.

I noticed that. It looks like IndexBufferObj is handled by the caller because of  differences between Apple and ARB semantics.

Fixed by commit 9afbd04d892f96e7fc6b689ca57ea5da124f7560