Announcement

Collapse
No announcement yet.

A Fourth Release Candidate For Mesa 7.5

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

  • #16
    Originally posted by BlackStar View Post
    Do you have *any* idea what displacement mapping and SSAO stand for?

    To put things into perspective, the NVS 135 is an IGP that is advertized as 2d only and comes *without* any memory. Its results fall somewhere between a discrete 7600 and 7800 GPU and have better image quality to boot.

    Make no mistake, recent IGPs from nvidia and esp. ati pack quite a bit of horsepower.
    Yes I do know what displacement mapping and SSAO are. Lets put it into perspective. Your "performance equivalents" were budget discrete parts over 3 years ago and are old and slow compared to the discreet parts nowdays. If you want to run something like old doom 3 your gonna have a hard time even hitting playable framerates @ 1024.

    Comment


    • #17
      Originally posted by deanjo View Post
      Yes I do know what displacement mapping and SSAO are. Lets put it into perspective. Your "performance equivalents" were budget discrete parts over 3 years ago and are old and slow compared to the discreet parts nowdays. If you want to run something like old doom 3 your gonna have a hard time even hitting playable framerates @ 1024.
      If you actually knew what you were talking about, you wouldn't be comparing to Doom 3, which has neither.

      Obviously, IGPs will be slower than discrete GPUs or, in the best case, equivalent to low-end offerings of the current generation. This doesn't mean they are useless for 3d: 7600s and 7800s still perform acceptably in many games today. Which is important, since IGPs take a large (the largest?) slice of GPU sales.

      The point here is that a dead cheap IGP can match the performance of a mid-range GPU from the previous generation, improve on its image quality *and* offer more features (video decoding, OpenCL). Obviously, you won't use an IGP if you are a gamer or otherwise care about 3d performance, but guess what? Most people aren't gamers.

      Bottom line: a good IGP is the perfect match for an HTPC and the occasional game. Low power consumption? Check. Video decoding? Check. Acceptable performance? Check.

      Edit: WTH, thought this was the HTPC thread! This is way off-topic for the Mesa3d discussion, apologies.
      Last edited by BlackStar; 06-27-2009, 04:03 PM.

      Comment


      • #18
        Originally posted by BlackStar View Post
        If you actually knew what you were talking about, you wouldn't be comparing to Doom 3, which has neither.
        I never said doom had either. I was using it as a example of how inadequate igp solutions are for anything but basic desktop use or running old apps. They simply do not have the needed horsepower for present 3d graphics standards. Lets face it nobody sane would even think of trying to run Crysis on any IGP.

        Obviously, IGPs will be slower than discrete GPUs or, in the best case, equivalent to low-end offerings of the current generation. This doesn't mean they are useless for 3d: 7600s and 7800s still perform acceptably in many games today.
        When the resolution is dropped drastically and eyecandy at the bare minimum.

        The point here is that a dead cheap IGP can match the performance of a mid-range GPU from the previous generation, improve on its image quality *and* offer more features (video decoding, OpenCL). Obviously, you won't use an IGP if you are a gamer or otherwise care about 3d performance, but guess what? Most people aren't gamers.
        Actually your IGP that you used for an example would be equivelent (a hair less because of memory) to the bottom feeder, the 8400 GPU

        Bottom line: a good IGP is the perfect match for an HTPC and the occasional game. Low power consumption? Check. Video decoding? Check. Acceptable performance? Check.
        The only one up to the task is a nvidia IGP with the blobs. In FOSS land there still isn't a solution that does not require brute force processing by the CPU on HD content. Bye bye power consumption.

        Edit: WTH, thought this was the HTPC thread! This is way off-topic for the Mesa3d discussion, apologies.
        And as which Mesa3D performance is ~ 50-60 percent of what propriatary GL stack is able do. Which BTW is what your comparing in your examples. Best 3d performance is experienced with blobs, not mesa3d.

        Comment


        • #19
          Originally posted by deanjo View Post
          And as which Mesa3D performance is ~ 50-60 percent of what propriatary GL stack is able do. Which BTW is what your comparing in your examples. Best 3d performance is experienced with blobs, not mesa3d.
          Patches welcome.

          ~ C.

          Comment


          • #20
            What are the Mesa developers doing there? There is no problem if they take the time they need for developing. But announcing something similar to "it will be out in three days" and after three months there is still nothing is harming the project.

            Comment


            • #21
              How is it harming the project? I suspect most of the people who are actually doing the heavy lifting of pushing Mesa's 3D support forward are concentrating on git master anyway. The release schedule doesn't matter for them, unless they are themselves directly involved in the release process or maybe if they're working for a distribution.

              The only way it could be seriously harming the project was if it were turning away people who might be interested in joining and helping out. I doubt that this is the case.

              Edit: Okay, so it may be bad press, and that shouldn't be entirely shrugged off. But still, you won't get your 3D features at a faster rate just because an arbitrary release schedule is enforced.

              Comment


              • #22
                To come to the point immediately: it is all about bad press. I understand that release schedules cannot always be kept and I think it is better to postpone a release than to enforce it in a broken state. It is an entirely emotional thing. Being enthusiastic about the release in April ("it is out this week"), it is disappointing to still wait for it about three months later. My statistics on reporting bugs about X.org and related software has significantely dropped, because I am pretty disillusioned after waiting for a long time for the new releases of Mesa and X. Yes, the projects do not need my bug reports. But it is the whole "bad press" thing that hurts the project.

                Comment


                • #23
                  Okay, you've convinced me that it hurts the project, because I disagree with you

                  Here's why: the project *does* need bug reports - at least high quality ones, I'm just going to assume that that's what you provided.

                  If the bad release managment turns you away from doing that, then yes, it hurts the project. (Note that, depending on the type of bug, it is usually necessary that you're prepared to build Git mesa, or maybe at least run -edgers packages or whatever your distro equivalent is. If you're prepared to do that, then maybe you shouldn't be that disappointed about slow releases? Just a suggestion - and I realize that running bleeding edge stuff isn't for everyone)

                  Comment


                  • #24
                    Originally posted by nhaehnle View Post
                    Here's why: the project *does* need bug reports - at least high quality ones, I'm just going to assume that that's what you provided.
                    I try my best, collecting any information that might be useful. Bringing a problem down to a *really* simple testcase is usually too hard for me, because I do not know enough about X.org and time is unfortunately limited.

                    If the bad release managment turns you away from doing that, then yes, it hurts the project. (Note that, depending on the type of bug, it is usually necessary that you're prepared to build Git mesa, or maybe at least run -edgers packages or whatever your distro equivalent is. If you're prepared to do that, then maybe you shouldn't be that disappointed about slow releases? Just a suggestion - and I realize that running bleeding edge stuff isn't for everyone)
                    Principally it is ok for me to try things with bleeding edge code from git or other versioning systems. But using the latest final release is currently not an option with some packages, because they cause bad problems with my hardware. Once I had a problem with my graphics driver. I did not report the problem in the bug tracker of my distribution, because it seemed to be an upstream bug. I could bisect it and reported it in the freedesktop bug tracker. It was fixed within three days. So I went to the bug tracker of my distribution and described the bug and linked the upstream bug report with the fix. They did not backport the fix because the next release was scheduled to be out within the next days. Actually it took nearly a month until the release was out and another two weeks until it was in the distribution repositories.

                    Another problem with git sources: not seldom I run into new problems when using vanilla sources, because my distribution has patched something. In such a case I do not know if a missing patch is causing the problem or if the checked out code is broken on my system configuration. Then applying the distribution patches sometimes fails because they are not compatible. Sometimes I try to apply a patch manually, but things may get even worse then, because I do not know the code. Furthermore it might be possible that I should use code from git from the project itself and several of its dependencies (e.g. Linux kernel master git). This all costs pretty much time and when a new problem shows up, it might be caused by one of half a dozen bleeding edge components. Also I have to update this git stuff manually and can not rely on the update mechanism of my distribution.

                    The disappointment does not come from slow releaes. It comes from schedules that are postponed again and again. Why are schedules being published if you can not at least roughly rely on them?

                    Comment


                    • #25
                      Originally posted by Mr. Anderson View Post
                      The disappointment does not come from slow releaes. It comes from schedules that are postponed again and again. Why are schedules being published if you can not at least roughly rely on them?
                      Because 3D drivers are hard to write and even harder to make stable.

                      Comment


                      • #26
                        Originally posted by MostAwesomeDude View Post
                        Because 3D drivers are hard to write and even harder to make stable.
                        I have no doubt about that. But IMO it is better not to make promises (publish schedules) that can not be kept.

                        Comment


                        • #27
                          Is it possible that the Mesa 7.5 and Xorg 7.5 schedules are being mixed up here ?

                          I remember reading about an April schedule for Xorg 7.5, based on "four months after xserver 1.6" but I don't remember reading anything about a Mesa 7.5 schedule.

                          Comment


                          • #28
                            It began with this:

                            Brian Paul of Tungsten Graphics (now owned by VMware) announced today that he intends to release Mesa 7.5 in the coming days. Specifically, he hopes to release Mesa 7.5 this Friday. It hasn't been that long since Mesa 7.3 has been released (let alone Mesa 7.4), but the 7.5 release is imminent. Brian explains, "I'm looking at making the 7.5 release on Friday. The main objective of this development release will be an initial milestone / roll-out of the Gallium bits. Then, I'd like to quickly create the Mesa 7.6 branch for stabilization. git/master will then again be open to any/all development."
                            in a Phoronix article back in April: Gallium3D-Capable Mesa 7.5 Release This Week!

                            Comment


                            • #29
                              Yeah, I think those plans changed almost immediately though, if you follow the mailing list thread in the article :

                              http://sourceforge.net/mailarchive/f...ame=mesa3d-dev

                              What the thread says, in essence, is that the release model for Mesa changed. Rather than 7.5 being a "get the code out but don't consider it stable" release and 7.6 being the stable release, the plan changed so that a 7.5 branch would be created and 7.5.1 would be the stable release, created off the 7.5 branch. At some point it seems that there was an unspoken decision to make 7.5 rather than 7.5.1 the stable release and skip the unstable 7.5 release entirely.

                              So, in short words, the 7.5 release being worked on now is what was originally called 7.6, and was later called 7.5.1. I'm not 100% sure of this but it seems pretty likely.
                              Last edited by bridgman; 07-14-2009, 01:26 PM.

                              Comment


                              • #30
                                in a Phoronix article back in April: Gallium3D-Capable Mesa 7.5 Release This Week!
                                Well, to be blunt, there's your problem: it's a Phoronix article. The actual message made no such promises at all.
                                Last edited by Ant P.; 07-14-2009, 01:30 PM.

                                Comment

                                Working...
                                X