Announcement

Collapse
No announcement yet.

53 Patches Published For Gallium3D's Direct3D 9 Support

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

  • #41
    Originally posted by mannerov View Post
    It's not true anymore.

    Since Fedora wanted to ship Gallium Nine support, we made patches to have a DRI2 fallback. So it'll work with DRI2 (but there is a small perf hit)
    Cool! Just checked it - Nine works again! Thank you!

    As I understand it still misses some features (?), because for example Flatout 2 doesn't start when Nine is enabled with message "Failed to create effect: data/shaders/pro_static2x.sha", and if I copy native windows d3dx9_30.dll to flatout folder it starts but cars are black. Should I file a bug for this issue?

    NFS Underground and Underground 2 also don't start with Nine with the following message:

    ../../../../../../src/gallium/drivers/r600/r600_state.c:1076:r600_init_depth_surface: Assertion `format != ~0' failed.

    Comment


    • #42
      Originally posted by vitalif View Post
      Cool! Just checked it - Nine works again! Thank you!

      As I understand it still misses some features (?), because for example Flatout 2 doesn't start when Nine is enabled with message "Failed to create effect: data/shaders/pro_static2x.sha", and if I copy native windows d3dx9_30.dll to flatout folder it starts but cars are black. Should I file a bug for this issue?

      NFS Underground and Underground 2 also don't start with Nine with the following message:

      ../../../../../../src/gallium/drivers/r600/r600_state.c:1076:r600_init_depth_surface: Assertion `format != ~0' failed.
      The first flatout message is due to missing d3dx9_30.dll functions. That part is entirely in wine, and nine only replaces d3d9.dll
      We solved a lot of black thing issue recently, but there are some remaining ones. Probably going to be fixed in some time.

      For NFS, it means it uses a depth stencil format without checking its support first, but that the card doesn't support it.
      That means all vendors are supporting the format and that NFS doesn't even check.
      Checking the formats r600 actually support, I think I know what common format NFS could be trying to use. it's a format
      radeonsi support, so it was more difficult to notice.
      What we map for the d3d9 depth format to gallium depth format doesn't matter that much, because applications are not allowed
      to read the content with a pointer (or write to it). That's why wine for example maps a lot of depth formats to gl formats that aren't
      really matching, but it works.
      If you are willing to try out more, I can send you a patch, and you would tell me if it fixes it for you.

      Comment


      • #43
        Originally posted by mannerov View Post
        The first flatout message is due to missing d3dx9_30.dll functions. That part is entirely in wine, and nine only replaces d3d9.dll
        We solved a lot of black thing issue recently, but there are some remaining ones. Probably going to be fixed in some time.

        For NFS, it means it uses a depth stencil format without checking its support first, but that the card doesn't support it.
        That means all vendors are supporting the format and that NFS doesn't even check.
        Checking the formats r600 actually support, I think I know what common format NFS could be trying to use. it's a format
        radeonsi support, so it was more difficult to notice.
        What we map for the d3d9 depth format to gallium depth format doesn't matter that much, because applications are not allowed
        to read the content with a pointer (or write to it). That's why wine for example maps a lot of depth formats to gl formats that aren't
        really matching, but it works.
        If you are willing to try out more, I can send you a patch, and you would tell me if it fixes it for you.
        Thanks, send the patch to vitalif %at% mail ru, I'll check it

        Comment


        • #44
          Originally posted by curaga View Post
          ..except native 2d acceleration and support for not tearing. Glamor is not enough.
          There is no native 2d hardware on any modern AMD GPUs.

          Originally posted by darkbasic View Post
          He knows, he was simply arguing that glamor sucks so much to not even be considerated "acceleration"
          What? My 2d is butter smooth and tear-free with glamor, I even use it instead of EXA with r600g. Not using a compositor is your own fault: Compositing is faster than no compositing on modern hardware and Wayland will require it.

          Comment


          • #45
            Originally posted by TAXI View Post
            There is no native 2d hardware on any modern AMD GPUs.
            He knows

            Originally posted by TAXI View Post
            What? My 2d is butter smooth and tear-free with glamor, I even use it instead of EXA with r600g. Not using a compositor is your own fault: Compositing is faster than no compositing on modern hardware and Wayland will require it.
            Since when do you use glamor? I used it long enough to know why lots of people get hives when they hear "glamor". Glamor was a completely different beast at the early radeonsi stages and some hatred developed towards it, even if it works fine now
            ## VGA ##
            AMD: X1950XTX, HD3870, HD5870
            Intel: GMA45, HD3000 (Core i5 2500K)

            Comment


            • #46
              Originally posted by TAXI View Post
              Not using a compositor is your own fault: Compositing is faster than no compositing on modern hardware and Wayland will require it.
              Yes, it is my choice. Under X compositing means an extra layer of software, an extra memory copy before display. Under Wayland this is not so, no extra copy there, but Wayland won't be ready for another five years (gut feeling, happy to be proven wrong).

              We're extremely lucky now that we can pick between *multiple* open-source vendors based on smaller criteria like this. My next GPU will be an Intel since it doesn't need a compositor under X to not tear. If hw A requires less software than hw B, everything else being equal, I will buy (and recommend to others) hw A

              (I'm also disliking everything GCN-based because of the choice to go with LLVM - it is greatly slower to compile than r600sb which in turn is greatly slower than the without-sb compiler. Not to mention a huge dependency, huge on disk, and in RAM. Stutters in games due to compile pauses suck, and glamor means you also have those stutters in 2d use.)

              Comment


              • #47
                Originally posted by curaga View Post
                My next GPU will be an Intel since it doesn't need a compositor under X to not tear.
                Are you sure Intel hardware does not need compositing for tear-free? Intel devs seem to think otherwise (http://www.phoronix.com/forums/showt...ht=#post346637).

                And as far as I know all video cards launched after M$ released Windows Vista are designed to work only with compositing as that's how Windows is going to use it.

                Comment


                • #48
                  Originally posted by Ansla View Post
                  Are you sure Intel hardware does not need compositing for tear-free? Intel devs seem to think otherwise (http://www.phoronix.com/forums/showt...ht=#post346637).

                  And as far as I know all video cards launched after M$ released Windows Vista are designed to work only with compositing as that's how Windows is going to use it.
                  Intel driver has built-in compositor which is disabled by default.
                  Option "TearFree" "boolean"
                  Disable or enable TearFree updates. This option forces X to perform all rendering to a backbuffer prior to updating the actual display. It requires an extra memory allocation the same size as a framebuffer, the occasional extra copy, and requires Damage tracking. Thus
                  enabling TearFree requires more memory and is slower (reduced throughput) and introduces a small amount of output latency, but it should not impact input latency. However, the update to the screen is then performed synchronously with the vertical refresh of the display
                  so that the entire update is completed before the display starts its refresh. That is only one frame is ever visible, preventing an unsightly tear between two visible and differing frames. Note that this replicates what the compositing manager should be doing, however
                  TearFree will redirect the compositor updates (and those of fullscreen games) directly on to the scanout thus incurring no additional overhead in the composited case. Also note that not all compositing managers prevent tearing, and if the outputs are rotated, there will
                  still be tearing without TearFree enabled.

                  Default: TearFree is disabled.

                  Comment


                  • #49
                    Originally posted by darkbasic View Post
                    He knows
                    Then I really don't understand what he meaned with "native 2d".

                    Since when do you use glamor? I used it long enough to know why lots of people get hives when they hear "glamor". Glamor was a completely different beast at the early radeonsi stages and some hatred developed towards it, even if it works fine now
                    I tried it a few times before it got included into xorg and am using it on my "stable" machines since xorg 1.16, so I remeber the "different beast" but as you said: times change.

                    Originally posted by JS987 View Post
                    Intel driver has built-in compositor
                    So he wants to avoid using a compositor by using a compositor? Sounds logical...

                    Comment


                    • #50
                      Originally posted by TAXI View Post
                      I tried it a few times before it got included into xorg and am using it on my "stable" machines since xorg 1.16, so I remeber the "different beast" but as you said: times change.
                      Yes, but you didn't *HAVE* to use it like radeonsi users. Also beware that even before the inclusion it got quite decent in recent times.
                      ## VGA ##
                      AMD: X1950XTX, HD3870, HD5870
                      Intel: GMA45, HD3000 (Core i5 2500K)

                      Comment

                      Working...
                      X