Announcement

Collapse
No announcement yet.

xf86-video-ati 6.9.0 RC2 Driver Released

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

  • #11
    Originally posted by mityukov View Post
    "Ask Phoronix members to give you a "link for dumbs" and they'll send you to GitWeb!" ;-)

    10x anyway, I'm not as skilled in C but I think I will be able to read at least .h files..


    btw, it's now clear for me that Mesa has both software (basically for referencing) and HW implementations.

    Another point, that I got, is that Mesa acts as a "core" for opensource DRI drivers.

    Do I have any progress? %)


    > xf86-video-ati is the DDX driver.

    DDX -- means basically 2D?

    .. what then about these recent articles:
    * Open-Source ATI Driver Achieves 3D Success
    * Gaming With The Open-Source R500 Driver
    etc?

    Why they refer to Driver (not to HW branch of Mesa)?
    No worries; I didn't expect you to actually read the code, just thought it might give you a better sense of what all the pieces do

    Sounds like you are "getting it". There are three pieces :

    - DDX aka X driver - initialization, display modesetting, 2d & video acceleration. Acceleration usually works without drm driver but works better with drm driver. Contains some code to initialize the rest of the 3D stack and let it know where windows are on screen etc...

    - drm aka kernel driver - mostly manages command submission to the chip and interrupt/fence handling back from the chip; allows multiple drivers to share the acceleration bits (eg 2d from ddx, 3d from mesa)

    - mesa aka 3d aka opengl driver - user mode portion of the 3d stack; takes opengl commands in at the top, fires chip-specific commands out the bottom through drm

    DRI means many things (it's a module, it's an infrastructure, it's a driver, it's a lifestyle) but is essentially the protocols which tie the above three pieces together. The important bit is that it lets the application call mesa directly to draw 3d stuff really fast while staying in sync with what the X driver is doing with windows etc...


    re: articles, you need to understand that there are two kinds of Linux users :

    - the ones who understand how x, drm and mesa drivers all fit together and think it is so obvious they just talk about the X driver and assume you know that drm and mesa are needed

    - the ones who have no idea what x, drm and mesa drivers do and so only talk about the x driver

    There is also a bit of a "two camps" issue - officially the drm and mesa drivers are not part of "X", so some people still focus mostly on making sure X and 2D/video work properly (even if drm and mesa are not there) while another group feels that 3D is an essential part of the modern user experience and treat drm and mesa as a "must have".
    Test signature

    Comment


    • #12
      Is there any planned release for libdrm that allows to compile 6.9.0 driver?
      I have tried to compile it with stock 2.3.0 drm and current 7.0 Mesa and it doesn't work, so I guess newer versions are required. I try to avoid using git checkouts on my main systems.
      When I try to compile the new driver, I get a "legacy_crtc.c no member named 'crtc'" error.
      I'm using a Slackware 12.1 system.

      Comment


      • #13
        Hey, any news on the progress on the MESA side of things?

        The current OSS radeon 3D code leaves a lot to be desired. For example, enabling fog on r300 results in lots of in game artifacts. Also, a lot of functions are still slow. Not only does glxinfo show this as a slow caveat next to many functions, but there are measurable performance hits. One practical example includes glBitmap (and a 5-7fps slowdown when this is used to display text over a 3D scene).

        Comment


        • #14
          So, in order to have 3D-enabled OSS driver for my R500, I heed to compile the following things from the Git:
          - Mesa itself (since 3D support for R500 was added recently);
          - xf86-video-ati
          - X-Server/Client (?) (.. I'm on Ubuntu Hardy...)


          By the way, am I right thinking "fgrlx" has its own OGL core (i.e., it's not rely on Mesa lib's functions when firing chip-specific commands, but uses its own ones?).

          Comment


          • #15
            The fglrx driver does not use the open source mesa or drm components (other than header files for DRI compatibility) but does follow the DRI core protocols. We have proprietary APIs for things like in-kernel memory management, in the same way that TTM/GEM are defining new APIs today.

            I'm not sure of the exact component versions in Hardy; you may also need an updated drm client (mesa/drm). There is a specific build sequence required to make it work AFAIK, but there are a few guides available. I have to run but hopefully someone can point you to an up-to-date set of build instructions.
            Test signature

            Comment


            • #16
              Originally posted by bridgman View Post
              I'm not sure of the exact component versions in Hardy; you may also need an updated drm client (mesa/drm). There is a specific build sequence required to make it work AFAIK, but there are a few guides available. I have to run but hopefully someone can point you to an up-to-date set of build instructions.
              Thank's, I don't need a link to guide, at this time. The question was to realize which components are involved

              It was really informative to talk to you about these "basics", bridgman. Thanks a lot!

              Comment

              Working...
              X