Originally posted by marvin42
View Post
Announcement
Collapse
No announcement yet.
R600g "Soft" FP64 Shows Signs Of Life, Enabling Older GPUs To Have OpenGL 4 In 2018
Collapse
X
-
A couple questions:
1. Will this reflect OpenCL? Keep in mind, compute tasks are what demand FP64 the most.
2. What exactly is processing the FP64? Is the CPU taking the load? Because if so, I imagine the performance would be so bad that you might as well just use SWR, softpipe, llvmpipe, or whatever. Though, I suppose that also depends on the task being calculated.
If Arlie can manage to get R600 to have at least 1/16 FP64 performance, that'd be incredible. That'd breathe new life in some of this old hardware I have currently running on fglrx.
Comment
-
Originally posted by schmidtbag View PostA couple questions:
1. Will this reflect OpenCL? Keep in mind, compute tasks are what demand FP64 the most.
2. What exactly is processing the FP64? Is the CPU taking the load? Because if so, I imagine the performance would be so bad that you might as well just use SWR, softpipe, llvmpipe, or whatever. Though, I suppose that also depends on the task being calculated.
If Arlie can manage to get R600 to have at least 1/16 FP64 performance, that'd be incredible. That'd breathe new life in some of this old hardware I have currently running on fglrx.Michael Larabel
https://www.michaellarabel.com/
Comment
-
Originally posted by Michael View Post
It would be mostly useless if someone spent all that effort to do a Vulkan driver for HD 5000/6000 since most games have a GL renderer complementing Vulkan (even with RADV right now it still generally trails RadeonSI performance and any older Vulkan driver would see even less work than RADV so would likely be much slower than R600g) and any Vulkan-only game likely is too demanding for running on HD 5000/6000 class hardware.
Comment
-
Originally posted by schmidtbag View PostA couple questions:
1. Will this reflect OpenCL? Keep in mind, compute tasks are what demand FP64 the most.
Originally posted by schmidtbag View Post2. What exactly is processing the FP64? Is the CPU taking the load? Because if so, I imagine the performance would be so bad that you might as well just use SWR, softpipe, llvmpipe, or whatever. Though, I suppose that also depends on the task being calculated.
Originally posted by schmidtbag View PostIf Arlie can manage to get R600 to have at least 1/16 FP64 performance, that'd be incredible. That'd breathe new life in some of this old hardware I have currently running on fglrx.
all in all, sw fp64 will be there to enable rare use of fp64. Any shader that uses fp64 heavily will be likely 100-1000x slower.Last edited by orome; 19 January 2018, 11:11 AM.
- Likes 3
Comment
-
Originally posted by Michael View PostThe soft FP64 support is implemented in GLSL so on the GPU.Originally posted by orome View PostNo. OpenCL uses different compiler (LLVM), even native fp64 for pre-GCN asics that support it is missing. GL compute shaders should work though.
it's running on the GPU using integer instructions to implement the operations. I.e. instead of using one fp64 instruction it'll use dozens integer instructions.
That would make him a magician. AMD hw usually has between 1/16 to 1/64 fp64 performance in HW. It means that the same operation (single instruction) takes 64x longer for DP. Moreover, most advanced operations (log, exp, ...) only have fp32 instructions, so the entire operation needs to be implemented in SW for fp64, that usually means 100s of GPU instructions.
- Likes 2
Comment
-
Originally posted by orome View Post
No. OpenCL uses different compiler (LLVM), even native fp64 for pre-GCN asics that support it is missing. GL compute shaders should work though.
it's running on the GPU using integer instructions to implement the operations. I.e. instead of using one fp64 instruction it'll use dozens integer instructions.
That would make him a magician. AMD hw usually has between 1/16 to 1/64 fp64 performance in HW. It means that the same operation (single instruction) takes 64x longer for DP. Moreover, most advanced operations (log, exp, ...) only have fp32 instructions, so the entire operation needs to be implemented in SW for fp64, that usually means 100s of GPU instructions.
all in all, sw fp64 will be there to enable rare use of fp64. Any shader that uses fp64 heavily will be likely 100-1000x slower.
- Likes 3
Comment
-
Originally posted by nanonyme View Post
I disagree. Only reason for sw fp64 are conformance with OpenGL 4.whateveritwas. You're not expected to use it ever
Comment
-
Originally posted by Xorg View PostYes, that's my case. But, unfortunately, forcing OpenGL 4.3 doesn't allow me to run CAT Interstellar on Steam. Time has come to change my video card, I hope Navi will rocks.
Comment
-
Originally posted by leipero View Post
Forcing 4.3 doesn't allow to run genymotion for example, it crashes instantly, but 4.3COMPAT does run it.
- Likes 3
Comment
Comment