Announcement

Collapse
No announcement yet.

ATI R600/700 OSS 3D Driver Reaches Gears Milestone

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

  • #31
    libtxc_dxtn.so doesn't show up in drm (at least not Alex's version).

    It does show up in /mesa/src/mesa/main/texcompress_s3tc.c and then probably compiled in /mesa/src/mesa/libmesa.a and libmesagallium.a. I did use --disable-gallium.

    Comment


    • #32
      Great news, look forward to testing this w/ my 4850x2, thanks AMD and community. ^^

      Comment


      • #33
        Yeah, just tested RV620 with glxgears and Xv. Xv fixes colors! Funny things. Flickering is still available, probably because on lack of VSYNC?


        Originally posted by forum1793 View Post
        This guide shows in DRM to make shared-code.

        cd shared-code
        sudo make install

        Edit: I haven't been doing that in past unless it is automatically done from make at top level. Is this needed?
        I think it is also done when you use make in top directory. If I'm right it copies source files to right places, so next things you compile can see updated radeon/drm modules.

        Comment


        • #34
          Not sure what happens when you do make install in shared-core. I was running make and make install at the top level to update libdrm and headers, then another make in linux-core to produce the actual drm binary files. I didn't think building in shared-core actually did anything -- AFAIK the shared-core files are only used when you build linux-core or bsd-core

          See the last comment in : http://jbridgman.livejournal.com/945.html

          Looks like the instructions at http://www.x.org/wiki/radeonhd%3Aexperimental_3D call for two separate invocations of make + make install, one for libdrm and one for shared-core. Not sure if that is any better than one invocation at the top level.
          Last edited by bridgman; 07-16-2009, 02:29 AM.

          Comment


          • #35
            Originally posted by Zajec View Post
            Yeah, just tested RV620 with glxgears and Xv. Xv fixes colors! Funny things. Flickering is still available, probably because on lack of VSYNC?


            I think it is also done when you use make in top directory. If I'm right it copies source files to right places, so next things you compile can see updated radeon/drm modules.

            I agree with you. I have test this with an Radeon 3850.

            but if i start glxgears the screen is black and for the normal picture i have to klick with the mice


            Im Using the radeonhd driver.

            Comment


            • #36
              shared-core is where the files that are shared between linux and bsd live. There's nothing to build in there. The files are symlinked into linux-core and bsd-core. The kernel modules for linux are built in linux-core.

              Comment


              • #37
                Originally posted by Nille View Post
                I agree with you. I have test this with an Radeon 3850.

                but if i start glxgears the screen is black and for the normal picture i have to klick with the mice


                Im Using the radeonhd driver.
                Not sure, do you mean whole screen? For me just glxgears has weird (white/black flickering) colors. I use radeonhd as well.

                Comment


                • #38
                  Originally posted by Zajec View Post
                  Not sure, do you mean whole screen? For me just glxgears has weird (white/black flickering) colors. I use radeonhd as well.
                  no if i start glxgears the whole screen is black. after klick on the desktop everything is "normal" again.



                  And i have make a very short video

                  http://rapidshare.com/files/25636082...0_converted.7z 535KB

                  mh i have uploaded the video @youtube http://www.youtube.com/watch?v=b8bFloFnnBM i think this is easyer and faster as rapidshare

                  EDIT the video has only 10FPS this is the reasson why everthing is so fast ^^
                  Last edited by Nille; 07-16-2009, 03:24 AM.

                  Comment


                  • #39
                    Hi there,

                    just wanted to say that I have the same problem like Nille. Using a integrated Radeon HD3200 here (RS780 chipset).

                    Did check it with a fresh mesa git checkout (r6xx-rewrite branch) and the corresponding DRM module from Alex's repo. libdrm is git master with the radeon API enabled. xf86-video-ati is also git master, another recent compile.

                    Loading the DRM module works without problems, starting X works flawlessly but starting glxgears just "blacks" the current desktop.

                    Nothing suspicious in the kernel log, haven't checked Xorg.log though. And it's not like the app, driver or kernel crashes or anything. It's just that the screen turns black.

                    I can switch back and forth between X and the console, and also between my 4 virtual desktops (using XFCE). The only desktop that stays black is the one where glxgears was called. I can kill it from another desktop, then switch back, having some mild screen corruption which reverts back to normal once I open some apps or resize windows.

                    So it's definitely better than before where calling glxgears crashed the whole X server.

                    I read that glxgears is supposed to work now, so are we encouraged to open bug reports for such problems, or is it still too early for something like that?
                    I can generate logs, backtraces and stuff, if that helps. Just let me know what you need.

                    EDIT: It just came to my mind that I have the XFCE compositor enabled, I'll check if this is a problem later.

                    Comment


                    • #40
                      Originally posted by LiquidAcid View Post
                      libdrm is git master with the radeon API enabled.
                      From what I understand (I have edited a previous post of mine about this) you still need to use libdrm from Alex' repo. But you can _build_ your mesa with libdrm from git master.

                      Comment


                      • #41
                        Originally posted by bridgman View Post
                        (b) get back to 1500fps from 15fps by accelerating the back-to-front buffer copy,
                        See, here's where I'm fuzzy. Aren't buffer swaps supposed to, you know, swap buffers? As in not copy from the back- to the front-buffer at all but instead just swap them? Or is this just some temporary trick you use for now because getting the hardware to do a proper swap is hard?

                        Comment


                        • #42
                          I believe the idea of "buffer swap" dates back to the days when OpenGL apps usually ran full screen and an overlay was floated in front for menus etc...

                          If the app is running full screen then AFAIK it is possible to do an actual swap, usually called "page flipping" in X/DRI-speak. If the app is not running full screen, however, then you need to copy from back buffer (hidden) to front buffer (screen) without affecting the other content which is already on the screen.

                          That said, I don't see page flipping on fullscreen apps used as much as I would expect, not sure why. It may be that the growing use of compositors (which add their own copy step anyways) is displacing the traditional "OpenGL owns the screen" style of operation, or it may just be a lower priority than all the other big changes currently being made in the stack. A high-end GPU can do a full-screen copy in well under a millisecond anyways, and even a low-end GPU only takes a few milliseconds.
                          Last edited by bridgman; 07-16-2009, 09:19 AM.

                          Comment


                          • #43
                            Right, of course. Didn't think that all the way through. For windowed apps a copy makes sense. as they effectively share the front-buffer with the window manager (in DRI1 at least). Guess the overhead is simply smaller than I imagined. 'Twas just something about copying that triggered my premature optimization circuits.

                            Comment


                            • #44
                              Originally posted by bridgman View Post
                              A high-end GPU can do a full-screen copy in well under a millisecond anyways, and even a low-end GPU only takes a few milliseconds.
                              More like microseconds, actually. 1080p is ~7.9MB per frame, which translates needs something between 80μs (ultra high-end GPUs with GDDR5 memory) to 4ms (ultra low end Intel IGPs with single-channel DDR2 shared memory).

                              Fglrx seems to enable page flipping on un-re-directed fullscreen apps but fall back to copying when the window becomes redirected (e.g. a background window pops-up or you leave fullscreen). You get a momentary flicker, but it's a good compromise between performance and visual quality. Older Windows drivers (esp. nvidia ones) used to flicker horribly whenever a notification / menu came in front of an OpenGL/D3D app.

                              Comment


                              • #45
                                Originally posted by BlackStar View Post
                                Older Windows drivers (esp. nvidia ones) used to flicker horribly whenever a notification / menu came in front of an OpenGL/D3D app.
                                Yeah, now it only flickers where the notification is. Sometimes a bit annoying if you're trying to concentrate and the notification jumps in and out in less than a second intervals before calming down.

                                Comment

                                Working...
                                X