Re: [osg-users] [build] How to properly use the OSG_GL3_AVAILABLE CMake option?
Hi, I eventually abandoned my tries to use GL3. As I stated before, at the time I tried to use it (under Windows) my conclusion was that the file osg/GL needs some fixing to work under Windows. I don't know what the state is now (I was using 2.9.9). Cheers, Florian -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34104#34104 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] How to properly use the OSG_GL3_AVAILABLE CMake option?
Hi, I am having exactly the same issues, please could you post your suggestion how to fix this ? Thank you! Cheers, ParticlePeter -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34103#34103 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] How to properly use the OSG_GL3_AVAILABLE CMake option?
Hi, I am getting compile errors with VS 2008, e.g. a define min conflicts with the line: Code: if (fabs(length2) = std::numeric_limitsdouble::min()) in Matrix_implemenation.cpp. The define comes from Windows SDK 7.1 WinDef.h that looks like this: Code: #ifndef NOMINMAX #ifndef max #define max(a,b)(((a) (b)) ? (a) : (b)) #endif #ifndef min #define min(a,b)(((a) (b)) ? (a) : (b)) #endif #endif /* NOMINMAX */ Anyone facing the same issues? I read CMake: Code: # Both Cygwin and Msys need -DNOMINMAX ??? IF(UNIX) ADD_DEFINITIONS(-DNOMINMAX) ENDIF(UNIX) And then again I read gl3.h: Code: #if defined(_WIN32) !defined(APIENTRY) !defined(__CYGWIN__) !defined(__SCITECH_SNAP__) #define WIN32_LEAN_AND_MEAN 1 #include windows.h #endif File GL reads: Code: #elif defined(OSG_GL3_AVAILABLE) #define GL3_PROTOTYPES 1 #include GL3/gl3.h #ifndef GL_APIENTRY #define GL_APIENTRY APIENTRY #endif // GL_APIENTRY #else Do I conclude correctly, that Windows also needs global define NOMINMAX because gl3.h includes windows.h without the define? Alternatively file GL should define NOMINMAX before include gl3.h? Cheers, Florian -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=32084#32084 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] How to properly use the OSG_GL3_AVAILABLE CMake option?
Hi, I just figured there's more problems because of gl3.h including windows.h, well at least the one I am trying to use, which is http://www.opengl.org/registry/api/gl3.h It includes windows.h if APIENTRY is not defined. The relevant portion of (my) gl3.h reads: Code: #if defined(_WIN32) !defined(APIENTRY) !defined(__CYGWIN__) !defined(__SCITECH_SNAP__) #define WIN32_LEAN_AND_MEAN 1 #include windows.h #endif The inlcude file osg/GL has similar hacks before including gl.h (which apparently does not include windows.h by itself). But I believe we are missing these hacks before including gl3.h ? Looks like that (under Windows) we need to make sure APIENTRY is defined also before including gl3.h ? If anyone can confirm that, I could submit an appropriate osg/GL Cheers, Florian -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=32099#32099 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] How to properly use the OSG_GL3_AVAILABLE CMake option?
Hi Peter, As Paul mentions, as you've found out the hard way, right now you have to set the flags all manually to disable/enable the appropriate parts of the OSG to build against the different GL targets. My plan has been to test out the ports as flexible as possible - trying out GLES paths on standard GL for instance, and this phase of development is now near completion as the ports are now near complete. Then in the completion phase move generating all the settings for each for the targets automatically - i.e. the default selection of options is done by Cmake for you once you decide which GL target you want to use. This week I should be able to get to tackling these CMake changes, and they should make it in for the next 2.9.7 dev release. Cheers, Robert. On Sat, Dec 12, 2009 at 10:45 PM, Peter Bear th3fly...@gmail.com wrote: Just for the search function :) If you get errors like this: error C2039: 'glBegin' : is not a member of '`global namespace'' error C3861: 'glBegin': identifier not found error C2039: 'glEnd' : is not a member of '`global namespace'' error C3861: 'glEnd': identifier not found turn off everything but GL3 with the gl available options to fix it. Cheers, Peter -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=21376#21376 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] How to properly use the OSG_GL3_AVAILABLE CMake option?
Paul Martz wrote: I believe this is already in a post somewhere, so the search function should be covered. :-) It'd be nice if selecting the OSG_GL3_AVAILABLE CMake variable would automatically re-set all the FFP-type variables, but currently it does not do so, and you have to do this manually. Paul Martz Skew Matrix Software LLC _http://www.skew-matrix.com_ http://www.skew-matrix.com/ +1 303 859 9466 Peter Bear wrote: Just for the search function :) If you get errors like this: error C2039: 'glBegin' : is not a member of '`global namespace'' error C3861: 'glBegin': identifier not found error C2039: 'glEnd' : is not a member of '`global namespace'' error C3861: 'glEnd': identifier not found turn off everything but GL3 with the gl available options to fix it. Cheers, Peter -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=21376#21376 ___ osg-users mailing list http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Post generated by Mail2Forum I did it to specifically cover searching up the error codes :) -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=21450#21450 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] How to properly use the OSG_GL3_AVAILABLE CMake option?
Just for the search function :) If you get errors like this: error C2039: 'glBegin' : is not a member of '`global namespace'' error C3861: 'glBegin': identifier not found error C2039: 'glEnd' : is not a member of '`global namespace'' error C3861: 'glEnd': identifier not found turn off everything but GL3 with the gl available options to fix it. Cheers, Peter -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=21376#21376 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] How to properly use the OSG_GL3_AVAILABLE CMake option?
I believe this is already in a post somewhere, so the search function should be covered. :-) It'd be nice if selecting the OSG_GL3_AVAILABLE CMake variable would automatically re-set all the FFP-type variables, but currently it does not do so, and you have to do this manually. Paul Martz Skew Matrix Software LLC _http://www.skew-matrix.com_ http://www.skew-matrix.com/ +1 303 859 9466 Peter Bear wrote: Just for the search function :) If you get errors like this: error C2039: 'glBegin' : is not a member of '`global namespace'' error C3861: 'glBegin': identifier not found error C2039: 'glEnd' : is not a member of '`global namespace'' error C3861: 'glEnd': identifier not found turn off everything but GL3 with the gl available options to fix it. Cheers, Peter -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=21376#21376 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] How to properly use the OSG_GL3_AVAILABLE CMake option?
Hi John, On Fri, Nov 27, 2009 at 3:21 AM, John Price john.pric...@gmail.com wrote: My understanding of the way bindness graphics actually achieves its speedup is by not requiring CPU dereferencing of graphic object pointers and the likely L2 cache misses this causes. NVidia bindless graphics extension is about reducing the CPU overhead in draw dispatch, but... for the majority of modern graphics applications draw dispatch isn't the bottleneck, so it'll only help the minority of graphics apps that draw dispatch is a bottleneck. Again, I'd ask yourself am is draw dispatch likely to be a bottleneck in my app? Likely cases of draw dispatch limited app is when you have many thousands of separate geometries and state in screen on each frame. Even without the bindless graphics extension you can address this bottleneck with a more balanced scene graph layout - i.e. make it more coarse grained, by clumping geometry and state together. If you can't address the draw bottleneck with a more efficient scene graph then implementation the bindless graphics extension will be important, if not then there is sure plenty of other things that you can invest your time in to get better peformance. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] How to properly use the OSG_GL3_AVAILABLE CMake option?
Hi John, On Wed, Nov 25, 2009 at 9:02 PM, John Price john.pric...@gmail.com wrote: My project is still in development and has a long term objective. My view is forward looking, so I am interested in embracing gl3 as development progresses. I am primarily developing for nVidia hardware, and am particularly interested in nVidia extensions to gl3 that they refer to as Bindness Graphics. nVidia states: Bindless Graphics refers to changes to OpenGL that can enable close to an order of magnitude improvement in the CPU-limitedness of graphics applications. Bindless Graphics has the following desirable properties: • The driver need not dereference a vertex buffer or constant buffer on the CPU in order for the GPU to use it. • Relieves the limits on how many buffer objects can be accessed at once by shaders • Buffer objects are accessed as C-style pointer dereferences in the shading language • Allows for dependent pointer fetches, enabling more complex scene graph structures to be built into buffer objects providing significant new flexibility in the use of shaders. Measurements have shown that bindless graphics can result in more than 7x speedup! I'm pretty curious about the bindless graphics extension, it would be great to reduce the CPU overhead of making lots of fine grained OpenGL calls. The 7x speed up is very very unlikely to be something you'll see though, my guess is that they probably had to really squeeze out a contrived example to produce that type of bottleneck with the old calls, with real world usage the speed up will far less and often will result in no speed up at all as the bottleneck is more often fill rate rather getting data to the GPU. For you own app I'd aks the simple question - is your bottleneck draw dispatch, if not then bindless graphics won't make any difference for you. Bindless graphics will complicate trying to manage code that works on both bindless and non bindless as the extensions not only affect the the GL calls doing dispatch of the data but also shaders, so you'd need to keep multiple sets of shaders to handle the different hardware/driver capabilities. So I'm keen to see bindless graphics make it's way into the OSG to help reduce the draw dispatch overhead, more important for GL3 now that display lists are no longer supported, but we should be realistic about the potential benefits/pitfalls. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] How to properly use the OSG_GL3_AVAILABLE CMake option?
Hi Robert,
My understanding of the way bindness graphics actually achieves its speedup is
by not requiring CPU dereferencing of graphic object pointers and the likely L2
cache misses this causes.
nVidia states:
OpenGL has evolved in a way that allows applications to replace many of the
original state machine variables with blocks of user-defined data. For example,
the current vertex state has been augmented by vertex buffer objects,
fixed-function shading state and parameters have been replaced by
shaders/programs and constant buffers, etc.. Applications switch between coarse
sets of state by binding objects to the context or to other container objects
(e.g. vertex array objects) instead of manipulating state variables of the
context. In terms of the number of GL commands required to draw an object, this
enables applications to be an order of magnitude more efficient. However, this
explosion of objects bound to other objects has led to a new bottleneck -
pointer chasing and CPU L2 cache misses in the driver, and general L2 cache
pollution.
Recent OpenGL graphics applications tend to change state at roughly these
frequencies:
for (...) { // cold
data downloads, render target changes, etc.
for (...) { // warm
bind textures
for (...) { // hot
bind constants
bind vertex buffers
Draw();
}
}
}
The most frequent state changes are binding vertex buffer objects (every draw),
followed closely by binding constant buffers. Vertex buffer and constant buffer
binds are significantly more expensive than one might expect. These binds
require several reads from the driver internal object data structure to
accomplish what the driver actually needs to do. In an OpenGL driver, it looks
like this:
name-obj (lookup object by name)
obj-{refcount, GPU address, state, etc.} (dereference object to reference
count it, to get its GPU virtual address, and validate its state).
Each of these dereferences has a high probability of causing a CPU L2 cache
miss due to the inherently LRU-eviction-unfriendly nature of graphics
applications (each frame starts over at the beginning). These L2 cache misses
are a huge bottleneck in modern drivers, and a penalty paid for every frame
rendered.
End nVidia states.
I think these extensions address new bottlenecks created by the switch to gl3
style vertex and constant buffers, shaders for everything, etc. It seems to be
a graphic driver bottleneck, not a scenegraph problem. But what nVidia is doing
is admitting the problem and is trying to provide OpenGL users a way to take
advantage of an optimization technique.
The OpenGL extensions are GL_NV_shader_buffer_load and
GL_NV_vertex_buffer_unified_memory.
I am not competent enough with gl3 yet to begin to implement these in code, but
it seems it may be worth doing that at some point. I like to add quality in
things I pursue. As I progress, I will keep in touch. For now I am a toddler.
Thank you!
Cheers,
John
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=20462#20462
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] How to properly use the OSG_GL3_AVAILABLE CMake option?
Hi Robert and Paul, Thank you both for your replies. Your answers affirmed my own investigations into gl3. For Paul - my OSG project is being developed for Win32 x64. I have just moved it to Windows 7 x64. It is tied to Windows because it is designed to work in concert with other Windows commercial apps that will probably never be ported to Linux. My project is still in development and has a long term objective. My view is forward looking, so I am interested in embracing gl3 as development progresses. I am primarily developing for nVidia hardware, and am particularly interested in nVidia extensions to gl3 that they refer to as Bindness Graphics. nVidia states: Bindless Graphics refers to changes to OpenGL that can enable close to an order of magnitude improvement in the CPU-limitedness of graphics applications. Bindless Graphics has the following desirable properties: • The driver need not dereference a vertex buffer or constant buffer on the CPU in order for the GPU to use it. • Relieves the limits on how many buffer objects can be accessed at once by shaders • Buffer objects are accessed as C-style pointer dereferences in the shading language • Allows for dependent pointer fetches, enabling more complex scene graph structures to be built into buffer objects providing significant new flexibility in the use of shaders. Measurements have shown that bindless graphics can result in more than 7x speedup! Unfortunately the nVidia OpenGL SDK which usually provides code examples seems to be stuck at this time at the GeForce 8 gl2.1 level. Hopefully this will be updated sometime in the future. As it seems that I am at about the same juncture as everyone else with respect to gl3, I don't feel so alone or incompetent as I did when I first began asking questions. I plan to take Paul's advice and begin writing gl3 code. If I come up with anything useful I will gladly contribute it with a submission. I have found that the Red Book 7th Edition covers gl3 and gl3.1. I also found the book Beginning OpenGL Game Programming 2nd Edition by Luke Benstead has been updated to gl3. I have just ordered it, but don't have it yet. Thank you! Cheers, John -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=20392#20392 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] How to properly use the OSG_GL3_AVAILABLE CMake option?
Hi John, I haven't tried GL3 yet - this work was done by Paul Martz, but I did the GLES work which served as ground work for the GL3 support so I'll have bash at an answer: On Mon, Nov 23, 2009 at 10:58 PM, John Price john.pric...@gmail.com wrote: My nVidia graphics driver supports GL 3.2. So I enabled OSG_GL3_AVAILABLE and got hundreds of errors about gl3.h. I downloaded gl3.h from OpenGL.org and placed it where it would be found, and got hundreds of new errors. I know I am doing something wrong and was wondering if someone would be kind enough to provide a quick tutorial. I don't need complete newbie instructions, just the necessary steps to compile OSG with gl3. My guess is the the GL compile errors are down to you not disabling the the build of the GL1/GL2 features at the same time as enable the GL3 build as the GL3 header doesn't contain these features. Using ccmake/CMakeStup you can adjust the following entries (mostly setting them all to OFF) : OSG_GLU_AVAILABLE OFF OSG_GL1_AVAILABLE OFF OSG_GL2_AVAILABLE OFF OSG_GL3_AVAILABLE ON OSG_GLES1_AVAILABLE OFF OSG_GLES2_AVAILABLE OFF OSG_GL_DISPLAYLISTS_AVAILABLE OFF OSG_GL_MATRICES_AVAILABLE OFF OSG_GL_VERTEX_FUNCS_AVAILABLE OFF OSG_GL_VERTEX_ARRAY_FUNCS_AVAILABLE OFF OSG_GL_FIXED_FUNCTION_AVAILABLE OFF This is obviously a bit of pain right now, but my plan is to do some further work on the CMake scripts to set all this automatically depending upon your GL target. I haven't tackled this up to now as getting the code base portable across all these targets has been my priority. FYI, you can actually simulate what it's like just having GL3.2 or GLES 2 by disabling these features even when building against GL2. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] How to properly use the OSG_GL3_AVAILABLE CMake option?
Hi Robert, Thank you again for taking the time to reply. Your assumptions were correct, I had not turned off the other GL options. I am planning to play with gl3 a little, there must be some advantages to using it. But it also seems at first glance that one might be giving up some optimizations in OSG by not using gl1 and gl2. I am curious if it might be useful to create a gl3 compatibility context to take advantage of existing optimizations. I have to admit that I have found only bits and pieces of useful information on gl3 even though it appears to be at rev. 3.2. My assumptions about a compatibility context could be completely off. If you or Paul Martz have found a source of useful information about gl3 I would be very appreciative if you could share it with me and the OSG community. In the mean time I will begin the learning curve by doing. Thank you! Cheers, John -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=20282#20282 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [build] How to properly use the OSG_GL3_AVAILABLE CMake option?
Hi, My nVidia graphics driver supports GL 3.2. So I enabled OSG_GL3_AVAILABLE and got hundreds of errors about gl3.h. I downloaded gl3.h from OpenGL.org and placed it where it would be found, and got hundreds of new errors. I know I am doing something wrong and was wondering if someone would be kind enough to provide a quick tutorial. I don't need complete newbie instructions, just the necessary steps to compile OSG with gl3. Thank you! Cheers, John -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=20193#20193 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
