On 17 Oct 2004, at 10:15, Erik Hofman wrote:
Before other people think "WOW, FG could run 60% faster!!!", please keep in
mind that an application like FG can't do everything just by using VBOs and DLists.
For what it's worth, experts keep telling me the display lists are always faster than VBO's anyhow. The advantage of VBO's comes when you want to use non-static data like morphing.
That and the fact that all drivers seem to support display lists at the moment make me believe we should stick to display lists a little longer.
That sounds totally incorrect as I understand it. VBOs are essentially the same ideas as vertex arrays, but with more control over which memory they are located in (system, AGP or GPU) and with how they will be updated. They can be used for 'streamed' vertex data such as skeletal animation and morphing (by specifying that they should not be GPU resident) but for FG the benefit (which should be large) would come from placing each tile (or other large data set) and mesh onto the GPU as a fixed, resident VBO.
The win comes from avoiding the transfer of static vertex data over the AGP bus each frame, and since flight simulators have almost zero per-frame mesh data (apart from maybe smoke, moving water and clouds) this should give a large win on systems which are bandwidth limited (it won't help the fill-rate limited systems, of course). Also, the drivers should optimise GPU-resident VBOs memory layout, which again will give a substantial win.
Display lists are a more general solution, but mostly save the function call and marshalling overhead into the driver, as I understand it - they can't achieve the specific optimisation that VBOs can, because arrays are explicitly a client-side feature in GL.
The more modern scene graphs such as Ogre and OSG usually have an API where the client software fills a big memory buffer with the vertex data, and they pick the best approach to getting that to the card based on runtime information - VBOs, arrays or whatever. Realistically I think that has to be the long term goal, because the classic OpenGL API is simply too hard to optimise for the massive throughput modern cards are capable of : the cards want to be fed with large blocks of shader and vertex data, then set going.
Given FG's goal of cross-platform support, the obvious (only?) way not to be held back to the original OpenGL 1.1 and 1.2 APIs is using some layer which abstracts this.
H&H
James
--
The lack of planning on your part does not constitute to an emergency on mine
_______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
