Announcement

Collapse
No announcement yet.

Performance Work Coming Up For Mesa 7.11

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

  • #31
    Originally posted by Azpegath View Post
    Hahahaha what? Gimme that tinfoil hat! Give it to me!
    Brilliant retort. You forgot you're on drugs or see a head shrinker who will give you drugs.

    Psychopaths love to kill small animals and birds are falling out of the sky to create an environment of fear. You have all the situational awareness of blind deaf dumb guy. You just aren't mute.

    Comment


    • #32
      Originally posted by Hephasteus View Post
      There's not blobs must die only open source drivers should be allowed in linux bozos. What there are is an operating system controls your computer and takes responsibility for controlling your computer.
      No, it doesn't. The GPL has a "NO WARRANTY" (yes, in capitals) section.

      There goes your "responsibility."

      Comment


      • #33
        Originally posted by Hephasteus View Post
        Brilliant retort. You forgot you're on drugs or see a head shrinker who will give you drugs.

        Psychopaths love to kill small animals and birds are falling out of the sky to create an environment of fear. You have all the situational awareness of blind deaf dumb guy. You just aren't mute.
        Got a war trauma of some kind?

        Anyway; proprietary sucks, simply because it doesn't integrate with the big open source development environment. As a result it may work with it, but you can ask yourself how.

        Last, but not least; Thanks devs!

        Comment


        • #34
          Originally posted by V!NCENT View Post
          Anyway; proprietary sucks, simply because it doesn't integrate with the big open source development environment.
          From my point of view, the big open source development environment sucks because it makes it difficult for proprietary drivers to integrate with it.

          Comment


          • #35
            Open source projects are set up in a way that makes development easier.

            That's exactly how it should be, because manpower is limited, and the devs should concentrate on development.

            Why should OPEN SOURCE developers make their own lives and their own development intentionally difficult, just so two or three companies can keep their own source closed? Makes no sense.

            Comment


            • #36
              Originally posted by RealNC View Post
              From my point of view, the big open source development environment sucks because it makes it difficult for proprietary drivers to integrate with it.
              It must be hard in life being that stupid.

              Dave.

              Comment


              • #37
                Originally posted by airlied View Post
                It must be hard in life being that stupid.

                Dave.
                Despite the fact that the original post wasn't one of the smartest, Dave has quite a direct way to point that out. I mean it wouldn't be the first time he gave such an answer either.

                Comment


                • #38
                  Originally posted by airlied View Post
                  It must be hard in life being that stupid.
                  So you're calling stupid anyone who wishes for a driver ABI.

                  Nice going, Dave.

                  Comment


                  • #39
                    Originally posted by agd5f View Post
                    Pageflipping as it is currently implemented in dri2 only flips during the vblank period (swap interval of 1) so it's limited to the refresh rate. Ideally, we also support pageflipping when the swap interval was 0 as well so you'd get atomic pageflipping (with tearing) for maximum frame rates. dri2 needs to work to enable this however. Even with vblank synchronized pageflipping, it still helps performance in that is reduces memory bandwidth requirements and pipeline latency since you don't have to do an additional blit to copy the back buffer to the front buffer.
                    Does the description above agree with this new article?
                    http://www.phoronix.com/scan.php?pag...item&px=OTAwMg

                    Radeon Page-Flipping: Support for the Radeon DRM to utilize KMS page-flipping support has finally landed in the mainline tree after it's been available with Intel's DRM for a few releases now and then more recently has been Nouveau page-flipping. The page-flipping support should improve the open-source driver performance.

                    Comment


                    • #40
                      Originally posted by RealNC View Post
                      So you're calling stupid anyone who wishes for a driver ABI.
                      Yes, and for good reason.

                      This has been discussed to death over and over again. The current limiting factor in getting better OSS drivers is developer manpower, so anything that can help them out should be the #1 priority. The only people hurt by this are the devs at AMD and NVidia, and they have enough manpower to overcome the problem. Everyone else does not.

                      Comment


                      • #41
                        Originally posted by agd5f View Post
                        If we knew exactly what needed to be fixed we'd do it. It comes down to lots of profiling. [..]
                        Sounds like an interesting task. What exactly has to be profiled, how is it done and is any special ability required to do that despite of a lot of patience? :-)

                        Comment


                        • #42
                          Originally posted by hal2k1 View Post
                          Does the description above agree with this new article?
                          http://www.phoronix.com/scan.php?pag...item&px=OTAwMg
                          I'm not quite sure what you are asking. Radeon pageflipping support was merged for 2.6.38 and as I noted, it's vblank synced, but does reduce memory bandwidth requirements and pipeline latency since it avoids the additional blit required for the bufferswap which has a factor in performance. The frame rate if refresh rate limited, but the memory bandwidth requirements are lower. For non-vblank-synced pageflipping, the dri2 code in the xserver needs some additional work.

                          Comment


                          • #43
                            Originally posted by smitty3268 View Post
                            Yes, and for good reason.

                            This has been discussed to death over and over again. The current limiting factor in getting better OSS drivers is developer manpower, so anything that can help them out should be the #1 priority. The only people hurt by this are the devs at AMD and NVidia, and they have enough manpower to overcome the problem. Everyone else does not.
                            You say "hurt by this", what do you mean by "this"? The lack of an ABI?

                            On another note (start rant, hehe):
                            Even though they have manpower (and that they are "huge evil corporations"TM), they usually don't have an infinite amount of money. Especially not AMD I assume...
                            The manpower they do have, they're probably trying to do the best they can with. Sadly that "best" usually doesn't align with what we think is the best for the Linux community. But of course I don't think the developers are to blame for this, it's usually decisions made far above their heads. They're probably just as frustrated with their managers as us other coders are, hehe

                            Comment


                            • #44
                              Originally posted by LibertyZero View Post
                              Sounds like an interesting task. What exactly has to be profiled, how is it done and is any special ability required to do that despite of a lot of patience? :-)
                              Basically profile a 3D app whose performance you want to improve and see where most of the time is spent. If a lot of time per frame is spent copying vertexes, you might look at those paths in the driver. rinse and repeat.

                              Comment


                              • #45
                                Heh... Stable ABI... "Hey Gallium dudes, forget about LLVM; stick to TGSL for ten years! Oh and Limug guys; forget about a good kernel; do it like NT!" Yeah that'll be the day, morons, when the reason for closed ddrivers is simply speed. Speed that FLOSS doesn't have because of a manpower problem and not an awesomeness problem.

                                Comment

                                Working...
                                X