Page 2 of 2 FirstFirst 12
Results 11 to 14 of 14

Thread: No Stable RadeonHD 2D Driver This Year

  1. #11
    Join Date
    Sep 2007
    Posts
    128

    Default

    Quote Originally Posted by butdie View Post
    AMD still holds up specs this late, while they suggested 2D by this year.

    Just don't get feed up by AMD propaganda. They do not really care about customers. They couldn't get fglrx for years, therefore, no miracle for open source either.

    Everything from AMD is propaganda. There benchmarkings, like, "super fast barcelona", "open source video".

    Remember, RMS still holds the sign, "Don't buy from ATI, enemy of your freedom", now we can safely s/TI/MD/.

    http://en.wikipedia.org/wiki/Image:R...n_sign_ATI.jpg
    I'm taking this as an attack on not just AMD here, but to the developers contributing to the open source RadeonHD driver. I dislike people making these statements. Put some backing into them, not just "OMGSJTHEYRE LIES!"

    If you've ever looked at the git repo (I look at it every couple days), there's quite a bit of activity going on it - lots to say the least. To bash them just because they can't get 2D out by the end of the year even though it visibly shows that they are working away at it is ... shortsighted I would say? Lack of patience? Overdemanding? Unrealistic?

    Maybe they shouldn't have said they would have 2D done by end of the year, but hey, if you've ever developed before, delays usually happen.

    AMD itself also has a decent relationship with OSS to my understanding, and their processors have worked well with Linux.

    I should also mention, specs WERE released. Were they complete? No. But did they release something? Yes. Actions speak louder than words, and while we all have our doubts, I'm willing to give them the benefit of the doubt this time around (given that they have released 2D specs already). The next thing we know, when 3D specs are released (hopefully), people will complain that they can't get DRI soon after, therefore everything AMD spews is a complete lie.

  2. #12
    Join Date
    Nov 2007
    Posts
    1,024

    Default

    Keep in mind guys that the newest ATI chipsets don't even have a 2D component. AMD *must* release 3D docs, or there will be no 2D rendering on those cards at all. 2D rendering and acceleration is all done with the usual 3D operations, shaders, frame buffer objects, and so on.

  3. #13
    Join Date
    Jun 2006
    Posts
    3,046

    Default

    Quote Originally Posted by elanthis View Post
    Keep in mind guys that the newest ATI chipsets don't even have a 2D component. AMD *must* release 3D docs, or there will be no 2D rendering on those cards at all. 2D rendering and acceleration is all done with the usual 3D operations, shaders, frame buffer objects, and so on.
    If the resident rep for AMD, John Bridgman, who's been posting as bridgman on here was telling the truth in a recent IRC chat on the DRI developer's channel, then this is actually happening. They're having a problem of staffing- they need people to help sanitize the documentation they have before it goes out (no brown paper bag moments, no leaked 3rd party IP, etc.- and there's some of that in their stuff, trust me... ) and they need people to work on the current closed driver.

    Considering that Dave Arlie just put in a new branch on the DRI codebase: R500 support. That means just the very thing you're talking about.

  4. #14
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,404

    Default

    The R5xx family and the RS690 all have the same 2d acceleration hardware as previous generations of ATI graphics chips -- the programming model hasn't really changed since the R1xx/R2xx. As a result, the original programming docs are still applicable (for 2d and DRM only, though), and the "radeon" 2d acceleration code should run pretty much unchanged on 5xx and 690. EDIT - Apparently it does.

    The 6xx family does not have a dedicated 2d accelerator block, but the command processor microcode can accept 2d acceleration commands and emulate them on the 3d engine using a precompiled shader blob. That's the missing info we need to release :

    - docco for which 2d commands we emulate (we don't emulate all the command packets; hopefully we emulate the important ones)
    - r6xx and r5xx microcode
    - the precompiled shader blob for 2d emulation
    - sample code or documentation to set up the emulation mechanism

    We still need to put out more info for full 3d support, of course, and we're just starting to make progress on that. The programming model for 5xx 3d is not too different from previous ASICs while the 6xx has the unified shader core which programs quite a bit differently.

    EDIT -- I've been meaning to put up a table like this for a while...

    DIFFERENCES FROM 4xx to newer parts and impact on driver/developers

    Display controller / display driver - all new for 5xx, 6xx and RS690 -- 690 is more like 6xx than 5xx
    2d accelerator HW / XAA & EXA driver - unchanged for 5xx and 690, emulated but similar for 6xx
    ring buffer & cmd processor / DRM driver- largely unchanged although memory management evolves from gen to gen
    3d engine / mesa driver - 690 unchanged except vertex shaders in SW, a bit different for 5xx, all new for 6xx
    video & overlay HW / video driver - all new on all parts
    SD video acceleration - unchanged on 5xx and 690, a bit different on 6xx
    HD video acceleration - new on 6xx

    You can kinda see what this means for driver development. The display controller is all new so that pretty much has to be written and debugged from scratch along with learning the quirks of the new hardware. Pretty much everything else can make good use of existing code, expecially since everything in the graphics stack except for the display driver is in the process of being rearchitected anyways (EXA over TTM, DRI2, Gallium etc...).

    It seems like a really cool time to be an open source graphics developer.
    Last edited by bridgman; 11-20-2007 at 10:15 PM.

Posting Permissions

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