Announcement

Collapse
No announcement yet.

AMD Radeon GPUs Run Great With Linux 3.11 Kernel, Mesa 9.3-devel

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

  • #16
    Originally posted by blackiwid View Post
    which other big project does such stupid stuff? Even debian freezes only one version and then release it and then after some time they freeze another one...
    I thought it was pretty standard practice, actually.

    After a period of development, you have a feature freeze to prepare a new release. So you branch the release candidate away from the development branch. From that point on, only bugfixes go into the rc branch, new functionality goes into development branch.

    Comment


    • #17
      Originally posted by blackiwid View Post
      which other big project does such stupid stuff? Even debian freezes only one version and then release it and then after some time they freeze another one... there are maybe several branches but basicly there are all there for freezing exactly one release at a time (stupid system also btw, and yes its a distro not comparable to a developed softare...)
      ????

      This is _exactly_ what mesa is doing. 9.1 was released, development went on in master as 9.2-dev (like kernel 3.x-rcX). After some time 9.2-dev got branched to 9.2 to be released ("frozen" as you might call it) and new feature development is not allowed there only bug fixes until release. The "feature development" goes on in master, now as 9.3-dev.

      9.1 is still a branch where fixes may get backported to and in case there are enough of them 9.1.x gets released (you might call it LTS or whatever).

      Comment


      • #18
        Originally posted by blackiwid View Post
        soso it really hurts, I sit here with the cutting edge *cough* archlinux with mesa 9.1 while 9.3 tests are out.

        pfff I dont really know who I have to blame here more, is it mesas fault for having 20 unstable-branches (normaly oyu have 1 and the rest are feature branches) never heard of release early release often, or unflexibility of archlinux folks.

        I mean fedora hat mesa 9.2 from the beginning, my dad using it since then without problems, so I think a bit both but mostly arch linux. If you want a recent X stack arch is not the way to go.

        Yes arch has other advantages great wiki and some packages fedora dont have.

        So because it seems that arch linux devs are not asking themselves how stable stuff is they take what gets signed stable by upstream in blind believe that before that its garbage and with that tag it must be good enough, so when do we see we finaly 9.2 tagged as stable by the mighty gods so I can hope to see finaly after 2-3 months stable mesa 9.2 (thats the reallity despite different tagging) here in arch mesa 9.2.

        BTW for what again is testing tree in arch? And yes I know there is AUR, but please try to build any of that mesa builds without rewriting dependencies and pray to god and compile for hours on my zacate machine its not happening, it is about factor 10 easier to compile a own kernel and get it running then replacing the X stack with its 10 billion dependencies.
        you didnt look hard enough, lcarlier pkgbuild is binary and ready to test and it include the latest ag5df kernels for DPM

        here is the link http://pkgbuild.com/~lcarlier/mesa-git/x86_64/

        just download the latest of each and do "pacman -U *tar.xz" as root

        note: this are binaries and don't require recompile anything, if anything provided by stable arch need unstable deps will be here too in binary form

        Comment


        • #19
          the lib32..... are not needed if you don't use multilib btw, skip them if like me if you use a pure 64 arch

          Comment


          • #20
            Originally posted by jrch2k8 View Post
            you didnt look hard enough, lcarlier pkgbuild is binary and ready to test and it include the latest ag5df kernels for DPM

            here is the link http://pkgbuild.com/~lcarlier/mesa-git/x86_64/

            just download the latest of each and do "pacman -U *tar.xz" as root

            note: this are binaries and don't require recompile anything, if anything provided by stable arch need unstable deps will be here too in binary form
            thx for that hint, is there no wiki site or any other site that links to this and describes it, how are you supposed to find it, search mesa*.tar.xz over google file search?

            Sorry want to stop bitching ^^ but at least I get know a valid hint.


            For all the others I alraedy said that mesas version scheme is not the primary problem here, and that I find that archlinux is the main problem for me here.

            To give another 2 example that its not normal, fedora... they have rawhide but they branch from that a current +x version when x is out the final version not a rc or beta. Or take ubuntu they also only announce the branch of ubuntu next wenn ubuntu is out.

            like I said distros are maybe something different.

            But the main point I was saying is that calling it version X+1 when version X is not out (as final x.0 version) is very strange, I dont know any other projekt that does that. Like the kernel they call it NEXT not x+1 till x is out.

            Firefox the same libreoffice the same...


            is kde doing this? they have a very special version system so maybe they do that too? special in maybe extreme classic, so when its done its done instead of the now in bigger opensource projects main scheme release to a date and look whats done till then. thats a bit like mesa? not having fixed release dates. But I think they also dont do that? I am not using kde so I am not shure here? Or give me another 1 bigger projekt that does call its next branch official version xy. Or is it only a branch but no tag? A branch I would think is okish.

            The main problem I have here is I think that they dont tagged any 9.2ish version. no 9.2 rc1 or at least beta 1 or something. make at least one rc1 if you really want to "freeze" it very long make if you want 1000 rc-s but dont release nothing.
            Last edited by blackiwid; 08-14-2013, 07:38 AM.

            Comment


            • #21
              Originally posted by blackiwid View Post
              thx for that hint, is there no wiki site or any other site that links to this and describes it, how are you supposed to find it, search mesa*.tar.xz over google file search?

              Sorry want to stop bitching ^^ but at least I get know a valid hint.


              For all the others I alraedy said that mesas version scheme is not the primary problem here, and that I find that archlinux is the main problem for me here.

              To give another 2 example that its not normal, fedora... they have rawhide but they branch from that a current +x version when x is out the final version not a rc or beta. Or take ubuntu they also only announce the branch of ubuntu next wenn ubuntu is out.

              like I said distros are maybe something different.

              But the main point I was saying is that calling it version X+1 when version X is not out (as final x.0 version) is very strange, I dont know any other projekt that does that. Like the kernel they call it NEXT not x+1 till x is out.

              Firefox the same libreoffice the same...


              is kde doing this? they have a very special version system so maybe they do that too? special in maybe extreme classic, so when its done its done instead of the now in bigger opensource projects main scheme release to a date and look whats done till then. thats a bit like mesa? not having fixed release dates. But I think they also dont do that? I am not using kde so I am not shure here? Or give me another 1 bigger projekt that does call its next branch official version xy. Or is it only a branch but no tag? A branch I would think is okish.

              The main problem I have here is I think that they dont tagged any 9.2ish version. no 9.2 rc1 or at least beta 1 or something. make at least one rc1 if you really want to "freeze" it very long make if you want 1000 rc-s but dont release nothing.
              google -> "mesa git arch" 5th link but anyway it can be google remembering stuff i looked for

              about mesa releases cycle are actually pretty sane, about your confusion is that sometimes Distros want a very recent feature that is only in mesa git, so they checked a specific revision from git and test it as much as they can and package it to offer certain feature first, so you end up with a package mesa-9.2-as557fdsd where "9.2 is current master" and "as557fdsd" is partial git hash but of course mesa has not released 9.2 and they don't care since they can't control what distros maintainers fetch to their packages.

              In the case of arch they simply stick to released mesa that should work for everyone and let the testing versions rest in pkgbuild, so they dont affect users that want stability over performance/features, at ost i think you should propose this links get included into the wiki to make life easier for early testers like you

              if you wanna know the current official releases check mesa3d.org

              Comment


              • #22
                Originally posted by jrch2k8 View Post
                google -> "mesa git arch" 5th link but anyway it can be google remembering stuff i looked for

                ....

                if you wanna know the current official releases check mesa3d.org
                I find it not very early... its more like different grades of stability different projects wait for before they release their stuff, you see that in arch linux had kernel 3.10 very early while fedora has mesa 9.2 for 2 months or so included. and the freeze time of the kernel is I think way shorter than that of mesa and it has probable more changelines per release.

                So I think streamlining different projects that depend on each other would be a good idea, you need kernel 3.10 and mesa 9.2 for uvd with radeon so releasing it several months differently is not helpful.

                like I said you can see that different then me but I think tagging it something like rc1 or beta1 would be helpful. I mean gnome does the same they try to release new versions of every projects that is a part of it, and the X stack should not have complete different releasedays/schemes.

                its basicly the most difficult part of linux updates and the most important in the same time, replacing the driver-stack, so making it even more complicated dont help.

                Comment


                • #23
                  The linux kernel uses a short merge window per release cycle when all the new features go in, so arguably the freeze time for the kernel is most of the release cycle and hence longer than the freeze time for Mesa. Mesa uses a pipelined model instead of merge windows, so freeze time of one release happens in parallel with development for the next release.

                  Merge windows make sense for Linux because there are a large number of largely independent subsystems which come together from different development branches during the merge window. That's not the case to the same extent for Mesa, so a single development branch and pipelining is probably a better fit.

                  (for pattern folks, a single development branch and pipelining via a major release branch is effectively the same as having a single subsystem and a zero-length merge window, but of course you already knew that )

                  There is a lot to be said for having all the components of the graphics stack on aligned release cycles, and things do seem to be heading that way.
                  Last edited by bridgman; 08-14-2013, 01:52 PM.

                  Comment


                  • #24
                    Originally posted by bridgman View Post
                    There is a lot to be said for having all the components of the graphics stack on aligned release cycles, and things do seem to be heading that way.
                    Nice to hear that, and nice to hear that I am not out of my mind thinking that would be a good idea

                    Sometimes a small rant can be productive (at least for me getting much information)

                    Comment


                    • #25
                      Does anyone still have the loud fan issue with the radeon drivers with dpm enabled on 3.11git ? I have this issue on an HD5700, and cant seem to solve this.

                      Additionally when switching OFF vblank, my screen goes dark!

                      Comment


                      • #26
                        Originally posted by xtachx View Post
                        Does anyone still have the loud fan issue with the radeon drivers with dpm enabled on 3.11git ? I have this issue on an HD5700, and cant seem to solve this.
                        Do you have 2 monitors attached?

                        If that's the case see: https://bugzilla.kernel.org/show_bug.cgi?id=60523

                        My current workaround: Deactivate one screen when I don't use it.

                        Comment


                        • #27
                          Originally posted by droste View Post
                          Do you have 2 monitors attached?

                          If that's the case see: https://bugzilla.kernel.org/show_bug.cgi?id=60523

                          My current workaround: Deactivate one screen when I don't use it.
                          Yes exactly, I have 2 monitors. I do not want to deactivate any of them because i use them a lot (usually while coding, i have my references on one and code in another). The fan sounds like a jet engine.

                          Comment


                          • #28
                            Originally posted by droste View Post
                            Do you have 2 monitors attached?

                            If that's the case see: https://bugzilla.kernel.org/show_bug.cgi?id=60523

                            My current workaround: Deactivate one screen when I don't use it.
                            Droste, can you also test the performance of flightgear and virtualbox with the new radeon drivers? I wanted to compare the performance with catalyst. I havent installed 3.11 kernel yet, I was using a liveUSB to test the new radeon drivers.

                            I took a look at the bugreport and I will add to it detailing what I see in my system (Radeon HD5700), and will have a look at the source code to try to figure out the bug.

                            Comment


                            • #29
                              I could. Is there a flightgear benchmark, timedemo or something like this? I'm also not sure what you want me to do with virtualbox. It worked for me for ages with windows xp/7 guests and is mainly a CPU intensive task isn't it?

                              Comment


                              • #30
                                Originally posted by droste View Post
                                I could. Is there a flightgear benchmark, timedemo or something like this? I'm also not sure what you want me to do with virtualbox. It worked for me for ages with windows xp/7 guests and is mainly a CPU intensive task isn't it?
                                In flightgear, there is an option to display the FPS. I usually do my benchmark with flightgear on full screen (so I know the resolution), and 1 test with rembrandt OFF and another with rembrandt ON. (the rest of the settings does not make a big difference, maybe 1 FPS at best).

                                In catalyst, with rembrandt OFF I get about 60 FPS, with it ON, I get around 23. However, with the recent versions of catalyst, its a bit hard to test, since the clouds are all black and the shader does not work properly. (it is a catalyst problem - it "broke" before, was fixed with 12.3beta3 and the bug "reappeared" with 12.6 . Really bad!!!) I am just interested with the screen resolution vs FPS. (both rembrandt on / off)


                                I sometimes use virtalbox to make 3D models (autodesk), and use it to play some directX games. I just want to know how well it runs on catalyst. Lastly, when I get home in about 2 days, I will try the 3.11git myself. Sounds like the open source driver made a lot of progress and I can finally ditch catalyst!

                                Comment

                                Working...
                                X