R600g "Soft" FP64 Shows Signs Of Life, Enabling Older GPUs To Have OpenGL 4 In 2018

[duby229]

Or more likely to succeed, send in a mesa patch for drirc that implements the application profile hack to force the override automatically. (since apparently 4.3COMPAT does work)

Yeah, that's true. But just for me personally I have some moral problems with that. Just for example that is -the- reason Unigine keeps releasing broken demo's.

[TumultuousUnicorn]

Forcing 4.3 doesn't allow to run genymotion for example, it crashes instantly, but 4.3COMPAT does run it.

I can confirm 4.3COMPAT doesn't solve my issue.

Assertion failed: (Config.Shaders[CrossCompiler::SHADER_STAGE_VERTEX].Resource == 0) != (Config.Shaders[CrossCompiler::SHADER_STAGE_COMPUTE].Resource == 0) [File:C:\UE4_16_3\Engine\UnrealEngine-4.16.3-release\Engine\Source\Runtime\OpenGLDrv\Private\OpenGLShaders.cpp] [Line: 1737]

[smitty3268]

As already said, it implements a compatibility profile, which mesa will never support. The only option is to contact them and try to explain why compatibility profiles will never be supported. That way they can fix their own code.

Or more likely to succeed, send in a mesa patch for drirc that implements the application profile hack to force the override automatically. (since apparently 4.3COMPAT does work)

[marvin42]

What exactly do you mean? The document you are linking to is from 2010. OpenGL defines tesselation shaders. and R600 supports them.

fp64 was also supported if the hw supported it. Unfortunately, older hw does not support it, hence the software emulation. The same holds for tessellation. No support on older hw, but maybe software emu possible.

[duby229]

Forcing 4.3 doesn't allow to run genymotion for example, it crashes instantly, but 4.3COMPAT does run it.

As already said, it implements a compatibility profile, which mesa will never support. The only option is to contact them and try to explain why compatibility profiles will never be supported. That way they can fix their own code.

[leipero]

Yes, 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.

Forcing 4.3 doesn't allow to run genymotion for example, it crashes instantly, but 4.3COMPAT does run it.

[duby229]

I disagree. Only reason for sw fp64 are conformance with OpenGL 4.whateveritwas. You're not expected to use it ever

Yes exactly. At the time when r600g was being developed clover was supposed to be the corresponding OpenCL implementation. Unfortunately that implementation didn't work well. So really the only good reason for this is to knock it off the feature list so a higher GL status can be achieved.

[nanonyme]

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.

I disagree. Only reason for sw fp64 are conformance with OpenGL 4.whateveritwas. You're not expected to use it ever

[schmidtbag]

The soft FP64 support is implemented in GLSL so on the GPU.

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.

Thanks for the clarifications. I guess for the time being I won't be depending on these drivers for OpenCL for a while. That's fine though - fglrx's OpenCL performance is still pretty good.

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.

AMD's hardware isn't that bad with FP64. From my research, most mid range or higher GCN models are 1/32 at the worst, but most are better. I have a HD 7770 that I think is 1/16, which is pretty decent for a mid-range consumer-level GPU. I have a FirePro V7900 that from my recollection has 1/8 FP64. Despite being 7 years old, that GPU still outperforms modern GPUs that are more power hungry than it. It crunches through milkyway@home workloads in about 2.5 minutes, sometimes even less than 2 minutes.

[orome]

A couple questions:
1. Will this reflect OpenCL? Keep in mind, compute tasks are what demand FP64 the most.

No. OpenCL uses different compiler (LLVM), even native fp64 for pre-GCN asics that support it is missing. GL compute shaders should work though.

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.

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.

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.

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.