Page 2 of 2 FirstFirst 12
Results 11 to 13 of 13

Thread: Easy Mesa Projects To Start Working On GPU Drivers

  1. #11
    Join Date
    Jan 2011
    Posts
    1,287

    Default

    Quote Originally Posted by siavashserver View Post
    From source code we have:

    Code:
    /**
     * Allocate space for and store data in a buffer object.  Any data that was
     * previously stored in the buffer object is lost.  If \c data is \c NULL,
     * memory will be allocated, but no copy will occur.
     *
     * This is the default callback for \c dd_function_table::BufferData()
     * Note that all GL error checking will have been done already.
     *
     * \param ctx     GL context.
     * \param target  Buffer object target on which to operate.
     * \param size    Size, in bytes, of the new data store.
     * \param data    Pointer to the data to store in the buffer object.  This
     *                pointer may be \c NULL.
     * \param usage   Hints about how the data will be used.
     * \param bufObj  Object to be used.
     *
     * \return GL_TRUE for success, GL_FALSE for failure
     * \sa glBufferDataARB, dd_function_table::BufferData.
     */
    static GLboolean
    _mesa_buffer_data( struct gl_context *ctx, GLenum target, GLsizeiptrARB size,
    		   const GLvoid * data, GLenum usage,
    		   struct gl_buffer_object * bufObj )
    So what is glBufferData supposed to do in plain English? Well that's going to feed the binded (currently active) OpenGL buffer with data residing in memory (CPU side) which can be geometry attributes like vertex positions, normals, tangents, indices, bone weights (used for skinning) or whatever user (graphics/game programmer) wants and uploads them to GPU memory. Now everytime that user wants to draw something, he just binds those buffers which already resides in GPU memory again and kindly asks her to render them.

    Take a look at here for glBufferData definition: http://www.khronos.org/opengles/sdk/...BufferData.xml
    Thanks for the pointers. I read the source code after commenting. According to that definition, I think it would be proper to just use FREE(), as it says it discards the old data. A realloc would probably incur in an unneeded copy. At least that's how the traditional realloc works, I ignore how mesa_realloc works, but I assume they chose to name it realloc because it works like realloc. In that case, either the documentation is wrong for data == NULL (as it wouldn't copy anything and the original data will still be there) or realloc shouldn't be used, as it contradicts the documentation in this case.

  2. #12
    Join Date
    Oct 2013
    Posts
    198

    Default

    Quote Originally Posted by mrugiero View Post
    Thanks for the pointers. I read the source code after commenting. According to that definition, I think it would be proper to just use FREE(), as it says it discards the old data. A realloc would probably incur in an unneeded copy. At least that's how the traditional realloc works, I ignore how mesa_realloc works, but I assume they chose to name it realloc because it works like realloc. In that case, either the documentation is wrong for data == NULL (as it wouldn't copy anything and the original data will still be there) or realloc shouldn't be used, as it contradicts the documentation in this case.
    Yes, you are absolutely right. Realloc's extra memcpy is unnecessary, whether data being NULL or not. And it's safe to free bufObj->Data in both cases. According to the specification:

    Quote Originally Posted by man glBufferData
    glBufferData creates a new data store for the buffer object currently bound to target. Any pre-existing data store is deleted. The new data store is created with the specified size in bytes and usage.
    Quote Originally Posted by man glBufferData
    If data is NULL, a data store of the specified size is still created, but its contents remain uninitialized and thus undefined.

    I'll send a new patch to fix this issue. Thank you all for the tips!

  3. #13
    Join Date
    Jan 2011
    Posts
    1,287

    Default

    Quote Originally Posted by siavashserver View Post
    Realloc's extra memcpy is unnecessary, whether data being NULL or not.
    About this part, my comment about it being NULL was only about the original data being there. If it is not NULL, then the new data will overwrite the original when the copy happens. As there is no copy if it is NULL, you will still have the original contents in the new data member.

    I'll send a new patch to fix this issue. Thank you all for the tips!
    Your welcome
    Thanks for contributing.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •