Announcement

Collapse
No announcement yet.

How to get involved with open source Radeon driver development (Newbie Friendly)

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

  • #11
    Originally posted by siavashserver
    Thank you very much, that was very useful!


    OK, I just finished working on Enable ARB_map_buffer_alignment in all drivers newbie project. I have cloned Mesa git repository, created my own branch and performed required changes in a few small git commits. How should I prepare and send patches upstream?
    First, I'd make sure that you haven't regressed anything in the Piglit test suite. Secondly, I'm not sure if Piglit has any tests for this feature... If it does, make sure they pass. If it doesn't, consider creating and submitting new tests to the piglit mailing list.

    Next, if you're ready to submit:
    1) Join the [email protected] mailing list (otherwise mails get stuck in a moderation queue until they get approved).
    2) Use git send-email [email protected] ${git commit which is the one before the start of your patch series}

    That git command will find all patches newer than the one that you specify on the command line and will send each patch as an email to the mesa-dev mailing list. It generates a diff/patch for each and quotes it in-line so that it's easy for the rest of the list to provide in-line feedback/comments. If you've got more than 2-3 patches, it would also be good to include a cover letter (Add the "--compose" param to your send-email call).

    There's a good chance that your first version won't get approved immediately. Either there'll be coding style changes, or functionality changes, or something else that someone wants fixed. Don't get discouraged. When you've made the requested changes, send a v2 of the patches (and include at the bottom of each commit message a summary of what changed in each successive version).

    It's probably also good to include a note in the cover letter that you don't have commit access to the upstream mesa repository. It's an indicator that someone with push access should commit your patches for you once they've been reviewed successfully.

    The same workflow generally applies to piglit patches (list address is [email protected]). In general, if you're fixing a bug that doesn't have a piglit test that exposes it, it's always good to create and submit a test that exposes it. Same with enabling new features (we want to know that the new feature works properly).

    Since you're working on an extension that's not supported by your radeon's binary drivers, it'll be hard to run a comparison test on catalyst. But if you work on anything that is not supported by mesa, but is supported by another driver that you have access to, it's always good to run the tests on as many drivers as you can, just to make sure that the various drivers agree on how the implementation should be done (and that you haven't coded the implementation and the tests incorrectly). Just keep in mind that the catalyst/nvidia binary drivers are occasionally wrong too.

    Comment


    • #12
      Originally posted by Veerappan View Post
      It's probably also good to include a note in the cover letter that you don't have commit access to the upstream mesa repository. It's an indicator that someone with push access should commit your patches for you once they've been reviewed successfully.
      If you've gotten all positive review and nothing left to fix don't be afraid to bump the list or email the maintainers/developers of the driver that you're working on, there is a lot of churn in mesa list (and piglit too) and it's easy for devs to forget that you don't have push access

      Originally posted by Veerappan View Post
      Since you're working on an extension that's not supported by your radeon's binary drivers, it'll be hard to run a comparison test on catalyst. But if you work on anything that is not supported by mesa, but is supported by another driver that you have access to, it's always good to run the tests on as many drivers as you can, just to make sure that the various drivers agree on how the implementation should be done (and that you haven't coded the implementation and the tests incorrectly). Just keep in mind that the catalyst/nvidia binary drivers are occasionally wrong too.
      nvidia is especially important to test on if you can, since they generally lead the pack in GL features, and they are also the golden standard against which most closed-source developers work; even if they are wrong it is often necessary to emulate their (non-compliant) behavior.

      Comment


      • #13
        This blog has some newbie suggestions: http://www.itsqueeze.com

        Comment


        • #14
          I have GMA 4500 hardware, is it possible to implement OpenGL 3+ features for this generation?

          Comment


          • #15
            Originally posted by imamdxl View Post
            I have GMA 4500 hardware, is it possible to implement OpenGL 3+ features for this generation?
            I don't see any reason that can interfere to do this. What does confuse you?

            Comment

            Working...
            X