Page 3 of 5 FirstFirst 12345 LastLast
Results 21 to 30 of 43

Thread: ATI R300 Gallium3D DRI Support Is "Done"

  1. #21
    Join Date
    Aug 2007
    Posts
    153

    Default

    python is a Python binding that directly glues to a state tracker. I don't like it much; I'm sorely tempted to write my own.

    wgl and egl are other windowing system trackers similar to dri; wgl is for Windows and egl is an implementation of the EGL standard.

    g3dvl is the old video decoder Younes wrote for GSoC a few years ago. The Gallium API's changed and it's rotted a bit so there's ongoing work to refactor it into the rest of the codebase.

  2. #22
    Join Date
    Oct 2007
    Posts
    94

    Default

    sorry if it's a stupid question, but does that include R500 chips ? i have a mobility radeon x1600 (which is rv530 or something like that if i'm not mistaken) and i get worried whenever i see 'r300' this and 'r300' that in the logs ... i'm worried i'm not getting all of my card's worth, you know ?

    not that i never see r500 mentioned anywhere, so i guess perhaps the driver does utilize some capacities not present in r300 cards.


    maybe someone can shed a little light on this ?, as in, why do r500 cards always seem to be 'bundled up' with r300 in open source drivers while r600 and above seem to have their own thing going

  3. #23
    Join Date
    Mar 2009
    Location
    in front of my box :p
    Posts
    794

    Default

    Cheers!

    And damn. I'm "stuck" with 2 R600 chips. Well, but at least this will come next now. Still have to wait some time (or use fglrx).

    To pedepy:
    AFAIR the article says yes, R500 is also included in this "just R300 named" driver. R100, 200 had afaik more differences with the R300-R500 hardware while R300...500 are similar. R600 and up then have again more differences.

    Here see the feature matrix:
    http://www.x.org/wiki/GalliumStatus?action=show
    r300 (ATI R300/R400/R500)
    while
    r600 is (ATI R600/R700/R800)
    Last edited by Adarion; 11-10-2009 at 12:30 PM.

  4. #24
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,458

    Default

    The 3xx, 4xx and 5xx GPUs, along with the RS4xx and RS6xx IGPs, have the same basic 3D engine architecture so they're all handled by the same 3D hardware driver (r300 / r300g). The hardware implementation changed significantly from one generation to the next but the programming model didn't change much.

    Same with 6xx, 7xx and Evergreen (r600 / r600g) - the hardware implementation changed significantly but the programming model stayed more or less constant.

    One question I didn't see answered is "where is the state tracker for regular OpenGL". The answer is that the upper level mesa code acts as the OpenGL state tracker - it can either use "classic mesa" hardware drivers or Gallium3D drivers for hardware acceleration, determined at build time. The cool thing about Gallium3D is that the API allows the same hardware drivers that accelerate 3D to also be used for other things like video or 2D acceleration.
    Last edited by bridgman; 11-10-2009 at 02:25 PM.

  5. #25
    Join Date
    Aug 2009
    Posts
    2,264

    Default

    Quote Originally Posted by bridgman View Post
    One question I didn't see answered is "where is the state tracker for regular OpenGL". The answer is that the upper level mesa code acts as the OpenGL state tracker - it can either use "classic mesa" hardware drivers or Gallium3D drivers for hardware acceleration, determined at build time.
    Is mesa solely a FLOSS implementation of the OpenGL spec in state tracker mode, or does it do more than just being an OpenGL implementation?

  6. #26
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,458

    Default

    I think strictly speaking it is a FLOSS implementation of an API similar to OpenGL

  7. #27
    Join Date
    Aug 2009
    Posts
    2,264

    Default

    Quote Originally Posted by bridgman View Post
    I think strictly speaking it is a FLOSS implementation of an API similar to OpenGL
    Which obviously leads me to ask you: in what ways does mesa differ from OpenGL?

    PS: And why?

  8. #28
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,458

  9. #29
    Join Date
    Aug 2009
    Posts
    2,264

    Default

    Quote Originally Posted by bridgman View Post
    So basically the flow of code may differ from the official implementation, but it is compatible. Although not licensed officially so they can't claim to be perfect and there is no warranty that it is indeed compatible with the OpenGL spec, but they are doing their best to do so and it is their only goal?

  10. #30
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,458

    Default

    It's not that they "can't claim to be perfect", more like they "can't claim to be OpenGL".

Posting Permissions

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