Announcement

Collapse
No announcement yet.

Mesa Development Has Gone Wild This Year

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

  • #21
    Originally posted by rosco View Post
    Sorry to crash your party, but 2016 is also the year of the infamous bug in radeon which makes TF2 and other major games unplayable by hard locking your machine.

    https://bugs.freedesktop.org/show_bug.cgi?id=93649
    I was going to mention that.

    X-Plane 10 also has a nasty bug which locks the machine after exiting it. I reported it in late 2015 to Kernel developers, and again this year to FDO's bug tracker. NO RESPONSE WHAT SO EVER. Not even X-Plane developers wanna look into that.

    And the TF2 bug? What the actual fuck is that? VALVe doesn't care about the bug; Mesa developers can't find it (if it even is Mesa's fault); we don't know if the bug is in the firmware, TF2, Mesa, Kernel drivers, LLVM, etc.

    It's problems like these that make me love and hate the OSS drivers, and also love and hate that clunky FGLRX/Catalyst thing.

    Comment


    • #22
      Kudos to Mesa developers, your work is much appreciated.

      Since this year was so good and now OGL is practically done, can we expect having similar performance to Windows? Some games have 1/3 of the performance, some I hit 13 FPS while on Windows I git 30-40.

      Comment


      • #23
        Originally posted by Amarildo View Post

        Since this year was so good and now OGL is practically done, can we expect having similar performance to Windows? Some games have 1/3 of the performance, some I hit 13 FPS while on Windows I git 30-40.
        I would say - not always, since blobs have threaded GL... which is actually sort of in driver performance enhancement feature and not part of the specs.

        And whatever else function unaccelerated or not properly optimized that uses CPU too much for no need ... if you ask me on win-lin, it is all about more or less CPU bound difference.

        Comment


        • #24
          Particulary it is any post processing that is slow, like AA, Mblur, DoF, even smoke... whatever push hard on draw calls, vbos, etc.

          Not to mention that llvm break those all the time on radeonsi

          Comment


          • #25
            Originally posted by dungeon View Post
            Particulary it is any post processing that is slow, like AA, Mblur, DoF, even smoke... whatever push hard on draw calls, vbos, etc.

            Not to mention that llvm break those all the time on radeonsi
            Thankfully not to me, at least. No AA or 8xAA on CSGO yelds virtually no performance impact. The same for X-Plane.

            Comment


            • #26
              Originally posted by Amarildo View Post
              Thankfully not to me, at least. No AA or 8xAA on CSGO yelds virtually no performance impact. The same for X-Plane.
              It sounds like it didn't work then But actually i like to summ couple years of experience with git stack in one sentence, that does not mean random user should have bug exactly now.

              BTW, impact of AA and other postprocessing is usually less visible on high bandwidh cards... but particular CS:GO is generally CPU bound, so likely because of that perf does not move

              Comment


              • #27
                It did work ;-)

                Comment


                • #28
                  Originally posted by Amarildo View Post
                  It did work ;-)
                  Of course it did, but looks like it didn't as you don't see perf impact because you mentioned CPU capped game... so preferably use some GPU bound case like Unigine benchmarks and enable/ disable it.

                  Also there can be much difference between big and less big chips. Say, impact on Hawaii should be less then on Kaveri, in percents per se etc... that is about what i talking

                  Comment


                  • #29
                    Oh, I get what you're saying. Unfortunatelly I don't have any GPU-intensive game.

                    Comment


                    • #30
                      Originally posted by debianxfce View Post

                      Gstreamer is used by the industry, for example in cars and other embedded solutions. Gstreamer is way more stable, faster and takes less resources than pulseaudio. It is the pulseaudio with its bluetooth audio toys that should never exists.
                      why isnt gstreamer pushed more by distros?

                      Comment

                      Working...
                      X