Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 23

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

  1. #11
    Join Date
    Oct 2013
    Posts
    195

    Default

    It looks like all those tasks are new OpenGL 4 extensions. Is it possible for newbies owning OpenGL 3 capable and older graphics cards to pick up those?

  2. #12
    Join Date
    Jan 2009
    Posts
    624

    Default

    Quote Originally Posted by siavashserver View Post
    It looks like all those tasks are new OpenGL 4 extensions. Is it possible for newbies owning OpenGL 3 capable and older graphics cards to pick up those?
    Yes, those extensions can be supported on GL2 and later hardware.

  3. #13
    Join Date
    Oct 2013
    Posts
    195

    Default

    Quote Originally Posted by marek View Post
    Yes, those extensions can be supported on GL2 and later hardware.
    I had a look at supported extensions by FGLRX for my 4890, but none of them is supported. Is that a show stopper?

    Here is the list of supported OpenGL extensions: http://pastebin.kde.org/pglnnibhx

  4. #14
    Join Date
    Oct 2013
    Posts
    195

    Default

    Fortunately ARB_map_buffer_alignment extension is supported, this brings tears in my eyes! I'm going to have a look at that one

  5. #15
    Join Date
    Jan 2009
    Posts
    624

    Default

    Quote Originally Posted by siavashserver View Post
    I had a look at supported extensions by FGLRX for my 4890, but none of them is supported. Is that a show stopper?

    Here is the list of supported OpenGL extensions: http://pastebin.kde.org/pglnnibhx
    Don't worry that the closed driver doesn't support it. Your driver is probably older than the extensions!

  6. #16
    Join Date
    Jul 2013
    Posts
    208

    Default

    Most things have been answered here already but just a couple of things to add:

    Quote Originally Posted by siavashserver View Post
    6) How is Mesa and open source drivers source code structured? (Related directories and files)
    In the mesa source:
    docs/sourcetree.html - Has an overview of the directory structures

    Quote Originally Posted by siavashserver View Post
    9) What is usual coding conventions and styles being used?
    In the mesa source:
    docs/devinfo.html - Provides some tips to new developers including coding styles information.


    These files are also avaliable on the Mesa website but they not as up to date.

  7. #17
    Join Date
    Oct 2013
    Posts
    195

    Default

    Quote Originally Posted by tarceri View Post
    Most things have been answered here already but just a couple of things to add:

    In the mesa source:
    docs/sourcetree.html - Has an overview of the directory structures

    In the mesa source:
    docs/devinfo.html - Provides some tips to new developers including coding styles information.

    These files are also avaliable on the Mesa website but they not as up to date.
    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?

  8. #18
    Join Date
    Nov 2008
    Location
    Madison, WI, USA
    Posts
    873

    Default

    Quote Originally Posted by siavashserver View Post
    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 mesa-dev@lists.freedesktop.org mailing list (otherwise mails get stuck in a moderation queue until they get approved).
    2) Use git send-email --to=mesa-dev@lists.freedesktop.org ${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 piglit@lists.freedesktop.org). 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.

  9. #19

    Default

    Quote 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

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

  10. #20
    Join Date
    Oct 2013
    Posts
    195

    Default

    Quote Originally Posted by Veerappan View Post
    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.
    Yup, fortunately there was a test implemented for this feature and successfully passed.


    Quote Originally Posted by Veerappan View Post
    Next, if you're ready to submit:
    1) Join the mesa-dev@lists.freedesktop.org mailing list (otherwise mails get stuck in a moderation queue until they get approved).
    2) Use git send-email --to=mesa-dev@lists.freedesktop.org ${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).
    Thanks for the tip, that really makes life easier! I also included a note about not having write access as you suggested. Let's hope that it gets merged on first shot

    Newbie Project : Enable ARB_map_buffer_alignment in all drivers


    Quote Originally Posted by crymsonpheonix View Post
    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.
    Unfortunately it's just me and my 4890 right now and I can not afford a new machine, but yeah that's on my todo list

Tags for this Thread

Posting Permissions

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