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

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

    Write something...
    Last edited by siavashserver; 02-23-2017, 07:33 AM.

  • martin01
    replied
    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?

    Leave a comment:


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

    Leave a comment:


  • oibaf
    replied
    This blog has some newbie suggestions: http://www.itsqueeze.com

    Leave a comment:


  • crymsonpheonix
    replied
    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.

    Leave a comment:


  • Veerappan
    replied
    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.

    Leave a comment:


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

    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

    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.

    Leave a comment:


  • marek
    replied
    Originally posted by siavashserver
    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!

    Leave a comment:


  • marek
    replied
    Originally posted by siavashserver
    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.

    Leave a comment:


  • marek
    replied
    Ian Romanick posted a wiki with some project suggestions for people wanting to get into Mesa development. Hopefully, experienced people will avoid these projects.

    See: http://wiki.freedesktop.org/dri/NewbieProjects/

    The announcement: http://lists.freedesktop.org/archive...er/048905.html

    Leave a comment:

Working...
X