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

[agd5f]

Am I correct that among EG/NI, those are Cypress/Hemlock, Cayman and Aruba? Those chips have FeatureFMA enabled in LLVM, and according to the ISA documentation, FP32 FMA is present if FP64 operations are supported, and also the R600g PIPE_CAP_DOUBLES query code, while returning 1 for all EG/NI chips due to the software implementation, has another semi-leftover conditional specifically for those chips. Or are there some additions/exception to this?

It's been a while, but IIRC, the following terascale chips support FP64:
RV670
RV770
Cypress/Hemlock
Cayman
Aruba

[Triang3l]

FP64 is only supported in hardware on a subset of the Terascale chips.

Am I correct that among EG/NI, those are Cypress/Hemlock, Cayman and Aruba? Those chips have FeatureFMA enabled in LLVM, and according to the ISA documentation, FP32 FMA is present if FP64 operations are supported, and also the R600g PIPE_CAP_DOUBLES query code, while returning 1 for all EG/NI chips due to the software implementation, has another semi-leftover conditional specifically for those chips. Or are there some additions/exception to this?

And is there a list of R6xx/R7xx chips supporting double-precision operations? I'm unable to locate any official documentation for this unfortunately, the closest I was able to find is two somewhat contradictory statements in the OpenCL programming guide saying that "double-precision is only supported on the AMD Radeon™ HD69XX devices", yet "a Cypress device can perform two double-precision ADD operations/cycle in each stream core", and R6xx/R7xx don't have FP32 FMA that's tied to FP64 availability in later generations, so LLVM's FeatureFMA doesn't cover them.

[qarium]

EOL is hyperbole. There's a lot of great games that were released on DX9, including Dark Souls 1 & 2. The originals not the HD versions. Even games like Mass Effect 1,2,3 and Dead Space were recently remade, but the originals still hold up. I don't think people realize how many great games were released on DX9. This is more towards people who have no need to upgrade, or financially can't afford to do so. You're still better off using these GPU's on Windows 10/11 due to the lack of proper DX11 support. Without Vulkan it'll be difficult to give someone a reason to switch over to Linux. GCN and up cards work perfectly fine. Older TeraScale DX10 based GPU's have great OpenGL support and Gallium Nine. It's the DX11 TeraScale GPU's that get screwed.

you are right dx9 games are great. but do you really think one has to run them on dx10 hardware or older ?
from a technical point of view these 14-16 year old cards because of the age have many technical problems from the electronic point of view.
i can say for all the computers i do support i removed all systems older than 12 years from service.

see it like this i have a HD6870 not in use i can give it away for free... 0€ and if you watch ebay cards like these go for 1€

this leaves only noebooks/laptops who can not replace the gpu ...

or do you think you need to run on dx9/dx10 class hardware if you can get a better dx11 card for 0€ ?

[Dukenukemx]

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 ,

EOL is hyperbole. There's a lot of great games that were released on DX9, including Dark Souls 1 & 2. The originals not the HD versions. Even games like Mass Effect 1,2,3 and Dead Space were recently remade, but the originals still hold up. I don't think people realize how many great games were released on DX9. This is more towards people who have no need to upgrade, or financially can't afford to do so. You're still better off using these GPU's on Windows 10/11 due to the lack of proper DX11 support. Without Vulkan it'll be difficult to give someone a reason to switch over to Linux. GCN and up cards work perfectly fine. Older TeraScale DX10 based GPU's have great OpenGL support and Gallium Nine. It's the DX11 TeraScale GPU's that get screwed.

[qarium]

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 ,

[qarium]

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.

[Dukenukemx]

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.

[Dukenukemx]

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.

[Triang3l]

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.

[agd5f]

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.