Announcement

Collapse
No announcement yet.

Wine "PBA" Shows Potential For Improving Direct3D-Over-OpenGL Performance

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

  • #11
    Originally posted by pal666 View Post
    what games have licensed wow's engine?
    I meant its quality. It's up-to-par. It's an example. That kind of industry standard. The kind of coding standard other engines might do well following.

    Comment


    • #12
      Originally posted by artivision View Post
      Do not assume here that the other WineD3D devs are bad programmers. They just have made the wrong decision to make WineD3D9 compatible with the equivalent OGL version which i think is OGL2 or hardly 3 and surely not 4.3-4.4. The correct thing is to keep the old compatibility and have an expansion 'speed' set only for those with newer GPUs.
      GL_ARB_buffer_storage is opengl 4.4 Also this was not support in a lot of drivers until recently in 2013.

      Mesamatrix shows you something intereseting.
      Show Mesa progress for the OpenGL, OpenGL ES, Vulkan and OpenCL drivers implementations into an easy to read HTML page.

      Radeon HD 2000 series what is R600 is from 2007 and it support opengl 4.4 finally as of 2 months ago .

      But when you go cross platform for likes of Android hello being restricted to opengl 3.3 hello 2010.

      Do note Microsoft documentation for Dx 9 for XP documents operating buffers in the GL_ARB_buffer_storage way. So feature you could do in direct x 9 in 2002 you can only do in opengl 4.4 after 2013 and its taken 4+ years for it to become common and wine developers missed seeing it. With number of bugs this happens.

      Its items like GL_ARB_buffer_storage not being implemented thinking how long Nvidia closed source drivers have had it shows that wine developers have not exactly been focusing on Nvidia.

      This is one of the big traps you need never versions of opengl to have all the features that older versions of direct x had.

      Comment


      • #13
        Originally posted by debianxfce View Post
        Technically android is a flop, it does not roll and uses old software. It is not open, it is quite difficult to make your own distribution to an android phone. Android does have many apps, there is no need to run virus hoover apps there. So wine developers should drop android support and focus to desktop Linux distributions.
        Not one of those points means that codeweavers behind wine will not get money by providing support for Android to allow companies to deprecate their old windows tablets.

        There are a lot of company only applications that don't work on Android.

        Really you a bias to the Linux Desktop not think how the Codeweavers has to think about to get money to keep the infrastructure for testing and development of wine ticking over.

        So your idea of drop Android support means less money for wine operations. A lot of Linux users don't pay for wine. It why supporting OS X and now Android is being important. Its all comes about how to fund the project.

        Comment


        • #14
          Originally posted by oiaohm View Post

          GL_ARB_buffer_storage is opengl 4.4 Also this was not support in a lot of drivers until recently in 2013.

          Mesamatrix shows you something intereseting.
          Show Mesa progress for the OpenGL, OpenGL ES, Vulkan and OpenCL drivers implementations into an easy to read HTML page.

          Radeon HD 2000 series what is R600 is from 2007 and it support opengl 4.4 finally as of 2 months ago .

          But when you go cross platform for likes of Android hello being restricted to opengl 3.3 hello 2010.

          Do note Microsoft documentation for Dx 9 for XP documents operating buffers in the GL_ARB_buffer_storage way. So feature you could do in direct x 9 in 2002 you can only do in opengl 4.4 after 2013 and its taken 4+ years for it to become common and wine developers missed seeing it. With number of bugs this happens.

          Its items like GL_ARB_buffer_storage not being implemented thinking how long Nvidia closed source drivers have had it shows that wine developers have not exactly been focusing on Nvidia.

          This is one of the big traps you need never versions of opengl to have all the features that older versions of direct x had.
          You're oversimplifying.

          First, you need to check when the extension existed as an extension to a prior OpenGL version, rather than being a mandatory part. (In this case, not a big difference. OpenGL 4.4 came out shortly after it was approved and ratified.)

          Second, you need to track down the vendor-specific OpenGL extension that it's probably based on. (Similar to how AMD's Mantle evolved into Vulkan and DisplayPort Adaptive Sync evolved from AMD FreeSync.)

          It wouldn't surprise me if nVidia or ATi exposed the same functionality through NV_* and/or ATI_* extensions during the DirectX 9 era since the hardware was already made, they don't have to get approval for their own OpenGL extension namespaces, and it made the hardware more attractive to any OpenGL-using potential buyers.

          That's why OpenGL tends to be better than DirectX for in-house applications where you don't have to support a broad user base. GPU manufacturers can implement functionality and push out OpenGL extensions for it immediately, but they have to wait on Microsoft to release a new DirectX version.

          Comment


          • #15
            It's cool and all but we do have Gallium Nine and soon VK9. This will be good in the mean time for those none AMD and none Vulkan capable graphic cards.

            Comment


            • #16
              Originally posted by ssokolow View Post
              Second, you need to track down the vendor-specific OpenGL extension that it's probably based on. (Similar to how AMD's Mantle evolved into Vulkan and DisplayPort Adaptive Sync evolved from AMD FreeSync.)

              Prior art has to be listed in the extension application. This extension there is no prior. Really the document above also shows it did not exist before 2013 or opengl 4.4.

              I had not over simplified. There was no NV_ or ATI_ of this feature.

              Originally posted by ssokolow View Post
              That's why OpenGL tends to be better than DirectX for in-house applications where you don't have to support a broad user base. GPU manufacturers can implement functionality and push out OpenGL extensions for it immediately, but they have to wait on Microsoft to release a new DirectX version.
              This is a presume that Opengl would always have all the features of the hardware because hardware vendors are free to extend. But items like GL_ARB_buffer_storage that exposes a feature from Dx 8/9 from 2002 and slightly before only in Opengl in 2013 shows that vendors don't always extend. This also explains some of the trouble wined3d has making direct x perform is having to work around missing features.

              Comment


              • #17
                Originally posted by debianxfce View Post
                Companies do not use android tablets, they are toys that breaks easily. Companies do buy new rugged windows tablets and you can run Linux distribution in them. Chuwi and other Chinese do make cheap intel based dual boot tablets and you can run Linux distribution with them easily.

                Grow a clue. There are companies out there using Rugged Android tablets and devices. They don't break easily. So there is a market for what codeweavers is up-to just you are clueless to it. Claiming companies don't use android tablets is being clueless.

                Comment


                • #18
                  Originally posted by Dukenukemx View Post
                  It's cool and all but we do have Gallium Nine and soon VK9. This will be good in the mean time for those none AMD and none Vulkan capable graphic cards.
                  I would say we don't have any gallium dx. Nine is not actively developed and not usable in normal wine. This prevents testing and attracting more people. Also ite usefulness is questionable. Vulkan will make this unnecessary and so will the move to higher versions of DirectX.

                  Comment


                  • #19
                    Originally posted by artivision View Post
                    Do not assume here that the other WineD3D devs are bad programmers. They just have made the wrong decision....
                    Good programmers tend to make good decisions in my observations.

                    Comment


                    • #20
                      Originally posted by bemerk View Post

                      I would say we don't have any gallium dx. Nine is not actively developed and not usable in normal wine. This prevents testing and attracting more people. Also ite usefulness is questionable. Vulkan will make this unnecessary and so will the move to higher versions of DirectX.
                      Who uses normal Wine? It's so bad that I refuse to upgrade to Wine 3.0 over Wine-Staging. I would lose too much in doing this. Also, as good as VK9 will be, it won't be better than Gallium-Nine. This would be a good alternative for Nvidia users cause generally they don't use Nouveau, but for AMD users Gallium Nine is the better option. DirectX 11 over Vulkan is also a good idea, and one I'm excited for. If there was a Gallium Eleven, I would also use that over Vulkan.

                      Comment

                      Working...
                      X