Hi Johannes, I'm curious what drivers and hardware did you come across the issues?
Robert. On Fri, Nov 26, 2010 at 1:23 PM, Johannes Bäuerle <[email protected]> wrote: > Hi, > > I found a runtime failure related to vertex buffer objects. While creating a > VBO, the call glBufferSubData crashed with the return value GL_INVALID_VALUE. > glBufferSubData is only used if a VBO contains more than one array, else > glBufferData data can directly be used. In the given case the vbo contains > two arrays of the type GL_ELEMENT_ARRAY_BUFFER. The arrays have two different > data types GL_UNSIGNED_INT/GL_UNSIGNED_SHORT. > > The used target hardware requires VBOs to have offsets and sizes which are > multiples of 4 byte. If the element array with data type > GL_UNSIGNED_SHORT(2byte) contains an odd number of elements the length is no > multiple of 4 bytes. As result the glBufferSubData call returns the > GL_INVALID_VALUE error. This ends up in weird output as the state after the > error is undefined.Usually random data from memory will be used to draw the > geometry. When disabling VBO's the error does not occur. > > I tried to fix the error by ensuring that arrays loaded into VBOs always have > a length which is a multiple of n bytes. n is the size in bytes to which the > platform aligns offsets in memory calls or data sizes of the > glBuffer[Sub]Data call. If an array does not match the requirement, the size > is modified to the next boundary satisfying the platform's requirement. This > has the same effect as adding padding bytes. As the element array data > references vertices by index no invalid data will be called as following > DrawArray calls store the size of the element array by themselves and > therefore only call the valid areas. The fix only tries to satisfy the > requirement that the size must be a multiple of n. > > As different platforms may have different requirements I created a > #ifdefwhich controls the size. The value for the #ifdef is set by an option > of the cmake build environment, OSG_BUFFER_ALIGNMENT, which is a string > containing the number of bytes to align vbo's to . That way the definition > can be passed per platform/build. Per default (value '1') this modification > is disabled, as it would not have any effects. Usual case, if the feature is > enabled, will be the boundary of 4 byte. > > The fix only requires a minor change in the BufferObject.cpp source file and > a small change in the top level cmake file. As the default behavior is to > disable the feature it won't break existing builds. > > I have built the osg in a linux desktop gl2 configuration with disabled > fixed-funtion-pipeline features. > > Has anyone had similir behavior of VBO's, or is there a better location to > fix this issue? > > Thank you! > > Cheers, > Johannes > > ------------------ > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=34126#34126 > > > > > Attachments: > http://forum.openscenegraph.org//files/osg_616.zip > > > _______________________________________________ > osg-submissions mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
