Hi Marcus, > Andreas Zieringer wrote: >> Hi Marcus, >> >> >>> Hi, >>> >>> I noticed a while ago that 1.8 has VBO's. This is nice. :) >>> >>> However, since it always creates STATIC_DRAW buffers, it's not very >>> efficient if one has dynamic geometry. From what I gather, the buffers >>> are even deleted/created every time. This isn't really optimal. The >>> current VBO impl looks a bit 'quick' as well (a global VBO list?), so it >>> might be more thoroughly implemented in 2.0? >>> >> yes it is just a replacement for display lists, doing it right would be >> quite complicated for 1.x. >> >> VBO's are quite nice even if you use them only for static stuff. >> >> - saves plenty of main memory (only with the new nvidia 97.x drivers) >> > Can you use the 8800 driver with earlier cards? I haven't tested yet. > For regular cards, there is only the 93.71 driver on their site. I > should try this, as I have some strange performance problems. If they've > worked on VBO's that might fix a lot of issues here. Very interesting!
Yes works fine with older cards just download a hacked driver from http://www.laptopvideo2go.com/index.php?drivers >> - the creation of vbo's is much faster (about 6 times) >> - rendering is faster if you use triangle lists with cache optimized >> indices. >> > My main gripe is that if I update geometry dynamically, I do not want > VBO's as STATIC (I'd rather not have them then). I have both static and > dynamic geometry and want the static using VBO's and the old ones not > using VBO's (or with dynamic/stream flag). >>> To fix the current situation (we have a performance problem in >>> updateVBO), I was thinking that you should simply not use VBO's if >>> dlistcache is false. I can make a patch for that. :) >>> >> Hmm I don't get this one. If you enable vbo's you always render with >> vbo's the dlistcache flag doesn't matter. >> With vbo's disabled it behaves like before when the dlistcache is false >> everything is rendered in immediate mode. >> > Yup. And since static vbo's is almost as bad as displaylists with > dynamic geometry, I would think you could use the same flag to adjust > the VBO behaviour. >>> Of course, it would be better to: >>> * Use DYNAMIC-/STREAM_DRAW if dlist-cache is set to false (and perhaps >>> rename it to a static/dynamic flag to make it more clear?) >>> >> the dlistcache flag has nothing to do with dynamic static whatever it >> just enables or disables display lists rendering, of course for vertex >> animations you should disable it. >> > Do'h. I totally missed the vbo-flag in GeometryBase! That's why I had > the gripe about vbo being on all the tie. > > So, currently I would have to set both dlistcache(false) and vbo(false) > for dynamic geometry. yes. >> I was thinking about adding a vbo mode to change the STREAM_DRAW stuff. >> > I was thinking that the dlistcache flag was a dynamic/static geometry > flag instead, then OpenSG would either use static VBO's or display-lists > for static geometry, and not display lists or dynamic VBO's for dynamic > geometry (by passsing the dynamic/static flag to GeoVBO::update). Sounds > like an easy backwards compatible fix to me, what do you think? sure that's possible but not very transparent. Right now you have to manipulate the vbo flag to get vbo rendering. There are also some more vbo modes so I think it is better to add a extra vbo mode field. I will try do add support for the dynamic stuff into 1.8.1. > Disabling VBO's altogether is more easily done with > Window::ignoreExtension(). I can't really think why I would want to > disable it per object, unless it was very small (<50 verts perhaps) & > dynamic. hmm diabling it like this could lead to problems as the dlistcache flag is not checked in the handleGL method. >>> * Not recreate buffers unless the size/type has changed. >>> >> yeah that would be nice. It is just a bit tricky to detect it. >> > You can query the existing buffer size, wouldn't that help? Use > mapbuffer if it's the same and just memcpy it there (or buffersubdata). yes good idea that could work. > Also, I saw the comment about memleak with buffersubdata. Is it a > ever-increasing leak or just a temporary leak. If the latter, could it > be due to gl-pipelining (GL renders using the previous data so it > buffers your upload until finished and then deallocates the old.) > > Also, have you tried using mapbuffer? (I would think it could be > similar, that you are given a new area to write to because the old one > is in use) I think the problem was it used used some main memory where it shouldn't not sure. Andreas >>> Patching for that would take more time, and might not be worth it if 2.0 >>> is doing it better? >>> >> I think in 2.0 it's completely different but better ask Dirk he >> implemented it. > Righto. Dirk? :) > > Cheers, > /Marcus > > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Opensg-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/opensg-users > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
