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

  • qarium
    replied
    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.

    Leave a comment:


  • Triang3l
    replied
    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

    Leave a comment:


  • qarium
    replied
    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.

    Leave a comment:


  • qarium
    replied
    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.

    Leave a comment:


  • Eirikr1848
    replied
    Originally posted by dragorth View Post
    There are 2011 MacBooks running HD6000 era GPUs. 12 year old hardware is fine for most purposes, it is us that are pushing the envelope, most people aren't.
    My 17” 2011 MacBook Pro yearns for the day it can play some games again on Linux with Proton using ye olde Vulkan wrapper.

    Leave a comment:


  • Eirikr1848
    replied
    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.
    The formerly named Amermine Zone / NimeZ drivers do some tinkering magic on windows as well. Not sure if you can do hybrid Amermine Zone + Omega - but maybe?

    Leave a comment:


  • dragorth
    replied
    There are 2011 MacBooks running HD6000 era GPUs. 12 year old hardware is fine for most purposes, it is us that are pushing the envelope, most people aren't.

    Leave a comment:


  • lowflyer
    replied
    Even if this driver will never achieve a real-world use, The experience this coder gathered through this exercise is priceless!

    BTW: I've still got a 6450 and two 6950 cards lying around.

    Leave a comment:


  • dragorth
    replied
    Originally posted by mxan View Post

    There is no compatibility layer, Mesa runs entirely in userspace. The DRM (kernel side drivers) are mostly developed by the same people developing Mesa, but they are developed officially as part of Linux not as part of Mesa, and there are no compatibility layers there either, they are just ported straight to the BSDs.
    I may be confusing the *BSD solutions with GenodeOS who calls their Linux driver stack a compatibility layer. Thanks for the correction.

    Leave a comment:


  • willmore
    replied
    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.

    Leave a comment:

Working...
X