Announcement

Collapse
No announcement yet.

AMD's opensource lies exposed

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

  • #91
    Originally posted by Qaridarium
    is there no tesselation in openGL4 ?
    Uhm... only in opengl 4.1 as far as I know.
    ## VGA ##
    AMD: X1950XTX, HD3870, HD5870
    Intel: GMA45, HD3000 (Core i5 2500K)

    Comment


    • #92
      GL4 requires DX11 hardware.
      GL3 requires DX10.1 hardware.
      GL2.1 requires DX9(*) hardware.

      (GL2.1 defines some features that are not available in all DX9 cards).

      Tessellation is available in OpenGL 4.0 core.

      From now on, we will probably see a major OpenGL revision for each major DX version, i.e. GL5 for DX12 and so on. This makes sense for everyone: hardware manufacturers, developers and end-users.

      Comment


      • #93
        Originally posted by pingufunkybeat View Post
        An adgf5 centerfold?
        Leopard thongs FTW!

        Comment


        • #94
          Originally Posted by BlackStar
          GL4 requires DX11 hardware.
          GL3 requires DX10.1 hardware.
          GL2.1 requires DX9(*) hardware.

          (GL2.1 defines some features that are not available in all DX9 cards).

          Tessellation is available in OpenGL 4.0 core.

          From now on, we will probably see a major OpenGL revision for each major DX version, i.e. GL5 for DX12 and so on. This makes sense for everyone: hardware manufacturers, developers and end-users.
          Originally posted by Qaridarium
          sure thats it... he is just wrong ...
          what do You mean "just wrong" !, sure i forgot about Tessellation but then im human so it's inevitable i suppose , im sure you forget obscure things too ?

          by obscure im sure your aware it seems as of today that Tessellation usage is used by perhaps 2 or 3 windows games at most and the odd obscure workstation option in their app's id imagine too!, and those that did try it so far ended up turning it off to get responsiveness back, as Tessellation slowed their hardware right down.

          but skip that slowdown for the moment, lets not forget i said 'set a DX10.1* capable hardware as your minimum spec' the reason is simple , you mentioned why not set DX11 so you want them to set that as the minimum spec today ?

          how realistic is it do you think that mesa would actually set that DX11 basline requirement today and actually write code to that DX11 hardware spec when Intel currently only does 10.1 at most ?, or arm dev's using a similar X10.1 spec until mali 6 arrives on mass ,and AMD wanting to try and support at least base 10.1 spec (as they officially drop 9.0c card by card support bit by bit today in their closed driver etc)

          as i said 'setting a DX10.1* capable hardware as your minimum spec' today seems far more reasonable dont you agree ?

          sure, writing a few software emulation for the few missing hardware options (or whatever term you want to call it) would probably be required, but what's the alternative, support dx9.0c forever and never get full GL3 or partial GL4 in mesa Linux/OSS for cards that can do/come close to it ? what would you suggest then as the alternative as of today?

          Comment


          • #95
            Originally posted by popper View Post
            what's the alternative, support dx9.0c forever and never get full GL3 or partial GL4 in mesa Linux/OSS for cards that can do/come close to it ? what would you suggest then as the alternative as of today?
            There is no alternative, because dropping support for DX9 GPUs is simply not on the table. In general, GPUs become unsupported once no dev owns them, or wishes to support them, anymore.

            Comment


            • #96
              This post seems to be written by a Fox News reader... (ironic)

              Originally posted by glxextxexlg View Post
              The famous argument of AMD spec fanboys is that AMD will allways go on with providing full specs for their hardware while binary blob support can eventually break. In fact the truth is the opposite of it. It appears that the false opensource prophecy can break any time soon:

              http://www.cs.auckland.ac.nz/~pgut00..._cost.html#oss

              From that text:


              Will opensource "drivers" from AMD support OpenGL 3x/4x and video acceleration in the future? Given the patented floating point support in OGL 3 and s3tc and these DRM arrangements, I've my doubts.
              So amd linux users will have half-baked featureless opensource drivers when amd will drop binary driver support for r600/r700 hardware and another waiting period will start for these people to be able to play OilRush.

              Wake up.
              Well, I'm a bit late in this thread but... personally, I think this post deserves a place in FailBlog, or, even better, in a "Phoronix Forum's Hall of Fame"...

              About most of the things you put there, think twice about it.
              Are these problems with OS AMD drivers AMD's FAULT?!
              I don't think so. From what I know, most of them are patent-related (IP) ones. The remaining are HR. (there aren't too many dedicated professional driver programmers for Linux Graphics Hardware... )
              Summarizing, I think you're being unfair with AMD's efforts to allow system interoperability. The effort they've been doing in the latest 2/3 years has been awesome, at least.

              Cheers

              Comment


              • #97
                Originally posted by glxextxexlg View Post
                AMD dropped support for r300 - r500 hardware in early 2009 and they left development of the open drivers to independent developers like marek olsak and corbin simpson. It took them a very long time and tremendous amounts of unpaid hard work to make r300g an OK driver (...)
                Which proves all the information is out there, it just takes lots of manpower to implement it. AMD said they'd release docs and they did. AMD said they'd help with developers and they do.

                They never promised a team the same size as the closed source drivers. They never promised to write all features the community couldn't keep up with. They never promised to fix the whole open source graphics stack.

                True, there's a few tidbits they can't give out. But at least 90% of the missing features are due to lack of manpower. Much of the UVD functionality could be done in shaders, if there was manpower. OpenGL 3/4 support lacks lots of manpower. Hell, if there was a surplus you could have some do reverse engineering projects.

                It's the open source community that doesn't have enough people, not AMD. AMD didn't start this project so they could make another set of drivers 100% written by themselves, only open source. For years the community said "give us specs" and when they did people like you come and say "oh, and write the driver for us too".

                Comment


                • #98
                  Originally posted by Qaridarium
                  come one what is wrong about this part ? ? ? if you buy amd hardware you pay the dev's to dev a OS driver thats simpel and nothing wrong about that.
                  If your not going to write the driver yourself then WTF is the point of turning over the specs if you are going to depend on the same entity to do all the work?

                  Comment


                  • #99
                    Originally posted by Kjella View Post
                    It's the open source community that doesn't have enough people, not AMD. AMD didn't start this project so they could make another set of drivers 100% written by themselves, only open source. For years the community said "give us specs" and when they did people like you come and say "oh, and write the driver for us too".
                    +1000 If your going to depend on the people that produce the specs to write the drivers then there is no need to open the specs in the first place as those people have had them all along.

                    Comment


                    • Originally posted by Qaridarium
                      in the same way if you get an support ticket from redhat you pay the devs to dev the driver to.
                      Nothing in the AMD marketing or technical specifications for the product you purchased claimed anything about Linux support, much less FOSS drivers.

                      If you buy a car and don't have a driver's license and insurance, that's not the car manufacturer's problem. If you buy a pad of paper and don't buy a pen, that's not the paper company's problem. If you eat Mexican food and don't buy some Zantac, that's not Mexico's problem.

                      If the paper company starts giving out cheap pens with every pad of paper, that's certainly nice of them, but you still don't get the right to bitch that the pen isn't a high quality fountain pen. Not unless you actually paid extra for it, or unless the paper was marketed as including an expensive quality pen.

                      its simple you get what you pay for.
                      And you never paid for FOSS Linux drivers. You paid for a piece of hardware that includes Windows drivers. If you expected it to have FOSS Linux drivers, that's not AMD's problem.

                      Do you expect AMD to also develop drivers for Solaris, BSD, QNX, iOS, Haiku, Inferno, Minix, Symbian, FreeDOS, etc.? Because AMD never once claimed in any of the marketing material on any product they shipped that those would be supported, so anyone expecting such support has their head lodged somewhere dark and stinky.

                      AMD includes Windows support with their GPUs. They have OS X support, likely implemented largely by Apple. They have limited Linux support for a limited range of distributions on a limited range of GPUs (FireGL on enterprise distros, mainly). Everything else is unsupported, and if it works, that's just a bonus.

                      Comment

                      Working...
                      X