Announcement

Collapse
No announcement yet.

The Major Open-Source ATI Improvements Over Two Years

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

  • #31
    Old crappy extensions won't be added. Only the extensions which applications need and use will.

    You should see all those MISSING lines on proprietary drivers, you'd be hell of surprised.

    It's possible that some unused and unadvertised extensions will be removed from Mesa. Like who the hell needs GL_NV_fragment_program?

    Comment


    • #32
      Originally posted by BlackStar View Post
      There's a good reason why many of those functions are missing. For instance, moern hardware no longer supports color tables - should drivers implement a slow software fallback for that case? What about hardware- and vendor-specific extensions?

      What the goal should be is to make everything in OpenGL core available first, work on the compatibility profile second and, if there's nothing better left to do, add oddball extensions last. OpenGL 4.1 core is probably missing fewer than 100 entry points at this point (most of which are overloads of each other).

      Edit: for comparison, OpenGL 4.1 compatibility has ~1000 entry points or ~2200 incl. extensions.
      Problem being, vendors just keep on introducing new extensions, and application authors just keep on using them. If either (a) vendors would stop thinking they need a special extension just for them, or (b) app writers would stick to the required core + ARB extensions and write all their code in terms of that, there'd be a lot fewer app crashes out there. ESPECIALLY with commercial games (not necessarily run through Wine, either; a lot of native Linux games use extensions that aren't available in Mesa).

      Most game developers (with the exception of the vdrift author, I guess, since that game runs especially well on Mesa) are loathe to QA their software against any form of Mesa during the development process, and they're also unwilling to support or fix their software to be compatible with Mesa. So if the vendor extensions are out there, and apps are relying upon them, you can either support them, or you can just provide one more reason for people to resent the open source graphics stack.

      Linus Torvalds explains what I'm trying to say in more gruff, but more poignant and accurate words. He's referring to the glibc maintainers, but it could just as easily be applied to people hacking on Mesa who think that not implementing vendor extensions is a bad idea or lowest priority:

      https://bugzilla.redhat.com/show_bug.cgi?id=638477#c129

      Who cares if you have to implement workarounds in software? Make the user call out hex into their microphone if you have to. But for the love of god, don't crash. If someone's GL app crashes, or refuses to start, or hangs their system, this is a problem in Mesa. I don't say this only because you can't fix proprietary programs to use 100% pure, standards compliant GL; I say this also because of the simple fact that, even if the user had the source code sitting on their hard drive, they wouldn't know how to fix it. You have to be a graphics developer (or at least a really crafty software engineer) to fix a problem like this; Joe User can't expect all open source programs to work 100% with Mesa just because they're open source. That's a pipe dream.

      Sure, open source programs are probabilistically more likely to run on Mesa because a developer might try the program with mesa, notice a problem, and fix it in the app rather than the driver, perhaps by writing the code to use a different extension. But who's to prevent an open source developer from writing a GL program that uses loads of vendor extensions not available in Mesa, and then getting that program checked in as binaries to Ubuntu, Fedora and OpenSUSE? It would likely get picked right up, especially if it's popular.

      At that point you're in the same situation regardless of whether the user is running a proprietary or open source app. It doesn't work. It might be the app's fault in principle, but in practice, it's the driver's fault -- especially if the same app binary works on other drivers.

      So why'd I write all this? Because right now I'm trying to add support for GL_ATI_draw_buffers to gallium, which is an extension that (very) closely resembles GL_ARB_draw_buffers, an extension already implemented. Hell, even glDrawBuffersARB is exposed as a public API in libGL. But it isn't advertised, and the shader compiler doesn't recognize it as an OPTION. Trine would run fine if someone would have bothered to write the 10 or 20 lines of code peppered here and there to support it. But now I'm left doing it, and I'm not even a graphics developer. I'm just following patterns I notice in the code, using my knowledge of C and intuition.

      Comment


      • #33
        Originally posted by allquixotic View Post
        Problem being, vendors just keep on
        Linus Torvalds explains what I'm trying to say in more gruff, but more poignant and accurate words. He's referring to the glibc maintainers, but it could just as easily be applied to people hacking on Mesa who think that not implementing vendor extensions is a bad idea or lowest priority:
        Good link.

        Comment


        • #34
          allquixotic,

          No matter what you are trying to point out, all I can say is: Patches welcome.

          Though I find it surprising that there is such a bullshit chat under an article that actually shows Catalyst is worse: 3 graphs show r300g is faster, other 3 graphs show Catalyst is faster, and the other two graphs show Catalyst can't run Nexuiz.

          (BTW, the Hyper-Z optimizations are disabled by default on r300g, so we still might be able to beat Catalyst in openarena and others if we enable them, who knows).

          Thanks to Michael for the article, it keeps us posted about the current state of drivers in a bigger picture.

          Comment


          • #35
            Originally posted by marek View Post
            Old crappy extensions won't be added. Only the extensions which applications need and use will.
            ARB_imaging is 'old and crappy' but is also used by a few applications.

            It's possible that some unused and unadvertised extensions will be removed from Mesa. Like who the hell needs GL_NV_fragment_program?
            Cg, mainly, as well as a few Nvidia demos. I wouldn't be surprised if a few games also utilized it, but GL_ARB_fragment_program should be more than sufficient.

            Originally posted by allquixotic
            Problem being, vendors just keep on introducing new extensions, and application authors just keep on using them.
            Yes, this is called progress. Word it differently and you'll how ridiculous this sounds:

            "Problem being, the Gnome Foundation just keeps on introducing new versions, and application authors just keep on using them."

            "Problem being, Intel just keeps on introducing new processors, and application authors just keep on using them."

            Who the hell needs a quad core SB when you already have a Pentium 200MHz (non-MMX)? (But, but... SB is more capable! Yes, so are those new extensions).

            Originally posted by marek
            Though I find it surprising that there is such a bullshit chat under an article that actually shows Catalyst is worse: 3 graphs show r300g is faster, other 3 graphs show Catalyst is faster, and the other two graphs show Catalyst can't run Nexuiz.

            (BTW, the Hyper-Z optimizations are disabled by default on r300g, so we still might be able to beat Catalyst in openarena and others if we enable them, who knows).

            Thanks to Michael for the article, it keeps us posted about the current state of drivers in a bigger picture.
            Quoted for truth!

            The rest is bullshit from the haters and naysayers who don't miss a chance to bash the open-source drivers.

            Comment


            • #36
              Originally posted by marek View Post
              Though I find it surprising that there is such a bullshit chat under an article that actually shows Catalyst is worse: 3 graphs show r300g is faster, other 3 graphs show Catalyst is faster, and the other two graphs show Catalyst can't run Nexuiz.
              Marek, you (and the other devs) have killed most of the anti-OSS "arguments" people like to spout around here.

              They are getting desperate, which is just beautiful to see

              Comment


              • #37
                Originally posted by marek View Post
                (BTW, the Hyper-Z optimizations are disabled by default on r300g, so we still might be able to beat Catalyst in openarena and others if we enable them, who knows).
                Is this something users can enable somehow?

                Comment


                • #38
                  Set this environment variable:

                  RADEON_HYPERZ=1

                  It's worth mentioning it really speeds up openarena. You can also set this to get info whether it's actually used:

                  RADEON_DEBUG=info

                  The latter is available only in 7.11-devel IIRC and it prints something like this:

                  r300: AA compression: NO, Z compression: YES, HiZ: YES

                  The text in bold is the Hyper-Z status. We don't enable it by default because of some bugs, but most apps should work fine. If you find a bug, please report it at https://bugs.freedesktop.org/

                  Comment


                  • #39
                    Originally posted by marek View Post
                    Set this environment variable:

                    RADEON_HYPERZ=1

                    It's worth mentioning it really speeds up openarena. You can also set this to get info whether it's actually used:

                    RADEON_DEBUG=info

                    The latter is available only in 7.11-devel IIRC and it prints something like this:

                    r300: AA compression: NO, Z compression: YES, HiZ: YES

                    The text in bold is the Hyper-Z status. We don't enable it by default because of some bugs, but most apps should work fine. If you find a bug, please report it at https://bugs.freedesktop.org/
                    Do you know when these things will get 'ported' to r600g? Or are they not needed / supported by the hardware?

                    Comment


                    • #40
                      Originally posted by tball View Post
                      Do you know when these things will get 'ported' to r600g? Or are they not needed / supported by the hardware?
                      The r600 hardware can do it, but the code to get it running is very hardware-specific. Some ideas are the same, but very little (if any) code can be shared. I guess we will have to write it from scratch.

                      Comment

                      Working...
                      X