Announcement

Collapse
No announcement yet.

Open-Source "Terakan" Vulkan Driver For Radeon HD 6000 Series Shown On Windows

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

  • #21
    Originally posted by Developer12 View Post
    So many people seem to have caught michael's terminal benchmarker-brain syndrome.
    Vulkan is rapidly becoming the *only* graphics API used on linux. Not just for high-spec games but for everything from window managers to gui toolkits and from there to regular old productivity tools, misc config menus, and random stuff like that. SDL is used for a lot of random boring apps, not just games. What happens if/when they deprecate openGL entirely? That's totally on the table for the next 5-10 years.
    Most of the stuff the average user runs on a linux desktop is perfectly capable of being run with *software rendering* if push comes to shove, but when more and more stuff is deprecating the openGL backend a vulkan implementation becomes mandatory. At that point anyone with this older hardware has to choose between this GPU-accelerated vulkan solution and the vulkan equivalent of LLVM-pipe. Clearly, having an implementation of vulkan with at least *basic* GPU acceleration is preferable.
    exactly i have such a radeon HD6870 and the only reason this card is no longer in use its surprise surprise not performance its compatibility with vulkan.

    ok you can replace a PCIe card in a normal PC but what about notebooks ? mans such old notebooks are still in use. and most of them can not switch the gpu.
    Phantom circuit Sequence Reducer Dyslexia

    Comment


    • #22
      Originally posted by Dukenukemx View Post
      The main benefit to having a Vulkan driver for these GPU's is not to run games like Baldur's Gate 3, but to run DX11 games which these GPU's were meant for. Not a problem on Windows and you can even install the Omega Drivers to get a more modern driver for this older GPU's. On Linux you can do DX11->OpenGL but that's not very good for performance. I'm not even sure if FP64 support was ever added to these GPU's? There are also a number of games that might benefit from Vulkan on these GPU's, like Hollow Knight. Don't forget emulators.
      right vulkan is the only way on linux to play DX11 games permanently. dx11 to openGL is very slow.
      Phantom circuit Sequence Reducer Dyslexia

      Comment


      • #23
        Originally posted by Tomin View Post
        I wonder which kernel driver this uses.
        It currently supports DRM Radeon 2.50.0 (but I'm planning to make some kernel changes such as fixing the address relocations involved in DISPATCH_INDIRECT, but they will be optional — vkCmdDispatchIndirect on R8xx will be handled on 2.50.0, where it's totally broken, by splitting command buffer submissions and awaiting and reading the needed grid size on the CPU just like currently in R600g, very slow, but better than nothing), and there's prototype-level support for the Crimson Edition beta driver on Windows (but there I've only tested Terakan on a single discrete R8xx GPU in 64-bit applications). I'm also planning to add support for the last WHQL Catalyst driver, the last FirePro drivers, and also to check if Catalyst 13.12 on Windows Vista provides all the necessary functionality.

        Originally posted by willmore View Post
        Anyone know where this coder is located? I've got a colection of 6000 cards in NA that I'd be willing to donate if they want them. International shipping is prohibitive, though.
        I'm in Russia, but I think it would be more beneficial if the driver was tested by different users when it's closer to a practically usable state (it's still missing around a half of the baseline functionality), to cover more apps and usage scenarios — but thanks for the offer anyway. Eventually, when my two R8xx and R9xx graphics cards become insufficient, I'm planning to get a few more testing devices, specifically Llano and Trinity APUs, more CrossFire setups (HD 5970, and maybe multiple graphics cards — though true device group support is outside my plans currently, but need to handle them properly in memory allocation on Windows), early "Cypress" chip revisions (HD 5870) for potential hardware bugs, and FirePro GPUs that have a separate driver package on Windows, as well as a single-GPU HD 69xx, and maybe a different HD 6990 since mine behaves weirdly, randomly disabling the PCI Express port until I perform a CMOS reset.

        Originally posted by Dukenukemx View Post
        I'm not even sure if FP64 support was ever added to these GPU's?
        Are you referring to hardware or to software support? FP64 is actually very fast on TeraScale, some of the instructions are half-rate (two-slot, to be more precise), some are quarter-rate — a nice property GCN gaming GPUs didn't keep except for some early GCN 1.0 chips. I don't know how well it's actually supported by AMD's own drivers, though since the instructions are there, I'd expect them to actually be used. Unfortunately, the shader compiler in the Gallium R600g driver (that I'm also using in Terakan) only supports hardware FP64 on the VLIW4 R9xx, falling back to software emulation on VLIW5. I'm not sure why though given that the slot assignment rules for FP64 appear to be at least mostly the same between VLIW5 and VLIW4, maybe co-issuing of FP64 operations with another instruction in the transcendental slot isn't working as desired yet, but I think gerddie may implement it in the future.

        Originally posted by Eirikr1848 View Post
        My 17” 2011 MacBook Pro yearns for the day it can play some games again on Linux with Proton using ye olde Vulkan wrapper.
        Are you suggesting detouring some calls to IOKit or whatever user-mode graphics drivers use there? 👀​
        Last edited by Triang3l; 23 April 2024, 05:59 PM. Reason: Clarified that R600g uses software FP64 emulation on R8xx

        Comment


        • #24
          Originally posted by Triang3l View Post
          It currently supports DRM Radeon 2.50.0​
          i have some questions. where did you get the idea to write this vulkan driver ?
          also do you get any money from this ? do you have a sponsor ?
          do you have some way so that people can send you money for your work ?
          for me you are really a true hero against planet obsolescence and obsolescence in general.

          because the directX11 to OpenGL Codepath in wine is so slow Vulkan is really the only way to play DX11 games permanently on vulkan. this means your driver is a true win for these cards.

          and i really don't unterstand why all the people believe this kind of hardware is so slow but its pretty clear that a HD6870 or HD7950 is not slow hardware.

          many games are still on the level of DX11 games ... more or less these cards only become obsolete because of no vulkan support.

          your work is really nice. i hope its a start of a successful career.
          Phantom circuit Sequence Reducer Dyslexia

          Comment


          • #25
            Originally posted by Triang3l View Post
            Are you referring to hardware or to software support? FP64 is actually very fast on TeraScale, some of the instructions are half-rate (two-slot, to be more precise), some are quarter-rate — a nice property GCN gaming GPUs didn't keep except for some early GCN 1.0 chips. I don't know how well it's actually supported by AMD's own drivers, though since the instructions are there, I'd expect them to actually be used. Unfortunately, the shader compiler in the Gallium R600g driver (that I'm also using in Terakan) only supports hardware FP64 on the VLIW4 R9xx, falling back to software emulation on VLIW5. I'm not sure why though given that the slot assignment rules for FP64 appear to be at least mostly the same between VLIW5 and VLIW4, maybe co-issuing of FP64 operations with another instruction in the transcendental slot isn't working as desired yet, but I think gerddie may implement it in the future.​
            FP64 is only supported in hardware on a subset of the Terascale chips.

            Comment


            • #26
              Originally posted by qarium View Post

              i have some questions. where did you get the idea to write this vulkan driver ?
              also do you get any money from this ? do you have a sponsor ?
              do you have some way so that people can send you money for your work ?
              Vulkan was initially carefully designed to be implementable on any GPU supporting OpenGL ES 3.1, and I thought that Direct3D 11-compatible GPUs would be well above that bar (although in reality I've already been encountering some very scary requirements related to texture layouts, which are mostly relevant to the maintenance extensions, but so far there haven't been any hard blockers), so the lack of Vulkan support on those GPUs seemed like an interesting gap to fill.

              The idea of writing your own driver for some graphics API for some GPUs that don't have it yet seemed tempting overall — and since I already have experience with TeraScale's feature incubator architecture ATI R400 in the Xenia Xbox 360 emulator, ATI/AMD was the obvious choice. Plus, I want to expand hardware support of Xenia itself, but it's written to take advantage of explicit-style API features (such as vkCmdCopyBufferToImage, pipeline state object caching, separate GPU emulation and UI threads), so I didn't want to bother with OpenGL or Direct3D 11 in it.

              What finally made me get a TeraScale graphics card was that while finishing my implementation of fragment shader interlock for RADV (another important feature for Xenia… with a long and fun story about AMD's complicated relationship with fragment shader interlock, and finally apparently truly coming to an end looking at one recent LLVM pull request), I was looking for what else could be done in Mesa, and saw some OpenGL 4.6 support tasks in R600g — one thing that was particularly interesting was GL_ARB_shader_group_vote for which I posted some pseudocode ideas (although I still haven't tried writing the code for it due to how unusual the control flow involved in it is).

              I was also initially considering trying to support R6xx/R7xx, but they don't provide storage images, buffer/image and group-shared memory atomics, and multiple storage buffer bindings, all of which are mandatory in Vulkan. Though even on R8xx/R9xx game compatibility is expected to be low (but possibly should be fine for running DXVK, maybe with some UAV binding logic changes due to 8 UAV append/consume counters not fitting into the hardware UAV count limit of 12 alongside the resources themselves as Vulkan doesn't have them natively as part of UAVs unlike D3D11) as they can't support two features commonly used in games: no large arrays of bindless textures (resources are bound to fixed slots, with the limits in practice being close to D3D11.0's ones like 128 textures/buffers for reading per shader stage); and also subgroup operations aren't exactly straightforward, they'd need to be done through the LDS, but all of the LDS space in a compute shader can be used by group-shared memory.

              It's entirely a free time project, and I'm not intending to accept any donations/funding for it as I feel like that'd be kind of binding with regard to feature priorities and deadlines.
              Last edited by Triang3l; 23 April 2024, 08:24 PM.

              Comment


              • #27
                Originally posted by Triang3l View Post
                Are you referring to hardware or to software support? FP64 is actually very fast on TeraScale, some of the instructions are half-rate (two-slot, to be more precise), some are quarter-rate — a nice property GCN gaming GPUs didn't keep except for some early GCN 1.0 chips. I don't know how well it's actually supported by AMD's own drivers, though since the instructions are there, I'd expect them to actually be used. Unfortunately, the shader compiler in the Gallium R600g driver (that I'm also using in Terakan) only supports hardware FP64 on the VLIW4 R9xx, falling back to software emulation on VLIW5. I'm not sure why though given that the slot assignment rules for FP64 appear to be at least mostly the same between VLIW5 and VLIW4, maybe co-issuing of FP64 operations with another instruction in the transcendental slot isn't working as desired yet, but I think gerddie may implement it in the future.
                I'm referring to some of the HD 6000 cards that only had fp64 support through software. This makes it so these cards don't officially support newer version of OpenGL. I know there was work being done to implement soft fp64, but I don't know if that was ever finished.

                Comment


                • #28
                  Originally posted by Triang3l View Post
                  The idea of writing your own driver for some graphics API for some GPUs that don't have it yet seemed tempting overall — and since I already have experience with TeraScale's feature incubator architecture ATI R400 in the Xenia Xbox 360 emulator, ATI/AMD was the obvious choice. Plus, I want to expand hardware support of Xenia itself, but it's written to take advantage of explicit-style API features (such as vkCmdCopyBufferToImage, pipeline state object caching, separate GPU emulation and UI threads), so I didn't want to bother with OpenGL or Direct3D 11 in it.

                  What finally made me get a TeraScale graphics card was that while finishing my implementation of fragment shader interlock for RADV (another important feature for Xenia… with a long and fun story about AMD's complicated relationship with fragment shader interlock, and finally apparently truly coming to an end looking at one recent LLVM pull request), I was looking for what else could be done in Mesa, and saw some OpenGL 4.6 support tasks in R600g — one thing that was particularly interesting was GL_ARB_shader_group_vote for which I posted some pseudocode ideas (although I still haven't tried writing the code for it due to how unusual the control flow involved in it is).
                  So this is a byproduct of working on Xenia?
                  I was also initially considering trying to support R6xx/R7xx, but they don't provide storage images, buffer/image and group-shared memory atomics, and multiple storage buffer bindings, all of which are mandatory in Vulkan.
                  Anyone who has a DX10 level ATI GPU can probably get away with using Gallium Nine. DX10 features were never really tempting anyway, due to the massive performance loss.

                  Comment


                  • #29
                    Originally posted by Triang3l View Post
                    It's entirely a free time project, and I'm not intending to accept any donations/funding for it as I feel like that'd be kind of binding with regard to feature priorities and deadlines.
                    i am pretty sure that if someone donate money to you they do not expect deadlines and bindung features.

                    some people donate money only based on your past actions. without any future expectations.
                    Phantom circuit Sequence Reducer Dyslexia

                    Comment


                    • #30
                      Originally posted by Dukenukemx View Post
                      So this is a byproduct of working on Xenia?
                      Anyone who has a DX10 level ATI GPU can probably get away with using Gallium Nine. DX10 features were never really tempting anyway, due to the massive performance loss.
                      any card who can not at minimum do DX11 is more or less EOL.. end of life.

                      as you say DX10 was never a hit and DX9 title are really old ,
                      Phantom circuit Sequence Reducer Dyslexia

                      Comment

                      Working...
                      X