Announcement

Collapse
No announcement yet.

Open-Source ATI Evergreen Acceleration Builds Up

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

  • bridgman
    replied
    The major blocks - "2D features", "Mesa 3D features" and "Gallium features" - seem to be correct, although it's possible that some of them could move to "Done" (we're not very good at deciding when to make that last transition). The big change over the last month or so has been going from "WIP with no visible sign of progress" to "WIP - oh look, code !" but not enough to move any of the WIP cells to Mostly.

    In the last two blocks - "Output" and "Other" - I imagine that all of the "WIP" cells should probably read "Mostly" (but I haven't had a chance to test myself) and the "TODO" cells should read either "WIP" or "Mostly". Maybe someone who actually *has* a dual-link DVI display or a DisplayPort monitor could comment or update the page.

    We probably need to update the definitions to make it clear whether "Done" means "Done in released drivers" or "Done but you need to build from git right now". I would update it but I'm not sure what current thinking is, will ask the IRC folks. Clarifying that would probably help make the transition from Mostly to Done a bit crisper.

    Leave a comment:


  • Louise
    replied
    Are there news on the Feature Matrix front?

    http://www.x.org/wiki/RadeonFeature

    Or perhaps an overview of the priorities are right now?

    Leave a comment:


  • bridgman
    replied
    Originally posted by markg85 View Post
    I don't get that part... Why does the OSS driver needs any clearing from AMD's legal stuff?
    It's just the release of programming information (register offsets, bitfields, function of those fields etc..) that needs to be cleared. The activity is usually called "legal review" but think of it as "required by legal" rather than "performed by legal".

    Originally posted by Ex-Cyber View Post
    It's (partly?) written by AMD employees who have access to internal info. AMD thus has to review the code to make sure that it only reveals "safe" information (e.g. not breaching NDAs that AMD has with other companies and not revealing details of DRM-related features).
    Exactly. It's primarily a technical review, done with an understanding of the legal issues. We're also looking for things like details of new product generations and hardware features. The basic idea is to draw a line between "how to program the chip" (which we want to expose) and "how the chip is implemented" (which we want to keep secret).

    The initial preparation of code/docs is done almost entirely from internal hardware design information, even reading the hardware emulation code that was written a year or two before first silicon. Sometimes that's the best way to understand exactly how the hardware works.

    Originally posted by curaga View Post
    One thing I've wondered about legal review of code is that doesn't that need people who are both lawyers and programmers?
    Pretty much; they don't have to be actual lawyers but that is the kind of knowledge that's needed to make the reviews effective. You can do the reviews without those hybrid skills but it's very slow and painful. The requirement for an unusual combination of skills is IMO one of the things that holds companies back from supporting open source development.

    Leave a comment:


  • hanglekuk
    replied
    Radeon Feature Wiki page

    Somehow RadeonFeature page at Xorg Wiki feels abandoned:
    RadeonFeature (last edited 2010-02-28 22:27:45 by Louise Hoffman).

    Would anyone care to update info?

    Leave a comment:


  • curaga
    replied
    One thing I've wondered about legal review of code is that doesn't that need people who are both lawyers and programmers?
    Damn, they must have some huge salaries

    Leave a comment:


  • Ex-Cyber
    replied
    Originally posted by markg85 View Post
    I don't get that part... Why does the OSS driver needs any clearing from AMD's legal stuff?
    It's (partly?) written by AMD employees who have access to internal info. AMD thus has to review the code to make sure that it only reveals "safe" information (e.g. not breaching NDAs that AMD has with other companies and not revealing details of DRM-related features).

    Leave a comment:


  • markg85
    replied
    and have cleared AMD's legal review.
    I don't get that part... Why does the OSS driver needs any clearing from AMD's legal stuff?

    Other then that. Awesome to finally see the early beginnings of 2d acceleration in the evergreen cards. I can certainly use it for my card ^_^

    Leave a comment:


  • monraaf
    replied
    Originally posted by bridgman View Post
    It's a tossup which will be harder for the developers - making the card run reliably over AGP or making the card light up in the cardboard box.

    How close is the cardboard box to the computer ?
    About 6 feet. But I guess either option would be easier than to make the card work reliable with fglrx

    Leave a comment:


  • bridgman
    replied
    Originally posted by monraaf View Post
    LOL, just today I removed my Evergreen card and put it back in the cardboard box. I hope the acceleration code follows soon so I can put the card back in my system.
    It's a tossup which will be harder for the developers - making the card run reliably over AGP or making the card light up in the cardboard box.

    How close is the cardboard box to the computer ?

    Leave a comment:


  • bridgman
    replied
    I imagine that GEM/TTM will be part of the initial acceleration support, so the GEM>evergreen part is what's being worked on now. Not sure it's possible to run without it anymore, at least not in KMS.

    Wayland should be orthogonal - AFAIK it runs over the standard driver stack.

    Leave a comment:

Working...
X