Announcement

Collapse
No announcement yet.

53 Patches Published For Gallium3D's Direct3D 9 Support

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

  • #51
    Originally posted by darkbasic View Post
    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.
    Also...

    (a) initial exa acceleration for radeonsi would probably have been iffy for a while anyways because we would have had to start from scratch with both the exa code and the hand-written shaders... feeling was that even with glamor's limitations at the time the performance wouldn't be much different from an early EXA implementation

    (b) as agd5f and others said, the reason for choosing glamor was that it had the potential to accelerate more of the drawing operations being done today than exa and deliver better overall performance

    Comment


    • #52
      Originally posted by TAXI View Post
      Then I really don't understand what he meaned with "native 2d".
      Direct code, ie not GL shaders. Written in the native asm. It avoids the compile stutter and extra cpu use.

      So he wants to avoid using a compositor by using a compositor? Sounds logical...
      Intel's approach to tearfree is less efficient than radeon's, but it's still more efficient than a standalone compositor program.

      Comment


      • #53
        Originally posted by curaga View Post
        Direct code, ie not GL shaders. Written in the native asm. It avoids the compile stutter and extra cpu use.



        Intel's approach to tearfree is less efficient than radeon's, but it's still more efficient than a standalone compositor program.
        You can still choose to contribute patches to resolve the compile stutter issue.
        I guess all shaders would have to be compiled at the initialisation of glamor.
        Also perhaps you can make use of GL_ARB_separate_shader_objects, which allows, like for d3d, to use a vertex shader with several pixel shaders and vice versa without having to link again (no recompilation), but I don't think that's the problem of glamor

        Comment


        • #54
          Originally posted by mannerov View Post
          You can still choose to contribute patches to resolve the compile stutter issue.
          That would involve rewriting LLVM. Hardly a job for one person, even if I cared enough & had such hw.

          I guess all shaders would have to be compiled at the initialisation of glamor.
          Also perhaps you can make use of GL_ARB_separate_shader_objects, which allows, like for d3d, to use a vertex shader with several pixel shaders and vice versa without having to link again (no recompilation), but I don't think that's the problem of glamor
          Compiling in the GL sense helps nothing, because the driver does a separate compile on first use. That is the cause of stutter.

          Comment


          • #55
            Originally posted by curaga View Post
            That would involve rewriting LLVM. Hardly a job for one person, even if I cared enough & had such hw.



            Compiling in the GL sense helps nothing, because the driver does a separate compile on first use. That is the cause of stutter.
            Are you really sure it's the driver ?
            Wit gallium Nine and radeonsi, I really don't the the impression it does recompile at first use, but rather that everything is compiled at start of the program (which is what debug info says)

            Comment


            • #56
              Originally posted by bridgman View Post
              Also...

              (a) initial exa acceleration for radeonsi would probably have been iffy for a while anyways because we would have had to start from scratch with both the exa code and the hand-written shaders... feeling was that even with glamor's limitations at the time the performance wouldn't be much different from an early EXA implementation

              (b) as agd5f and others said, the reason for choosing glamor was that it had the potential to accelerate more of the drawing operations being done today than exa and deliver better overall performance
              I'm fine with the glamor choice, but why the hell did you have to wait for Intel (Keith Packard) to fix it? You should have been writing the EXA code anyway if it wasn't for glamor, so why not fixing at least the bigger glamor bottlenecks? Or at least giving your users some fallbacks in the meantime... Intel already had their glamor fallbacks for their driver since ages, and they didn't even need it because they already had both EXA and SNA for daily use
              Last edited by darkbasic; 10 January 2015, 08:37 AM.
              ## VGA ##
              AMD: X1950XTX, HD3870, HD5870
              Intel: GMA45, HD3000 (Core i5 2500K)

              Comment


              • #57
                Hmmm... so how can I compile Wine with DRI2 fallback support? Atm I get DRI3 error during compilation (compiling from this pkgbuild on Arch).
                Last edited by gutigen; 10 January 2015, 08:40 AM.

                Comment


                • #58
                  Originally posted by gutigen View Post
                  Hmmm... so how can I compile Wine with DRI2 fallback support? Atm I get DRI3 error during compilation (compiling from this pkgbuild on Arch).
                  The PKGBUILD seems a little outdated. I'm no expert, mind you, but what I did to get it to build was:
                  * replaced lines containing '../$pkgname/configure --with-d3dadapter9 \' with '../$pkgname/configure --with-d3dadapter --with-d3dadapter-dri2-fallback \'
                  * added 'dri2proto' to makedepends (without it you get an error complaining about 'dri2tokens.h' being missing)
                  * I also added 'dri3proto' and 'presentproto' to makedepends (I'm not sure if these packages are actually required, I was tired and wanted wine to actually build without throwing errors and failing after 15+ minutes of compiling)

                  Also, you could remove either line 42 or 52, because they seem to contain the same thing (libxcomposite and lib32-libxcomposite).

                  Comment


                  • #59
                    Originally posted by gutigen View Post
                    Hmmm... so how can I compile Wine with DRI2 fallback support? Atm I get DRI3 error during compilation (compiling from this pkgbuild on Arch).
                    You are probably missing dri3 headers. The wine build is not yet perfect, and the configure phase should be improved, for example to tell you you need these headers.

                    Comment


                    • #60
                      Originally posted by andy_v View Post
                      The PKGBUILD seems a little outdated. I'm no expert, mind you, but what I did to get it to build was:
                      * replaced lines containing '../$pkgname/configure --with-d3dadapter9 \' with '../$pkgname/configure --with-d3dadapter --with-d3dadapter-dri2-fallback \'
                      * added 'dri2proto' to makedepends (without it you get an error complaining about 'dri2tokens.h' being missing)
                      * I also added 'dri3proto' and 'presentproto' to makedepends (I'm not sure if these packages are actually required, I was tired and wanted wine to actually build without throwing errors and failing after 15+ minutes of compiling)

                      Also, you could remove either line 42 or 52, because they seem to contain the same thing (libxcomposite and lib32-libxcomposite).
                      Native Direct3D 9 is active.

                      Thank you!

                      Perhaps it would make sense to update those pkgbuilds for Nine? If maintainer or someone related reads this ofc.

                      Comment

                      Working...
                      X