Bug 72895 - Missing trees in flightgear 2.12.1 with mesa 10.0.1
Missing trees in flightgear 2.12.1 with mesa 10.0.1
Status: RESOLVED FIXED
Product: Mesa
Classification: Unclassified
Component: Mesa core
unspecified
All Linux (All)
: medium normal
Assigned To: mesa-dev
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-12-20 02:51 UTC by Barto
Modified: 2014-02-12 17:37 UTC (History)
3 users (show)

See Also:


Attachments
glxinfo output (56.84 KB, text/plain)
2013-12-20 02:51 UTC, Barto
Details
trees are displayed normally in flightgear 2.12.1 (118.72 KB, image/jpeg)
2013-12-20 02:52 UTC, Barto
Details
trees disappear in flightgear 2.12.1 after starting the engine (112.23 KB, image/jpeg)
2013-12-20 02:53 UTC, Barto
Details
git bisect log (1.99 KB, text/plain)
2013-12-22 07:39 UTC, Barto
Details
patch (765 bytes, patch)
2014-02-07 22:31 UTC, Fredrik Höglund
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Barto 2013-12-20 02:51:05 UTC
Created attachment 91014 [details]
glxinfo output

I have a radeon HD4650 PCIe running in archlinux 64 bits OS,

I use the r600 driver,

OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD RV730
OpenGL core profile version string: 3.1 (Core Profile) Mesa 10.0.1 ( you can fin full gxinfo output in the attachement with this message )

Since I upgrade to Mesa 10.0.1 I notice missing trees in flightgear 2.12.1,

on startup I can see trees, vegetations, but if I maximize the windows or if I start the engine or move the plane the trees disappear,

it's a weird bug because sometimes the trees appear again when moving the plane or using a different point of view ( tower, outside the plane ), but instantly these trees disappear again when I return in the cockpit of the plane,

see the attachements with this mail ( 2 screenshots, one with the trees displayed, and one when the bug occurs, no trees ),

I think it's a bug from mesa 10.0.1 because with mesa 9.2.5 I don't have this bug
Comment 1 Barto 2013-12-20 02:52:17 UTC
Created attachment 91015 [details]
trees are displayed normally in flightgear 2.12.1

trees are displayed normally in flightgear 2.12.1 at startup
Comment 2 Barto 2013-12-20 02:53:40 UTC
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
Comment 3 Michel Dänzer 2013-12-20 03:03:12 UTC
Can you bisect?
Comment 4 Barto 2013-12-20 03:27:04 UTC
I don't know how to do a bissect, but I will try
Comment 5 Barto 2013-12-22 07:38:07 UTC
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
Comment 6 Barto 2013-12-22 07:39:11 UTC
Created attachment 91114 [details]
git bisect log

the git bisect log,

# first bad commit: [59b01ca252bd6706f08cd80a864819d71dfe741c] mesa: Add ARB_vertex_attrib_binding
Comment 7 Barto 2014-01-13 14:46:37 UTC
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
Comment 8 Barto 2014-02-04 21:41:41 UTC
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
Comment 9 Fredrik Höglund 2014-02-04 23:01:25 UTC
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?
Comment 10 Barto 2014-02-04 23:17:27 UTC
(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
Comment 11 Benjamin Bellec 2014-02-05 19:59:19 UTC
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.
Comment 12 Barto 2014-02-07 02:08:56 UTC
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
Comment 13 Barto 2014-02-07 04:05:28 UTC
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
Comment 14 Ilia Mirkin 2014-02-07 04:34:30 UTC
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.
Comment 15 Barto 2014-02-07 21:00:20 UTC
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
Comment 16 Fredrik Höglund 2014-02-07 22:31:21 UTC
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?
Comment 17 Ilia Mirkin 2014-02-07 22:46:13 UTC
(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.
Comment 18 Barto 2014-02-07 23:18:35 UTC
(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
Comment 19 Benjamin Bellec 2014-02-07 23:35:53 UTC
(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).
Comment 20 Fredrik Höglund 2014-02-07 23:38:08 UTC
(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 21 Ian Romanick 2014-02-07 23:38:50 UTC
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.
Comment 22 Fredrik Höglund 2014-02-07 23:58:59 UTC
(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.
Comment 23 Fredrik Höglund 2014-02-12 17:37:18 UTC
Fixed by commit 9afbd04d892f96e7fc6b689ca57ea5da124f7560