AMD R600g Is Making Progress With Tessellation, Running Heaven

[Guest]

Yes, Metro 2033 and Last Light Redux play nice with the free driver. But they don't let me change options inside the game, only that stupid quality bar. The other graphical options freeze the game and then go back to the previous state.

Settings are stored in ~/.steam/root/steamapps/common/Metro 2033 Redux/110000106d2b5d5/user.cfg

[przemoli]

It is possible, Catalyst does something like it. Developers just don't think it's a high priority issue. (It truly isn't from their point of view.)

Not only Catalyst. Intel Windows driver, Nvidia driver too.

[eydee]

If the only missing feature is fp64 (assuming the game doesn't actually use it) can't you just force a GL level over-ride either manually or via drirc ?

There is a bug in Steam that it segfaults if the GL version is globally overriden. Instead, open Steam, right click your game, select properties, then set launch options. Type "MESA_GL_VERSION_OVERRIDE=4.1FC MESA_GLSL_VERSION_OVERRIDE=410 %command%" into the field. This is how I got the mentioned GL4 games to run.

[asdfblah]

If softpipe/llvmpipe had tess, we would have fp64 emulation, right?

[darkbasic]

If softpipe/llvmpipe had tess, we would have fp64 emulation, right?

No. (Stupid char limit)

[asdfblah]

No. (Stupid char limit)

Oh, wait, nevermind, I confused different features... Anyway, if fp64 in softpipe/llvmpipe is already done (according to mesamatrix.net ), why not use that?

[smitty3268]

Oh, wait, nevermind, I confused different features... Anyway, if fp64 in softpipe/llvmpipe is already done (according to mesamatrix.net ), why not use that?

This has been gone over a lot of times before.

You don't want to fall back to CPU emulation for fp64 support, when the GPUs can do it themselves. (Not natively, but the GPU can use f32 instructions to emulate f64 instructions - that's much faster than doing it on the CPU, and dragging everything else related to that shader also to be on the CPU just because it had a 64bit instruction in it at one place)

[eydee]

This has been gone over a lot of times before.

You don't want to fall back to CPU emulation for fp64 support, when the GPUs can do it themselves. (Not natively, but the GPU can use f32 instructions to emulate f64 instructions - that's much faster than doing it on the CPU, and dragging everything else related to that shader also to be on the CPU just because it had a 64bit instruction in it at one place)

There could be some fallback until the real thing is implemented though. Some applications might not need high speed, only the ability to run.

[airlied]

There could be some fallback until the real thing is implemented though. Some applications might not need high speed, only the ability to run.

Then those apps can use llvmpipe directly. It just doesn't make any sense what you propose to try and run one shader in software on the CPU. The answer that makes sense is to write fp64 on fp32 support for r600g, nothing else is even worth the thought process.

[eydee]

Then those apps can use llvmpipe directly. It just doesn't make any sense what you propose to try and run one shader in software on the CPU. The answer that makes sense is to write fp64 on fp32 support for r600g, nothing else is even worth the thought process.

It doesn't work like that. Mesa/Radeon is a developing framework trying to catch up with existing applications and mimicing what proprietary code has been doing for years. Programs using Opengl already exist and the requirements are already written. What Mesa can do is fulfilling them, or fooling the program to believe in this. Or stay behind. Programs won't be patched.

This can change in the future, when developers accept it and officially support it. This is very rarely the case in the present and won't change in the near future.