Announcement

Collapse
No announcement yet.

Easy Mesa Projects To Start Working On GPU Drivers

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Easy Mesa Projects To Start Working On GPU Drivers

    Phoronix: Easy Mesa Projects To Start Working On GPU Drivers

    For those Linux users with C/C++ development experience that have been wanting to get involved with working on the open-source Mesa 3D/OpenGL drivers, a new Wiki page has been setup that outlines -- almost step-by-step -- some easy projects to get started on for adding new OpenGL features to Mesa...

    http://www.phoronix.com/vr.php?view=MTUyNDY

  • #2
    Very useful.
    Documentation about how features where implemented could be added to help newbies.
    It tells them how stuff are being done and gives a good example to get some information about the problems encountered.

    Comment


    • #3
      Thank you very much Michael for covering this on front page! Hopefully this will help main developers to focus on delivering key features and attracting more people.


      Originally posted by plonoma View Post
      Very useful.
      Documentation about how features where implemented could be added to help newbies.
      It tells them how stuff are being done and gives a good example to get some information about the problems encountered.
      First project was fairly easy and it was mostly a matter of looking up function definitions and replacing them

      Comment


      • #4
        Originally posted by siavashserver View Post
        First project was fairly easy and it was mostly a matter of looking up function definitions and replacing them
        Programming Mantra: If it seems easy, you have not yet understood the problem :-)


        Since I'm not subscribed to mesa-dev, I'll post here:
        11/17:
        Code:
        -   new_data = _mesa_realloc( bufObj->Data, bufObj->Size, size );
        +   new_data = _mesa_align_malloc( size, ctx->Const.MinMapBufferAlignment );
        malloc and realloc do entirely different things. I don't think this change is correct.


        Thanks for your work!

        Comment


        • #5
          Originally posted by rohcQaH View Post
          Programming Mantra: If it seems easy, you have not yet understood the problem :-)


          Since I'm not subscribed to mesa-dev, I'll post here:
          11/17:
          Code:
          -   new_data = _mesa_realloc( bufObj->Data, bufObj->Size, size );
          +   new_data = _mesa_align_malloc( size, ctx->Const.MinMapBufferAlignment );
          malloc and realloc do entirely different things. I don't think this change is correct.


          Thanks for your work!
          Actually, that change seems to be correct, as the guidelines for the project say whoever wrote it believes it shouldn't be using realloc

          Comment


          • #6
            Originally posted by mrugiero View Post
            Actually, that change seems to be correct, as the guidelines for the project say whoever wrote it believes it shouldn't be using realloc
            But as I replied on the list, we have the potential for a memory leak here. It's possible that the ->Data pointer is always null at the beginning of this function, but if it's not, we've just allocated memory that we'll never free.

            Comment


            • #7
              Originally posted by Veerappan View Post
              But as I replied on the list, we have the potential for a memory leak here. It's possible that the ->Data pointer is always null at the beginning of this function, but if it's not, we've just allocated memory that we'll never free.
              Then maybe it should be asserted that it is null at the beginning? I don't know, I'm only saying what it reads from the NewbieProjects page. I didn't really look into it. While I do know the difference between malloc and similar functions and realloc, I do not know what mesa_buffer_data is supposed to do.

              Comment


              • #8
                Originally posted by mrugiero View Post
                Then maybe it should be asserted that it is null at the beginning? I don't know, I'm only saying what it reads from the NewbieProjects page. I didn't really look into it.
                Either an assert, an unconditional FREE(bufObj->Data) [FREE() is safe if the pointer you feed it is null], a check for a non-null value so we can free it, or we just verify that realloc was always wrong and this can never be called with a non-null Data pointer.

                Originally posted by mrugiero View Post
                While I do know the difference between malloc and similar functions and realloc, I do not know what mesa_buffer_data is supposed to do.
                You and me both.

                I haven't dug up the surrounding code, I've just gone through the patch contents themselves so far. The only other one that looks odd is that the ILO driver sets its minimum alignment to 4k, as opposed to all other drivers which look like they align to 64-byte boundaries. Maybe that's a requirement of ILO, but it seems odd that only this driver has that requirement... but I haven't checked if i965 classic uses this same alignment requirement.

                Comment


                • #9
                  Originally posted by Veerappan View Post
                  The only other one that looks odd is that the ILO driver sets its minimum alignment to 4k, as opposed to all other drivers which look like they align to 64-byte boundaries. Maybe that's a requirement of ILO, but it seems odd that only this driver has that requirement... but I haven't checked if i965 classic uses this same alignment requirement.
                  According to the NewbieProjects page, that's because the ILO driver calls intel_winsys_alloc_buffer for allocation, and it always gets page-aligned allocation. So the 4096 number is because it is the page-size. What I wonder is why they are using magic numbers instead of defining this things globally as named constants or definitions (do they do it this way in the patches? I haven't looked into them).

                  Comment


                  • #10
                    Originally posted by rohcQaH View Post
                    Since I'm not subscribed to mesa-dev, I'll post here:
                    11/17:
                    Code:
                    -   new_data = _mesa_realloc( bufObj->Data, bufObj->Size, size );
                    +   new_data = _mesa_align_malloc( size, ctx->Const.MinMapBufferAlignment );
                    malloc and realloc do entirely different things. I don't think this change is correct.
                    Originally posted by mrugiero View Post
                    Actually, that change seems to be correct, as the guidelines for the project say whoever wrote it believes it shouldn't be using realloc
                    Originally posted by Veerappan View Post
                    But as I replied on the list, we have the potential for a memory leak here. It's possible that the ->Data pointer is always null at the beginning of this function, but if it's not, we've just allocated memory that we'll never free.
                    I guess you guys are correct; I've proposed to use _mesa_align_realloc instead. I'll wait for Ian's comment.


                    Originally posted by mrugiero View Post
                    I do not know what mesa_buffer_data is supposed to do.
                    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

                    Comment


                    • #11
                      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.

                      Comment


                      • #12
                        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:

                        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.
                        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!

                        Comment


                        • #13
                          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.

                          Comment

                          Working...
                          X