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

Thread: Radeon DRM Driver Gets New Branches

  1. #11
    Join Date
    Aug 2007
    Posts
    6,615

    Default

    What logic should be behind this?

  2. #12
    Join Date
    Jun 2009
    Posts
    2,927

    Default

    So, what does a dumb user like myself, who compiles this stuff nightly, need to do?

    Switch branches to radeon-testing? Stick with drm-next?

    I guess drm-radeon-testing is what I want...

  3. #13
    Join Date
    Jan 2007
    Location
    Germany
    Posts
    2,124

    Default

    @Qaridarium: KDE 4.4 (released in about two months) does not really use take advantage of OpenGL 2 yet. KDE 4.5 however will shine with OpenGL2/3 and that stuff is already heavily under development.

  4. #14
    Join Date
    Jan 2008
    Posts
    294

    Default

    Quote Originally Posted by DanL View Post
    The GLSL code is only for radeonhd at the moment: http://cgit.freedesktop.org/mesa/mes...7dad5ef3a783d0
    No, it works for radeon as well.

    Since radeonhd doesn't work with KMS it's likely that radeon + KMS will be the driver to use to get the most GL features.

  5. #15
    Join Date
    Dec 2008
    Posts
    985

    Default

    Quote Originally Posted by Qaridarium View Post
    Yes if the GPU-chip can handle openGL2 the speedup und Feature-Explosion will be Impressive!

    Right now!

    you can test this! i test it by my self on the GAME:HON witout 7.8+(kms+opengl) the game do not start because GSGL 1.1 is needet (openGL2) with 7.8 and kms+OpenGL2 activated the game starts!
    Firefox has a built-in spell checker, you may want to give it a try...

  6. #16
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,441

    Default

    Quote Originally Posted by legume View Post
    No, it works for radeon as well.

    Since radeonhd doesn't work with KMS it's likely that radeon + KMS will be the driver to use to get the most GL features.
    DanL was probably trying to say "it works for HD-xxxx hardware", ie r6xx and up.

    I believe similar work is underway for 3xx-5xx, however -- see nha's r300 work back in early October.
    Last edited by bridgman; 12-03-2009 at 12:08 PM.

  7. #17
    Join Date
    Dec 2008
    Posts
    985

    Default

    Quote Originally Posted by bridgman View Post
    DanL was probably trying to say "it works for HD-xxxx hardware", ie r6xx and up.

    I believe similar work is underway for 3xx-5xx, however -- see nha's r300 work back in early October.
    Does Richard work full-time on the glsl code or just in the weekends? His latest commit last Sunday fixed some of the glsl demos, but there are still some that lockup the GPU (iirc progs/glsl/deriv). I'm just wondering how far away we are from full glsl support. Would be nice if we get a weekly status update or something

  8. #18
    Join Date
    Jan 2008
    Posts
    294

    Default

    Quote Originally Posted by bridgman View Post
    DanL was probably trying to say "it works for HD-xxxx hardware", ie r6xx and up.
    Ahh, of course, sorry DanL I can't see the word radeonhd without thinking of the driver.

  9. #19
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,441

    Default

    Quote Originally Posted by monraaf View Post
    Does Richard work full-time on the glsl code or just in the weekends? His latest commit last Sunday fixed some of the glsl demos, but there are still some that lockup the GPU (iirc progs/glsl/deriv). I'm just wondering how far away we are from full glsl support. Would be nice if we get a weekly status update or something
    Richard is working full time on GLSL. Like most developers, he would much prefer to polish and finalize the code before committing it to a public repo, but if he pushes out his latest working code at least once a week then I don't bug him for weekly status reports. Writing code is always more fun than writing status reports, so once a week out comes the new code

    There's a large element of "learn as you go" here, so status reports would be "here's what works" rather than "here's what has to be done before I'm finished" anyways. Most of the work here is in that nasty little area between "it's finished in theory" and "it's finished in practice", more so than with most development.

    The roadmap is pretty simple though...

    - get the simple tests and demos working properly
    - get the rest of the tests and demos working properly
    - if application bugs occur try to replicate the problem in a simple test then fix, hopefully leaving a test behind for next time
    - if all else fails, debug application issues directly

    I guess we're somewhere in the second step right now.

    One thing I haven't had time to do is build estimation models specific to open source development work. So far I have been using models from commercial development projects, which seem to be pretty good at a "whole project" level but don't work so well between milestones. My impression is that initial progress (from start to "testable") tends to be slower for open source drivers because the pre-existing code base is often both older and less well documented, but there's a point where community developers are able to pile on and start investigating specific issues so progress zooms ahead much more quickly than you would see with a fixed-team-size commercial project.

    The other estimating challenge right now is that there are a lot of interesting things going on with the driver stack, so community developers are spread across more projects than usual. I don't have a good model for "shininess" (ie project X being sufficiently appealing that community developers work on X rather than Y or Z), but that seems to be one key to making useful schedule estimates. We're also seeing some very capable new developers appear seemingly out of nowhere and start diving into very complex stuff -- and I don't have an model for the spontaneous arrival of new developers either

    If one person does all the work these things take a *long* time, so we try to focus our developers on areas where working inside AMD makes a difference, ie getting new hardware functionality working for the first time and leaving working code and/or documentation so the community can pick up and run with it.
    Last edited by bridgman; 12-03-2009 at 01:02 PM.

  10. #20
    Join Date
    Dec 2008
    Posts
    985

    Default

    Quote Originally Posted by bridgman View Post
    Richard is working full time on GLSL. Like most developers, he would much prefer to polish and finalize the code before committing it to a public repo, but if he pushes out his latest working code at least once a week then I don't bug him for weekly status reports. Writing code is always more fun than writing status reports, so once a week out comes the new code
    Thanks for the info. Looking forward to his latest commit this weekend

Posting Permissions

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